| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The busybox-w32 shell initialises HOME when it starts. However,
if applets are run outside the environment provided by the shell
they may find HOME is unset. This caused a problem for 'vi' as
it was unable to locate its .exrc.
If HOME isn't available in the environment make getenv(3) provide
a sensible default value. The shell must use the *real* getenv(3)
when determining if HOME is already set.
Also, unrelated to the above, the shell shouldn't treat failure of
getpwuid(3) as a fatal error.
Costs 72-80 bytes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It appears the CRT and OS each have a copy of the environment.
mingw_putenv() fools the CRT into accepting an empty environment
variable by calling _putenv("V=0") then truncating the new value
by hand. But _putenv() also updates the OS environment with the
fake 'V=0' value. Commit 5b48ca53b (win32: pass NULL to spawnve,
not environ) resulted in this fake value being used and hence empty
variables getting the value '0'.
- Add a call to SetEnvironmentVariable() in mingw_putenv() to update
the OS environment.
- Restore the use of NULL environment pointers in mingw_spawnvp().
- Add a test.
(GitHub issue #250)
|
| |
|
|
|
|
|
|
|
|
| |
Revert the change to mingw_putenv() in the previous commit.
When compiling for MSVCRT (i.e. not for UCRT) revert some of the
changes from commit 5b48ca53b (win32: pass NULL to spawnve, not
environ).
(GitHub issue #250)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows environment variables: a never-ending source of fun.
It seems the recent hack to work around problems in UCRT breaks
the hack to set empty environment variables. The change to the
empty variable isn't reflected in the environment seen by the C
runtime.
Use the WIN32 API to set the empty variable then set a dummy
variable to make the C runtime take notice.
(GitHub issue #250)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WIN32 _putenv() can't set an environment variable with an empty
value because 'NAME=' is treated as a request to delete the variable.
Allow mingw_putenv() to set an empty value by first setting a fake
value and then truncating it.
This problem has always been present in mingw_putenv() but it became
particularly pressing when ash started treating all applets as NOEXEC.
The environment of NOEXEC applets is created by clearing the current
environment and using putenv() to set a new one from the shell
variables. Empty variable were not being set.
See GitHub issue #197.
|
| |
|
|
|
|
|
|
| |
Use xasprintf() to create string in unsetenv().
Clarify when we're using WIN32 _putenv().
No change in functionality; saves 16 bytes.
|
| |
|
|
|
|
|
|
|
|
|
| |
It turns out that with the new toolchain safe API calls work on all
all platforms. Even the original code from commit fa147bd7e works
on Windows XP when built with the new tools.
- Remove the unsafe environment manipulation via the environ array
- Microsoft's putenv takes a copy of its argument so the string
can be freed
- Rewrite some routines and add more error checking
|
| |
|
|
|
| |
The functions copy_environ and free_environ became unused following
commit ac181bf54 "win32: simplify spawning applets".
|
| |
|
|
|
|
|
|
|
|
|
| |
Commit fa147bd 'Use putenv to implement unsetenv/clearenv' allowed
BusyBox to run on ReactOS but broke it on Windows XP so it was
reverted.
It turns out that the same change is required on 64-bit Windows.
Reinstate the 'safe' environment manipulation code but make it a
configuration option. Add a config file for 64-bit Windows that
does the right thing.
|
| |
|
|
| |
This reverts commit fa147bd7ecb086f4fb9a4afea16b946693a822ce.
|
| |
|
|
|
|
|
|
|
|
| |
noexec applets failed on ReactOS 0.3.17. This was because the
environment was being manipulated directly using the environ pointer.
Implementing unsetenv and clearenv using putenv fixes the problem.
WIN32 putenv doesn't allow environment variables to have empty
values. This was the case before and it's still the case after
this change. Shell variables are fine.
|
| | |
|
| | |
|
|
|
clearenv() is not supported yet.
|
