Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!apple!rutgers!njin!princeton!phoenix.Princeton.EDU!pfalstad From: pfalstad@phoenix.Princeton.EDU (Paul John Falstad) Newsgroups: comp.unix.internals Subject: Re: replacement getwd(3). Message-ID: <3907@idunno.Princeton.EDU> Date: 7 Nov 90 20:52:12 GMT References: <1431@carol.fwi.uva.nl> Sender: news@idunno.Princeton.EDU Organization: Princeton University, Princeton, New Jersey Lines: 30 In article eric@mks.com (Eric Gisin) writes: >In article <1431@carol.fwi.uva.nl> casper@fwi.uva.nl (Casper H.S. Dik) writes: > I've written a replacement getwd(3) for SunOS 4.x that returns ~user/tail > (with ~user expanded as in /etc/passwd) if the current directory > is a subdirectory of a user's home directory. > [The original might return: /tmp_mnt/foo/bar/bletch/usrs/casper/dir > the new returns /usr/casper/dir] > My question is: what utilities (if any) will break because of this? >Ideally none would break, because any properly written program >on SysV or SunOS would use getcwd(), not getwd(). >Any program that effectively does chdir(getwd()) would break >with your getwd. ~ expansion is handled by applications, >not libc and the kernel. I _think_ he meant that whenever the old getwd() would return the actual path to a users home directory, the new one will use the symbolic link listed in /etc/passwd. At least I infer that opinion the example he gave. He didn't really mean getwd would return ~ -- anyone smart enough to write a library function like this would _probably_ be smart enough to know that the shell expands ~. It's probably not such a good idea to replace the library function, though. Applications which depend on the result of getwd() to be hard paths free of symbolic links will break. I don't know of any offhand though... -- Paul Falstad, pfalstad@phoenix.princeton.edu PLink:HYPNOS GEnie:P.FALSTAD "Your attention, please. Would anyone who knows where the white courtesy phone is located please pick up the white courtesy phone."