Hi
On Wed, Oct 09, 2013 at 02:51:17PM -0700, Ross Boylan wrote:
> I was a little surprised to find that I needed to quote my variable
> definitions in /etc/default, at least for nfs-kernel-server.
> RPCMOUNTDOPTS="--manage-gids --no-nfs-version 4"
> works, but
> RPCMOUNTDOPTS=--manage-gids --no-nfs-version 4
> produces
> # /etc/init.d/nfs-kernel-server restart
> /etc/default/nfs-kernel-server: line 12: --no-nfs-version: command not
> found
>
> Is it generally the case that multi-word arguments should be quoted
> in /etc/default?
Yes. Generally (perhaps always?) the files in /etc/default are shell
script fragments which are sourced (a.k.a. "dotted") by the init
script. Hence they have to obey the normal shell syntax.
In the case of nfs-kernel-server, my version [1] has:
DEFAULTFILE=/etc/default/nfs-kernel-server
...
if [ -f $DEFAULTFILE ]; then
. $DEFAULTFILE
fi
In a shell script, the first word will normally be the command
name. However, it is fully valid to set environment variables on the
same line which only take effect for that one command. E.g.:
LC_ALL=C sort < /etc/passwd
In your case (without the quotes):
RPCMOUNTDOPTS=--manage-gids --no-nfs-version 4
gets interpreted as "set the environment variable RPCMOUNTDOPTS to
'--manage-gids' while executing the command '--no-nfs-version' with a
single parameter of '4'".
> /etc/init.d/nfs-kernel-server includes
> start-stop-daemon --start --oknodo --quiet \
> --exec $PREFIX/sbin/rpc.mountd -- $RPCMOUNTDOPTS
> I don't see -- mentioned in the man page for start-stop-daemon or
> rpc.mountd.
The same is the version for my version (!).
Generally, most commands use getopt or getopts for parsing parameter[2],
and thus allows for the '--' special parameter to denote "no further
flags" - thus the remaining parameters will not be interpreted as
flags.
E.g. If you have a troublesome file named "-f", it can be removed by:
rm -- -f
Without the "--" notation, the "rm" command would interpret "-f" as a
flag, not as the name of a file to be removed.
The '--' parameter rises to prominence when you have commands which
act as "wrappers" for other commands, but the wrappers need to accept
options: They need some way of telling which options are for the
wrapper and which ones are for the wrapped command.
Examples of this that I can think of off the top of my head are
start-stop-daemon (obviously), xargs, time, su, rsh, ssh, sudo,
tsocks, sockify, and flock. And there are probably lots of others
obvious examples to embarrass me.
Similarly, many "young ones" can be caught out if a directory contains
a file "-i":
root@remover:~# ls -l
total 0
-rw-r--r-- 1 root root 0 Oct 9 22:08 -i
-rw-r--r-- 1 root root 0 Oct 9 22:09 bar
-rw-r--r-- 1 root root 0 Oct 9 22:09 foo
root@remover:~# rm *
rm: remove regular empty file `bar'? n
rm: remove regular empty file `foo'? n
where the first file named "-i" gets interpreted as an option to the
rm command, rather than a filename to remove.
Hope this helps
[1] Your version may be different, but likely to be similar enough to
illustrate the point
[2] http://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html
IIRC this is a POSIX standard too, but I may be wrong.
--
Karl E. Jorgensen
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131009221923.GA26819@hawking
