From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3D064187.EFE0CC96@null.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <66556c53bb0f92dac0b0484edeef3f8d@plan9.bell-labs.com> Subject: Re: [9fans] bug or a feature? Date: Wed, 12 Jun 2002 08:53:54 +0000 Topicbox-Message-UUID: aa29d31c-eaca-11e9-9e20-41e7f4b1d025 "rob pike, esq." wrote: > This is long-standard behavior for shells. Feature. Indeed, but since so many other aspects of Unix were rethought for Plan 9, it deserves some consideration; it's certainly contrary to simplicity and regularity. Perhaps someone knows the history of this decision, but my *guess* is that it was deemed to be more useful in "typical" interactive use: % cp foo.* bar cp: foo.*: nonexistent file As of 6th Edition Unix there was a separate "glob" utility. For some purposes, e.g. find . whatever -print | xargs ... I find myself providing an extra argument "/dev/null" to the command invoked under xargs control; e.g. when it's "grep" and I want to be sure to see the filename even if the grep is invoked with just one filename argument (that works around an irregularity in "grep", again likely to be due to thinking about interactive use). Too bad there is nothing similar that could be used as an "empty string" placeholder. (I introduced that notion in the 1999 C standard as part of the specification for handling empty arguments to function-like macros, and it made it easy to be sure that the empty arguments didn't vanish until we really wanted them to.)