3 ms·

Some reasons: — It is possible to “see” a command line (in "ps" output, etc.) in ways that you won’t see environment settings. This can be useful when passing

Some reasons: — It is possible to “see” a command line (in "ps" output, etc.) in ways that you won’t see environment settings. This can be useful when passing information to a sub-process that you need to keep private. — It may be that you are configuring your sub-process in a place that is “far away” from the point that actually executes the command. Rather than have to thread an extra command-line argument through your code to make sure it is part of the final command invocation, it can be quite convenient to just set a variable. I have often used this to enable debugging features or test experimental features, or even to disable entire features when unexpected problems arise. — In a similar way, your program may use multiple languages or otherwise be difficult to manage in any common way without environment variables. — In a cross-platform scenario, environment variable names might be far easier to keep constant across UNIX, Windows, etc. than command-line syntax. I’m sure there are other reasons.

Someone 10y ago
I don't see any argument for having arguments there, and that is what the OP asked for. One argument for having command-line arguments is that it can be less typing, as argument names can be implied. Compare: >cp foo bar with >from=foo to=bar cp It also seems easier to me to specify multiple arguments from the command line, but that probably could be solved (mostly) by changing sh syntax.
- grymoire1 10y ago
  The POSIX shell has nothing to do with the syntax of the command. You can write a shell script that can parses cp from=foo to=bar if you wanted to. The shell expands metacharacters and variables, and sets up STDIN/STDOUT. But = is not a meta-character, so it is pased to the command unchanged. Several UNIX commands use that sort of syntax - like dd(1).
  - makecheck 10y ago
    With the "env" command it’s possible to set environment using key=value for anything (it just means you have to say "env a=x b=y cmd -arg1 -arg2" instead of expecting "cmd a=x b=y -arg1 -arg2" to be valid).
- tene 10y ago
  The main argument, to me, for command-line arguments is that they're not automatically inherited by child processes like environment variables are, so you don't have to rely on every process tidying up its environment before executing anything else. To me, that just seems like a recipe for heisenbugs and spooky-action-at-a-distance.
tene 10y ago
You may already be aware of this, but it's trivial to read a process's environment variables, for any process running as the same user, or when root. They're exposed as a null-delimited text file in /proc/$pid/environ. You can even get ps to print the environment variable for you, if you use the 'e' flag (no leading dash). Depending on your actual security constraints, this may be important to be aware of. Of course, there are a variety of options for reading a process's arbitrary memory locations, so for actual security you need to control accesss to the host, but if you're worried about leaking 'ps' for command line arguments, you should be similarly aware about 'ps' showing environment variables.
- mnarayan01 10y ago
  "Usually" permissions on /proc/$pid/environ are way more restrictive than on /proc/$pid/cmdline.
  - tene 10y ago
    Yep, that's why I mentioned "as the same user". It's slightly less of a risk of data exposure, but it's worth being aware of when evaluating your threat model.

Someone 10y ago

I don't see any argument for having arguments there, and that is what the OP asked for. One argument for having command-line arguments is that it can be less typing, as argument names can be implied. Compare: >cp foo bar with >from=foo to=bar cp It also seems easier to me to specify multiple arguments from the command line, but that probably could be solved (mostly) by changing sh syntax.

grymoire1 10y ago
The POSIX shell has nothing to do with the syntax of the command. You can write a shell script that can parses cp from=foo to=bar if you wanted to. The shell expands metacharacters and variables, and sets up STDIN/STDOUT. But = is not a meta-character, so it is pased to the command unchanged. Several UNIX commands use that sort of syntax - like dd(1).
- makecheck 10y ago
  With the "env" command it’s possible to set environment using key=value for anything (it just means you have to say "env a=x b=y cmd -arg1 -arg2" instead of expecting "cmd a=x b=y -arg1 -arg2" to be valid).
tene 10y ago
The main argument, to me, for command-line arguments is that they're not automatically inherited by child processes like environment variables are, so you don't have to rely on every process tidying up its environment before executing anything else. To me, that just seems like a recipe for heisenbugs and spooky-action-at-a-distance.

tene 10y ago

You may already be aware of this, but it's trivial to read a process's environment variables, for any process running as the same user, or when root. They're exposed as a null-delimited text file in /proc/$pid/environ. You can even get ps to print the environment variable for you, if you use the 'e' flag (no leading dash). Depending on your actual security constraints, this may be important to be aware of. Of course, there are a variety of options for reading a process's arbitrary memory locations, so for actual security you need to control accesss to the host, but if you're worried about leaking 'ps' for command line arguments, you should be similarly aware about 'ps' showing environment variables.

mnarayan01 10y ago
"Usually" permissions on /proc/$pid/environ are way more restrictive than on /proc/$pid/cmdline.
- tene 10y ago
  Yep, that's why I mentioned "as the same user". It's slightly less of a risk of data exposure, but it's worth being aware of when evaluating your threat model.