Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Denver Mods 4/2/84) 6/24/83; site drutx.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!hogpc!houxe!drutx!jas
From: jas@drutx.UUCP
Newsgroups: net.unix
Subject: Re: An odd difference between "cat file" and "cat<file"
Message-ID: <179@drutx.UUCP>
Date: Tue, 17-Apr-84 18:29:23 EST
Article-I.D.: drutx.179
Posted: Tue Apr 17 18:29:23 1984
Date-Received: Wed, 18-Apr-84 19:03:41 EST
References: <3723@utcsrgv.UUCP>, <367@opus.UUCP> <197@alberta.UUCP>, <227@pyuxnn.UUCP>, <342@tty3b.UUCP> <2420@allegra.UUCP>
Organization: AT&T Information Systems Laboratories, Denver
Lines: 52

(Goodness, what a long list of references!)

>>>  I frankly don't know why there is a difference between cat ab* and
>>>  cat <ab*.  It seems to me that file name expansion should be done
>>>  before anything else.

>>  So tell me, what would you expect to see if ab* matched two or more
>>  files?

> I would have expected an error message, of course.  I would also have
> expected an error message after typing
>
>	cat < abc abd
>
> In fact, both sh and csh silently ignore 'abc'.  (Surprise!)

No, sh and csh are NOT silently ignoring 'abc'!  They (or at least sh)
are setting the cat process's standard input to the file 'abc', which is
exactly what they are supposed to do.  cat does not read from file 'abc'
when it is invoked as above for the same reason that it does not read from
your terminal when you say 'cat /etc/passwd':  it only reads its standard
input when it is invoked with no arguments, or if one of its arguments is
'-'.

The position of the I/O redirection instruction on the command line is
immaterial.  Try "< /etc/passwd cat"!

Wild-card expansion after an I/O redirection operator could be handled in
any of these three ways:

(1)  Don't expand after an I/O redirection operator.  (That's the way it
     is now.)  The argument for this approach is that I/O redirection is
     not part of the command line the shell is building, but a meta-instruction
     to the shell.  Since file name expansion is usually used as shorthand
     for multiple file names, and the I/O redirection operators take a
     single file-name operand, file name expansion should not be done here.

(2)  Expand after an I/O redirection operator, but issue an error message
     and don't run the command if it expands to more than one file name.
     The argument in favor is that file name expansion is also used to
     save keystrokes on long file names, and that this will do what most
     people probably want and expect.

(3)  Let file name expansion be a straight textual expansion regardless of
     where it occurs.  The advantage is that it is simple.  The disadvantage
     is that when a filename expands to more than one file, the results may
     not be what the eager typist desired.  (Note that the shell does not
     expand command names, either.  How would you like to see "ca* /etc/passwd"
     handled?)

Jim Shankland
..!ihnp4!druxy!jas