aboutsummaryrefslogtreecommitdiff
path: root/win32/env.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* win32: provide a default value for HOMERon Yorston2023-01-291-5/+11
| | | | | | | | | | | | | | | | 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.
* win32: better fix for empty environment variablesRon Yorston2022-05-051-0/+4
| | | | | | | | | | | | | | | | | | | 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)
* win32: revert changes related to environment variablesRon Yorston2022-05-041-8/+12
| | | | | | | | | | 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)
* win32: new code to set empty environment variableRon Yorston2022-05-031-12/+8
| | | | | | | | | | | | | | 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: allow putenv() to set empty valuesRon Yorston2020-08-211-4/+18
| | | | | | | | | | | | | | | | 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.
* win32: env.c code shrink and clarificationRon Yorston2020-08-211-7/+6
| | | | | | | | Use xasprintf() to create string in unsetenv(). Clarify when we're using WIN32 _putenv(). No change in functionality; saves 16 bytes.
* win32: always use safe API calls to manipulate environmentRon Yorston2018-02-131-100/+26
| | | | | | | | | | | 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
* win32: remove unused functionsRon Yorston2017-08-231-21/+0
| | | | | The functions copy_environ and free_environ became unused following commit ac181bf54 "win32: simplify spawning applets".
* Allow different ways to manipulate environment for XP vs 64-bitRon Yorston2015-07-031-0/+59
| | | | | | | | | | | 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.
* Revert "Use putenv to implement unsetenv/clearenv"Ron Yorston2014-12-181-46/+11
| | | | This reverts commit fa147bd7ecb086f4fb9a4afea16b946693a822ce.
* Use putenv to implement unsetenv/clearenvRon Yorston2014-11-231-11/+46
| | | | | | | | | | 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.
* win32: add popen implementation that uses shellRon Yorston2012-04-231-1/+3
|
* win32: implement clearenv()Nguyễn Thái Ngọc Duy2010-09-141-1/+10
|
* win32: add getenv(), setenv(), unsetenv() and clearenv()Nguyễn Thái Ngọc Duy2010-09-101-0/+119
clearenv() is not supported yet.