From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <200910062027.ac05515@salmon.maths.tcd.ie> References: <20091005192428.GA24445@nipl.net> <200910052204.aa92451@salmon.maths.tcd.ie> <13426df10910051922h6d40c1b2u5a8481db9a2a9b64@mail.gmail.com> <4ACB026E.4070409@maht0x0r.net> <200910062027.ac05515@salmon.maths.tcd.ie> Date: Tue, 6 Oct 2009 15:10:53 -0500 Message-ID: From: Jason Catena To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] mishandling empty lists - let's fix it Topicbox-Message-UUID: 823e111e-ead5-11e9-9d60-3106f5b1d025 On Tue, Oct 6, 2009 at 14:27, John Stalker wrote: >> just write a single combinator that when applied to a command >> makes it behave in the "no non-flag arguments =3D=3D dont run" way. >> Then its just: >> >> =A0 =A0 =A0l0 cat $args >> =A0 =A0 =A0l0 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