SPUG: Docs on "-l" wrong?

Fred Morris m3047 at inwa.net
Tue Aug 26 02:12:27 CDT 2003


Tim writes:
>SPUGsters,
>
>Does anybody think the -l documentation from "perldoc perlrun"
>is any good? This is a confusing topic in the first place, IMHO, and
>this man page makes it moreso. See my comments below.  And I'd welcome
>yours too.
>
>-Tim
>       -l[octnum]
>            enables automatic line-ending processing.  It has two
>            separate effects.  First, it automatically chomps $/
>            (the input record separator) when used with -n or -p.
>            Second, it assigns "$\" (the output record separator)
>            to have the value of octnum so that any print state-
>            ments will have that separator added back on.  If
>            octnum is omitted, sets "$\" to the current value of
>            $/.  For instance, to trim lines to 80 columns:
>
>                perl -lpe 'substr($_, 80) = ""'
>
>Tim's comment:
>The whole point of this example, which unfortunately goes unstated,
>is that when you truncate lines, you lose their attached newlines,
>so without -l adding the "\n" back in automagically, the (long) lines
>would not be separated by anything.

Seems to me that any line < 80 characters in the above example is not
truncated... as opposed to a literalist reading of "the first 80 characters
of each line": the former assumes that very few (if any) lines would ever
be longer than 80 characters (VT-100? VT-52?), while the latter assumes
that the intent is really to do something to each line. Having been around
long enough, that seems to me to be the lever which moves the world. From
that it follows that lines < 80 characters would be treated differently
than others.. or would they? My first impression of what that says is "-l
is going to add a newline back on to any unfortunate line which is munged".
In fact it only hit me that -l necessarily has to add a record terminator
to *every* line on further reflection.

>I'm left wondering, is this passage
>meant to be an aid to developing the readers knowledge, or a test of it?
>8-}  This is fine documentation written for the people who don't need it,
>but not the others.

I'm guessing neither, but that it is an example which is getting somewhat
dated. (I've used the -l flag before and it's worked as I expected it to..
I'd never even thought about this before!) (Maybe it's good I didn't read
the documentation?)

>            Note that the assignment "$\ = $/" is done when the
>            switch is processed, so the input record separator
>            can be different than the output record separator if
>            the -l switch is followed by a -0 switch:
>
>                gnufind / -print0 | perl -ln0e 'print "found $_" if -p'
>
>            This sets "$\" to newline and then sets $/ to the
>            null character.
>
>Tim says:
>Instead of leaving it to the reader to disentangle the confusing
>prose and wonder whether 0 is an argument to -n or something
>else, I'd prefer an explicit statement that -l is donating the
>terminal newlines to the solution (via $\), and -0 is setting $/
>to the null character.

I confess to never having used -0 or thought about it until now! It seems
clear it's not an argument to -n. It seems that what they're saying is that
the input and output separators are decoupled, and that I could for
instance programmatically change one independently of the other (which
would better suit my style and needs: I never do any paragraph-oriented
processing, all lines or slurp... how do I use -0 to set it to undef?)... I
assume that's true anyway, both from some zen intuition as well as from
that snippet of documentation. However it's hard to tell without context
whether the intention of that snippet is to explain the decoupling or to
explain -0.

--

Fred Morris
m3047 at inwa.net





More information about the spug-list mailing list