The organization of configuration files is much less uniform than your questions seem to imply. There is no "class", there is no "hierarchy", and there is no global "configuration czar" nor committee that decrees a common syntax or other nice clean generalizations like the ones you are seeking. There is only a multitude of separate applications like R
, bash
, screen
and the GNOME desktop environment, all of whom have their own ways of doing things, so you should look at the documentation for each individual program to answer any specific questions about a particular file. If it seems ad-hoc, that's because it is: most of Unix / Linux software out there was developed for different purposes by different people who all went about configuration slightly differently.
To answer your other questions pointwise:
*rc
and *profile
do not mean very much, so this question can't really be answered. "rc" is merely a commonly used abbreviation or suffix for configuration files. Its etymology goes back to ancient times (in computer years), and probably means run commands (from runcom). Just because applications use the same word does not mean they agree on conventions. "profile" is a much less common suffix.
Define "scope". Most applications do not share configuration files with other non-related applications. The one possible exception is /etc/profile
and .profile
, which may be used by multiple different shells (including at least sh
and bash
). There is something called an environment associated with every running process which can contain variables that may affect the behavior of said process. Generally, environment variables are set by the appropriate shell configuration files, or perhaps the configuration files of whatever graphical desktop environment you are using. There are also configuration files for "libraries", like .inputrc
for readline and .gtkrc*
for GTK, which will affect every application that uses the library.
No, there is no global hierarchy for configuration files. Again, refer to the documentation for the specific program in question, for example, the bash
manual for bash
. A general convention you can usually rely on is that user settings in $HOME
override system-wide configuration in /etc
. This is typically accomplished by reading the user file after the system one, so that later settings overwrite earlier ones. However, this is not a guarantee, and for definitive answers you should refer to the documentation for the specific program you are using.
There is no "class", at least none general enough to encompass all the files you've listed in your question, so the question of a reference for such a "class" is moot. Again, refer to the documentation of the specific program you are using.
POSIXly, the parsing for options should stop at --
or at the first non-option (or non-option-argument) argument whichever comes first. So in
cp -R file1 -t /mybackup file2 -f
that's at file1
, so cp
should recursively copy all of file1
, -t
, /mybackup
and file2
into the -f
directory.
GNU getopt(3)
however (that GNU cp
uses to parse options (and here you're using GNU cp
since you're using the GNU-specific -t
option)), unless the $POSIXLY_CORRECT
environment variable is set, accepts options after arguments. So it is actually equivalent to POSIX option style parsing's:
cp -R -t /mybackup -f -- file1 file2
The getopts
shell built-in, even in the GNU shell (bash
) only handles the POSIX style. It also doesn't support long options or options with optional arguments.
If you want to parse the options the same way as GNU cp
does, you'll need to use the GNU getopt(3)
API. For that, if on Linux, you can use the enhanced getopt
utility from util-linux
(that enhanced version of the getopt
command has also been ported to some other Unices like FreeBSD).
That getopt
will rearrange the options in a canonical way which allows you to parse it simply with a while/case
loop.
$ getopt -n "$0" -o t:Rf -- -Rf file1 -t/mybackup file2
-R -f -t '/mybackup' -- 'file1' 'file2'
You'd typically use it as:
parsed_options=$(
getopt -n "$0" -o t:Rf -- "$@"
) || exit
eval "set -- $parsed_options"
while [ "$#" -gt 0 ]; do
case $1 in
(-[Rf]) shift;;
(-t) shift 2;;
(--) shift; break;;
(*) exit 1 # should never be reached.
esac
done
echo "Now, the arguments are $*"
Also note that that getopt
will parse options the same way as GNU cp
does. In particular, it supports the long options (and entering them abbreviated) and honours the $POSIXLY_CORRECT
environment variables (which when set disables support for options after arguments) the same way GNU cp
does.
Note that using gdb and printing the arguments that getopt_long()
receives can help building the parameters to getopt(1)
:
(gdb) bt
#0 getopt_long (argc=2, argv=0x7fffffffdae8, options=0x4171a6 "abdfHilLnprst:uvxPRS:T", long_options=0x417c20, opt_index=0x0) at getopt1.c:64
(gdb) set print pretty on
(gdb) p *long_options@40
$10 = {{
name = 0x4171fb "archive",
has_arg = 0,
flag = 0x0,
val = 97
}, {
name = 0x417203 "attributes-only",
[...]
Then you can use getopt
as:
getopt -n cp -o abdfHilLnprst:uvxPRS:T -l archive... -- "$@"
Remember that GNU cp
's list of supported options may change from one version to the next and that getopt
will not be able to check if you pass a legal value to the --sparse
option for instance.
Best Answer
What you're doing should work. But bash turns off the
errexit
option in command substitutions, so it preserves all the options except this one. This is specific to bash and specific to theerrexit
option. Bash does preserveerrexit
when running in POSIX mode. Since bash 4.4, bash also doesn't clearerrexit
in a command substitution ifshopt -s inherit_errexit
is in effect.Since the option is turned off before any code runs inside the command substitution, you have to check it outside.
If you don't like this complexity, use zsh instead.