Globbing

[Oliver Fromme]

Jason Smethers wrote:
 > 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).
 > 
 > 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?

Doing it automatically would break other things.
There are cases where you have to take special
precautions when a command is executed multiple
times vs. once.  If xargs is used automatically,
you never know in advance for sure how often the
command will be invoked.

For example, it would break all tools that create
an output file based on a number of input files.
A typical example would be linking object files
to produce an executable:

$ cc -o mybinary *.o

If the shell automatically decides to use xargs,
then cc might be invoked multiple times, each time
with a subset of the object files.  Of course it
will fail and not produce a working binary.

That's just a simplified example of course.  There
are many more such cases.

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

I think you have to know the time when the file
was deleted, so you can access it right before
that timestamp.  If you don't know the time when
it was deleted, you have to use a binary search
on the directory (not difficult).  If the file
didn't change recently before it was deleted,
the the exact time of deletion doesn't really
matter, of course.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd