Re: /usr/local/bin in $PATH in system scripts?
Op dinsdag 08-05-2007 om 21:42 uur [tijdzone +0100], schreef Fergal Daly: > I'm looking for clarification of policy in the context of this bug > > https://launchpad.net/ubuntu/+source/gnome-system-tools/+bug/71336 > > and the fact that having your own version of Perl in /usr/local will > almost certainly break your Ubuntu admin tools. Is there anybody who knows why PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin is defined locally in that udev script, and not somewhere in a central place? That seems completely wrong to me... -- Jan Claeys -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
Ming Hua wrote: > On Thu, May 10, 2007 at 08:33:41PM -0700, Micah Cowan wrote: >> Ming Hua wrote: >>> For the sake of discussion, I think >>> >>> #!/usr/bin/env perl >>> >>> will pick up $PATH and is a valid #! line. I also believe this is widely >>> used. >> Yes, it will. But isn't that a somewhat silly suggestion considering the >> context? If /usr/bin/perl were "bad" then /usr/bin/env would be just as >> "bad", it seems to me... > > That's not the point. > > Fergal's argument is, if you think scripts honoring the $PATH variable > and use the binaries /usr/local/bin/ is a feature because it respects > the user preference, you should also think using "#!/usr/bin/env perl" > instead of "#!/usr/bin/perl" a feature as well, for the same reason. > And I think it's a valid argument. But why should it apply to perl and not to env? What if you have a broken env in /usr/local/bin? I actually thing that /usr/bin/env is probably preferable, though: but /usr/bin/perl has too strong a tradition behind it. I have noticed that a decent number of python programmers do it that way. I actually see both sides of the argument. Perhaps there should be a single location for a base "restricted path" to be stored, and modifications would be made from that, if necessary. I would probably agree that /usr/local/bin shouldn't be in there by default. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On Thu, May 10, 2007 at 08:33:41PM -0700, Micah Cowan wrote: > Ming Hua wrote: > > > > For the sake of discussion, I think > > > > #!/usr/bin/env perl > > > > will pick up $PATH and is a valid #! line. I also believe this is widely > > used. > > Yes, it will. But isn't that a somewhat silly suggestion considering the > context? If /usr/bin/perl were "bad" then /usr/bin/env would be just as > "bad", it seems to me... That's not the point. Fergal's argument is, if you think scripts honoring the $PATH variable and use the binaries /usr/local/bin/ is a feature because it respects the user preference, you should also think using "#!/usr/bin/env perl" instead of "#!/usr/bin/perl" a feature as well, for the same reason. And I think it's a valid argument. Debian guarantees /usr/bin/perl and /usr/bin/env will work. I think the focus of this discussion is what happens if we have a "bad" /usr/local/bin/perl, not a "bad" /usr/bin/perl. Ming 2007.05.10 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
Ming Hua wrote:
> On Thu, May 10, 2007 at 08:59:19AM -0700, Micah Cowan wrote:
>> Fergal Daly wrote:
>>
>>> You are also implying that everything in /usr/bin that start with
>>>
>>> #! /usr/bin/{perl,python,...}
>>>
>>> is wrong and should actually start with
>>>
>>> #! {perl,python,...}
>> That doesn't work. #! requires a path.
>
> For the sake of discussion, I think
>
> #!/usr/bin/env perl
>
> will pick up $PATH and is a valid #! line. I also believe this is widely
> used.
Yes, it will. But isn't that a somewhat silly suggestion considering the
context? If /usr/bin/perl were "bad" then /usr/bin/env would be just as
"bad", it seems to me...
--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
signature.asc
Description: OpenPGP digital signature
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On Thu, May 10, 2007 at 08:59:19AM -0700, Micah Cowan wrote:
> Fergal Daly wrote:
>
> > You are also implying that everything in /usr/bin that start with
> >
> > #! /usr/bin/{perl,python,...}
> >
> > is wrong and should actually start with
> >
> > #! {perl,python,...}
>
> That doesn't work. #! requires a path.
For the sake of discussion, I think
#!/usr/bin/env perl
will pick up $PATH and is a valid #! line. I also believe this is widely
used.
Ming
2007.05.10
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On 10/05/07, Micah Cowan <[EMAIL PROTECTED]> wrote:
> Fergal Daly wrote:
> > On 10/05/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> >> On Wed, May 09, 2007 at 07:03:30PM -0400, Jim Doherty wrote:
> >>> Sorry, I have no idea what ubuntu policy is. But good defensive
> >>> scripting practice includes setting your $PATH to something safe. A
> >>> good script should always not trust the environment it was handed along
> >>> with many other things that people don't always do.
> >> I have to disagree. The environment is precisely the tool available to
> >> users to
> >> change the behavior of your script externally. It's not nice to stomp on
> >> user
> >> preferences.
> >>
> >> The original problem is user error. Installing an upgraded perl in
> >> /usr/local
> >> without installing all of the needed perl libraries or removing
> >> /usr/local/bin
> >> from the default system PATH is incorrect usage. Don't break features to
> >> avoid
> >> user error, please.
> >
> > You have 2 assertions in one sentence, I'm splitting them up.
> >
> > 1 - "Installing an upgraded perl in /usr/local without installing all
> > of the needed perl libraries is incorrect usage"
> >
> > This directly contradicts the debian policy I quoted which essentially
> > says that the contents of /usr/local should have no impact on whether
> > your system works or not. I know Debian is not Ubuntu but in the
> > absence of Ubuntu policy docs, I'm assuming that the Debian policy is
> > a sane starting point.
>
> Yes, but that's not actually what it states (repasted):
> > "However, because /usr/local and its contents are for exclusive use of
> > the local administrator, a package must not rely on the presence or
> > absence of files or directories in /usr/local for normal operation."
>
> It is not relying on the presence or absence of any files. It is relying
> on your PATH to give it a good perl. That /perl/ is relying on the
> presence or absence of various files. I don't think that this paragraph
> was ever meant to be applied to such indirect reliance.
It's relying on the absence of perl or if perl is there it's relying
on the presence of /usr/local/lib/perl/Foo/Bar.pm . Also, it's not
_my_ PATH, it's the path that is explicitly set by some system
scripts.
Can you give me a definition of "good perl" that isn't equivalent to
"exactly compatible with /usr/bin/perl"? Where "compatible" means
feature for feature _and_ bug for bug because I as a sysadmin have no
idea what the next apt-get upgrade will depend on.
If /usr/local/bin/X has to be exactly the same as /usr/bin/X, what's the point?
Please also address how I'm supposed to keep the modules in this
version of perl in sync with the versions in /usr/lib without help
from apt (I'm not saying it can't be done but your interpretation
imposes this extra work on me). How about when I install a package
that pulls in a new perl-Blah.deb as a dependency? I should manually
track and replicate these changes?
A far more useful interpretation is "the contents /usr/local should
have no effect on the system's normal operation". What are the
down-sides of this interpretation?
> > You are also implying that everything in /usr/bin that start with
> >
> > #! /usr/bin/{perl,python,...}
> >
> > is wrong and should actually start with
> >
> > #! {perl,python,...}
>
> That doesn't work. #! requires a path.
Sorry
#! /usr/bin/env {perl,python,...}
The point being that if you believe that all system scripts should
respect each user's path then you should be appalled at the number of
things in /usr/bin/ that completely ignore it,
F
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
Fergal Daly wrote:
> On 10/05/07, Forest Bond <[EMAIL PROTECTED]> wrote:
>> On Wed, May 09, 2007 at 07:03:30PM -0400, Jim Doherty wrote:
>>> Sorry, I have no idea what ubuntu policy is. But good defensive
>>> scripting practice includes setting your $PATH to something safe. A
>>> good script should always not trust the environment it was handed along
>>> with many other things that people don't always do.
>> I have to disagree. The environment is precisely the tool available to
>> users to
>> change the behavior of your script externally. It's not nice to stomp on
>> user
>> preferences.
>>
>> The original problem is user error. Installing an upgraded perl in
>> /usr/local
>> without installing all of the needed perl libraries or removing
>> /usr/local/bin
>> from the default system PATH is incorrect usage. Don't break features to
>> avoid
>> user error, please.
>
> You have 2 assertions in one sentence, I'm splitting them up.
>
> 1 - "Installing an upgraded perl in /usr/local without installing all
> of the needed perl libraries is incorrect usage"
>
> This directly contradicts the debian policy I quoted which essentially
> says that the contents of /usr/local should have no impact on whether
> your system works or not. I know Debian is not Ubuntu but in the
> absence of Ubuntu policy docs, I'm assuming that the Debian policy is
> a sane starting point.
Yes, but that's not actually what it states (repasted):
> "However, because /usr/local and its contents are for exclusive use of
> the local administrator, a package must not rely on the presence or
> absence of files or directories in /usr/local for normal operation."
It is not relying on the presence or absence of any files. It is relying
on your PATH to give it a good perl. That /perl/ is relying on the
presence or absence of various files. I don't think that this paragraph
was ever meant to be applied to such indirect reliance.
> You are also implying that everything in /usr/bin that start with
>
> #! /usr/bin/{perl,python,...}
>
> is wrong and should actually start with
>
> #! {perl,python,...}
That doesn't work. #! requires a path.
--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
signature.asc
Description: OpenPGP digital signature
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On 10/05/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> On Wed, May 09, 2007 at 07:03:30PM -0400, Jim Doherty wrote:
> > Sorry, I have no idea what ubuntu policy is. But good defensive
> > scripting practice includes setting your $PATH to something safe. A
> > good script should always not trust the environment it was handed along
> > with many other things that people don't always do.
>
> I have to disagree. The environment is precisely the tool available to users
> to
> change the behavior of your script externally. It's not nice to stomp on user
> preferences.
>
> The original problem is user error. Installing an upgraded perl in /usr/local
> without installing all of the needed perl libraries or removing /usr/local/bin
> from the default system PATH is incorrect usage. Don't break features to
> avoid
> user error, please.
You have 2 assertions in one sentence, I'm splitting them up.
1 - "Installing an upgraded perl in /usr/local without installing all
of the needed perl libraries is incorrect usage"
This directly contradicts the debian policy I quoted which essentially
says that the contents of /usr/local should have no impact on whether
your system works or not. I know Debian is not Ubuntu but in the
absence of Ubuntu policy docs, I'm assuming that the Debian policy is
a sane starting point.
What you are basically saying is that whenever I install _anything_
into /usr/local/bin I should carefully check that no system scripts
will be upset by this. I also need to check that no system scripts in
the _future_ will be upset by this!
Also, if I install my own perl in /usr/local/bin, I must install all
the libraries used by any other package that might be installed by
Ubuntu but I must do this by hand because apt will only manage the
dependencies of my /usr/bin/perl .
This basically makes it impractical to put anything into /usr/local/bin.
You are also implying that everything in /usr/bin that start with
#! /usr/bin/{perl,python,...}
is wrong and should actually start with
#! {perl,python,...}
in order to pick up whatever version of {perl,python,...} the user prefers.
In summary, you are saying that anything I put in /usr/local/bin
should be such that I could safely put it into /usr/bin. So what's the
point of /usr/local?
2 - "Installing an upgraded perl in /usr/local without removing
/usr/local/bin from the default system PATH is incorrect usage"
Users should not have to modify 20 scripts in /etc/ just because
they've put something in /usr/local/bin,
F
> -Forest
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGQxgHRO4fQQdv5AwRAihpAJ9Xt+Taa2NQLDPwp6q/1Ieo1zgVgwCgiuAL
> tt0Y02QX+zHj7Bvuw/9wcNA=
> =qnXL
> -END PGP SIGNATURE-
>
>
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On Wed, May 09, 2007 at 07:03:30PM -0400, Jim Doherty wrote: > Sorry, I have no idea what ubuntu policy is. But good defensive > scripting practice includes setting your $PATH to something safe. A > good script should always not trust the environment it was handed along > with many other things that people don't always do. I have to disagree. The environment is precisely the tool available to users to change the behavior of your script externally. It's not nice to stomp on user preferences. The original problem is user error. Installing an upgraded perl in /usr/local without installing all of the needed perl libraries or removing /usr/local/bin from the default system PATH is incorrect usage. Don't break features to avoid user error, please. -Forest signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
Fergal Daly wrote: > Hi, > > I'm looking for clarification of policy in the context of this bug > > https://launchpad.net/ubuntu/+source/gnome-system-tools/+bug/71336 > > and the fact that having your own version of Perl in /usr/local will > almost certainly break your Ubuntu admin tools. > > I have always assumed that it was safe to put whatever I like in > /usr/local/ and my system will continue to work. This seems to be > backed up by Debian policy > > http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit > > which contains this paragraph > > "However, because /usr/local and its contents are for exclusive use of > the local administrator, a package must not rely on the presence or > absence of files or directories in /usr/local for normal operation." > > This seems quite sensible, otherwise it leads to mysterious and hard > to track-down failures. > > Is this ubuntu policy too? > Sorry, I have no idea what ubuntu policy is. But good defensive scripting practice includes setting your $PATH to something safe. A good script should always not trust the environment it was handed along with many other things that people don't always do. Jim > I can't see any real benefit to including /usr/local/bin and I can > find plenty of people in the forums who can't start *-admin, > presumably due to problems similar to mine, > > F > signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On 09/05/07, Soren Hansen <[EMAIL PROTECTED]> wrote: > On Wed, May 09, 2007 at 10:43:29AM +0200, Oliver Grawert wrote: > > > "However, because /usr/local and its contents are for exclusive use > > > of the local administrator, a package must not rely on the presence > > > or absence of files or directories in /usr/local for normal > > > operation." > > how does that even remotely relate to your complaint ? the package > > itself just uses the default system paths and obviously doesnt *rely* > > on anything in /usr/local apparently ... > > No, but it *does* rely on the *absence* of a b0rken perl interpreter > there. Yes. Although there's nothing broken about it, it's just a vanilla perl install and that means it doesn't have certain modules relating to DBus or gnome or whatever (I can't remember the exact error), F > > -- > | Soren Hansen| Linux2Go | http://Linux2Go.dk/ | > | Seniorkonsulent | Lindholmsvej 42, 2. TH| +45 46 90 26 42 | > | [EMAIL PROTECTED] | 9400 Norresundby, Denmark | GPG key: E8BDA4E3 | > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFGQYsAonjfXui9pOMRAuBBAJwJT1VRHNBJFU3aB1CjUtZ07c/TdgCgmyMT > pc5WblW6yW0Q52x/fMxIpj8= > =hu4o > -END PGP SIGNATURE- > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On Wed, May 09, 2007 at 10:43:29AM +0200, Oliver Grawert wrote: > > "However, because /usr/local and its contents are for exclusive use > > of the local administrator, a package must not rely on the presence > > or absence of files or directories in /usr/local for normal > > operation." > how does that even remotely relate to your complaint ? the package > itself just uses the default system paths and obviously doesnt *rely* > on anything in /usr/local apparently ... No, but it *does* rely on the *absence* of a b0rken perl interpreter there. -- | Soren Hansen| Linux2Go | http://Linux2Go.dk/ | | Seniorkonsulent | Lindholmsvej 42, 2. TH| +45 46 90 26 42 | | [EMAIL PROTECTED] | 9400 Norresundby, Denmark | GPG key: E8BDA4E3 | signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
hi, On Di, 2007-05-08 at 21:42 +0100, Fergal Daly wrote: > > "However, because /usr/local and its contents are for exclusive use of > the local administrator, a package must not rely on the presence or > absence of files or directories in /usr/local for normal operation." how does that even remotely relate to your complaint ? the package itself just uses the default system paths and obviously doesnt *rely* on anything in /usr/local apparently ... ciao oli signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On 08/05/07, Daniel Robitaille <[EMAIL PROTECTED]> wrote: > On 5/8/07, Fergal Daly <[EMAIL PROTECTED]> wrote: > > > > I can't see any real benefit to including /usr/local/bin and I can > > find plenty of people in the forums who can't start *-admin, > > presumably due to problems similar to mine, > > I personally use /usr/local/bin to install my own version of Firefox, > without the need to uninstall the Ubuntu's version of Firefox. Since > /usr/local/bin/ is ahead of /usr/bin in the standard $PATH of users, > if I have a /usr/local/bin/firefox it is picked up by default by all > my users. You have quoted my last paragraph completely out of context. I put /usr/local/bin first in my path too, that's a perfectly fine use of /usr/local/bin and is not the problem. The problem is that when a system script puts /usr/local/bin first it can pick up all kinds of versions that don't do what it is expecting. In this case, /etc/dbus-1/event.d/70system-tools-backends picks will pick up a custom version of perl, expecting it to have the usual Ubuntu perl modules available and it fails. Worse, it fails silently, with the result that nobody (not even root) is authorised to run the admin tools. Shouldn't system scripts should only be invoking the system-supplied versions of binaries? F > > -- > Daniel Robitaille > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On 5/8/07, Fergal Daly <[EMAIL PROTECTED]> wrote: > > I can't see any real benefit to including /usr/local/bin and I can > find plenty of people in the forums who can't start *-admin, > presumably due to problems similar to mine, I personally use /usr/local/bin to install my own version of Firefox, without the need to uninstall the Ubuntu's version of Firefox. Since /usr/local/bin/ is ahead of /usr/bin in the standard $PATH of users, if I have a /usr/local/bin/firefox it is picked up by default by all my users. -- Daniel Robitaille -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
/usr/local/bin in $PATH in system scripts?
Hi, I'm looking for clarification of policy in the context of this bug https://launchpad.net/ubuntu/+source/gnome-system-tools/+bug/71336 and the fact that having your own version of Perl in /usr/local will almost certainly break your Ubuntu admin tools. I have always assumed that it was safe to put whatever I like in /usr/local/ and my system will continue to work. This seems to be backed up by Debian policy http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit which contains this paragraph "However, because /usr/local and its contents are for exclusive use of the local administrator, a package must not rely on the presence or absence of files or directories in /usr/local for normal operation." This seems quite sensible, otherwise it leads to mysterious and hard to track-down failures. Is this ubuntu policy too? I can't see any real benefit to including /usr/local/bin and I can find plenty of people in the forums who can't start *-admin, presumably due to problems similar to mine, F -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
