Re: [9fans] mishandling empty lists - let's fix it
one last note on this because it is kind of interesting.
...
I think that in limited situations, inconsistency is a good thing.
And, conversely, one can take consistency as an absolute good, and run
off the road.
...
ron
I agree with most of this, and with most of what I've edited out.
But I think that in this case we can distinguish two types of
utilities: those that behave inconsistently for a well thought out
and useful reason, and those which are inconsistent merely because
someone wasn't thinking properly.
Cat, for example, is inconsistent for sensible reasons. In a world
where it has options, and p9 cat still doesn't, the convention of
assuming stdin in the absence of arguments is mildly useful. It's
also easy to add /dev/null to the list if you want to avoid that
behaviour. Globbing can be a problem here, which is what the OP was
complaining about, but that is, if anything, a problem with the shell.
Rm is, I think, an example of someone who simply wasn't thinking
properly. In
rm `{ complicated pipeline }
I almost certainly want the exit status to reflect whether all the
selected files were deleted, even if there weren't any, so I want
rm without arguments to succeed silently. There is no real advantage
to the present behaviour. Yes, it warns you that you might not have
removed what you wanted to, but that's not the way UNIX and it's
descendants are supposed to behave. After all, if I type
rm -rf $jnukdir/*
then I don't expect a warning that $jnukdir is not defined while
$junkdir is, and that perhaps what I really meant was
rm -rf $junkdir
Everything can be carried to extreme. Even ancestor worship. The
basic utilities were written by smart people who didn't always fully
understand what they were doing. There is nothing radical about
suggesting that we try not to repeat their mistakes.
--
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282
Re: [9fans] mishandling empty lists - let's fix it
2009/10/7 John Stalker stal...@maths.tcd.ie:
Rm is, I think, an example of someone who simply wasn't thinking
properly. In
rm `{ complicated pipeline }
I almost certainly want the exit status to reflect whether all the
selected files were deleted, even if there weren't any, so I want
rm without arguments to succeed silently.
it does under plan 9.
FWIW, my experimental alphabet shell formalised the types of command line
arguments and checked usage before invoking the actual command.
each option took a fixed number of arguments; options were followed
by zero or more fixed arguments, optionally followed by a repeated
argument of the same type. this was sufficient for many of the conventional
commands, but not, for instance, mv which has a fixed argument at the
end.
as with any language, static typing is an advantage (it avoids some errors)
and a disadvantage (it's hard to do some things because they don't fit
within the type system). mileage varies.
Re: [9fans] mishandling empty lists - let's fix it
Everything can be carried to extreme. Even ancestor worship. The basic utilities were written by smart people who didn't always fully understand what they were doing. There is nothing radical about suggesting that we try not to repeat their mistakes. well why not take your own advice and implement this. live with it. let us know how it goes. - erik
Re: [9fans] mishandling empty lists - let's fix it
Everything can be carried to extreme. Even ancestor worship. The basic utilities were written by smart people who didn't always fully understand what they were doing. There is nothing radical about suggesting that we try not to repeat their mistakes. well why not take your own advice and implement this. live with it. let us know how it goes. - erik Would you please start reading posts before replying to them? The only thing I have proposed is that people stop gratituously creating programs which treat empty lists exceptionally. If that is what you mean by the paragraph above then I do try to implement it, and am quite happy with the results. But I think you mean something else. You mean that I want to replace cat, rm, chmod etc. by programs which adhere to this principle. I've said several times that I am not going to do this and that I think it would break too many things, including most of my own shell scripts. -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] mishandling empty lists - let's fix it
I prefer my version to your versions. I can see uses for them already. ron So do I, though I'm not sure I would have called the latter my versions. That's not the point however. Since I don't seem to been have sufficiently clear, I'll reword it a bit: There are a lot basic UNIX/p9 utilities which treat empty lists inconsistently. It would be nice if there were fewer, but you can't arrange that without breaking many things. The list I gave was what you would get by looking through /bin on a BSD system and making empty lists behave like other lists, just empty. Most of your list would, in fact, be more useful, but of of course break even more existing scripts. I think you got one wrong, however. `cat' would concatenate 0 files, i.e. ouptut nothing, cat would copy stdin to stdout How do you perform the original, concatenating, function of cat with this version? With my version I can type `cat -' or at worst `cat /dev/fd/0' to replicate the behaviour of your version. An idea more along the lines of your others would be that cat reads a list of files on stdin and concatentes their contents to stdout. -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] mishandling empty lists - let's fix it
On Sun, Oct 4, 2009 at 12:46 PM, Richard Miller 9f...@hamnavoe.com wrote: `--' ends options, forces consistent multi-file mode, allows empty lists Hey, yeah, great idea. And why not use '---' to force switching to Linux compatible mode, and '' to switch to BSD syntax, and '-' for System V syntax (5 hyphens, System 5, easy to remember). Oh, and we might need a way to switch back to Plan 9 syntax. That better be '' (0 hyphens). Example: cat -s - -s '' -v prints the contents of file named '-v', squeezing multiple empty lines (BSD -s) and silencing error message (System V -s). I'm sure the people in charge of writing the next version of the PoSix standard will be very happy to adopt your proposal! That is, if they have not independently 'discovered' this fantastic solution to this horrible 'problem' already on their own. Of course, they could also move with the times, and adopt an XML format for command arguments which would be much more extensible and Web 2.0 compliant. That way all commands could share the same dynamically linked parser, and one could write scripts with their favorite XML-editor! uriel
Re: [9fans] mishandling empty lists - let's fix it
You can build this whole dream using plan9 and show the world, you don't
have to rewrite any of the utilities, just shape the calling convention
to your liking.
I bet you could even find the pattern and wrap the whole lot in a meta
script, maybe even utilise an FS
fn mkdir {
if(! ~ $#* 0)
/bin/mkdir $*
ifs = '
'
m = `{read}
while(! ~ $#m 0) {
ifs = ' '
p = `{echo -n $m}
/bin/mkdir $p
ifs='
'
m = `{read}
}
}
with no newlines in directory names
*On Mon, Oct 5, 2009 at 2:04 PM, John Stalker stal...@maths.tcd.ie wrote:
`cat' would concatenate 0 files, i.e. ouptut nothing,
cat would copy stdin to stdout
`chmod 755' would set the permissions of no files to 755,
would read a list of files from stdin and change the modes
`cp foo/' would move no files to the directory foo,
would read a list of files from stdin and copy them.
`df' would show free disk space for no filesystems,
would read a list of file system names and df them.
`kill' would stop no processes,
would read a list of pids in and stop them.
`ln foo/' would hardlink no files into the directory foo,
would read a list of filenames in and ln them
`ls' would list no files (you would use `ls .' for the usual case),
would read a list of file names in and ls them.
`mkdir' would create no directories,
would read a list of file names in and mkdir them (I could really use this one)
`mv foo/' would move no files into the directory foo,
would read a list of file names in and mv them
`ps -U' would show no users' processes,
would read a list of user names in and ps them
`rm' would remove no files,
would read a list of file names in and rm them
and `sh' would execute no scripts in the Bourne shell.
would read a set of commands from stdin and ... oh wait it does this.
I prefer my version to your versions. I can see uses for them already.
ron
Re: [9fans] mishandling empty lists - let's fix it
There are a lot basic UNIX/p9 utilities which treat empty lists inconsistently. It would be nice if there were fewer, but you can't arrange that without breaking many things. the beauty is that these utilities do inconsistent things, and therefore are not easily confused. we're arguing that birds, mammals and fish should all have the same number of legs. let's hope there are no centipeds. - erik
Re: [9fans] mishandling empty lists - let's fix it
On Tue, Oct 06, 2009 at 08:59:32AM +0200, Uriel wrote: I'm sure the people in charge of writing the next version of the PoSix standard will be very happy to adopt your proposal! That is, if they have not independently 'discovered' this fantastic solution to this horrible 'problem' already on their own. Of course, they could also move with the times, and adopt an XML format for command arguments which would be much more extensible and Web 2.0 compliant. That way all commands could share the same dynamically linked parser, and one could write scripts with their favorite XML-editor! uriel Breaking news: bash now uses mysql to store your history, environmental variables, et cetera. Don't forget to tune in at 7 to discuss Emacs newest feature,a Virtual Machine that runs in the editor. -- Jake Todd // If it isn't broke, tweak it! pgprtPUY4wVko.pgp Description: PGP signature
Re: [9fans] mishandling empty lists - let's fix it
So I'd welcome commands which behave the new way, and I wouldn't have a problem calling them by other names. My thinking is that a shell with slightly different command execution semantics may be required, together with commands and/or built-in commands and functions that behave consistently with the shell's philosophical design. In addition, I don't think an empty list should ever be implied, or at minimum ought to be able to be specified explicitly, () would suit me fine, '' may or may not be a viable alternative. But we've drifted off a critique of conventional usage to the realms of philosophical design and the terms of discussion are now very different. ++L
Re: [9fans] mishandling empty lists - let's fix it
On Tue, Oct 6, 2009 at 14:27, John Stalker stal...@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
Re: [9fans] mishandling empty lists - let's fix it
sqweek:
It seems to me the obvious way to gain consistency is to do the list parsing
in one place only:
hi sqweek,
Thanks for the thoughtful response. You are right, it could be fixed with
another tool like xargs. I wrote a similar tool modify which I use to modify
files in place with standard tools, like `modify nl : a b c` to number lines in
three files. Given that nearly all the tools do already handle lists of
arguments (wrongly), I saw a need to correct them.
Plan 9 tools that accept options already do accept `--' to mark the end of
options and the start of proper arguments, it is a necessary feature.
I will show what sort of change would be needed for grep. I have not looked at
the source for plan 9 grep, so this is just an example.
If the existing code was:
char *pattern;
int use_stdin, prefix_filename;
...
if strcmp(argv[i], --) == 0
...
...
pattern = argv[0]; ++argv; --argc;
use_stdin = !argc;
prefix_filename = argc 1;
The changed code would be:
char *pattern;
int dwim, use_stdin, prefix_filename;
dwim = 1;
...
if strcmp(argv[i], --) == 0
dwim = 0
...
...
pattern = argv[0]; ++argv; --argc;
use_stdin = dwim !argc;
prefix_filename = !dwim || argc 1;
The difference from current logic is very slight. It's not rocket science.
Then something like:
grep foo -- `{find ...}
would work correctly and consistently.
grep foo -- *
will still not work because rc's globbing also fears zero and returns the
pattern instead of an empty list if there are no matches.
Sam
Re: [9fans] mishandling empty lists - let's fix it
you're retaining the inconsistency, but candy-coating it. No, I'm offering a simple syntax using which one can avoid the inconsistency. I'm retaining the option to have inconsistent behaviour, for backward compatibility, and because some people seem to like it for command-line use. cat * # still ok, will break if no files match, or a file called -v etc cat -- * # more reliable (so long as * returns empty if it fails to match) The new syntax comes for free with `--', which is the standard syntax used by almost all programs that take options and also process one or more files named on the command line. `--' is needed so that these programs can cope with filenames starting with a dash like `-README-' for example, and not confuse them with options. All serious scripters should be using this `--' already, especially if they are doing sysadmin work, otherwise their scripts may break or go on a rampage deleting stuff when some user makes a file called `-rf'. This fix (to support zero-length file lists when using `--') would not only keep compatibility, it would also fix a whole lot of buggy scripts that are using `--' but not checking for the empty list. I doubt anyone should invest the time and effort to implement this I've added support for this feature into my get_options function, which I use in my own programs. It took me about 1 minute to do that. I expect a similar amount of time would be needed to fix each major tool having the problem. There might be 10 or 20 such tools that are commonly used in plan 9. So it would be less than a couple hours work. cat - cat /fd/0 cat There's no longer any need to implement support for `cat -' and similar to avoid the problem of mishandling empty file lists, although it might be nice. I'm sick of this topic like everyone else must be so that's all from me. Sam
Re: [9fans] mishandling empty lists - let's fix it
sqweek wrote:
fn apply {
cmd=$1
shift
while(! test $1 = :) {
cmd=($cmd $1)
shift
}
for(i in $*) $cmd $i
}
# eg: apply grep foo : *.c
that's the beauty of the rc shell, you can define what you like
fn cat {
if(~ $#* 0)
/bin/cat /dev/null
if not {
as = ()
for(a in $*) {
if(~ $a -)
as = ($as /fd/0)
if not
as = ($as $a)
}
/bin/cat $as
}
}
now
% echo test | cat
% echo test | cat -
test
% cat /lib/words | sed 1q
AAA
%
If your shell programs are defeated by unexpected empty lists I suggest
you write better shell programs :)
Re: [9fans] mishandling empty lists - let's fix it
grep foo -- * will still not work because rc's globbing also fears zero and returns the pattern instead of an empty list if there are no matches. i used to think that was a misfeature. in college i wrote a shell that elided failed globs in the argument list. the problem is that people assume that failed globs generate an error, e.g. cat «glob pattern» [2=] || echo cat failed i didn't redesign the system, so that would hang with my shell. if we follow your redesign of unix, we would never get an error because cat * does nothing and wouldn't be an error at all. one would need to write x = * if(~ $#* 0) echo cat failed if not cat $x that seems less attractive to me. - erik
Re: [9fans] mishandling empty lists - let's fix it
Does anyone agree with me that it needs fixing? For what it's worth, I agree that it's a problem. Maybe it's just the fact that I'm a mathematician, but I've always felt that any command which accepts a list of files should behave the way I would expect when presented with an empty list. Cat, rm, chmod, etc. do not. At a minimum I think we should try to avoid creating further exceptions. Does it need fixing? Implementing it properly would break most shell scripts I've written. If there were renamed versions of cat, rm, chmod, etc. which treated empty lists in the expected way then I would probably use them in situations were portability is not an issue. It would remove a frequent source of bugs and leave me with one less thing to worry about. Then there is the shell. If you only use commands which behave sanely for empty lists then the current globbing rules are a pain. Changing them to, for example, expand * to `' in an empty directory breaks too many things. I've learned to avoid globbing as much as possible. In any shell with command substitution globbing is unnecessary, and is often dangerous. I would happily use a shell with NO globbing, just to avoid another source of worries. -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] mishandling empty lists - let's fix it
i think this is all a bit dramatic. ... if i could roll back time, i would push for regular expressions instead of the goofy shell matching. then knuth could have to say that unix is 29 definitions of regular expressions living under one roof. :-) But you can use regular expressions instead of goofy shell matching. Find and ls give you lists of file names and grep prunes them for you. Shell command substitution then puts them in the right place in the command, or use xargs when appropriate. I don't claim that globbing is a horrible evil, merely that it is an unnecessary evil. -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] mishandling empty lists - let's fix it
I think that you're right to complain, but that you aren't quite complaining about the right thing and are therefore offering the wrong solution. The problem is utilities which take list arguments, but which treat empty lists differently. Shell globbing rules can make this better or worse, depending on context, but the problem is in the semantics of our favourite utilities. In a consistent world `cat' would concatenate 0 files, i.e. ouptut nothing, `chmod 755' would set the permissions of no files to 755, `cp foo/' would move no files to the directory foo, `df' would show free disk space for no filesystems, `kill' would stop no processes, `ln foo/' would hardlink no files into the directory foo, `ls' would list no files (you would use `ls .' for the usual case), `mkdir' would create no directories, `mv foo/' would move no files into the directory foo, `ps -U' would show no users' processes, `rm' would remove no files, and `sh' would execute no scripts in the Bourne shell. None of these would produce errors. These are UNIX examples, but Plan 9 is not much different in this regard. A quick glance shows that somewhere between a third and a half of all the basic utilities have this property. Nothing you do to the shell will change this much. A quick look through shell scripts I've written recently convinces me that almost all of them would break if the basic utilities were modified to treat empty lists consistently, even though only one uses file name globbing in any way. If you really want to fix the problem then the sensible thing to do would be to write new versions of many utilities, with new names, and then write a shell without globbing. For new scripts you would use the new utilities and shell and leave everything else as it is. Is it worth the effort? That's a question which can only be answered by the person who would be doing the work. -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] mishandling empty lists - let's fix it
if `--' is seen, do not do anything dwimmy in the case of 0 or 1 files in the list, treat them like any longer list. The system is very much the same. No, it's more complicated, because it is two systems with a mode bit to choose between them. Russ
Re: [9fans] mishandling empty lists - let's fix it
If you really want to fix the problem then the sensible thing to do would be to write new versions of many utilities, with new names, and then write a shell without globbing. For new scripts you would use the new utilities and shell and leave everything else as it is. Is it worth the effort? That's a question which can only be answered by the person who would be doing the work. I see the point of having utilities handle no-input without failing and without error output (other than maybe a status to test the case), when their output is used as input to other utilities, especially as embedded commands on the command line. I often use the backtick style to output into an assignment to *, to separate with $1 etc. Currently if a program fails, then instead of no output (maybe ok, depending on the program) it delivers a noisy error message and an exit status. This style is not the most common use case: most people mean to change the state of the system when they run a command, and want to see error messages when a list turns up empty. So I'd welcome commands which behave the new way, and I wouldn't have a problem calling them by other names. (My first thought was the suffix 0. You might want to avoid the prefix g.) John Stalker Jason Catena
Re: [9fans] mishandling empty lists - let's fix it
On Mon, Oct 5, 2009 at 2:04 PM, John Stalker stal...@maths.tcd.ie wrote: `cat' would concatenate 0 files, i.e. ouptut nothing, cat would copy stdin to stdout `chmod 755' would set the permissions of no files to 755, would read a list of files from stdin and change the modes `cp foo/' would move no files to the directory foo, would read a list of files from stdin and copy them. `df' would show free disk space for no filesystems, would read a list of file system names and df them. `kill' would stop no processes, would read a list of pids in and stop them. `ln foo/' would hardlink no files into the directory foo, would read a list of filenames in and ln them `ls' would list no files (you would use `ls .' for the usual case), would read a list of file names in and ls them. `mkdir' would create no directories, would read a list of file names in and mkdir them (I could really use this one) `mv foo/' would move no files into the directory foo, would read a list of file names in and mv them `ps -U' would show no users' processes, would read a list of user names in and ps them `rm' would remove no files, would read a list of file names in and rm them and `sh' would execute no scripts in the Bourne shell. would read a set of commands from stdin and ... oh wait it does this. I prefer my version to your versions. I can see uses for them already. ron
Re: [9fans] mishandling empty lists - let's fix it
`ln foo/' would hardlink no files into the directory foo, would read a list of filenames in and ln them better: ln: '/bin/ln' directory entry not found - erik
Re: [9fans] mishandling empty lists - let's fix it
On Tue, Oct 6, 2009 at 4:37 AM, erik quanstrom quans...@coraid.com wrote: `ln foo/' would hardlink no files into the directory foo, would read a list of filenames in and ln them better: ln: '/bin/ln' directory entry not found well, yea, but I didn't want to get into that one :-) ron
Re: [9fans] mishandling empty lists - let's fix it
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, lu...@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
Re: [9fans] mishandling empty lists - let's fix it
What do you think of this proposal? I think the saying is the game is not worth the candle. I doubt anyone should invest the time and effort to implement this, specially as few will adopt its use. Of course, fifty years from now everyone would be savvy to it, but by then one expects a different environment and this type of consistency will have lost meaning. Plus, by adding this feature you're not achieving the objective I thought you sought, which was to make the commands inherently consistent: you're retaining the inconsistency, but candy-coating it. My long-ago mentor would suggest you have not yet read Catch-22. ++L
Re: [9fans] mishandling empty lists - let's fix it
cat - cat /fd/0
Re: [9fans] mishandling empty lists - let's fix it
cat - cat /fd/0 cat :-) ++L
Re: [9fans] mishandling empty lists - let's fix it
`--' ends options, forces consistent multi-file mode, allows empty lists Hey, yeah, great idea. And why not use '---' to force switching to Linux compatible mode, and '' to switch to BSD syntax, and '-' for System V syntax (5 hyphens, System 5, easy to remember). Oh, and we might need a way to switch back to Plan 9 syntax. That better be '' (0 hyphens). Example: cat -s - -s '' -v prints the contents of file named '-v', squeezing multiple empty lines (BSD -s) and silencing error message (System V -s).
Re: [9fans] mishandling empty lists - let's fix it
2009/10/4 Sam Watkins s...@nipl.net:
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, lu...@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.
It seems to me the obvious way to gain consistency is to do the list
parsing in one place only:
fn apply {
cmd=$1
shift
while(! test $1 = :) {
cmd=($cmd $1)
shift
}
for(i in $*) $cmd $i
}
# eg: apply grep foo : *.c
Of course, this is likely to run you into other problems with the way
some programs want to use their arguments, which is why unix/plan 9
adopt the pragmatic approach.
PS. excuse the test usage, feel free to point out the ~ idioms - if I
see them often enough they might stick in my memory :)
PPS. i didn't actually check the semantics of for on an empty list,
maybe a conditional is required
-sqweek
Re: [9fans] mishandling empty lists - let's fix it
cat * /dev/null is the recommended solution. -rob
Re: [9fans] mishandling empty lists - let's fix it
On Sat, Oct 03, 2009 at 10:01:09AM -0700, Rob Pike wrote: cat * /dev/null is the recommended solution. Thanks Rob, That works with cat, but it won't work with chmod, grep -L, ls, find, file and many others. I think all of the unix and plan 9 utilities that deal with a variable number of files have this problem. Does anyone agree with me that it needs fixing? Sam
Re: [9fans] mishandling empty lists - let's fix it
On Sun, 04 Oct 2009 03:03:27 +1100 Sam Watkins s...@nipl.net wrote: find -name '*.c' | xargs cat | cc - # this clever cc can handle it :) This program works fine until there are no .c files to be found, in that case it hangs, waiting for one on stdin! This is a hazard to shell scripters, and a potential source of security holes. Your example doesn't hang (and if it does, your xargs is broken). You are thinking of something like this: $ echo 'cat $*' foo.sh $ sh foo.sh This is not elegant but a reasonable tradeoff. A common use of many tools is in a pipeline and having to type - every time can get annoying. To fix this you may think of changing your shell to append /dev/null if a command is given no arguments but that will fail in cases like `cat -v'. In unix it is upto each command to interprets its arguments and a shell can not assume anything about command arguments.
Re: [9fans] mishandling empty lists - let's fix it
Does anyone agree with me that it needs fixing? I don't. I also think that even if it were a problem the usage is far too ingrained to be fixable. -rob
Re: [9fans] mishandling empty lists - let's fix it
Does anyone agree with me that it needs fixing? I don't. I also think that even if it were a problem the usage is far too ingrained to be fixable. Nor do I. Having the no-argument case be filter behavior (stdin/stdout) is the most elegant, consistent, and predictable of the options I've seen. BLS
Re: [9fans] mishandling empty lists - let's fix it
Nor do I. Having the no-argument case be filter behavior (stdin/stdout) is the most elegant, consistent, and predictable of the options I've seen. Yeah, I always found the lone - very ugly! If you do a fix you could also add --outputfile in order to improve the readability :D
Re: [9fans] mishandling empty lists - let's fix it
Does anyone agree with me that it needs fixing? sorry, I don't agree that it is broken so I don't thing it need fixing. It does occasionally annoy me that tr(1) will not take a file as an argument but again, changing that would have implications too wide to make it worthwhile; I try to think of it as OS patina. -Steve
Re: [9fans] mishandling empty lists - let's fix it
I don't see how this can be fixed in unix without breaking umpteen million shell scripts. By creating new commands with distinct new names. ++L
