Russ Allbery wrote:
> Kel Modderman <[email protected]> writes:
>
>> It is the opinion of myself and Petter Reinholdtsen, maintainers of the
>> sysvinit package, that the last sentence of ยง9.3.1 of policy is no
>> longer relevant and should be removed:
>>
>> """Also, if the script name ends in .sh, the script will be sourced in
>> runlevel S rather than being run in a forked subprocess, but will be
>> explicitly run by sh in all other runlevels."""
>
> I went to write the patch for this, but I paused when I saw that the other
> part of this sentence (explicitly running such scripts with sh at other
> run levels) is implemented. The current /etc/init.d/rc runs the script
> directly if it doesn't end in .sh but runs it with sh if it does.
>
As alternative, I propose not to use the suffix .sh:
- now we change /will be sourced/could be sourced/ , with a footnote that
deprecated such feature
- we bugs package, to remove the suffix .sh
- after most of the most important packages removed the .sh suffix,
the policy remove the exception, maybe introducing a footnote which
shortly explain the past rules (this will simplify the writing of
rationale in the new doc)
Rationale:
users could be confused by the .sh suffix.
> At least on my system, all of the scripts ending in .sh have a proper #!
> line and are executable, so this wouldn't make any difference there, but I
> wanted to double-check first before also removing that since it appears to
> be implemented.
hmm. All init.d script should be executable, with proper #! header.
Sysadmin are used to manually /etc/init.d/foo >stop|start|restart|reload>
So I don't understand your commentart.
ciao
cate
ciao
cate
_______________________________________________
Pkg-sysvinit-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
