On 2007/01/08 15:01, Luigi Bai <[EMAIL PROTECTED]> wrote: > 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.
"restoring quote semantics" is just a side effect of using eval, and it is a (mis-)feature which is not documented in the LSB spec. You could make sleepd's init script call eval to set variables somehow when you are sure there are no unwanted side effects, but changing lsb-base and bringing the horror of eval to _all_ of Debian is a bad thing. > 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? It happened in a package which isn't part of Debian, but I'm sure you will find official packages breaking under some configured conditions when you look for it. If the default configuration works, that doesn't mean it isn't broken - just insert a dollar or a space in some option in /etc/default/foo, and see it break. For this bug to be valid it doesn't matter whether there is really an official package which breaks. It violates the LSB spec, that should suffice. There aren't many packages using start_daemon yet, but with a broken implementation, it will be hard to convince maintainers to use it. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
