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.
To begin with, note that argv[0]
is not necessarily the program name. It is what the caller puts into argv[0]
of the execve
system call (e.g. see this question on Stack Overflow). (All other variants of exec
are not system calls but interfaces to execve
.)
Suppose, for instance, the following (using execl
):
execl("/var/tmp/mybackdoor", "top", NULL);
/var/tmp/mybackdoor
is what is executed but argv[0]
is set to top
, and this is what ps
or (the real) top
would display. See this answer on U&L SE for more on this.
Setting all of this aside: Before the advent of fancy filesystems like /proc
, argv[0]
was the only way for a process to learn about its own name. What would that be good for?
- Several programs customize their behavior depending on the name by which they were called (usually by symbolic or hard links, for example BusyBox's utilities; several more examples are provided in other answers to this question).
- Moreover, services, daemons and other programs that log through syslog often prepend their name to the log entries; without this, event tracking would become next to infeasible.
Best Answer
This blog can help you out.
A small fragment of this blog is here:
Other resources: