Why does this code works without cat ?

Discussion in 'Perl Misc' started by naruto canada, Apr 14, 2012.

  1. 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
    naruto canada, Apr 14, 2012
    #1
    1. Advertising

  2. naruto canada <> wrote:
    >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
    Jürgen Exner, Apr 14, 2012
    #2
    1. Advertising

  3. naruto canada <> writes:
    > 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.
    Rainer Weikusat, Apr 14, 2012
    #3
  4. naruto canada

    Guest

    Jürgen Exner <> wrote:
    > naruto canada <> wrote:
    > >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


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

    I don't.

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
    , Apr 14, 2012
    #4
  5. naruto canada

    Tim McDaniel Guest

    In article <20120414173132.929$>, <> wrote:
    >Jürgen Exner <> wrote:
    >> naruto canada <> wrote:
    >> >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

    >
    >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.

    --
    Tim McDaniel,
    Tim McDaniel, Apr 15, 2012
    #5
  6. with <20120414173132.929$> wrote:
    > Jürgen Exner <> wrote:
    >> naruto canada <> wrote:
    >> >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

    >
    > 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

    --
    Torvalds' goal for Linux is very simple: World Domination
    Stallman's goal for GNU is even simpler: Freedom
    Eric Pozharski, Apr 15, 2012
    #6
  7. writes:
    > Jürgen Exner <> wrote:
    >> naruto canada <> wrote:
    >> >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

    >
    > 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.
    Rainer Weikusat, Apr 15, 2012
    #7
  8. naruto canada

    Guest

    Rainer Weikusat <> wrote:
    > writes:
    > > Jürgen Exner <> wrote:
    > >> naruto canada <> wrote:
    > >> >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

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

    >
    > 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

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
    , Apr 15, 2012
    #8
  9. writes:
    > Rainer Weikusat <> wrote:
    >> writes:
    >> > Jürgen Exner <> wrote:
    >> >> naruto canada <> wrote:
    >> >> >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
    >> >
    >> > Why? Do you have to pay royalties to GNU every time you use cat?

    >>
    >> 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,


    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.

    >> Writing code which accomplishes nothing is a waste of time.

    >
    > 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?'.

    >> 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.


    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.

    >> 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.


    I was referring to the time necessary to read and understand some
    text. Unsurprisingly, that went right past you ...
    Rainer Weikusat, Apr 15, 2012
    #9
  10. wrote:
    >Jürgen Exner <> wrote:
    >> naruto canada <> wrote:
    >> >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

    >
    >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, Apr 15, 2012
    #10
  11. wrote:
    >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
    Jürgen Exner, Apr 15, 2012
    #11
  12. naruto canada

    Guest

    Rainer Weikusat <> wrote:
    > writes:
    > > Rainer Weikusat <> wrote:
    > >> writes:
    > >> > Jürgen Exner <> wrote:
    > >> >> naruto canada <> wrote:
    > >> >> >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
    > >> >
    > >> > Why? Do you have to pay royalties to GNU every time you use cat?
    > >>
    > >> 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,

    >
    > So, use cat then.


    Thanks, I think I will continue to do so.

    >
    > > 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


    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.



    > >
    > > 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 ...


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

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
    , Apr 15, 2012
    #12
  13. naruto canada

    Guest

    Jürgen Exner <> wrote:
    > wrote:
    > >Jürgen Exner <> wrote:


    > >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.


    And how big are *those* royalty checks?

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
    , Apr 15, 2012
    #13
  14. naruto canada

    Tim McDaniel Guest

    In article <20120415145533.929$>,
    <> wrote:
    >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,
    Tim McDaniel, Apr 16, 2012
    #14
  15. naruto canada

    Tim McDaniel Guest

    In article <>,
    J_rgen Exner <> wrote:
    >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.

    --
    Tim McDaniel,
    Tim McDaniel, Apr 16, 2012
    #15
  16. (Tim McDaniel) writes:
    > In article <20120415145533.929$>,
    > <> wrote:
    >>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 ...
    Rainer Weikusat, Apr 16, 2012
    #16
  17. On Mon, 16 Apr 2012 12:28:49 +0100, Rainer Weikusat wrote:

    > (Tim McDaniel) writes:
    >> In article <20120415145533.929$>, <>
    >> wrote:
    >>>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
    Martijn Lievaart, Apr 16, 2012
    #17
  18. Martijn Lievaart <> writes:
    > On Mon, 16 Apr 2012 12:28:49 +0100, Rainer Weikusat wrote:
    >> (Tim McDaniel) writes:
    >>> In article <20120415145533.929$>, <>
    >>> wrote:
    >>>>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, Apr 16, 2012
    #18
  19. Rainer Weikusat <> writes:
    > Martijn Lievaart <> writes:
    >> On Mon, 16 Apr 2012 12:28:49 +0100, Rainer Weikusat wrote:
    >>> (Tim McDaniel) writes:
    >>>> In article <20120415145533.929$>, <>
    >>>> wrote:
    >>>>>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" ...)
    Rainer Weikusat, Apr 16, 2012
    #19
  20. On Mon, 16 Apr 2012 14:48:09 +0100, Rainer Weikusat wrote:

    > Martijn Lievaart <> writes:
    >> On Mon, 16 Apr 2012 12:28:49 +0100, Rainer Weikusat wrote:
    >>> (Tim McDaniel) writes:
    >>>> In article <20120415145533.929$>,
    >>>> <> wrote:
    >>>>>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
    Martijn Lievaart, Apr 16, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Yadagiri Rao KP
    Replies:
    3
    Views:
    399
    Joseph Millar
    Aug 9, 2003
  2. Spendius
    Replies:
    2
    Views:
    2,957
    Rogan Dawes
    Dec 13, 2004
  3. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    874
    Mark Rae
    Dec 21, 2006
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,803
    Smokey Grindel
    Dec 2, 2006
  5. Elephant

    How to extend this code for doing "cat"

    Elephant, Jan 3, 2006, in forum: C Programming
    Replies:
    2
    Views:
    340
    clayne
    Jan 4, 2006
Loading...

Share This Page