Re: ls options: accept stdin, and list files except for...

[Dan Heller]

I wrote:
> > I can't use xargs, backticks, or even a shell script that saves the
> > list and launches things separately because of the inherent problem
> > that the command can't be executed if the arg list is too long.

I'll reply to richard's response first:

> Um, that's the problem that xargs is designed to avoid. It knows the maximum
> allowed command-line length. If the command-line would be too long for
> whatever command xargs is running, then it will split it.

While it technically "works" in that comands don't "fail", per se, it
doesn't solve the real problem at hand; the command is reading all the
info coming in (du, in this case), and tallying up info "on the fly". If
it then has to terminate and be restarted again (by xargs), it isn't aware
of it. To du, it's just running anew. To the user, it's supposed to be
one task. Some commands that are basically stateless (e.g, mv, cp, etc),
can survive with xargs exactly as you point out. Stateful commands,
(du, dd, tar) do not always have that luxury. The spirit of pipe() was
written into unix to solve this very problem, and commands were originally
all supposed to support this concept. I think "rogue" was the first unix
program (ok, it was a game) that didn't support this concept, but that
didn't last long; someone wrote "rogue-o-matic".  but I digress...

Anyway, the other method is to support the "take the input from a file"
approach that Dave pointed out:

> Another "standard" way to solve this is to have an option that is a file
> that contains options.
> This is fairly standard on lots of systems ...

I don't disagree with this approach at all, and if you deem it to be a
"standard" methodology, so be it. But, it's not an argument against the
"stdin" approach either. Not to beat a dead horse on the point, but the
UNIX heritage is all about having small, light processes that can be strung
together by pipes. Ok, so they may no longer be "small", and "light" is
a relative term now... but "strung together by pipes" is still a great idea
that should be supported to any degree that's feasible.

(Not that I have a problem with xargs at all, but let's remember that xargs
was _originally_ supposed to be the patch program that "fixed" the broken
programs that erroneously neglected to support stdin; now it seems to be
the preferred method? That's putting the cart before the horse, isn't it?)

But, more to the point, I do not think either competes with the other;
in fact, they are othogonal, and different situations can arise that may
call for using one approach over another. Stdout-to-stdin is better for
command-line piping, whereas the "file that contains options" approach
is better for scripts and other multi-state programming tasks (where
you  may need to save and preserve output from one command to be used
later as input to another).

If it weren't for the fact that this is all so easily implemented, I
could see the resistance. But, its implementation is so simple, standard,
and almost-ubiquitous in existing utils, why not just finish the job and
support it for all file-utils?


-- 
--dan
http://www.danheller.com/