Re: [9fans] mishandling empty lists - let's fix it

[Jason Catena <jason.catena@gmail.com>]

On Tue, Oct 6, 2009 at 14:27, John Stalker <stalker@maths.tcd.ie> wrote:
>> just write a single combinator that when applied to a command
>> makes it behave in the "no non-flag arguments == dont run" way.
>> Then its just:
>>
>>      l0 cat $args
>>      l0 chmod +x $args
>
>> Tim Newsham
>
> There is also a problem with identifying non-flag arguments.

For the original post's purpose ("commands such as cat, grep etc. do
not handle an empty argument list correctly") we might not have to go
this far.  If these new semantics are meant to process command line
arguments, then they should not be used with the l0 combinator to
process pipe input, which means they won't be called without some
attempt to supply them with arguments after options.  Common cases
where the attempt might provide no arguments would be shell variables
or backticked commands, which are both code that gets further
processed.  We can use this to delay the processing into the
combinator, and not execute the utility command if we have nothing to
do.

So, it should be sufficient to either (1) quote the argument-providing
code in the command line, to delay evaluating it until immediately
before the utility command in the combinator, and if non-nil apply its
output to the utility command; or (2) add some null argument like
/dev/null, depending on the command, in the combinator after any other
arguments, to make it quietly do nothing if the argument-providing
code evaluates to nil in the calling script.

Seems to me we have three different command sets now: one with the
current, traditional semantics which mix argument and pipe input, and
handle missing input inconsistently; a set (listed by John) which
handle no command-line arguments consistently. generally doing
nothing; and a set (listed by Ron) which handle standard input
consistently.  Of the three, Ron's set seems most interesting to me:
(1) if your tools can handle their arguments on standard input, they
ought to cleanly handle the null case too, (2) pipe is a cleaner
notation for passing output along than backtick within backtick within
backtick, and (3) pipes commonly pass multiple lines, not just
separated fields.

> John Stalker

Jason Catena