lm@snafu.Sun.COM (Larry McVoy) (02/04/89)
Hi-
A question for oldtimers: is there any good reason that null paths
(ie, open("", flags)) should NOT be considered an error. If you don't
already know that many kernels translate "" into "." you probably
can't answer this question. POSIX wants "" to be an error.
Thanks,
Larry McVoy, Lachman Associates. My opinions are that.gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/04/89)
In article <88368@sun.uucp> lm@sun.UUCP (Larry McVoy) writes: > A question for oldtimers: is there any good reason that null paths > (ie, open("", flags)) should NOT be considered an error. If you don't > already know that many kernels translate "" into "." you probably > can't answer this question. POSIX wants "" to be an error. We've discussed this before (Dennis even chipped in). From one point of view "" is a natural way to designate the CWD. However, it can lead to unpleasant surprises in usages such as: strcat( strcat( strcat( strcpy( cmd, "rm " ), dir ), "/" ), file ); system( cmd ); Also, "" is often the result of program bugs and having it be an illegal pathname is safer than letting the operation occur.
casper@uva.UUCP (Casper H.S. Dik) (02/04/89)
In article <88368@sun.uucp> lm@sun.UUCP (Larry McVoy) writes: >Hi- > A question for oldtimers: is there any good reason that null paths > (ie, open("", flags)) should NOT be considered an error. If you don't > already know that many kernels translate "" into "." you probably > can't answer this question. POSIX wants "" to be an error. > >Thanks, > >Larry McVoy, Lachman Associates. My opinions are that. I'm not an oldtimer, but I think that disallowing the null path would break many programs. The main reason why kernels translate "" into "." is beacause of paths containing //. Try: % cp -i vmunix / it responds with: replace //vmunix? Many more programs are affected by this. They all think <validdir>/<file> will always give a valid pathname. If validdir = "/" this breaks. If POSIX still allows // in pathnames (do they?), then they disallow only one special case of null paths, I would say that that's a bad idea. --cd ____________________________________________________________________________ Casper H.S. Dik University of Amsterdam | dik@uva.uucp The Netherlands | ...!uunet!mcvax!uva!dik
lm@snafu.Sun.COM (Larry McVoy) (02/06/89)
In article <613@uva.UUCP{ dik@uva.UUCP (Casper H.S. Dik) writes: {In article <88368@sun.uucp> lm@sun.UUCP (Larry McVoy) writes: {> A question for oldtimers: is there any good reason that null paths {> (ie, open("", flags)) should NOT be considered an error. If you don't ^^ {I'm not an oldtimer, but I think that disallowing the null path {would break many programs. { {The main reason why kernels translate "" into "." is beacause of paths {containing //. Try: {% cp -i vmunix / A number of people misinterpreted my question. When I say ``null path'' I do not mean ``null path component''. I mean a path where strlen(path) == 0, *path == 0, etc, etc. Larry McVoy, Lachman Associates. My opinions are that.
dce@stan.UUCP (David Elliott) (02/07/89)
In article <88368@sun.uucp> lm@sun.UUCP (Larry McVoy) writes: > A question for oldtimers: is there any good reason that null paths > (ie, open("", flags)) should NOT be considered an error. If you don't There are programs that will break, but in some cases it's just due to sloppiness. I ported the 4.3BSD tar to System V.3 last year, and found that it depended on "" being a legal name. I seem to recall that the fix in this case involved ignoring the case of the current path being "", not changing it to "", since it was a redundant or useless check. I'm sorry I can't be more specific. Maybe someone at MIPS can check the source, or maybe someone that archives comp.bugs.4bsd can look to see if I posted the fix (sometime around last August, I think). -- David Elliott ...!pyramid!boulder!stan!dce