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/ _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils