[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] [PATCH] scan message numbers from stdin

From: bergman
Subject: Re: [Nmh-workers] [PATCH] scan message numbers from stdin
Date: Tue, 19 Aug 2008 16:40:44 -0400

In the message dated: Tue, 19 Aug 2008 11:57:47 PDT,
The pithy ruminations from Eric Gillespie on 
<Re: [Nmh-workers] [PATCH] scan message numbers from stdin> were:


=> > >> if the commands are going to take text from stdin
=> > >> for the purpose of emulating "command line behavior",
=> > >> then the parsing must indeed emulate SHELL parsing
=> > >> lest it create a massive violation of
=> > >>
=> > >>         The Law of Least Amazement

It may have been poorly worded, but I agree with that (or with what I believe 
Chris was trying to say). I was pretty surprised to read the proposed specs and 
to see that scan would handle multiple lines as input differently than handling 
a single line with multiple message numbers.

I'd expect that these two examples would behave the same way:

        echo 1 2 3 | scan -
        cat << E-O-LIST | scan -

Sure, commands that are inheriently line-oriented (such as "sort") handle those 
cases differently. However, scan(1) is traditionally oriented toward processing 
a list of arguments, not a series of lines. In that sense, it's more like
"wc -w", which behaves the same way whether it gets it's STDIN on one line or 

=> What the heck kind of requirement is that?  Commands taking input
=> on the standard input must apply SHELL (csh or sh?) parsing to
=> the input?  I don't know what to make of this.

I think that trying to "emulate SHELL parsing" is putting it a bit too strongly.
We're not talking about "parsing" wildcards or shell-metas, but argument

I'd suggest that the spec be something like:

        scan(1) may accept a list of message numbers on STDIN. By default,
        these are whitespace (including \n) separated.

This is the same behavior as the default IFS under bash, csh, and ksh...zsh
adds NULL to that set.

I suppose that the value of $IFS could be examined as well, in case the user 
wants to do something really wild'n'crazy like:

        IFS="," echo "1,2,3" | scan -

Oh, and just in case it hasn't been said enough recently...

        "Thank you" to everyone who's continuing to maintain and
        develop nmh.

Mark "haven't really coded in C in years...for a good reason!" Bergman

=> -- 
=> Eric Gillespie <*> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]