barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (08/19/88)
I think I have found another bug with csh (surprise! :-) Systems: SunOS 4.0, Ultrix 2.3. any many many more. try this: echo ls >/tmp/a `cat /tmp/a` results: ls: Command not found. try echo /bin/ls >/tmp/a `cat /tmp/a` works But `/tmp/a` gives: a: permission denied : permission denied Why two errors? Now when I try: `junkname` where junkname does not exist, I get: junkname: Command not found /usr/ucb/: Permission denied Sometimes the directory is different from /usr/ucb/: Let's hear it for ad-hoc parsing. Is this a known bug? -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
greim@sbsvax.UUCP (Michael Greim) (08/20/88)
In article <5144@vdsvax.steinmetz.ge.com>, barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) writes: > I think I have found another bug with csh (surprise! :-) > Systems: SunOS 4.0, Ultrix 2.3. any many many more. > [stuff deleted] > But > `/tmp/a` > gives: > a: permission denied > : permission denied > Why two errors? The text within "`" is tried as a command, this is responsible for the first error. The result, a Null string, is returned. Then the csh tries to execute this result, a Null string. As this string does not start with a "/" csh searches for a file with this name in the directories specified in your path. It does so by trying to open the file in the directories of your path. The first try matches (!!). But as this file is most probably "." it cannot execute it, and this is responsible for the second error message. The string which is output, saying what file caused the error may vary with different implementations of csh or dir library routines. With my machines here, it is the empty (Null) string. Yes it is a bug but not only in csh. Csh should realize that the command's first word is empty. Try "cat ''" and you will get the contents of "." for the same reason : the first argument to cat is the Null string. The bug is really with open(2) and/or exec(2). I had it fixed for some time so that csh did not pass Null strings as parameters, but had to remove it for some reason, which does not come to my mind just now. Maybe test(1) did not perform correctly ? > > Now when I try: > `junkname` > where junkname does not exist, I get: > junkname: Command not found > /usr/ucb/: Permission denied Should be an effect of the same mechanism. -mg -- UUCP: ...!uunet!unido!sbsvax!greim | Michael T. Greim or greim@sbsvax.UUCP | Universitaet des Saarlandes CSNET: greim%sbsvax.uucp@Germany.CSnet| FB 10 - Informatik (Dept. of CS) ARPA: greim%sbsvax.uucp@uunet.UU.NET | Bau 36, Im Stadtwald 15 voice: +49 681 302 2434 | D-6600 Saarbruecken 11, West Germany # include <disclaimers/std.h>
flee@blitz (Felix Lee) (08/29/88)
In <5144@vdsvax.steinmetz.ge.com>, Bruce G. Barnett writes: > echo ls >/tmp/a > `cat /tmp/a` > results: > ls: Command not found. This is because csh tries to glob the command name: if you type "f*" and "f*" expands (uniquely) to "foo", then csh will execute "foo" without ever looking at your PATH. ("foo" will get executed even if "." isn't in your PATH.) And the globbing routine also tries backquote substitution. So the globbing succeeds, and csh ignores your PATH. Intuitively obvious, no? -- Felix Lee *!psuvax1!flee
greim@sbsvax.UUCP (Michael Greim) (08/30/88)
In article <3869@psuvax1.cs.psu.edu>, flee@blitz (Felix Lee) writes: = In <5144@vdsvax.steinmetz.ge.com>, Bruce G. Barnett writes: = > echo ls >/tmp/a = > `cat /tmp/a` = > results: = > ls: Command not found. = = This is because csh tries to glob the command name: if you type = "f*" and "f*" expands (uniquely) to "foo", then csh will execute = "foo" without ever looking at your PATH. ("foo" will get executed = even if "." isn't in your PATH.) Try it. csh looks at PATH, even if you use `...` or "*". "f*" will get expanded, because csh still knows your current working directory. But when it tries to execute the file foo it will give : "command not found". = = And the globbing routine also tries backquote substitution. So = the globbing succeeds, and csh ignores your PATH. On my machine the above produces a listing of files in the current directory. The reason for the "ls: Command not found" is most probably that /bin, or wherever ls might be, is not in PATH. -mg -- UUCP: ...!uunet!unido!sbsvax!greim | Michael T. Greim or greim@sbsvax.UUCP | Universitaet des Saarlandes CSNET: greim%sbsvax.uucp@Germany.CSnet| FB 10 - Informatik (Dept. of CS) ARPA: greim%sbsvax.uucp@uunet.UU.NET | Bau 36, Im Stadtwald 15 voice: +49 681 302 2434 | D-6600 Saarbruecken 11, West Germany # include <disclaimers/std.h>
hwt@leibniz.UUCP (Henry Troup) (08/30/88)
These bugs are also in SunOS 3.4 and 3.5 -- Henry Troup Bell Northern Research - not their opinions, however utgpu!bnr-vpa!bnr-di!leibniz!hwt