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...
