Timeline for Newlines in environment variable names under POSIX sh
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 8 at 15:10 | comment | added | Peter Cordes | @ilkkachu: I'd assume Linus does have a strong opinion that it's a stupid idea to use super-weird filenames (and wouldn't accept a pull request which added any to the Linux kernel source code, for example), but that's a different position than saying the kernel shouldn't even allow it. \@Gyro is presumably taking that out of context, or chiming in with an off-topic comment if they agree with me that it's just Linus's hyperbolic writing style to write it as a commandment, not an actual proposed standard. | |
| Sep 8 at 10:15 | comment | added | ilkkachu | @GyroGearloose, and, again, the Linux kernel, that one piece of software Linus has most influence in, allows arbitrary filenames, so it seems the Man doesn't really have that strong an opinion on the matter. | |
| Sep 8 at 6:33 | comment | added | Peter Cordes | @GyroGearloose: I generally agree with Linus's sentiment that it's a bad idea to create filename and directories with embedded newlines, since it makes life inconvenient for using one-off shell commands interactively on your own machine. (And tab programmable-completion stuff is often sloppy, even with commas, colons, and sometimes even spaces.) But that's irrelevant to this question, about what the POSIX standard says about what shells should do with weird environment strings. Being a bad idea doesn't stop something from being allowed. | |
| Sep 7 at 14:08 | history | became hot network question | |||
| Sep 7 at 4:23 | comment | added | Gyro Gearloose | @ilkkachu Yes, but he is one of the most well-known fiigurs today in the nx-univers. | |
| Sep 7 at 1:02 | comment | added | user10489 | I'm not saying how or why applications should filter their inputs, just that they should. It's up to the application to make sure its input data is handled in a safe way. | |
| Sep 6 at 20:55 | answer | added | ilkkachu | timeline score: 6 | |
| Sep 6 at 20:45 | comment | added | ilkkachu | @GyroGearloose, Linus might have a say about how things are done by the Linux kernel, but not all of Unix-land is Linux. He's not god or king and he can't make e.g. the BSDs or commercial Unixen do things his way. Also, even the Linux kernel quite happily accepts pretty much any binary string in filenames. You might consider putting down the book you found those commandments in... | |
| Sep 6 at 20:42 | comment | added | ilkkachu | @user10489, so does the fact that filenames can contain any characters (witness the myriad scripts that assume otherwise), and yet they still can. There's no-one to force a change that would forbid them. | |
| Sep 6 at 20:28 | comment | added | user10489 | Maybe this is obvious, but it needs to be said. The unlimited acceptance of characters in environment variable names and values poses a security risk, especially to shells, although maybe less so for applications. Obviously, every application (including the shell) needs to filter both names and values for security risks before using them. | |
| Sep 6 at 16:40 | comment | added | cas | Sorry, i meant one of the Related links Why do env var=value allow arbitrary name in var?. Which has now become a Linked question due to this comment. | |
| Sep 6 at 16:32 | comment | added | cas | it depends on the shell. as the linked answer says, many (most?) don't even import them, let alone re-export them. Some do. Bash does (or at least did at the time of that question, it's not something I care enough about to find out the current state. I just really dislike personal preferences and opinions, especially misguided ones, being stated as if they're holy commandments). Also, shells aren't the only things that exec other programs. | |
| Sep 6 at 16:24 | comment | added | muru | @cas I agree on everything you say, but on that last point: isn't the question here about children of shells? That is, will something started directly by a POSIX shell ever see an env var with a newline in the name? Even if there were some tool that started the shell the with such an env var, it looks like the child processes of that shell wouldn't see it. (Those processes might in turn add such env vars, but then that goes beyond the scope here.) | |
| Sep 6 at 16:19 | comment | added | cas | Also, as @emron's C code showed, shells are not the only source of environment variables. Pretty much every language has some trivial method to export them to the environment of child processes. And shells can obviously be child processes that inherit annoyingly-named variables from parent processes. | |
| Sep 6 at 16:18 | comment | added | cas | You certainly shouldn't ignore, or deliberately sabotage, parts of a spec just because you don't like them or think they're too much trouble. Every character except NUL is valid in a pathname. Every character except NUL and / is valid in a filename. The posix spec allows newlines and other "annoying" characters in environment variable names and requires that applications "tolerate the presence of such names". If you fail to do that, it's not the file or variable names that are at fault, it's you and your code. | |
| Sep 6 at 16:14 | comment | added | cas | Rather than be overly judgemental and label things as abominations like a wild-eyed zealot, it's far better and far more useful to strive to put Postel's Law into practice with every piece of code you write. Postel's Law is also known as the Robustness Principle and can be summarised as: "be conservative in what you send, be liberal in what you accept". While it needs to be applied with caution, it is a good part of the reason why the internet exists and doesn't suck anywhere near as much as it could, and why interoperability is possible. | |
| Sep 6 at 15:15 | comment | added | Gyro Gearloose | There is a command "set" (looking for keyword "set" on the internet is bound to fail). And, we are on unix/linux: any indecent characters in filenames or, even more, in variable names or commands, are an abomination onto Linus: don't do it, and curse those that poison you with such contaminated names. | |
| Sep 6 at 14:54 | history | asked | emron | CC BY-SA 4.0 |