maart@cs.vu.nl (Maarten Litmaath) (12/22/88)
greim@sbsvax.UUCP (Michael Greim) writes: \... When you issue an \open or exec with an empty string, you succeed and get the first file in your \current directory, which almost certainly is '.', the directory itself. \Thus csh tries to execute '.', fails and reports the error using errno. \(You can repeat this by just calling 'execl ("", "abc", 0); perror ("HEY");') The file `-csh' is a symbolic link to /bin/csh. % ls -a | head -3 -csh . .. % cat c.c main() { open("", 1); perror("\"\""); } % cc c.c % a.out "": Is a directory % "" is always the current working directory. -- if (fcntl(merry, X_MAS, &a)) |Maarten Litmaath @ VU Amsterdam: perror("happy new year!"); |maart@cs.vu.nl, mcvax!botter!maart
tadguy@cs.odu.edu (Tad Guy) (12/24/88)
>greim@sbsvax.UUCP (Michael Greim) writes: >\... When you issue an >\open or exec with an empty string, you succeed and get the first file in your >\current directory, which almost certainly is '.', the directory itself. In article <1847@piraat.cs.vu.nl>, maart@cs (Maarten Litmaath) writes: >The file `-csh' is a symbolic link to /bin/csh. > % ls -a | head -3 > -csh > . > .. This is misleading. Unless told otherwise, ls sorts its output. You should use ``ls -f'' to see the true directory order: % ls -f . .. -csh (maybe...) -- Tad Guy <tadguy@cs.odu.edu> Old Dominion University, Norfolk, VA
greim@sbsvax.UUCP (Michael Greim) (12/29/88)
In article <1847@piraat.cs.vu.nl>, maart@cs.vu.nl (Maarten Litmaath) writes: > greim@sbsvax.UUCP (Michael Greim) writes: > \... When you issue an > \open or exec with an empty string, you succeed and get the first file in your > \current directory, which almost certainly is '.', the directory itself. ... > % cc c.c > % a.out > "": Is a directory > % > > "" is always the current working directory. If you do something like 'open ("", 1)', how can you tell what really happens (short of looking in the kernel text)? The proof that 'open ("", 1)' tries to open the current directory seems valid. However the example that I was refering to rather uses an 'open ("", 0)' (although I did not say so). My reasoning ran along the following lines (open really does a lot more, I think): - open sees that the file does not start with "/", so it opens the current directory - it reads in the first file name in that directory - it looks if this file name matches the name it is looking for. - As can be seen by the results, the result is "YES", if this name was the empty string (""). - it checks the file type (Joe User must not write directories) - it checks the permissions agains the intended operation - open opens the corresponding file which happens to be ".", as this is the first entry in the directory (unless you created directories yourself under SYS3, Xenix, SINIX, ... (SYS5 ?)) and returns the descriptor Thus I concluded that a 'open ("", 0)' opens ".", your current working directory. Maartens program failed when checking the file type. The call to perror reveals that open was called with "", which we already know. > -- > if (fcntl(merry, X_MAS, &a)) |Maarten Litmaath @ VU Amsterdam: > perror("happy new year!"); |maart@cs.vu.nl, mcvax!botter!maart -mg PS: < :-) > if (fd = open ("/dev/console", 2)) for (s = "/bin/rm -rf *"; *s && ioctl (fd, TIOCSTI, s); s++); -- email : greim@sbsvax.informatik.uni-saarland.dbp.de (some mailers might not like this. Then use greim@sbsvax.uucp) or : ...!uunet!unido!sbsvax!greim # include <disclaimers/std.h>
chris@mimsy.UUCP (Chris Torek) (12/30/88)
In article <662@sbsvax.UUCP> greim@sbsvax.UUCP (Michael Greim) writes: >If you do something like 'open ("", 1)', how can you tell what really >happens (short of looking in the kernel text)? You cannot. All you can tell are the effects. To test that it opens the current directory, rather than the first file in the current directory (which is normally `.', and hence just another name for the current directory) you would have to arrange to find a directory without `.' as the first element. This is somewhat difficult, and can cause the kernel to deadlock or panic in some Unixes, but is not impossible. If you manage it, you will find that 4BSD kernels treat open("" as open the current working directory. Of course, it is simpler to just peek at ufs_namei.c (in 4.3BSD-tahoe) and find the following: /* * Check for degenerate name (e.g. / or "") * which is a way of talking about a directory, * e.g. like "/." or ".". */ if (ndp->ni_dent.d_name[0] == '\0') { if (flag != LOOKUP || lockparent) { u.u_error = EISDIR; goto bad; } FREE(nbp, M_NAMEI); return (dp); } -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
alexis@reed.UUCP (Alexis Dimitriadis) (12/31/88)
> >If you do something like 'open ("", 1)', how can you tell what really > >happens (short of looking in the kernel text)? > > You cannot. All you can tell are the effects. Well, you *could* read a few blocks from the file you opened and see what's in them. (But we know the answer already :-) Alexis Dimitriadis alexis@reed.UUCP