bobg+@andrew.cmu.edu (Robert Steven Glickstein) (05/29/91)
I'm a Perl beginner, but I'm amazed by how quickly I've picked up the language and how quickly I've been able to write really complex utilities. To an experienced C programmer like myself, Perl came very naturally and it is now my prototype/utility language of choice. OK, enough hype. :-) It seems that Perl ought to have a built-in getwd command, but it doesn't. Is it the case that the only way to find out the current working directory is to do $cwd = `/bin/pwd`; chop $cwd; ? Thanks in advance. ______________ _____________________________ Bob Glickstein | Internet: bobg@andrew.cmu.edu Information Technology Center | Bitnet: bobg%andrew@cmuccvma.bitnet Carnegie Mellon University | UUCP: ...!harvard!andrew.cmu.edu!bobg Pittsburgh, PA 15213-3890 | (412) 268-6743 | Sinners can repent, but stupid is forever
subbarao@phoenix.Princeton.EDU (Kartik Subbarao) (05/29/91)
In article <EcEkB=i00VsnE622gr@andrew.cmu.edu> bobg+@andrew.cmu.edu (Robert Steven Glickstein) writes: >I'm a Perl beginner, but I'm amazed by how quickly I've picked up the >language and how quickly I've been able to write really complex >utilities. To an experienced C programmer like myself, Perl came very >naturally and it is now my prototype/utility language of choice. OK, >enough hype. :-) > >It seems that Perl ought to have a built-in getwd command, but it >doesn't. By "built-in", do you mean that it should getcwd() every time it starts up and save that as a $something variable? There's really no need to do so, if you don't care about your current working directory. SOMEONE has to do the getcwd() call -- you don't get it for free. Is it the case that the only way to find out the current >working directory is to do > > $cwd = `/bin/pwd`; > chop $cwd; In the case that your shell sets a CWD or PWD environment variable, then you can access it in perl by: $cwd = $ENV{'CWD'} (or PWD, or whatever). -Kartik -- internet% whoami subbarao@phoenix.Princeton.EDU -| Internet kartik@silvertone.Princeton.EDU (NeXT mail) SUBBARAO@PUCC.BITNET - Bitnet
jmm@eci386.uucp (John Macdonald) (05/31/91)
In article <azWk8Os5gwrTw@idunno.Princeton.EDU> subbarao@phoenix.Princeton.EDU (Kartik Subbarao) writes: |In article <EcEkB=i00VsnE622gr@andrew.cmu.edu> bobg+@andrew.cmu.edu (Robert Steven Glickstein) writes: | |Is it the case that the only way to find out the current |>working directory is to do |> |> $cwd = `/bin/pwd`; |> chop $cwd; | |In the case that your shell sets a CWD or PWD environment variable, then you |can access it in perl by: | |$cwd = $ENV{'CWD'} (or PWD, or whatever). Be careful here - this only works if you will never have the Perl script run from a program or script written for an interpreter that does not keep $CWD correct. Tools should not be written to depend on being run in a very specialized context that can't be validated, unless you are absolutely sure that the will never be run from a different context (or evolve into something that will be run from a different context - there are many "temporary" programs around whose ages are measured in decades). -- Usenet is [like] the group of people who visit the | John Macdonald park on a Sunday afternoon. [...] luckily, most of | jmm@eci386 the people are staying on the paths and not pissing | on the flowers - Gene Spafford
lwall@jpl-devvax.jpl.nasa.gov (Larry Wall) (06/01/91)
In article <1991May31.161535.2023@eci386.uucp> jmm@eci386.UUCP (John Macdonald) writes: : In article <azWk8Os5gwrTw@idunno.Princeton.EDU> subbarao@phoenix.Princeton.EDU (Kartik Subbarao) writes: : |In article <EcEkB=i00VsnE622gr@andrew.cmu.edu> bobg+@andrew.cmu.edu (Robert Steven Glickstein) writes: : | : |Is it the case that the only way to find out the current : |>working directory is to do : |> : |> $cwd = `/bin/pwd`; : |> chop $cwd; : | : |In the case that your shell sets a CWD or PWD environment variable, then you : |can access it in perl by: : | : |$cwd = $ENV{'CWD'} (or PWD, or whatever). : : Be careful here - this only works if you will never have the Perl : script run from a program or script written for an interpreter that : does not keep $CWD correct. Tools should not be written to depend : on being run in a very specialized context that can't be validated, : unless you are absolutely sure that the will never be run from a : different context (or evolve into something that will be run from : a different context - there are many "temporary" programs around : whose ages are measured in decades). But also see pwd.pl in the Perl library. It uses the environment variable as a guess, but runs pwd if the guess is wrong. Thenceforth it can keep track of the current directory for you, as long as you call its chdir routine to do all your chdirs. My policy heretofore has been to drag my feet on adding routines that supply information that you only need once per process. Besides, it's good to force C programmers to use the toolbox occasionally. :-) Larry
hakanson@ogicse.ogi.edu (Marion Hakanson) (06/01/91)
In article <1991May31.181659.28817@jpl-devvax.jpl.nasa.gov> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >. . . >But also see pwd.pl in the Perl library. It uses the environment variable >as a guess, but runs pwd if the guess is wrong. Thenceforth it can keep >track of the current directory for you, as long as you call its chdir >routine to do all your chdirs. > >My policy heretofore has been to drag my feet on adding routines that >supply information that you only need once per process. Besides, it's >good to force C programmers to use the toolbox occasionally. :-) Second thing first: I disagree that you only need such information (the current working directory) once per process. In the presence of symbolic links, the only method I've come up with for finding the actual full path translation of a given path (relative or starting with "/") is to chdir() to the destination (or one "/" above, if it's not a directory) and to then find the "real" current directory. I have used this technique on more than one occasion, and without fail I have wished I didn't have to start up a "pwd" process to get this information. Now, to pwd.pl. It is quite unsatisfactory to me, in that it gives incorrect results in the presence of symbolic links. Under these (very common) conditions, the only way to find the current working directory is to ask the operating system. The alternative is to model the OS in your perl library. Most versions of Unix these days have a nice getwd() call -- I sure wish Perl could access it directly without running another program. ===== pwdtst ===== #!/usr/bin/perl require('pwd.pl'); &initpwd; $pwd = `pwd`; print "PWD=$ENV{'PWD'} pwd=$pwd"; &chdir($ARGV[0]) || die "Can't chdir($ARGV[0]): $!, aborted"; $pwd = `pwd`; print "PWD=$ENV{'PWD'} pwd=$pwd"; ================== === test script == Script started on Fri May 31 13:55:37 1991 ogicse 51% pwd /usr/etc ogicse 52% ls -lg local lrwxr-xr-x 1 root System 14 Apr 20 04:51 local -> /usr/local/etc ogicse 53% ~hakanson/perl/tests/pwdtst local PWD=/usr/etc pwd=/usr/etc PWD=/usr/etc/local pwd=/usr/local/etc ogicse 54% ~hakanson/perl/tests/pwdtst local/.. PWD=/usr/etc pwd=/usr/etc PWD=/usr/etc pwd=/usr/local ogicse 55% exit ogicse 56% script done on Fri May 31 13:56:51 1991 ================== -- Marion Hakanson Domain: hakanson@cse.ogi.edu UUCP : ogicse!hakanson