[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
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
[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
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
[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.
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
6 matches
Mail list logo
