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: John Kelly on 28 Jun 2010 12:20 On Mon, 28 Jun 2010 09:05:57 -0700 (PDT), "steven_nospam at Yahoo! Canada" <steven_nospam(a)yahoo.ca> wrote: >> 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. Good example. >But I guess it is whatever works for you personally that is best. I put local at the end of my default path to avoid unwitting overrides by me, the sysadmin. So I guess the best of both worlds would be what Barry suggested, two separate local hierarchies; one at the head of the path for intentional overrides, and another at the tail of the path for everything else. -- Web mail, POP3, and SMTP http://www.beewyz.com/freeaccounts.php
From: Janis Papanagnou on 29 Jun 2010 04:46 Keith Keller schrieb: > On 2010-06-26, John Kelly <jak(a)isp2dial.com> wrote: [snip] > >> With "local" at the end, there no danger of overriding system binaries >> with some local binary of the same name. And when "local" binary names >> conflict with system binaries, the local admin in control of "local" can >> give local binaries unique names, or perhaps uninstall system binaries >> of the same name, if they are not needed. > > Sometimes system binaries can't be uninstalled (because of local policy, > or package management, or whatever). Updating your OS from a vendor disk/tape/CD/DVD, for example, will overwrite your binaries in your system directories, and you'd have to do any individual replacement of such files again (provided that you have some backup version). > It's handy to have a way to > override a system binary without having to modify it. Janis > [snip]
From: Seebs on 29 Jun 2010 22:22 On 2010-06-26, John Kelly <jak(a)isp2dial.com> wrote: > 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. True. > With "local" at the end, there no danger of overriding system binaries > with some local binary of the same name. Yes. And also no way to do so, because... > And when "local" binary names > conflict with system binaries, the local admin in control of "local" can > give local binaries unique names, This is unworkable, in general -- too many programs care what their names are, or are written as scripts that want to be invoked by a binary of a specific name. > or perhaps uninstall system binaries > of the same name, if they are not needed. But they may well be needed, and having the canonical path work is very useful. > Other opinions? The obvious example would be an editor; say, "vi". It's almost certainly the case that there are explicit references to /usr/bin/vi. You don't want to modify that (because local modifications in a non-local directory are Bad Mojo). You don't want to remove it (because there's explicit calls to it). But if you install another vi, you almost certainly want an unqualified "vi" at a prompt to get the local one, which is presumably better in some way. The working assumption is that it is forbidden (or at the very least, inadvisable enough that very few admins will do it) to modify the standard system directories, and that /usr/local/bin exists precisely to allow the admin to override the defaults. On many systems, removing things from /bin or /usr/bin can easily be catastrophic -- in particular, many systems boot in a configuration where /usr/local/bin *is not available* during boot, so standard versions of the standard utilities must not be deleted. Think of it as being like scoping rules; "local" is more-local, and thus, should take precedence. Again, going back to the assumptions that underlie this, the only way someone should have privileges sufficient to write to /usr/local/bin would be if that person is believed competent to make a reasonable decision about when to override the system default installs. More generally, the same pattern applies to any other bin directory; if you have a bin directory that's specific to a working project, or a personal bin directory, it's put in front of /usr/local, which is in turn in front of plain /usr/bin and /bin, so that the most-specific versions are hit first. For instance, I work with a product which ships with its own versions of a number of software development tools. It needs these because various systems provide obsolete or buggy versions. One of our design requirements is that you must be able to use the product without root privileges on target machines, so we can't remove the buggy versions from /usr/bin. So, inside our product's build system, <PROJECT>/mumble/bin is first in $PATH, to ensure that you get our versions of utilities by default, and we don't have to worry about strange names. Trying to pick unique names increases the likelihood of clashes, and subverts the entire point of having a path searching mechanism in the first place. MHO. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Janis Papanagnou on 30 Jun 2010 08:10 Seebs schrieb: > [...] > More generally, the same pattern applies to any other bin directory; if > you have a bin directory that's specific to a working project, or a personal > bin directory, it's put in front of /usr/local, which is in turn in front > of plain /usr/bin and /bin, [...] Curious; are there systems where /usr/bin and /bin are not equivalent (or even identical [by one directory linking the other])? I don't recall having worked on a Unix system with different contents in those two directories. Janis
From: pk on 30 Jun 2010 08:15
Janis Papanagnou wrote: > Seebs schrieb: >> [...] >> More generally, the same pattern applies to any other bin directory; if >> you have a bin directory that's specific to a working project, or a >> personal bin directory, it's put in front of /usr/local, which is in turn >> in front of plain /usr/bin and /bin, [...] > > Curious; are there systems where /usr/bin and /bin are not equivalent > (or even identical [by one directory linking the other])? All the Linux systems I've worked with have very different things in those two directories. I though that was normal, but after your message I learned that there are indeed systems where the two directories are the same. |