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:
[SNIP!]
=> > >> 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 -
and
cat << E-O-LIST | scan -
1
2
3
E-O-LIST
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
several.
=>
=> 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
splitting.
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 <*> epg(_at_)pretzelnet(_dot_)org
=>
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers