Re: Bug#456796: getopt and parameters with spaces
T o n g:
>Package: util-linux
>Version: 2.13-8
>Severity: normal
>Hi,
>I seem to have found a bug of getopt from the util-linux
>package. Please correct me if I'm wrong.
>I believe that the suggested way to call getopt is
> eval set -- `getopt -o <options> -- "$@"`
>But I found that it can't handle parameters with spaces well:
> $ set -- -t 'test p 1' 2
> $ getopt -o t: -- "$@"
> -t 'test p 1' -- '2'
>Ok, so far so good, but:
> $ eval set -- `getopt -o t: -- "$@"`
There is nothing wrong with getopt. As you use command
substitution (`...`) without double quotes, the output of getopt
is scanned for word splitting, thus passing the following
argument list to the eval command (I use «...» here to denote the
distinct arguments):
«set» «--» «-t» «'test» «p» «1'» «--» «'2'»
eval concatenates its arguments into a single string yielding
set -- -t 'test p 1' -- '2'
This string is then read and executed by the shell.
> $ echo "'$2'"
> 'test p 1'
>I.e., the parameter passed is "test p 1", but after the
>parameter parsing, it becomes "test p 1" -- one space missing
>before '1'.
This is what you requested by word splitting and reconcatenation
as shown above.
$ eval set -- "`getopt -o t: -- "$@"`"
or
$ eval "set -- `getopt -o t: -- "$@"`"
or
$ eval 'set -- '"`getopt -o t: -- "$@"`"
and so on are the right thing.
>Comment?
Write 100 times
"I won't any more use parameter invocation (${name}) and
command substitution (`...` or $(...)) without double quotes
("..."), unless I really want word splitting or pathname
expansion."
(But don't use cut and paste! (:-))
I wish eval would only accept exactly one argument string; then
your mistake would have shown up as something like:
eval: superfluous arguments specified
debian-user@lists.debian.org.
--
Bitte in die Adressierung auch meinen |Please put my full name also into
Vor- u. Nachnamen stellen z.B. |the recipient like
Friedhelm Waitzmann <xxx@example>, (Friedhelm Waitzmann) xxx@example,
"Waitzmann, Friedhelm" <xxx@example>
Reply to: