There are no fast and firm rules, or even common conventions. At most, there are a few options that are used consistently across some common utilities — but not across all common utilities.
Here are a few common letters — but remember that these are by no means universal conventions. If you have one of the features described below, it's better if you use the corresponding option. If one of the options doesn't make sense for your utility, feel free to use it for something else.
-c COMMAND
or -e COMMAND
: execute a command. Examples: sh -c
, perl -e
.
-d
or -D
: debug.
-f
: force, don't ask for confirmation for dangerous actions.
-h
: help — but many utilities only recognize the long option --help
or nothing at all. Examples: Linux getfacl
, mount
. Counter-examples: GNU ls
, du
, df
(no short option, -h
is human size), less
(-?
is help, -h
is something else).
-i
: prompt for confirmation (interactive).
-n
: do not act, just print what would be done. Example: make
.
-r
or -R
: recursive.
-q
or -s
: quiet or silent. Example: grep -q
means display no output, grep -s
means display no error message.
-v
: verbose.
-V
: show version information.
Traditionally lowercase letters are used, and uppercase letters only came into use because there are only 26 lowercase letters. Sometimes uppercase letters have something to do with the corresponding lowercase letter (example: GNU grep -h/-H
, ssh -x/-X
, cp -r/-R
), sometimes not.
There is no standard way to retrieve the list of configuration variables that are supported on a system. If you program for a given POSIX version, the list in that version of the POSIX specification is your reference list. On Linux, getconf -a
lists all available variable.
fpathconf
isn't specific to PATH. It's about variables that are related to files, which are the ones that may vary from file to file.
Regarding ARG_MAX
on Linux, the rationale for depending on the stack size is that the arguments end up on the stack, so there had better be enough room for them plus everything else that must fit. Most other implementations (including older versions of Linux) have a fixed size.
Most limits go together with resource availability, with different resources depending on the limit. For example, a process may be unable to open a file even if it has fewer than OPEN_MAX
files open, if the system is out of memory that can be used for the file-related data.
Linux is POSIX-compliant on this point by default, so I don't know where you're getting at.
If you use ulimit -s
to restrict the stack size to less than ARG_MAX
, you're making the system no longer compliant. A POSIX system can typically be made non-compliant in any number of ways, including PATH=/nowhere
(making all standard utilities unavailable) or rm -rf /
.
The value of ARG_MAX
in limits.h
provides a minimum that applications can rely on. A POSIX-compliant system is allowed to let execve
succeed even if the arguments exceed that size. The guarantee related to ARG_MAX
is that if the arguments fit in that size then execve
will not fail due E2BIG
.
Best Answer
A guarantee: