Package: sysv-rc
Version: 2.86.ds1-5
Severity: serious
Debian Policy states (§9.3.1):
"Also, if the script name ends `.sh', the script will be sourced in
runlevel `S' rather that being run in a forked subprocess, but will
be explicitly run by `sh' in all other runlevels".
This could p
[Brendan O'Dea]
> I'm not quite sure what the initial rationale was, although Adam Heath
> suggested on IRC that it could be to allow scripts to set environment
> variables which would propagate through to subsequent scripts.
I'm not sure why it is documented in policy, but the sysv-rc
implementat
Brendan O'Dea wrote:
> Note: I believe that "return" should work to exit from a script both
> when sourced and when executed but perhaps someone with a copy of POSIX
> could confirm.
Disconfirmation:
$ cat /tmp/s
#!/bin/bash
echo foo
return
echo bar
[EMAIL
PROTECTED]:~/src/sysvinit/pkg-sysvinit
Brendan O'Dea wrote:
> there are quite a few instances in /etc/init.d/*.sh scripts where "exit" is
> called.
All the exit commands are either (1) at the end of usage exception sections,
or (2) preceded by colons ':'. Testing suggests that a ": exit 0" does the
same as ":", namely, nothing.
Miqu
On Mon, Nov 21, 2005 at 09:55:22AM +0100, Thomas Hood wrote:
>Brendan O'Dea wrote:
>> there are quite a few instances in /etc/init.d/*.sh scripts where "exit" is
>> called.
>
>All the exit commands are either (1) at the end of usage exception sections,
>or (2) preceded by colons ':'. Testing sugge
On Mon, Nov 21, 2005 at 09:34:11AM +0100, Thomas Hood wrote:
>Brendan O'Dea wrote:
>> Note: I believe that "return" should work to exit from a script both
>> when sourced and when executed but perhaps someone with a copy of POSIX
>> could confirm.
>
>
>Disconfirmation:
>
>$ cat /tmp/s
>#!/bin/bash
[Brendan O'Dea]
> Debian Policy states (§9.3.1):
>
>"Also, if the script name ends `.sh', the script will be sourced
>in runlevel `S' rather that being run in a forked subprocess, but
>will be explicitly run by `sh' in all other runlevels".
What a strange thing for policy to specify.
On Sat, Nov 19, 2005 at 11:33:44PM +0100, Petter Reinholdtsen wrote:
>[Brendan O'Dea]
>> Debian Policy states (§9.3.1):
>>
>>"Also, if the script name ends `.sh', the script will be sourced
>>in runlevel `S' rather that being run in a forked subprocess, but
>>will be explicitly run by
On Sat, Nov 19, 2005 at 11:33:44PM +0100, Petter Reinholdtsen wrote:
> >"Also, if the script name ends `.sh', the script will be sourced
> >in runlevel `S' rather that being run in a forked subprocess, but
> >will be explicitly run by `sh' in all other runlevels".
> What a strange thin
[Steve Langasek]
> It's perfectly sensible: if the scripts were meant to be run in
> parallel, they shouldn't have the ".sh" extension...
Eh, are you claiming that policy mention sourcing of .sh scripts to
make sure those scripts are not run in paralell? It does not sounds
reasonable to me, as th
[Petter Reinholdtsen]
> The patch look good, but will be equivalent to a forked subprocess
> when running the scripts in parallel.
Here is a possible patch to avoid running .sh scripts in the
background when using CONCURRENCY=shell.
Index: debian/sysv-rc/etc/init.d/rc
On Sun, Nov 20, 2005 at 08:20:59AM +0100, Petter Reinholdtsen wrote:
> [Steve Langasek]
> > It's perfectly sensible: if the scripts were meant to be run in
> > parallel, they shouldn't have the ".sh" extension...
> Eh, are you claiming that policy mention sourcing of .sh scripts to
> make sure tho
I'm not sure how this could happen, but when I enabled sourcing of the
.sh scripts in rcS.d/, the boot failed because /etc/rcS.d/S01glibc.sh
uses 'exit 0' at the end of the script, and thus terminates the S
runlevel. This script was added in glibc version 2.3.5-5 uploaded
2005-08-27. The strange
13 matches
Mail list logo
