gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Pipes?


From: Pierce T . Wetter III
Subject: Re: [Gnu-arch-users] Pipes?
Date: Wed, 17 Mar 2004 15:55:37 -0700


On Mar 17, 2004, at 1:42 PM, Tom Lord wrote:


From: "Pierce T.Wetter III" <address@hidden>

  Call me crazy, but I think that:

Your crazy.

 :-)

  tla tree-lint -m | tla delete

  Should work.

By extension of that idea, every command that can accept a few
arguments on the command line should be modified to have additional
code to read a list of those arguments from a stream.

In a few cases, such as tar, that's the right thing.   For example,
you might very well need to pass tar more arguments than can fit on a
command line and, at the same time, you need to handle all of those
arguments in a single invocation.   So, tar has such an option.

But xargs is designed to solve the common case.  The right thing here
is to make sure that xargs works.

I can easily think of cases where someone would want to pass more arguments
to tla then can fig in a command line...

There's a choice about how to make xargs work.   One idea is that
xargs could itself do unescaping.   It's going to pass arguments in an
argv so there would be no ambiguity resulting from unescaped
filenames.

 Thing is, xargs can do some unescaping already. It converts \\ to \ for
instance. It just seems to be doing different unescaping then the
pika escaping...

The other idea is that all arch commands should unescape their command
line arguments which are filenames.

Subcommand expansion (backticks and $(...)) complicates things.

 Which was why I was arguing for pipes instead.

  In other words, tla should be able to read in a list of file names
from stdin. For one thing, changing the idiom from backticks to pipes
would help the escaping stuff a lot, since files would be delimited by
returns instead.

  Or at least:

  tla tree-lint -m | tla delete -pipe

  should work. That is, if a command sees -pipe, it knows to read more
arguments from stdin.

  Any objections?

Yes.   I don't want every command that follows this pattern to need a
--pipe or --list option.

Actually, I was thinking it might be a global option. Early on in main(), it would look for a --pipe option, and if it found one, append stdin to argv before doing anything else.

 Pierce





reply via email to

[Prev in Thread] Current Thread [Next in Thread]