From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sun,  4 Oct 2009 18:17:48 +1100
From: Sam Watkins <sam@nipl.net>
To: 9fans@9fans.net
Message-ID: <20091004071748.GA16895@nipl.net>
References: <20091003191118.GD15021@nipl.net>
	<45a41ae73e4adf6d1b38fe9c31977c52@proxima.alt.za>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45a41ae73e4adf6d1b38fe9c31977c52@proxima.alt.za>
User-Agent: Mutt/1.5.13 (2006-08-11)
Subject: Re: [9fans] mishandling empty lists - let's fix it
Topicbox-Message-UUID: 7d20764a-ead5-11e9-9d60-3106f5b1d025

I wrote:
> I don't see how this can be fixed in unix without breaking umpteen million
> shell scripts.

On Sun, Oct 04, 2009 at 06:12:15AM +0200, lucio@proxima.alt.za wrote:
> By creating new commands with distinct new names.

I thought of a better way.  We can fix the commands without breaking
compatibility, using `--'.  `--' in unix normally excludes further options.
My idea is that `--' should force multi-file mode, excluding different
behaviour in case of an empty list or a single-member list.

  `--' ends options, forces consistent multi-file mode, allows empty lists

This gives the best of both worlds - existing usage is still valid, but people
can choose to use new syntax when dealing with lists of files.
It is consistent with the current meaning of `--' in unix.

Examples of new usage (using rc this time):

  # wrap stdin with a header and footer
  cat header - footer

  fn find { du -a $* | awk '{print $2}' }    # du/find are not fixed yet

  # cat all C files, ok if none
  cat -- `{find . | grep '\.c$'}

  # same thing, with grep instead, always outputs file:matching-line
  grep malloc -- `{find . | grep '\.c$'}

Down with DWIM!!

What do you think of this proposal?
Can you think of a real example where it would be incompatible?


Sam