Re: Version 2.1.70 ms-dos fs strange.

[Nick Holloway]

[e-mail] (Rogier Wolff) writes:
> So, go ahead and fix your shell. 
> 
> *.bak doesn't match anything, it should return "nothing". My shell
> (tcsh) says "*.bak: no match" in that case. When I do "rm *.o *.bak"
> and *.o matches something and *.bak doesn't, then I don't get the
> message, *.bak evaluates to an empty string, and all goes well.

I believe POSIX requires that if no files match a pattern, then the
pattern is left alone.  This is the way that ksh, bash, ash all work
(and sh always has done).

The handling of wildcards within shells is not the question being raised.
The problem is that 'unlink("*.bak")' returns EINVAL, not ENOENT.

It does seem reasonable that looking for a file whose name can not be
created should return ENOENT, and that trying to create that file should
return EINVAL.

I was going to compare this with the 14 char Minix FS, but >14 char file
names are non invalid, they are just truncated.

-- 
 `O O'  | [e-mail]  http://www.alfie.demon.co.uk/
// ^ \\ | [e-mail]  http://www.parallax.co.uk/~alfie/