Why does this code works without cat ?

[Eric Pozharski]

I'm sorry. I had not realized that we're not allow to discuss
redirecting output. Thank you for clarifying.

You understand difference between redirecting *one* input stream and
redirecting *two* output streams, don't you?

*CUT* [[ 'wc' is meta-syntactic, just like above ]]

 

[Eric Pozharski]

Quoth Eric Pozharski <[email protected]>: *SKIP*
Well, if you insist:

*SKIP*

I have to read it around. In order to lay hands on this I have to
register, what will take some time. Maybe some kind soul would point to
some pirated copy, but I guess not.

*SKIP* [[ no reason to quote unparsable ]]

I can't parse either of those paragraphs. In any case, this has nothing
whatever to do with bash: this is the way shish shells have behaved
since the Bourne shell.

Right. There's no need to implement a feature that noone uses. Noone
uses a feature because it's not implemented. zsh still wins.

 

[Rainer Weikusat]

*SKIP*

I have to read it around. In order to lay hands on this I have to
register, what will take some time. Maybe some kind soul would point to
some pirated copy, but I guess not.

Since the UNIX(*) standard is available for free (except that you
have to register), I doubt that someone would want to 'pirate' it ...

 

[Peter J. Holzer]

More generally, if the extension had used syntax which was previously
invalid, like the similar N<(cmd args) extension implemented by both zsh
and bash (but not ksh), there would have been no problem. In this case,
though, the syntax chosen *was* previously valid sh syntax, so zsh's
designers should have realised someone somewhere was probably using it
with its sh meaning, and chosen something else.

They probably did realize that and didn't care. The zsh is not intended
to be bourne shell compatible. It started as "mostly bourne shell, but
with the good parts of csh mixed in" and grew from there. There are
other differences, too - for example parameter expansion differs
significantly from the bourne shell - not by mistake, but because the
zsh developers considered the bourne shell broken in this regard and
decided to fix it. (The POSIX shell can never fix that - it must remain
backwards compatible)

hp

 

[Peter J. Holzer]

*SKIP*

I have to read it around. In order to lay hands on this I have to
register, what will take some time. Maybe some kind soul would point to
some pirated copy, but I guess not.

Try this link: http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm

Not pirated, just a deep link.

hp

 

[Eric Pozharski]

*SKIP*

Try this link: http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm

Not pirated, just a deep link.

Thank you kind soul for this pirated copy! Already reading.

As of registration, I guess, I've failed just as two years ago. I must
be from an "organisation". And I'm not.

 

[Eric Pozharski]

Quoth Eric Pozharski <[email protected]>:
*SKIP*
Well, if you insist:

| If more than one redirection operator is specified with a command,
| the order of evaluation is from beginning to end.
|
| A failure to open or create a file shall cause a redirection to fail.
|
| 2.7.1 Redirecting Input
|
| Input redirection shall cause the file whose name results from the
| expansion of word to be opened for reading on the designated file
| descriptor, or standard input if the file descriptor is not
| specified.

After reading and further research I must admit that's the only relevant
part. Now I can say, that bash-people and zsh-people read that
differently. POSIX, at least four years ago, says nothing what to do if
one FD is redirected more than once. "the order of evaluation is from
beginning to end" doesn't suppose that what's already evaluated should
be dropped. I've got to conclusion (and I'm not interested in
discussing this with bash-people) that both shells, bash and zsh, are
POSIX compliant.

However, I dare to comment a bit more. There're three concurent ways to
maintain STDIN for commands.

First, what cat(1) does, in essence, is turning files into clean
bytestream. OTOH, there's that puristic proverb about
useless-use-of-cat. And that proverb is mantra. Tell me, shell
wizards, what is more pure:

cat filename | grep word

or

grep -h word filename

And all that bytestream BS is relevant as long as cat(1) is fed with
filenames. Because,

Second comes redirection. It has bonuses, but (I stand corrected) it
comes with price. And that price is so huge that it renders redirection
useless. Isn't this elegant:

cat <<<"### /etc/hosts.allow ###" /etc/hosts.allow \
<<<"### /etc/hosts.deny ###" /etc/hosts.deny | lp

It's not, because it's not portable. What we have here is bash sneaking
it's features and limitations under disguise of compatibility. Good
news is that shell is so long forgotten that it doesn't harm anyone
anymore.

Third is command line tail. Well, we're supposedly talking Perl here,
it's an *interpreted* script, I can do whatever I want with that script.
I just need filenames.

Shortly, zsh wins, bash is lame, we all lose, and now I feel much better.

*CUT*