Why does this code works without cat ?

[naruto canada]

hi

I've encountered this code some times ago:

#!/usr/bin/env perl
$i=1;
while (<>) {
if (($len = length($_)) > $lmax) {
$lmax = $len;
@longest =($i.":$_");
}
elsif ($len == $lmax) {
push(@longest, $i.":$_");
}
$i=$i+1;
}
print @longest;

This code print longest lines from stdin. Strangely, it works without
cat. If my understanding is correct, "<>" (stdin) should require "cat"
to work. Can someone explain it?
Right now, for example, it works both ways like:
cat 1.txt | longest.line.pl
longest.line.pl 1.txt

 

[Jürgen Exner]

cat 1.txt | longest.line.pl

And again someone applying for the useless use of cat award.
If you want to use a file as standard input for a program then at least
do it without cat:

longest.line.pl < 1.txt

jue

 

[Rainer Weikusat]

I've encountered this code some times ago:

#!/usr/bin/env perl
$i=1;
while (<>) {
if (($len = length($_)) > $lmax) {
$lmax = $len;
@longest =($i.":$_");
}
elsif ($len == $lmax) {
push(@longest, $i.":$_");
}
$i=$i+1;
}
print @longest;

This code print longest lines from stdin. Strangely, it works without
cat. If my understanding is correct, "<>" (stdin) should require "cat"
to work. Can someone explain it?

'cat' is a program which concatenates all files whose
names appear as command-line arguments and writes the concatenated
content to its standard output. It is often used to display a
(sufficiently short) text file, although this is by no means to only
way to accomplish that:

[rw@sapphire]/tmp $ed a
a: No such file or directory
a
a
b
c
..
wq
6
[rw@sapphire]/tmp $sed '' a
a
b
c
[rw@sapphire]/tmp $grep '' a
a
b
c
[rw@sapphire]/tmp $perl -pe '' a
a
b
c
[rw@sapphire]/tmp $awk '{ print; }' a
a
b
c
[rw@sapphire]/tmp $comm a /dev/null
a
b
c

and so on.

 

[xhoster]

And again someone applying for the useless use of cat award.
If you want to use a file as standard input for a program then at least
do it without cat:

longest.line.pl < 1.txt

Why? Do you have to pay royalties to GNU every time you use cat?

I don't.

Xho

 

[Tim McDaniel]

Why? Do you have to pay royalties to GNU every time you use cat?
I don't.

It is, nevertheless, useless. I think it's much better to understand
what goes on with <> in Perl, and with < and > and | in shells, to be
able to manipulate things better.

 

[Eric Pozharski]

Why? Do you have to pay royalties to GNU every time you use cat?

I don't.

However, redirection comes with little bonuses:

{23:1} [0:0]% perl -wle 'print -s STDIN' </etc/passwd
1814
{2048:2} [0:0]% cat /etc/passwd | perl -wle 'print -s STDIN'
0

 

[Rainer Weikusat]

Why? Do you have to pay royalties to GNU every time you use cat?

The simple answer is because it is (technically) useless. Writing code
which accomplishes nothing is a waste of time. Letting the computer
execute code solely for the sake of executing it is a waste of
time. Forcing someone else to invest time (and effort) into
understanding something solely to discovers that it serves no
purpose is a waste of time.

 

[xhoster]

The simple answer is because it is (technically) useless.

What starts out as sending one file into Perl often turns into sending more
than one file into Perl, or sending one file into Perl with prefiltering
via grep or line limitations via head, or choosing certain columns with
cut, or any of a hundred things which are much easier and less error prone
if one starts with cat rather than redirection. These are all technically
useful things.

Furthermore, it keeps the overall flow of information on a pipeline running
from left to right, rather than zig-zagging.

Writing code
which accomplishes nothing is a waste of time.

Does the pipe character count as code? And how slowly do you type?

Letting the computer
execute code solely for the sake of executing it is a waste of
time.

The amount of time is trivial, and the "solely" is merely your ignorant
opinion.

Forcing someone else to invest time (and effort) into
understanding something solely to discovers that it serves no
purpose is a waste of time.

Anyone who doesn't know what cat does would be well served to take the time
to learn it.

Xho

 

[Rainer Weikusat]

What starts out as sending one file into Perl often turns into sending more
than one file into Perl,

So, use cat then.

or sending one file into Perl with prefiltering via grep or line
limitations via head, or choosing certain columns with cut, or any
of a hundred things

cat in front of any of these command is as useless as in front of
perl: They can either all work with files directly or use files the
shell opened for them

Furthermore, it keeps the overall flow of information on a pipeline
running from left to right, rather than zig-zagging.

In absence of at least one command which neither cat nor the command
which had a useless cat prefixed to it, there is no need for 'a
pipeline' aka 'copying all of the input data into and out of a kernel
buffer for no particular technical reason.

Does the pipe character count as code? And how slowly do you type?

The answers are 'yes it does' and 'This doesn't matter. Are we
perhaps trying to change an unwelcome topic?'.

The amount of time is trivial, and the "solely" is merely your
ignorant opinion.

Solely is a fact, no matter what your ignorant dissenting opinion
might be, and whether you consider something 'trivial' has no relation
to the question if it is necessary or not.

Anyone who doesn't know what cat does would be well served to take
the time to learn it.

I was referring to the time necessary to read and understand some
text. Unsurprisingly, that went right past you ...

 

[Jürgen Exner]

Why?

Because at least _I_ don't like cluttering my code with useless bits and
pieces. There simply is nothing to conCATenate here. Or do you also add
0 to an arithmetic expression or concatenate the empty string to a
string just because you can?

Reminds me of a former student who insisted on writing
if (SomeCondition == TRUE) {...}
every single time. Of course he got the correct result but the code is
nevertheless amateurish and nothing to brag about.

Do you have to pay royalties to GNU every time you use cat?
I don't.

Your OS does by creating, running, and cleaning up a totally superfluous
process.

Yes, there are exceptions where using cat() with a single file is useful
(or adding a 0 or concatenating an empty string). But this is not one of
them.

jue

 

[Jürgen Exner]

Anyone who doesn't know what cat does would be well served to take the time
to learn it.

It conCATenates the content of files, doesn't it?

jue

 

[xhoster]

So, use cat then.

Thanks, I think I will continue to do so.

cat in front of any of these command is as useless as in front of
perl: They can either all work with files directly or use files the
shell opened for them

The point you so cleverly miss is that turning a cat into a grep is let
easier, and less error-prone, than migrating a redirected file name from
after the perl -e 'whatever' to before it, and adding a grep.

I was referring to the time necessary to read and understand some
text. Unsurprisingly, that went right past you ...

If it is difficult to read and understand "cat" then you are probably
beyond help.

Xho

 

[xhoster]

Your OS does by creating, running, and cleaning up a totally superfluous
process.

And how big are *those* royalty checks?

Xho

 

[Tim McDaniel]

Furthermore, [cat instead of file redirection] keeps the overall flow
of information on a pipeline running from left to right, rather than
zig-zagging.

In bash, file redirection characters do not need to be at the end of a
command.

$ 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 EST 2012

$ </etc/motd cat
NetBSD 5.1.2 (PANIX-XEN3U-USER) #0: Wed Feb 15 19:17:33 EST 2012

"man bash" on that system reports

"The following redirection operators may precede or appear anywhere
within a simple command or may follow a command. Redirections are
processed in the order they appear, from left to right.

 

[Tim McDaniel]

Reminds me of a former student who insisted on writing
if (SomeCondition == TRUE) {...}
every single time. Of course he got the correct result

To anyone who doesn't see how much of a disaster that code is, please
note:

In Perl and C, and doubtless other languages, it works only if
SomeCondition is guaranteed to be either TRUE (a unique numeric value)
or some other numeric value(s) that are all to be interpreted as
false. If someone else decides to assign to SomeCondition according
to the standard behavior of Perl, where any of five possible values is
false and anything else is true, that code will silently operate
incorrectly, and it looks like like ought to work.

In languages where the boolean type is strict, where it really
will be either true or false, the test above is simply useless.

Any code like the above should be flatly rejected.

 

[Rainer Weikusat]

Furthermore, [cat instead of file redirection] keeps the overall flow
of information on a pipeline running from left to right, rather than
zig-zagging.

In bash, file redirection characters do not need to be at the end of a
command.

$ 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 EST 2012

Unless I'm very much mistaken, the filename argument is in the same
position relative to the command both times ...

 

[Martijn Lievaart]

Furthermore, [cat instead of file redirection] keeps the overall flow
of information on a pipeline running from left to right, rather than
zig-zagging.

In bash, file redirection characters do not need to be at the end of a
command.

$ 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 EST 2012

Unless I'm very much mistaken, the filename argument is in the same
position relative to the command both times ...

Funny how you can make substantiated nonsense arguments if you snip the
point of the argument away. Please reread the complete original post
carefully, you'll see it does make sense then.

M4

 

[Rainer Weikusat]

Furthermore, [cat instead of file redirection] keeps the overall flow
of information on a pipeline running from left to right, rather than
zig-zagging.

In bash, file redirection characters do not need to be at the end of a
command.

$ 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 EST 2012

Unless I'm very much mistaken, the filename argument is in the same
position relative to the command both times ...

Funny how you can make substantiated nonsense arguments if you snip the
point of the argument away. Please reread the complete original post
carefully, you'll see it does make sense then.

Funny how people always seem to misinterpret something such that it
doesn't make any sense and then try to hold the person who wrote it
responsible for that ...

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.

After I wrote my reply to the posting which contained this, it
occurred to me that this claim is actually wrong: Both

cat /some/file

and

cat </some/file

have the filename argument to the right of the command, hence, the
'zig-zagging' in the first command of a pipeline is there in both
cases. A related minor point would be that, with preciously few
exceptions, tr being the only one coming' to my mind immediately,
commands other than cat usually accept filename arguments themselves,
eg, to use one of the orginally mentioned examples, the pipeline

cat /var/log/syslog | head -n 10

and the command

head -n 10 /var/log/syslog

don't differ in this respect.

 

[Rainer Weikusat]

(e-mail address removed) (Tim McDaniel) writes:
Furthermore, [cat instead of file redirection] keeps the overall flow
of information on a pipeline running from left to right, rather than
zig-zagging.

In bash, file redirection characters do not need to be at the end of a
command.

$ 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 EST 2012

Unless I'm very much mistaken, the filename argument is in the same
position relative to the command both times ...

Funny how you can make substantiated nonsense arguments if you snip the
point of the argument away. Please reread the complete original post
carefully, you'll see it does make sense then.

Funny how people always seem to misinterpret something such that it
doesn't make any sense

Possibly, I should have deleted the 'In bash ...' sentence to make it
clearer that I was just using the two commands as an example and that
my text wasn't intended to 'argue against' the one which contained
them (OTOH, that would imply basing on argument on a gross
misrepresentation of something someone else wrote and since people
usually do this with my texts, I try to avoid that with other people's
texts as hard as possible ... IMHO, the point of a discussion is to
get a clearer picture of some set of facts and opinions about facts,
not "who won it" ...)

 

[Martijn Lievaart]

(e-mail address removed) (Tim McDaniel) writes:
Furthermore, [cat instead of file redirection] keeps the overall flow
of information on a pipeline running from left to right, rather than
zig-zagging.

In bash, file redirection characters do not need to be at the end of
a command.

$ 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 EST 2012

Unless I'm very much mistaken, the filename argument is in the same
position relative to the command both times ...

Funny how you can make substantiated nonsense arguments if you snip the
point of the argument away. Please reread the complete original post
carefully, you'll see it does make sense then.

Funny how people always seem to misinterpret something such that it
doesn't make any sense and then try to hold the person who wrote it
responsible for that ...

I don think I misinterpreted anything, unless it was the voices in your
head. I´m not psychic you know, and my amulet of ESP is out of order. I
do know what I read.

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.

Uh no? At least your reply (which I reacted on) was not a reply to this
claim. Therefore, the rest of your current reply is irrelevant.

I´ĺl assume it´s a misreading on your part, but this is a technical
newsgroup where accuracy is appreciated. Please do read what is written.
What you replied to actually was an argument in favor of your position,
but it seems you managed to interpret it as an argument against your
position.

M4