On Mon, Feb 16, 2009 at 10:01:37AM +0100, Giacomo A. Catenazzi wrote: > Russ Allbery wrote: > >Kel Modderman <k...@otaku42.de> 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.
While I agree in general that the .sh suffix should not be mentionned unless it has a specific meaning, I am afraid that your proposal will be technically troublesome, because the file /etc/init.d/*.sh are conffiles and renaming conffiles is a pain. Since such files are critical at startup, I am afraid than an attempt to rename them will make the upgrade path to squeeze more fragile. > > 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. I think Russ point is that there is no reason for policy to mandate to run them with 'sh /etc/init.d/foo' if you can just run them directly as '/etc/init.d/foo', as you suggest. If we are going to remove """Also, if the script name ends in .sh, the script will be sourced in runlevel S rather than being run in a forked subprocess""", then we can just remove any difference in handling a script called /etc/init.d/foo.sh versus /etc/init.d/bar. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org