Re: Some basic unix directory listing questions (long)
From: Stephen Riehm (stephen.riehm_at_gmx.net)
Date: 10/12/04
- Next message: Stephane CHAZELAS: "Re: Some basic unix directory listing questions"
- Previous message: Ashley Dawkins: "Ksh coprocess assistance."
- In reply to: Chris F.A. Johnson: "Re: Some basic unix directory listing questions"
- Next in thread: Paul Jarc: "Re: Some basic unix directory listing questions (long)"
- Reply: Paul Jarc: "Re: Some basic unix directory listing questions (long)"
- Reply: Bruce Barnett: "Re: Some basic unix directory listing questions (long)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 12 Oct 2004 09:10:26 +0200
Chris F.A. Johnson wrote:
> On 2004-10-12, Ed Morton wrote:
>>Chris F.A. Johnson wrote:
>>>On 2004-10-12, D. Alvarado wrote:
>>>>Hi everybody, Using "sh", I am running a little script
>>>>
>>>>./test.sh
>>>>
>>>>Couple of basic questions,
>>>>
>>>>1. From within "test.sh", how do I get the absolute path to test.sh?
[...]
>>> However, the full path is usually in $0, but not always.
>>>
>>> If not, you may have to search the PATH:
[...]
> I seem to recall a lengthy thread on this subject, in which the
> consensus was that this cannot be answered reliably in all
> situations. That's why I queried the reason for wanting this.
I don't recall the lengthy discussion, but software installation would
be a LOT easier IF there was a "reliable" way to find out where a
program is (as opposed to pwd which only tells you where the caller
is). I use this method extensively for perl "suites" which bring their
own libraries, configuration files, etc with them. Basically, you can
deliver your own bin/, lib/, etc/ tree - put it anywhere you like and
just run the scripts as they are. They find everything they need all
by themselves and "Just Work™". MacOS has always had this concept and
it's one of the reasons why software installation on that platform is
so easy, your GRANDMA can install (and uninstall!) software from that
system.
So much for the reasons. Now for a solution.
A few years back I tried solving this problem. I actually wrote a
version for sh, perl and in C. Then I noticed that someone cleverer
than I had written FindBin for perl, I stopped writing C code and the
sh version was over 100 lines and deemed impractical. This code has
since been lost to the sands of time :-( However, I re-coded the ksh
version a while back and if you're curious, I've uploaded it to
http: //opensauce .de/findself.tgz (remove the spaces). (It's only a
little test I wrote for myself, don't expect too much)
The problem is that the code required to do this either has to be part
of the operating system (ie: a simple call) or it has to be part of
the running script. As soon as you try to call a helper program you're
going to get the directory of the helper, which probably won't be the
directory of your script.
To make matters worse, there's a whole bunch of possibilities to cater
for.
IF you are running on unix (!) you _only_ have to deal with:
$0 doesn't have any /'s
it's just the name of a file - search for $ in $PATH
$0 starts with a /
it's the full path to the file - do nothing (yet)
any other $0
it's a path relative to the current directory - `pwd`/$0 should do it.
Then there are symbolic links!
If your script is in /opt/scripts/... but the sysadmin cleverly
provided you with a link in /usr/local/bin - the above could send
your script looking in /usr/local/bin instead of /opt/scripts... not
good.
As for hard links - no chance. This is why I'd like to see the OS tell
me where it found me!
That said, "who uses hard links these days"?
If you're using perl, have a look at the FindBin module. I usually use
the following at the beginning of all of my perl scripts:
#!/usr/local/bin/perl -w
use strict;
use FindBin qw( $RealBin, $RealScript );
use lib "$RealBin/../lib";
use MyModule; # found in ../lib, relative to this script
With this I can have as many test versions of my suite as I like. I
split the configuration files over several directories, ie: /etc/,
$RealBin/config/ and $HOME/.$RealScript/. (And they are honoured in
that order too btw.) Every instance picks up the "system"
configuration and the personal configuration, but also their own
internal configuration. Changing a library in one of those instances
only effects that instance, and of course installing is just a matter
of tar'ing the whole lot and dumping it on the target machine.
To the original poster: there's no silver bullet (yet :-).
To everyone else: does anyone know who we would have to convince to
get exec updated so that it left some indication of where the program
it just started was found? Linus? Dennis Ritchie?
(Then we just have to convince people to use it *sigh*)
OK - so I'm probably getting out of the wrong side of bed this
morning, sorry for the long post, but maybe I'm not the only deluded
soul on this planet who wants to be able to write code that just works
without having to jump through too many hoops.
Cheers,
Steve
- Next message: Stephane CHAZELAS: "Re: Some basic unix directory listing questions"
- Previous message: Ashley Dawkins: "Ksh coprocess assistance."
- In reply to: Chris F.A. Johnson: "Re: Some basic unix directory listing questions"
- Next in thread: Paul Jarc: "Re: Some basic unix directory listing questions (long)"
- Reply: Paul Jarc: "Re: Some basic unix directory listing questions (long)"
- Reply: Bruce Barnett: "Re: Some basic unix directory listing questions (long)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
