On Wed, 2015-12-09 at 22:05 +0000, Ian Jackson wrote:
> Ben Hutchings writes ("Re: update-initramfs should not set PATH"):
> > On Wed, 2015-12-09 at 21:56 +0000, Ian Jackson wrote:
> > > Ben Hutchings writes ("Re: update-initramfs should not set PATH"):
> > > > I'm not at all convinced that update-initramfs should be sensitive to
> > > > the path of the process invoking it. update-initramfs is not only used
> > > > interactively, but also automatically by package installation.
> > >
> > > Package installation should also occur with an appropriate PATH. If
> > > PATH contains exciting things then that is presumably deliberate.
> > >
> > > See policy 6.1 (last para):
> > >
> > > [...] Maintainer scripts should also not reset the PATH,
> > > though they might choose to modify it by prepending or appending
> > > package-specific directories. These considerations really apply to all
> > > shell scripts.
> > >
> > > I think it would be better to follow this recommendation here, unless
> > > you have a compelling reason to deviate from our usual practice.
> >
> > As update-initramfs is not a maintainer script, I fail to see the relevance.
>
> Firstly, the argument you made above, that update-initramfs is called
> "automatically by package installation", seems to be based on the idea
> that this is a good reason for setting the PATH.
My point was that it's called both from interactive shells *and* from
package upgrades, and there's no reason to think $PATH will be
consistent between those.
> Secondly, note "These considerations really apply to all shell
> scripts".
Yet most init scripts reset the PATH because this turns out to be a bad
idea in reality.
$ grep -rl 'PATH=[^$]*$' /etc/init.d | wc -l
63
$ grep -rL 'PATH=[^$]*$' /etc/init.d | wc -l
44
Ben.
--
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchettAttachment:
signature.asc
Description: This is a digitally signed message part