Globbing (was Re: HAMMER update 10-Feb-2008)

[Jason Smethers]

0432c$0$854$415eb37d at crater_reader.dragonflybsd.org>
In-Reply-To: <47b0432c$0$854$415eb37d at crater_reader.dragonflybsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 41
Message-ID: <47b0bc6f$0$854$415eb37d at crater_reader.dragonflybsd.org>
NNTP-Posting-Host: 76.30.224.215
X-Trace: 1202764912 crater_reader.dragonflybsd.org 854 76.30.224.215
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:12092

Oliver Fromme wrote:
> Filename expansion ("globbing") has nothing to do with
> file systems.  It is purely a shell feature (and every
> shell implements its own).  Putting it into the kernel
> makes no sense.  Note that there are globbing support
> functions in libc (POSIX/SUS wants them, and some apps
> use them), but no shell uses them, even the base /bin/sh
> implements its own filename expansion.
> 
> The limit you're talking about ("too many arguments")
> is the execve() argument limit.  Historically all the
> arguments plus environment could not exceed 64 KB.
> A few years ago FreeBSD increased the limit to 256 KB.
> I don't know if DragonFly did the same, but it doesn't
> matter much -- The point is that things like "rm *"
> are unsafe if you don't know to what amount the glob
> expression will expand.  No matter whether the limit
> is 64 KB or 256 KB, there _is_ a limit.
> 
> That's why xargs(1) exists:  "echo * | xargs rm" is
> safe (echo is a shell-builtin, so it is not subject to
> the execve argument limit).
> 
> Best regards
>    Oliver
> 


Would it not be possible to modify the shell itself to check for long 
argument lists, and implicitly do something similar to using xargs in 
such cases?

Or would this be a bad idea since it makes it far easier for users to 
shoot their foot?

Which brings up another point. Does HAMMER have a "deleted timestamp" 
which could be used in an undelete utility?


--
Jason Smethers