| Summary: | /bin/sh not handling some environment variable | ||
|---|---|---|---|
| Product: | Busybox | Reporter: | Olivier Voortman <olivier.voortman> |
| Component: | Standard Compliance | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | busybox-cvs |
| Priority: | P5 | ||
| Version: | 1.27.x | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | ash: pass environment variables with invalid names to children | ||
|
Description
Olivier Voortman
2017-08-16 12:24:55 UTC
This behaviour was introduced by commit b6838b520 "ash: [VAR] Sanitise environment variable names on entry": https://git.busybox.net/busybox/commit/?id=b6838b520afa8346751577cd7ccbe0b906cd3a52 Seems reasonable for a POSIX shell. Is there any POSIX RFC or documentation that explains what characters are allowed in the environment variable names ? Some apps we used depends on those [] to mimic arrays by doing KEY[0], KEY[1], .. Environment variables are defined here: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08 Environment variable names can contain pretty much anything apart from '='. However, shell variable ('parameter') names are much more restricted. Section 2.3.2 of this document covers parameter expansion: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html and points to the definition of an 'XBD Name': http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_235 where an 'XBD Name' is defined as: In the shell command language, a word consisting solely of underscores, digits, and alphabetics from the portable character set. The first character of a name is not a digit. I understand. Actually, I'm not trying to define a shell variable. I'd like the environment variables defined for /bin/sh to be passed to the sub-process launched without modification/filtering. It appears that even the original Bourne shell works the same way as ash in BusyBox: environment variables are sanitised when imported into the shell and child processes get an environment initialised from the shell variables. I have encountered your requirement before, though. I maintain the busybox-w32 port of BusyBox to Microsoft Windows. Environment variables in Windows have their own foibles: they're case-insensitive and some have names that aren't allowed in the shell though are acceptable to cmd.exe. See, for example, this issue: https://github.com/rmyorston/busybox-w32/issues/43 where a user wanted to access an environment variable named PROGRAMFILES(X86). They also wanted it to be passed to child processes, because Windows binaries expect to find such variables and might break if they can't. My solution was to import the variable with a name (PROGRAMFILES_X86_) that could be used in the shell while retaining the invalid name so that it would be passed to child processes. This last part was broken by the commit mentioned above, though nobody has noticed until now. I'll need to revisit my fix in busybox-w32. However, I'm not sure that something similar would be appropriate in the Unix version of BusyBox. The long history of the existing behaviour has trained Unix users not to put characters in their environment variable names that aren't acceptable to the shell. Created attachment 7206 [details]
ash: pass environment variables with invalid names to children
OK, I'm not saying this is a good idea, but I've made a patch that allows the shell to pass environment variables to its children, even if they have names that aren't acceptable to the shell.
Caveat emptor.
Fixed in git. Thanks! |