rpw3@fortune.UUCP (04/15/84)
#R:opus:-36700:fortune:26900045:000:799
fortune!rpw3 Apr 15 03:30:00 1984
This IS odd. I just tried it on 4.1bsd, and the same thing: "cannot open".
I also am a lazy typist, and when I know that a file exists, and there is
a unique path to it, I do as you do, for example:
fi*/ne*/art*/*info == file/net/articles/terminfo
'csh' (4.1bsd) ALLOWS "foo <fi*/ne*/art*/*info", 'sh' (4.1) doesn't. (If the
expansion is not unique, 'csh' says: "Ambiguous". I can dig it. It would be
asking a bit much for it to turn "foo <bar*" into "cat bar* | foo". ;-} )
This is weird since (as you note) 'sh' DOES allow "cd fi*/ne*/art*".
Therefore it MUST have a "ExpandUnique" (or some such) in it somewhere...
Rob Warnock
UUCP: {ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065wapd@houxj.UUCP (Bill Dietrich) (04/17/84)
I filed an MR to the BTL Unix maintainers a long time ago about this (not expanding wildcards after '<' and '>'). I was told that the reason was that this could easily lead to unintentional arguments : cat abc def >>x* expanding to : cat abc def >>x1 x2 x3 x4 which would be bad. My response was that not only is wildcarding dangerous in the current state (rm -fr x*), but there are cases where the shell silently ignores weird expansions (cd x*). They were unmoved. Bill Dietrich houxj!wapd
olson@fortune.UUCP (04/17/84)
#R:opus:-36700:fortune:26900046:000:1105 fortune!olson Apr 17 10:35:00 1984 > The reason that ``cat xyz*'' is expanded and ``cat <xyz*'' > is not has to do with the C getchar() call. cat takes any > arguments on the command line that don't start with a ``-'', > expands them, and interprets them as filenames. However, if > you use the ``<'' before the filename, the filename is actually > used as stdin and the filename is not put on the command line. > Therefore, cat thinks that you are typing in somthing from the > terminal. Hope this helps. > Curt Jeff Sampson > alberta!jeff This is totally mistaken, the expansion is done by the shell (in this case the Bourne shell). Only on non-unix systems that try to emulate Unix, (or have a different form of wild-card expansion), do the programs themselves do wild-card expansion. (There are, as always, exceptions even in programs that run under Unix.) I suspect, but have not verified, that the Bourne shell stops expanding wild cards after the >, <, and | chars (up to a terminal character, be it newline, &, or ;). (Those of you who have looked at the sh source know why I haven't verified it -:).) Dave Olson
olson@fortune.UUCP (04/18/84)
#R:opus:-36700:fortune:26900048:000:1047 fortune!olson Apr 18 10:17:00 1984 >> 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? > Tom Gloger > ihnp4!ltuxa!tty3b!tag The same as what the csh or sh does if you give it explicit names! The other files are passed as arguments to the command; (e.g. cat > a b), neither csh or sh care where the '> file' occurs in the command line. Unfortunately this is NOT what happens. If you have files a1 and a2, and type cat > a*, sh will (SILENTLY!) create a file called a* (as complained about in the original note), while csh complains 'a*: Ambiguous' (even if nonomatch is set). The basic complaint is that sh does NOT expand wild cards after >, <, <<, and >> (and their variants), while csh does. How ambiguity or lack of matches are handled is something else altogether! Dave Olson, Fortune Systems UUCP: {ihnp4,ucbvax!amd70}!fortune!olson ARPA: amd70!fortune!olson@BERKELEY
johnl@haddock.UUCP (04/19/84)
#R:opus:-36700:haddock:16700020:000:754 haddock!johnl Apr 18 11:47:00 1984 > The reason that ``cat xyz*'' is expanded and ``cat <xyz*'' >is not has to do with the C getchar() call. cat takes any >arguments on the command line that don't start with a ``-'', >expands them, and interprets them as filenames. However, if >you use the ``<'' before the filename, the filename is actually >used as stdin and the filename is not put on the command line. >Therefore, cat thinks that you are typing in somthing from the >terminal. Hope this helps. I wish that people who don't have the faintest idea what they're talking about would avoid "help" like this. Read the manual entry on the shell. (Sorry if this seems rude, but this is without a doubt the wrongest explanation of anything that I've ever seen.) John Levine, ima!johnl
andrew@orca.UUCP (Andrew Klossner) (04/24/84)
"'sh' DOES allow "cd fi*/ne*/art*". Therefore it MUST have a
"ExpandUnique" (or some such) in it somewhere..."
Nope, at least for the version distributed with 4.2BSD, which lets you
type
cd file1 file2 file3 ...
and treats it as "cd file1", ignoring the extra paths.
-- Andrew Klossner (decvax!tektronix!orca!andrew) [UUCP]
(orca!andrew.tektronix@rand-relay) [ARPA]