Package: lsb-base
Version: 3.1-22
Severity: important
The problem arose in the use of the start_daemon function in
/etc/init.d/sleepd (from the sleepd package). The sleepd daemon has a -F
parameter which can take spaces. This is not unlike other applications
(such as bash!) which can take parameters with spaces, like -c.
Assuming the configuration infrastructure that requires parameters to
sleepd to reside in /etc/default/sleepd, I see a problem. This PARAMS
environment variable must somehow encode a command line parameter which
can have spaces. Absent re-writing the sleepd to read its configuration
from a file, how would you encode the PARAMS environment variable to
work in this case? As you state, it's quite clear that quotes in the
variable value are only printable characters - they're not performing
the function you expect them to if they were actually on the command
line. Eval, however, restores that semantic to the quotes. I am not a
good enough shell programmer to know how to do this without the 'eval';
I have tried many various combinations of embedded quotes and backslashes.
In particular, what I need is for the start_daemon function to finally
execute the following:
/sbin/start-stop-daemon --start --nicelevel $nice --quiet --startas $exe
c --pidfile /dev/null --oknodo -- /usr/sbin/sleepd --unused 0
--ac-unused 0 --battery 10 --sleep-command '/usr/sbin/hibernate -F
/etc/hibernate/suspend.conf'
Note that the $PARAMS value is sent to the start_daemon function as part
of $@, and is put in the command line of start-stop-daemon after the --.
For what value of $PARAMS can I make this work to create the output above:
start_daemon -p /tmp/sleepd.pid /usr/sbin/sleepd $PARAMS
With the "eval" in start_daemon, I can make it work, and I haven't seen
any other start scripts break. While you do document strange possible
behaviour for the function, where does that breakage happen in practice?
id est, is it a "real" regression or a "potential" one? And if it is a
regression, then how should the sleepd script be written to work
correctly with the LSB functions?
Luigi
Max Kellermann wrote, On 01/08/2007 06:35 AM:
> Package: lsb-base
> Version: 3.1-22
> Severity: important
>
> I believe bug #388836 is invalid and the workaround introduced in
> 3.1-18 is not only wrong, but introduces a "real" bug.
>
> PARAMS="--this --that --start-command 'hibernate -F hibernate.conf'"
>
> [remark: I had to add double quotes around the value, because the
> submitter used invalid shell syntax - I assume this is what he meant]
>
> This just doesn't do what the submitter probably thinks it should.
> You can't use bash quotes inside a string value. It's a string, you
> can't nest quotes. The single quotes in the string are not being used
> to quote strings, they're just printable characters that happen to
> look like a single quote. There was no need to fix a bug because
> there was none.
>
> Let's talk about the new bug: spaces in parameters don't work at all
> if you specify them correctly:
>
> start_daemon -- /usr/sbin/foobard --foo "one two three"
>
> This should result in two parameters passed to /usr/sbin/foobard:
> first one is "--foo" and the second one is "one two three". Instead,
> start_daemon passes four parameters: "--foo", "one", "two", "tree".
>
> Please see the attached test scripts and try running foo.sh. The
> first invocation (directly, without start_daemon) is perfectly
> correct, the second one (with start_daemon) breaks in every case.
>
> Here's list of breakages caused by the "eval":
>
> - whitespaces in parameters cause the values to be split
> - can't use quotes in parameter values ("unexpected EOF while looking
> for matching `''")
> - can't use dollars in parameter values
> - empty paramers are dismissed
> - any amount of any whitespace is replaced with a single space
> - try backquotes! it's fun!
> - probably a lot more breakages due to bash syntax conflicting with
> parameter values
>
> Please remove the eval. It's evil.
>
> Max
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
