jbr0@cbnews.att.com (joseph.a.brownlee) (10/09/90)
In article <1990Oct7.001518.14216@diku.dk>, kimcm@diku.dk (Kim Christian Madsen) writes: > [...] on my system (a SYSV) system, find perfoms > a getpwd(3C) each time it enters a directory, and getpwd(3) is by > standard implemented by forking a shell to do a pwd(1) in oorder [sic] > to get the result [...] While this is somewhat off the subject, I have to admit that I have always wondered why getpwd(3C) is implemented this way. It seems exactly backward from one what normally expects (and sees) in UNIX, where UNIX programs are based on underlying system or subroutine calls. Of course, this reversal causes the poor performance mentioned above. I guess I always assumed that this is the way it is for historical reasons rather than due to some sound technical concern, but I admit that I am in the dark on this one. I would appreciate any enlightenment the net can provide. Followups to c.u.programmer since this is more a programming issue than a shell issue. -- - _ Joe Brownlee, Analysts International Corp. @ AT&T Network Systems /_\ @ / ` 471 E Broad St, Suite 1610, Columbus, Ohio 43215 (614) 860-7461 / \ | \_, E-mail: jbr@cblph.att.com Who pays attention to what _I_ say? "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/11/90)
In article <1990Oct9.122813.1329@cbnews.att.com> jbr0@cbnews.att.com (joseph.a.brownlee) writes:
[ why is getpwd() implemented as `pwd` in System V? ]
Because there's no getwd() system call to have the kernel do the job.
Unless you have some sort of privileges, you won't be able to figure
out the current directory when any higher directory is unreadable.
---Dancpcahil@virtech.uucp (Conor P. Cahill) (10/11/90)
In article <1990Oct9.122813.1329@cbnews.att.com> jbr0@cbnews.att.com (joseph.a.brownlee) writes: > >While this is somewhat off the subject, I have to admit that I have always >wondered why getpwd(3C) is implemented this way. It seems exactly backward >from one what normally expects (and sees) in UNIX, where UNIX programs are >based on underlying system or subroutine calls. Of course, this reversal >causes the poor performance mentioned above. I don't know the reason for making it a call to popen(), one reason may have been security (pwd could be a setuid pgm and do things that a function call couldn't). Anyway, the reason that this has never been changes is probably that it is not the performance looser that you seem to think. No program should make more than one call to getpwd(), since it will then know where it is and has to know where it goes from there. For the relatively few programs that really need to know the full path of the current directory, making it a popen is probably not that bad of a decision. Note that I am not saying that it was a good decision, just that it might not be that bad of a decision. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
kimcm@diku.dk (Kim Christian Madsen) (10/11/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <1990Oct9.122813.1329@cbnews.att.com> jbr0@cbnews.att.com (joseph.a.brownlee) writes: > [ why is getpwd() implemented as `pwd` in System V? ] >Because there's no getwd() system call to have the kernel do the job. >Unless you have some sort of privileges, you won't be able to figure >out the current directory when any higher directory is unreadable. That's maybe the indirect reason, the rest is because of sloppy AT&T programmers, that figured that there was no reason to copy code from pwd(1) into the getpwd(3C) routine. SYSVR4 is supposed to eliminate this idiotic behaviour of getpwd(3C), and I pray that AT&T have learned from the negative response they have got, and do not try this path again. As a sidenote, Doug Gwyn released a PD getpwd(3C) routine some time ago, that behave as supposed. Check source archives for the source. Regards, Kim Chr. Madsen
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/11/90)
In article <1990Oct11.012643.11274@diku.dk> kimcm@diku.dk (Kim Christian Madsen) writes: > >In article <1990Oct9.122813.1329@cbnews.att.com> jbr0@cbnews.att.com (joseph.a.brownlee) writes: > > [ why is getpwd() implemented as `pwd` in System V? ] > >Because there's no getwd() system call to have the kernel do the job. > >Unless you have some sort of privileges, you won't be able to figure > >out the current directory when any higher directory is unreadable. > That's maybe the indirect reason, the rest is because of sloppy AT&T > programmers, that figured that there was no reason to copy code from > pwd(1) into the getpwd(3C) routine. They weren't sloppy. There certainly was a reason not to copy code into getpwd(). If getpwd() doesn't invoke any system calls and doesn't invoke any setuid programs, then it may not be able to figure out the current directory. That would be ungood. This is not an ``indirect'' reason. > SYSVR4 is supposed to eliminate this > idiotic behaviour of getpwd(3C), POSIX has the system call (why'd they have to use a different name?), so all modern UNIX versions have a fast getpwd(). ---Dan
gt0178a@prism.gatech.EDU (Jim Burns) (10/11/90)
in article <1990Oct10.231857.11668@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) says: > I don't know the reason for making it a call to popen(), one reason may > have been security (pwd could be a setuid pgm and do things that a > function call couldn't). Not on my system (see below). And what about those shells that have pwd builtin? My shell's pwd seems to work fine, and the shell isn't setuid either. -rwxr-xr-x 1 root 16384 Nov 17 1989 /bin/pwd* -rwxrwxr-x 2 root 152692 Sep 18 11:51 /usr/local/bin/ksh* -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
jetfuel@csusac.csus.edu (Dave Jenks) (10/11/90)
In article <28623:Oct1103:09:1990@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >They weren't sloppy. There certainly was a reason not to copy code into >getpwd(). If getpwd() doesn't invoke any system calls and doesn't invoke >any setuid programs, then it may not be able to figure out the current >directory. That would be ungood. Actually, pwd(1) has no better chance of being able to figure out the current directory than getpwd(3) could, since pwd follows the directory from "." to "/" using each directory's ".." entry. The obvious advantage of using getpwd(3) is that it need not create a new process, etc. which does the same thing. Just having it all in a library routine (even the EXACT same code) would be faster and less prone to possible (however unlikely) errors. An interesting side note to all this - pwd won't work in a directory which doesn't contain the "." and ".." entries, or part of the path does not. I guess you could keep someone from knowing where the program chdir()ed to... -- ======================================================================= "Pro is to con, as progress is to Congress..." >>-@@-> Dave Jenks {uunet | ucbvax!ucdavis}!csusac!jetfuel =======================================================================
cpcahil@virtech.uucp (Conor P. Cahill) (10/11/90)
In article <23012:Oct1019:12:2790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <1990Oct9.122813.1329@cbnews.att.com> jbr0@cbnews.att.com (joseph.a.brownlee) writes: > [ why is getpwd() implemented as `pwd` in System V? ] > >Because there's no getwd() system call to have the kernel do the job. >Unless you have some sort of privileges, you won't be able to figure >out the current directory when any higher directory is unreadable. However, on most, if not all, current system V implementatins pwd is not setuid and only has the privileges of the user who invoked it, so it won't make a difference as to whether it is a function or a pipe. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
cpcahil@virtech.uucp (Conor P. Cahill) (10/11/90)
In article <14976@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (Jim Burns) writes: >in article <1990Oct10.231857.11668@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) says: >> I don't know the reason for making it a call to popen(), one reason may >> have been security (pwd could be a setuid pgm and do things that a >> function call couldn't). > >Not on my system (see below). Note that I said "could have been". There are no systems that I know of that have pwd as setuid, I am just saying that from the way it was architectured (pipe to another program) implies that they a reason may have been that some version in the past may have required that pwd be setuid. I know this is not the case for UNIX > V6, but I don't know what went on before that. >And what about those shells that have pwd >builtin? My shell's pwd seems to work fine, and the shell isn't setuid >either. The shells that have pwd built-in usually don't run getpwd()/getcwd() to get the directory each time. They run it once at start up time and then keep track of where they go. This causes problems if you run pwd (the shell built-in) from a directory that you got to via a symbolic link and it gives you the incorrect information (whereas /bin/pwd will give you the right stuff). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
dce@smsc.sony.com (David Elliott) (10/11/90)
In article <1990Oct11.044435.3729@csusac.csus.edu> jetfuel@csusac.UUCP (Dave Jenks) writes: >Actually, pwd(1) has no better chance of being able to figure out the >current directory than getpwd(3) could, since pwd follows the >directory from "." to "/" using each directory's ".." entry. This discussion has gotten very off-track. Dave, you must realize that not all systems are the same. There are systems on which pwd(1) is setuid root, just as there are systems without a mkdir(2) system call that have a setuid mkdir(1) command. These aren't BSD, and they may be considered archaic, but they do exist. The fact now is that SVR4, which is supposed to be POSIX-conformant, does not have a setuid version of pwd, and its version of getcwd(3C) works just like the BSD getwd(3) routine.
dkeisen@Gang-of-Four.Stanford.EDU (Dave Eisen) (10/11/90)
in article <1990Oct10.231857.11668@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) says: > I don't know the reason for making it a call to popen(), one reason may > have been security (pwd could be a setuid pgm and do things that a > function call couldn't). Another possibility is pointed up by the snippet from our man page for getwd: * Getwd changes directories (uses the system call chdir) to figure out which directory you are in. If there is an error, getwd may not be able to change back to the directory you were in when you called it. If this occurs, any files created will be in the wrong place. Or what if the permissions on your current directory have changed since it became your current directory and you can't chdir back to it? These problems go away if getwd is done by a different process. -- Dave Eisen Home: (415) 323-9757 dkeisen@Gang-of-Four.Stanford.EDU Office: (415) 967-5644 1447 N. Shoreline Blvd. Mountain View, CA 94043
cowan@marob.masa.com (John Cowan) (10/12/90)
In article <14976@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (Jim Burns) writes: >in article <1990Oct10.231857.11668@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) says: >> I don't know the reason for making it a call to popen(), one reason may >> have been security (pwd could be a setuid pgm and do things that a >> function call couldn't). > >Not on my system (see below). And what about those shells that have pwd >builtin? My shell's pwd seems to work fine, and the shell isn't setuid >either. > >-rwxr-xr-x 1 root 16384 Nov 17 1989 /bin/pwd* >-rwxrwxr-x 2 root 152692 Sep 18 11:51 /usr/local/bin/ksh* Try saying 'chmod u-rwx .' and then '/bin/pwd'. You'll probably get something like "pwd: can't stat .", at least that's what I get. (This assumes your system doesn't have a built-in get[p]wd() call. If it does, all bets are off.) /bin/pwd should be setuid root so that it doesn't get this error. -- cowan@marob.masa.com (aka ...!hombre!marob!cowan) e'osai ko sarji la lojban
chet@cwns1.INS.CWRU.Edu (Chet Ramey) (10/12/90)
In article <23012:Oct1019:12:2790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <1990Oct9.122813.1329@cbnews.att.com> jbr0@cbnews.att.com (joseph.a.brownlee) writes: > [ why is getpwd() implemented as `pwd` in System V? ] > >Because there's no getwd() system call to have the kernel do the job. BSD doesn't have one either; it's a library routine, at least through 4.3-tahoe. By the way, the name of the Posix (and S5) routine is getcwd(). Chet -- Chet Ramey ``As I recall, Doug was keen on boxing. But Network Services Group when he learned to walk, he took up puttin' Case Western Reserve University the boot in the groin.'' chet@ins.CWRU.Edu
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/12/90)
In article <2714A558.14A8@marob.masa.com> cowan@marob.masa.com (John Cowan) writes:
: /bin/pwd should be setuid root so that it doesn't get this error.
And then you get to watch it blow up as it tries to traverse an NFS filesystem
that doesn't export root privs. Ya can't win...
Larry Wall
lwall@jpl-devvax.jpl.nasa.govdel@thrush.mlb.semi.harris.com (Don Lewis) (10/12/90)
In article <2714A558.14A8@marob.masa.com> cowan@marob.masa.com (John Cowan) writes: >>in article <1990Oct10.231857.11668@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) says: >>> I don't know the reason for making it a call to popen(), one reason may >>> have been security (pwd could be a setuid pgm and do things that a >>> function call couldn't). >> >Try saying 'chmod u-rwx .' and then '/bin/pwd'. You'll probably get >something like "pwd: can't stat .", at least that's what I get. >(This assumes your system doesn't have a built-in get[p]wd() call. >If it does, all bets are off.) > >/bin/pwd should be setuid root so that it doesn't get this error. If the current directory (or another directory higher in the tree) is not publicly readable and lives on an NFS mounted filesystem which maps root to nobody, then making /bin/pwd setuid root will break it. In this case running /bin/pwd as the real user will work. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/12/90)
In article <1990Oct11.191936.10947@usenet.ins.cwru.edu> chet@po.CWRU.Edu writes: > In article <23012:Oct1019:12:2790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >In article <1990Oct9.122813.1329@cbnews.att.com> jbr0@cbnews.att.com (joseph.a.brownlee) writes: > > [ why is getpwd() implemented as `pwd` in System V? ] > >Because there's no getwd() system call to have the kernel do the job. > BSD doesn't have one either; it's a library routine, at least through > 4.3-tahoe. I was explaining the logic of having a setuid program. *If* you decide that pwd should work despite permissions, and *if* you don't have a getwd() system call to do the job, then you have to use a separate setuid program. It's also proper to call anything in the POSIX book a system call. > By the way, the name of the Posix (and S5) routine is getcwd(). In the article you're responding to, I complained about this. RTFABYFU. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/12/90)
In article <1990Oct11.140654.22117@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: > The shells that have pwd built-in usually don't run getpwd()/getcwd() to > get the directory each time. They run it once at start up time and then > keep track of where they go. This causes problems if you run pwd (the > shell built-in) from a directory that you got to via a symbolic link > and it gives you the incorrect information (whereas /bin/pwd will give > you the right stuff). But the shell can read the symbolic link and figure out where it's going. It can detect race conditions as follows: lstat() to tell it's a symbolic link, readlink(), figure out the pathname of the target directory, stat() the target directory, chdir() to the symbolic link, stat(".") to make sure everything's okay, and getwd() in the exceptional situation that the link or target has moved. The real problem is that the directory could be moved, or even removed, without the shell finding out. ---Dan
tim@delluk.uucp (Tim Wright) (10/12/90)
In <23012:Oct1019:12:2790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <1990Oct9.122813.1329@cbnews.att.com> jbr0@cbnews.att.com (joseph.a.brownlee) writes: > [ why is getpwd() implemented as `pwd` in System V? ] >Because there's no getwd() system call to have the kernel do the job. >Unless you have some sort of privileges, you won't be able to figure >out the current directory when any higher directory is unreadable. >---Dan Well I can't speak for all System V's but all the ones I have used don't have /bin/pwd suid anyway so that's no excuse. It would still be *massively* more efficient to do the work pwd does in a library call (i.e. stat back up the tree), than it is to fork and exec another command ! It just looks like people were very lazy (it couldn't have been that difficult to copy the pwd code to the library). $ cd junk $ chmod 700 junk $ chown somebody_else junk $ pwd pwd: cannot stat .! Yuk ! Tim -- Tim Wright, Dell Computer Corp. (UK) | Email address Dell Computer Corp. (UK), Bracknell | Domain: tim@dell.co.uk Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim "What's the problem? You've got an IQ of six thousand, haven't you?"
guy@auspex.auspex.com (Guy Harris) (10/13/90)
>> > [ why is getpwd() implemented as `pwd` in System V? ] >> >Because there's no getwd() system call to have the kernel do the job. OK, so why *isn't* "getwd()" implemented as `pwd' in BSD? After all, there isn't a "getwd()" system call in BSD to have the kernel do the job, either, at least as of 4.3-tahoe. There's a "getwd()" routine, but it ain't a "system call", it's more-or-less the algorithm "pwd" uses, turned into a subroutine.... >> >Unless you have some sort of privileges, you won't be able to figure >> >out the current directory when any higher directory is unreadable. > >They weren't sloppy. There certainly was a reason not to copy code into >getpwd(). If getpwd() doesn't invoke any system calls and doesn't invoke >any setuid programs, then it may not be able to figure out the current >directory. That would be ungood. This is not an ``indirect'' reason. The "pwd" command isn't set-UID on any UNIX systems I've run across, so regardless of *how* the *NON*-kernel implementation of "get the current working directory" in those systems happens to be done, it can't figure out the current directory when any higher directory is unreadable.... >POSIX has the system call Bzzt! Sorry, wrong answer, next contestant please. POSIX has *NO* "system calls", in the sense of "stuff that traps into a kernel that can do stuff user-mode code can't". POSIX has a bunch of *function calls*, and doesn't specify *how* they're implemented. >(why'd they have to use a different name?), Because it's a different call from "getwd()". It takes a "buffer size" argument that limits the number of characters that will be stuffed into the first argument. I.e., they standardized the *interface* from S5, not the *interface* from BSD.
ewv@craycos.com (Eric Varsanyi) (10/13/90)
In article <1990Oct11.012643.11274@diku.dk> kimcm@diku.dk (Kim Christian Madsen) writes: >That's maybe the indirect reason, the rest is because of sloppy AT&T >programmers, that figured that there was no reason to copy code from >pwd(1) into the getpwd(3C) routine. SYSVR4 is supposed to eliminate this >idiotic behaviour of getpwd(3C), and I pray that AT&T have learned from >the negative response they have got, and do not try this path again. > Getcwd.c in SVR4 does not use popen/system. It does what you might expect (walks up the tree using '.' and '..'). -- -Eric Varsanyi (ewv@craycos.com) Cray Computer Corporation
andrew@alice.att.com (Andrew Hume) (10/13/90)
In article <1990Oct11.012643.11274@diku.dk>, kimcm@diku.dk (Kim Christian Madsen) writes: > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > >In article <1990Oct9.122813.1329@cbnews.att.com> jbr0@cbnews.att.com (joseph.a.brownlee) writes: > > [ why is getpwd() implemented as `pwd` in System V? ] > ... > That's maybe the indirect reason, the rest is because of sloppy AT&T > programmers, that figured that there was no reason to copy code from > pwd(1) into the getpwd(3C) routine. SYSVR4 is supposed to eliminate this > idiotic behaviour of getpwd(3C), and I pray that AT&T have learned from > the negative response they have got, and do not try this path again. at&t, as are other large vendors, is responsible for some terrible code but this is really a poor choice to attack them on. as has been pointed out, a safe getpwd() routine has to fork so that chdir failures do not ruin the calling program's working dir. and if you are going to fork anyway, popen("pwd") sounds like unobjectionable overhead UNLESS you call getpwd() a whole lot. now, if your objection is why didn't at&t recode pwd into just calling a subroutine (that does its own fork and pipes etc), and i agree that in the long run this might have been better, then the answer is probably the regular one (its not broken, there are no MRs on it, don't bother it). i still don't understand why people get so uptight about how getpwd() is implemented. it took years to get anyone to pay any attention to implementing stdio efficiently and that hurts billions more programs ALL the time mor ethan getpwd() ever will. get a sense of proportion. andrew hume
cpcahil@virtech.uucp (Conor P. Cahill) (10/13/90)
In article <tim.655748499@holly> tim@delluk.uucp (Tim Wright) writes: >Well I can't speak for all System V's but all the ones I have used don't >have /bin/pwd suid anyway so that's no excuse. It would still be *massively* >more efficient to do the work pwd does in a library call (i.e. stat back How do you define *massively*? Is it really important to you that if you ran getcwd 1,000 times in a loop that it would take much longer to run than if it was not a popen()? Look at it from the system standpoint. getcwd/getpwd are seldom used functions, so the relative performance of the two implementations will not have any effect on the overall system performance (or even on the overall performance of a non-trivial application). Here is a portion of the output from my system accounting last month: TOTAL COMMAND SUMMARY COMMAND NUMBER TOTAL TOTAL TOTAL MEAN MEAN HOG NAME CMDS KCOREMIN CPU-MIN REAL-MIN SIZE-K CPU-MIN FACTOR TOTALS 646704 1876.70 2071.13 907889.81 0.91 0.00 0.00 pwd 689 1.90 0.61 2.72 3.10 0.00 0.22 Note that only 689 pwd's were run in an entire month. This includes command line pwds that weren't built-in to the respective shells, all calls to getcwd, etc. If you were to change this so that the calls to pwd were saved by implementing the pwd function that was soooooooo efficient that it used up zero time it would only change the total CPU by .61 minutes (or approx .02% - that is not a typo - the change is just 2 one-hundreds of one percent). I wouldn't make any changes to a system for that little of a gain. >up the tree), than it is to fork and exec another command ! It just looks >like people were very lazy (it couldn't have been that difficult to copy >the pwd code to the library). I wouldn't say lazy. Just realistic. Why change something that isn't broken? -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
tchrist@convex.COM (Tom Christiansen) (10/14/90)
In article <1990Oct13.121552.3878@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >TOTALS 646704 1876.70 2071.13 907889.81 0.91 0.00 0.00 >pwd 689 1.90 0.61 2.72 3.10 0.00 0.22 > >Note that only 689 pwd's were run in an entire month. This includes >command line pwds that weren't built-in to the respective shells, all >calls to getcwd, etc. Well, on my system, I've got around twice your total of commands (1.2meg), but I've got 8000 calls to pwd, plus 27000 calls to the csh, who runs a getwd() when he starts up. I'm glad my system doesn't do the fork/exec to get its working directory. But I agree that "massively" faster is probably an overstatement. Programs shouldn't need to do more than one of these per run. I'm not expecting to lose the permissions on an enclosing directory very much. If anything, I'd be concerned about losing the very directory itself, something that a suid pwd won't solve. --tom
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (10/14/90)
In article <23012:Oct1019:12:2790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: | Because there's no getwd() system call to have the kernel do the job. | Unless you have some sort of privileges, you won't be able to figure | out the current directory when any higher directory is unreadable. There were earlier version of UNIX which lackled the call (it's getcwd, by the way), but it's in recent versions of SysV, Xenix, etc. And there was never a reason to do more than one, and /bin/pwd is a program which could be run directly, father than by forking a shell as noted in the original posting, etc. In other words there's no reason for a problem, it's just a bad implementation one that system. Also, until I looked at the accounting file, I find it hard to believe that the fork happens more than once on any system. I don't say it doesn't, just that I want to see it. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
guy@auspex.auspex.com (Guy Harris) (10/14/90)
> * Getwd changes directories (uses the system call chdir) to figure out > which directory you are in. If there is an error, getwd may not be > able to change back to the directory you were in when you called it. > If this occurs, any files created will be in the wrong place. That may be true on your system - the 4.2BSD "getwd()" routine did, in fact, use "chdir()" - but it's not ture on all systems; the 4.3BSD "getwd()" doesn't use "chdir()".
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/14/90)
In article <4182@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > >> > [ why is getpwd() implemented as `pwd` in System V? ] > >> >Because there's no getwd() system call to have the kernel do the job. > OK, so why *isn't* "getwd()" implemented as `pwd' in BSD? Because the BSD programmers, unlike the AT&T programmers, decided that not being able to figure out your current directory (if you couldn't get to it from root) wasn't a problem at all. > >POSIX has the system call > Bzzt! Sorry, wrong answer, next contestant please. POSIX has *NO* > "system calls", Oh, give it a rest. Everything in the POSIX book is a system call. Sure, some calls might not be implemented inside the kernel---and BSD stat() might not be implemented inside the kernel either. (It can be written in terms of lstat() and readlink(), for example.) ---Dan
cpcahil@virtech.uucp (Conor P. Cahill) (10/14/90)
In article <21628:Oct1400:12:2990@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >and BSD >stat() might not be implemented inside the kernel either. (It can be >written in terms of lstat() and readlink(), for example.) Actually, to maintain binary compatibility with earlier code it has to be implemented in the kernel. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
richard@aiai.ed.ac.uk (Richard Tobin) (10/16/90)
In article <11478@alice.att.com> andrew@alice.att.com (Andrew Hume) writes: > as has been pointed out, a safe getpwd() routine has to fork so that > chdir failures do not ruin the calling program's working dir. Why does getpwd() have to chdir()? -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
boyd@necisa.ho.necisa.oz (Boyd Roberts) (10/22/90)
In article <21628:Oct1400:12:2990@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Oh, give it a rest. Everything in the POSIX book is a system call. POSIX specifies an _interface_. A system call is specific to the implementation and not to the _interface_. An _interface_ may be implemented as a system call. Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
decot@hpisod2.cup.hp.com (Dave Decot) (11/02/90)
Everything (at least everything one might think of calling a "system call" or "library routine" or "subroutine") in POSIX is called a "function". Implementation is irrelevant! You will conform! Dave