R
Rainer Weikusat
[...]
I suggest that you read the explanation I gave (both of them,
actually) ...
I suggest that you read the explanation I gave (both of them,
actually) ...
M
Martijn Lievaart
You're trolling me, right?
M4
R
Rainer Weikusat
Martijn Lievaart said:
Ok, spelled out again: Your _assumption_ about my intention is wrong.
This is partially my fault because I could have made this clearer (as
detailed in my 2n post on this), however, that doesn't make your
assumption any less wrong.
M
Martijn Lievaart
You're making less and less sense.
That indeed was said, but it was not what you reacted to.
You reacted to:
To which you said:
(conveniently omitting the third command line)
which is completely irrelevant to both the zigzagging claim and the file
redirection claim.
So what am I missing?
M4
R
Rainer Weikusat
Martijn Lievaart said:
Indeed. As I already explcitly wrote two times and implicitly pointed
out three times, my statement was supposed to refer to the wrong
'zig-zagging' claim and I was just using the two commands above as a
convenient example to illustrate that, without any intention
whatsoever to comment on the other content of the posting this example
came from.
[...]
The original claim was:
Furthermore, [cat instead of file redirection] keeps the overall
flow of information on a pipeline running from left to
right, rather than zig-zagging.
As illustrated in this nice example,
,----
| cat /etc/motd NetBSD 5.1.2 (PANIX-XEN3U-USER) #0: Wed Feb 15 19:17:33 EST 2012
|
| cat </etc/motd NetBSD 5.1.2 (PANIX-XEN3U-USER) #0: Wed Feb 15 19:17:33
`----
it actually 'zig-zags' ('zig-zaggs'?) in either case because the
filename argument is to the right either way.
T
Tim McDaniel
That's true, but
cat /etc/motd | some long command line with lots of options | maybe some other command
zig-zags much less than
some long command line with lots of options /etc/motd | maybe some other command
M
Martijn Lievaart
Ah got it. You used a post that shows that shows there is another way to
avoid the zig-zagging, incidentally using cat as an example, and snipped
the other way. Then you tried to make a point about cat, which was the
original topic, but not the topic of this post.
Yup, very clear. Not.
M4
P
Peter J. Holzer
My guess is that Rainer is missing something: The third command line,
which indeed doesn't zigzag, while the other two do.
(But personally I would prefer a uuoc to the third one in a shell
script: I suspect that most people don't know that shell feature)
hp
R
Randal L. Schwartz
xhoster> The point you so cleverly miss is that turning a cat into a
xhoster> grep is let easier, and less error-prone, than migrating a
xhoster> redirected file name from after the perl -e 'whatever' to
xhoster> before it, and adding a grep.
But you still don't need a cat.
On a sane shell, this works:
<somefile proggy arg arg
And when you want to turn that into a *concatenation* or a grep or other
filter, the file is already in teh right place.
No need for a useless use of cat.
xhoster> grep is let easier, and less error-prone, than migrating a
xhoster> redirected file name from after the perl -e 'whatever' to
xhoster> before it, and adding a grep.
But you still don't need a cat.
On a sane shell, this works:
<somefile proggy arg arg
And when you want to turn that into a *concatenation* or a grep or other
filter, the file is already in teh right place.
No need for a useless use of cat.
R
Randal L. Schwartz
Eric> However, redirection comes with little bonuses:
Eric> {23:1} [0:0]% perl -wle 'print -s STDIN' </etc/passwd
Eric> 1814
Eric> {2048:2} [0:0]% cat /etc/passwd | perl -wle 'print -s STDIN'
Eric> 0
You're confusing what -s can return on a pipe vs a file. Very different.
Eric> {23:1} [0:0]% perl -wle 'print -s STDIN' </etc/passwd
Eric> 1814
Eric> {2048:2} [0:0]% cat /etc/passwd | perl -wle 'print -s STDIN'
Eric> 0
You're confusing what -s can return on a pipe vs a file. Very different.
R
Randal L. Schwartz
Rainer> [rw@sapphire]/tmp $perl -pe '' a
perl -perl a
perl -perl a
E
Eric Pozharski
with said:
Huh? "blame me, I've got used to be guilty of anything" (c) me.
p.s.
{2809:5} [0:0]% perl -wle 'print -s STDIN' </etc/passwd </etc/group
0
And who's confused now?
P
Peter J. Holzer
I don't think that Eric is confusing anything. He is pointing out that
in the first example STDIN is a file handle to the file /etc/passwd So
you can determine its size, you can seek around in it, determin its
owner and permissions, etc.
Whereas in the second example STDIN is a file handle to a pipe. All you
can do with a pipe is read it sequentially.
They are, as you say, very different. Which is exactly what Eric was
showing, so I don't understand why you think he was confusing something.
hp
X
Xho Jingleheimerschmidt
I'm pretty sure that that was his point.
Xho
P
Peter J. Holzer
Ok, you just proved me wrong: You *are* confused.
I admit that this particular zsh feature (it doesn't work in bash) is a
bit confusing:
When you use one input redirection, zsh (like any other shell) opens the
file, forks a child process, dups the filedescriptor to fd 0, and
finally execs the program.
But when you use two or more redirections, zsh opens all the files,
creates a pipe and forks two child processes: The first one concatenates
the files and sends them to the pipe, the second one dups the pipe's
file descriptor to 0 and execs the program.
So i zsh, writing
perl -wle 'print -s STDIN' </etc/passwd </etc/group
is almost equivalent to writing
cat /etc/passwd /etc/group | perl -wle 'print -s STDIN'
The only difference is that zsh doesn't actually call an external
executable named cat but performs the concatentation internally. Of
course that doesn't make any difference to perl.
hp
R
Rainer Weikusat
I'm not missing anything: You don't have a leg to stand on, you're
just a guy who advocates bad coding habits just because they are bad
coding habits.
E
Eric Pozharski
*SKIP* [[ *relevant* description of differences of various shells ]]with said:
And zsh wins!
{6617:23} [0:0]% bash
{1:1} [0:0]$ perl -wle 'print -s STDIN' </etc/passwd </etc/group
1006
{26:2} [0:0]$ perl -nle '$aa++; END { print $aa }' </etc/passwd </etc/group
68
{56:3} [0:0]$ exit
{6889:29} [0:0]% perl -nle '$aa++; END { print $aa }' </etc/passwd </etc/group
105
{6900:30} [0:0]% wc /etc/passwd /etc/group
37 53 1814 /etc/passwd
68 68 1006 /etc/group
105 121 2820 total
E
Eric Pozharski
with said:
If that would be addressed to some weak mind, then such mind would spill
something along the lines "OH YOU *ARE* SO CONFUSED!!ONEONE". But I
don't think you're confused. You're trolling, read below.
*SKIP* [[ that's irrelevant already ]]
Wait a second. If that thread would have anything like a goal-post,
that would clearly constitute goal-post moving. All that in skipped had
nothing to do with redirecting *output*. We were talking redirecting
input.
cat /etc/passwd /etc/group | wc
wc </etc/passwd </etc/group
wc /etc/passwd /etc/group
That should prduce same result, shouldn't it?
T
Tim McDaniel
I'm sorry. I had not realized that we're not allow to discuss
redirecting output. Thank you for clarifying.
Leaving aside whether the model of redirection should have automatic
catting (zsh, you say) or just overriding (sh, bash), "wc" when given
file names produces one line of output per file and each line includes
the filename, and if it has more than one filename argument, it adds a
line of totals.
E
Eric Pozharski
with said:
The only reason for this could be POSIX. Any reference, please?
I admit, concatenating multiple input redirections makes zsh cooler.
OTOH, the only mention of multiple 'word's for bash I've found is that
'word' is subject to expansion and if that expansion resulsts in multiple
'word's then bash explicitly fails. OTOOH, zsh clearly explains MULTIOS
effects (being it on or off).
I think that bash people has considered what to do with multiple
confronting redirections. And found that it would be too hard to worth
a try. And in order to *hide* that purely ad hoc decision they didn't
mention that in docs. What makes bash lame.