Ethan Benson <firstname.lastname@example.org> wrote:
>yes but a much more portable way to do this is to use printf:
>printf "Restarting apache web server: "
>echo is notoriously inconsistent across *nix platforms. and the SUS
>(single unix specification) has or at least did mandate that echo
>should interpret no command line switches, when potato was unstable
>ash was altered to follow that, but had to be reverted since the
>startup process started looking like this:
>-ne Restarting apache web server:
>but ash asside you can't depend on echo doing anything but echoing
>plain text with a trailing newline, thats all it does consistently.
>anything special use printf instead.
Yes you can, at least in Debian. The policy specifically requires that
anything that might be installed as /bin/sh can deal with 'echo -n',
mainly because it's so widely used. I don't think -e is required.
>> And anyway, why would you want to insist on 'ash' ?
>its smaller, faster and just does posix. i can think of no reason why
>ANY initscript requires a bashism, you can do some really complicated
>things in pure posix that work perfectly in ash.
Like shoop ...
>initscripts should be plain posix shell scripts with no bashisms, and
>should have #!/bin/sh as the interpreter, this way you can link
>/bin/sh to ash without any problems. (this is perfectly allowable,
>and i think is even a config question on woody's ash)
>if the script DOES have a bashism then it should have #!/bin/bash so a
>non-bash /bin/sh does not break it. but using #!/bin/bash for no good
>reason is just lame.
Yeah, it's certainly a valid wishlist bug to ask that any given script
be made to work with /bin/sh, and at least a normal bug if it declares
/bin/sh but isn't.
Colin Watson [email@example.com]