default path
in [Shell]
|
Prev: YANQUI courts were ALWAYS K A N G A R O O Courts - thats how they carried out GENOCIDE of NATIVES !!!
Next: CONTROLLED DEMOLITION INC explosive-charge placement technician Tom Sullivan 911 TESTIMONIAL Video
From: Keith Keller on 26 Jun 2010 13:46 On 2010-06-26, John Kelly <jak(a)isp2dial.com> wrote: > On Sat, 26 Jun 2010 09:55:56 -0700, Keith Keller ><kkeller-usenet(a)wombat.san-francisco.ca.us> wrote: >> >>A good syadmin >>will use this feature sparingly but will still want it available if >>needed. > > I've never faced a situation where I had to do it. Somehow, I find > another way. I've never faced a situation where I *had* to do it, but I have on very rare occasion faced a situation where it was much easier and more helpful to do so. Somehow, I *almost* always find another way. The funny thing is, I find another way even with /usr/local/bin being first in the PATH, so that in the (again, *very* *rare*) event I can not find another way, I still have the option to put my binary there to override the system. --keith -- kkeller-usenet(a)wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt see X- headers for PGP signature information
From: Barry Margolin on 26 Jun 2010 21:55 In article <2gcc2696fu1oefslp9qduid0frsv47ph70(a)4ax.com>, John Kelly <jak(a)isp2dial.com> wrote: > On Sat, 26 Jun 2010 18:53:10 +0200, Janis Papanagnou > <janis_papanagnou(a)hotmail.com> wrote: > > >On 26/06/10 18:22, John Kelly wrote: > >> > >> In my default path, I prefer "local" at the end: > >> > >> /bin:/usr/bin:/usr/local/bin > >> > >> Seems like most distros though, do it the other way around and put > >> "local" first. To me that seems like a bad idea, because you could > >> inadvertently, without realizing it, override system binaries. > > > >But isn't that the purpose of /usr/local/bin, to override if > >necessary and add new (non-standard) tools if desired? Those > >local/bin directories should usually be quite empty anyway, so > >name clashes should be rare and then probably intended. > > Makes sense if you only run a vanilla distro. But I create many local > hacks and put them in local. But why would you install something with the same name as a standard command unless you wanted to override it? Well, you said it in your original post: it was inadvertent. But what if you really DID want your own version to take precedence. Do we need two directories, /usr/local/bin (at the end of PATH) and /usr/local/overrides (at the beginning)? You normally put things in the former, and only use the latter when you really intend to shadow standard commands. -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: John Kelly on 27 Jun 2010 00:06 On Sat, 26 Jun 2010 21:55:52 -0400, Barry Margolin <barmar(a)alum.mit.edu> wrote: >But why would you install something with the same name as a standard >command unless you wanted to override it? > >Well, you said it in your original post: it was inadvertent. > >But what if you really DID want your own version to take precedence. Do >we need two directories, /usr/local/bin (at the end of PATH) and >/usr/local/overrides (at the beginning)? I mentioned /usr/local/bin as an example; I mean the whole hierarchy of /usr/local/{bin,sbin,etc} is what I use for local customization. My point is, since I am customizing local for my own needs, why not go ahead and do some extra work to pick different names, so there won't be any conflict. Then, /usr/local at the end of the path makes sense. >You normally put things in the former, and only use the latter when >you really intend to shadow standard commands. When people shadow commands, is it really necessary? Or just a lazy way out of a problem? If you start shadowing binaries, you might be tempted to shadow shared libraries too. Then you have a real mess. -- Web mail, POP3, and SMTP http://www.beewyz.com/freeaccounts.php
From: Barry Margolin on 27 Jun 2010 21:52 In article <5did26p4m0ivmetahsu7io0b5cj740rlq8(a)4ax.com>, John Kelly <jak(a)isp2dial.com> wrote: > On Sat, 26 Jun 2010 21:55:52 -0400, Barry Margolin <barmar(a)alum.mit.edu> > wrote: > > >But why would you install something with the same name as a standard > >command unless you wanted to override it? > > > >Well, you said it in your original post: it was inadvertent. > > > >But what if you really DID want your own version to take precedence. Do > >we need two directories, /usr/local/bin (at the end of PATH) and > >/usr/local/overrides (at the beginning)? > > I mentioned /usr/local/bin as an example; I mean the whole hierarchy of > /usr/local/{bin,sbin,etc} is what I use for local customization. > > My point is, since I am customizing local for my own needs, why not go > ahead and do some extra work to pick different names, so there won't be > any conflict. Then, /usr/local at the end of the path makes sense. If you do that, it doesn't matter where it is in the path. The order only matters when there are duplicates. So the question is: which is more likely, that the conflict was intentional or inadvertent? > > > >You normally put things in the former, and only use the latter when > >you really intend to shadow standard commands. > > When people shadow commands, is it really necessary? Or just a lazy way > out of a problem? If you start shadowing binaries, you might be tempted > to shadow shared libraries too. Then you have a real mess. You shadow commands so you don't have to teach all your users to use the new command name, or change decades-old habits of your own. -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: steven_nospam at Yahoo! Canada on 28 Jun 2010 12:05
> >You normally put things in the former, and only use the latter when > >you really intend to shadow standard commands. > > When people shadow commands, is it really necessary? Or just a lazy way > out of a problem? If you start shadowing binaries, you might be tempted > to shadow shared libraries too. Then you have a real mess. One example I can think of...Commands that all users have access to, but we want to make the "default" command operate differently. Here is an example from our system, the "rm" command. We have developers who may issue the rm command on a copy of a script/program they were working on. Occasionally in the past, they have deleted work they thought they no longer needed, or were to general with their wildcards, and they get rid of something that they wanted to keep. So they come crying to the sysadmin and we used to have to either go to backup to get it, or tell them it is not available (somthing they worked on today which was not backed up yet). But we don't want to replace the default UNIX command, since any O/S upgrade or update could potentially replace our replacement.... Instead, now what we do is have our own "rm" command (a shell script), that takes a copy of what they asked to delete and we put a copy in a special temporary storage area for 24-48 hrs before making a call to the real rm command. Kind of like the Windows trashbin. If they made a mistake, they use another script called "unrm" and they can get their deleted file(s) back without having to ask the sysadmin. This works better for us than giving the scripts a different name (like "delete/undelete") because many of the users are also UNIX- fluent and have a tendency to use rm without even thinking. But I guess it is whatever works for you personally that is best. |