Xref: utzoo comp.bugs.4bsd:927 comp.unix.questions:9034 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!mcvax!unido!sbsvax!greim From: greim@sbsvax.UUCP (Michael Greim) Newsgroups: comp.bugs.4bsd,comp.unix.questions Subject: Re: Another bug with csh - `cat /tmp/a` Keywords: Ad-hoc parsing csh bug Message-ID: <620@sbsvax.UUCP> Date: 30 Aug 88 11:30:41 GMT References: <5144@vdsvax.steinmetz.ge.com> <604@sbsvax.uucp> <3869@psuvax1.cs.psu.edu> Organization: Universitaet des Saarlandes, Saarbruecken, West Germany Lines: 32 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