On Wednesday, July 24, 2002, at 12:42 , McCormick, Rob E wrote:
[..]
> I don't
> understand cwd (current working directory). My questions apply to this
> general scenario:
>
> In practice, I'd like to work with my .pl or .plx files in say,
> /myhome/bin/
[..]
Let's start with some simple basics - where the 'executable' resides
in the file system should NOT be confused with where the 'process' is
in the 'file system' when it invokes the 'executable'.
so when you 'login' to a system - it will spawn a 'login shell' and
normally do a 'chdir' to $HOME, so that as soon as you see yourself
logged into the machine and ask
what is my current 'working' directory
it will return something like the 'string' found in $ENV{HOME}.
let me illustrate this with the perl code appended at the end - called Iam
Welcome to Darwin!
[jeeves:~] drieux% Iam
/home/drieux/bin/Iam is In /home/drieux/bin - but Called from /Users/drieux
[jeeves:~] drieux%
notice that since I have my PATH set up to include "$ENV{HOME}/bin" the
code saw itself being invoked in that way - hence that it saw itself
being invoked in a 'fully qualified' path as if I had typed in
/home/drieux/bin/Iam
but there appears to be a 'bug' in the process - since the shell
appears to have logged me into that system in a 'strange place',
since I landed in "/Users/drieux" rather than in "/home/drieux"
what 'confuses' some is that they PRESUME that $ENV{HOME} should
be the 'same' string as where they 'actually' land in the file system.
but the fun of course is that file systems can be mounted, well,
differently, and hence one would also see the difference at a
shell level with the shell commands 'pwd' and 'cwd':
[jeeves:~] drieux% pwd
/Users/drieux
[jeeves:~] drieux% cwd
/home/drieux
[jeeves:~] drieux% ls -ld /home /Users
drwxr-xr-x 7 root wheel 194 Feb 16 12:17 /Users
lrwxrwxr-t 1 root admin 5 Jul 22 13:22 /home -> Users
[jeeves:~] drieux%
which of course can be implemented in various ways on different OS's
and different 'shells' -
vladimir: 55:] pwd ; echo $cwd
/net/gax/home/drieux
/home/drieux
vladimir: 56:] ls -ld /home/drieux /net/gax/home/drieux
lrwxrwxrwx 1 root other 20 Aug 13 2000 /home/drieux -> /net/
gax/home/drieux
drwxrwxrwx 34 drieux house 4096 Jul 12 06:55 /net/gax/home/drieux
vladimir: 59:]
and depending upon 'the documentation' - one is committed to
where one Actually is in the file system, as opposed to where
one Logically is in the file system....
So let's screw up the reality check one more way with resetting
our "PATH" and re-running our Iam script:
vladimir: 72:] sh
$ PATH="/net/gax/home/drieux/bin:$PATH"
$ export PATH
$ Iam
/net/gax/home/drieux/bin/Iam is In /net/gax/home/drieux/bin - but Called
from /net/gax/home/drieux
$
now, since the 'shell' found Iam in the FIRST directory listed in
the PATH environmental variable, it appears to be more like what
we 'would have expected'....
In 'simple systems' where everything follows a single 'rule set'
then it is reasonably simple that where one's "HOME" is, so
too one would be in the 'file system' as it actually occurred.
The fun steps in when you get into 'single system login' solutions
where we have a single notion of what
$HOME
is going to be set to - but, that may or may not be a 'local'
file system - or it may be a 'server mounted' directory....
{ cf: amd, afp, nfs, etc.... }
Hence it is easier on the LDAP variations for that
HOME=<token>
to be the same for all machines - and variations managed on
a host by host basis as to whether this machine is a part
of which 'home basing' solution:
eg:
gax: 55:] pwd ; echo $cwd
/export/home/drieux
/home/drieux
gax: 56:] Iam
/home/drieux/bin/Iam is In /home/drieux/bin - but Called from /export/home/
drieux
gax: 57:]
Notice if you will, that whether I am on a machine
where the Home is Disk Local, or a part of the
shared sever solution - I have the same simplistic
vision of the world because I do everything
relative to
$HOME
how some ever that may really be resolved on that machine....
the irony is that "$HOME/bin" still works across all of
the various machines and various implementations....
Hence irregardless which machine I am on, I know that
I will be able to find 'my executables' in the $ENV{PATH}
spawned by my login sequence....
but while that works this single sign on and
distributed networking solution does prevent me from the simple solution of
if $ENV{HOME} eq $curdir
since as you noticed - environmental variable is set
when the shell is spawned by the logind/sshd/telnetd/<etc>, which has to
deal with the fully integrated solution, but 'cwd'
style solutions still presume that 'reality' takes
precedence over network solutions...
hence you will normally find me solving that equivolency
by other means.....
> Would use Cwd; even be necessary?
sorta depends on whether you want to know where you are
in the file system at any given time - and whether or
not one planned to 'chdir' around to other places...
> What are some scenarios you've used Cwd.pm in the past?
when I need to know 'where I am' - to know IF I should
chdir to a new place - or to capture a directory path
that I will want to chdir back to....
> Why?
If I need to 'recurse' "down" through a set of directories
since I am implementing something like File::Find or some
other directory walking system:
say something like:
http://www.wetware.com/drieux/pbl/Sys/Admin/dirWalkerForCheckSum.txt
> If all files to be looped over are in, say, /data/path/files is it used to
> declare in pseudocode:
>
> <<define working directory as /data/path/files >>
[..]
when you are playing with things like
opendir()
readdir()
most folks forget that the 'file names' that are returned
are just that 'the name' - not the fully qualified path,
so there are several ways of solving all of that....
ciao
drieux
---
[jeeves:~/bin] drieux% sed 's/^/### /' Iam
### #!/usr/bin/perl -w
### use strict;
### use File::Basename qw/dirname/;
### use Cwd;
###
### # Iam - a piece of code to help with who is where when invoked
###
### my $name = $0;
### my $dir = dirname $name;
### my $curdir= cwd;
###
### print $name . " is In $dir - but Called from $curdir \n";
###
### exit(0);
[jeeves:~/bin] drieux%
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
