Carl Lowenstein wrote:
Couple of comments:
Shouldn't your script use fully qualified paths for commands it
invokes, or else set $PATH to fit your environment?
A fully qualified PATH or a specifically set path makes the script
completely useless for a different user, a different Linux or a
different OS.
Why in the world would you want to completely prevent the use of this
script in a different environment?
I think this is analgous to the use of a hardware RS232 null modem
box rather than making up a special cable to hide the connections. I
would rather have the search path dependencies written out where I can
see them than have them hidden in some user's environment.
So, you'd rather that your filesystem was a mess of brittle symbolic
links instead? I'm exaggerating, but only slightly.
At one company, we had *hordes* of scripts that did what you said and
hard encoded the paths. We had entire directories which had been around
for 5 years simply to support the links to enable those scripts.
Eventually, I got fed up with debugging this network of links on a
semi-weekly basis for my engineering team.
After suitable warning, I nuked those directories. *All* of them.
Including /usr/local.
Chaos ensued.
Yes, I warned people. Yes, I tried to get people to make quick
modifications to their scripts. Yes, I tried to point out that scripts
which were necessary to the running of the business needed to be on
backed up, version controlled directories and servers.
Everybody ignored these requests and only paid attention once everything
ground to a halt.
I took a *huge* amount of heat. Fortunately my manager stood firm
saying: "Where's your recovery plan? If those servers went dead *for
real*, you would be completely hosed. Fix the problem; we're not
putting those directories back. Especially since you can't even
identify which ones you need."
Normally it took a group less that an hour to hunt the one or two paths
which broke. On the other hand, there were also a couple of groups that
were so badly intertwined with the paths that we put the directories
back temporarily. However, we set a hard deadline 2 weeks later for
permanent removal.
So, here's what eventually happened:
The network picked up a *huge* boost in reliability and speed. The
number of NFS mounts decreased dramatically and the number of link
chases dropped like a stone.
Lots of annoying bugs suddenly disappeared because everybody was now on
the same, latest version of bash, perl, python, cvs, ssh, etc.
A few annoying bugs popped up because people were relying on specific
old versions of perl. These were required to be fixed.
There were a few vendor specific tools which required hard-coded paths
and old versions of Perl. We moved these off of the main cluster and
put them on a small cluster on its own which had special configuration,
backup and login procedures. Sometimes you just have to accomodate the
unique.
As a bonus, once there was some *pain* associated with using these old
vendor tools, people often found more convenient alternatives (which
were all newer and cheaper). As a result, our licensing fee outflow
also dropped because there was pressure to replace these old tools.
And I got to go back to doing engineering instead of system administration.
Moral: Do not use hard coded paths.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
