Re: [Gnu-arch-users] Pipes?

[Tom Lord]

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

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.

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

Subcommand expansion (backticks and $(...)) complicates things.
Suppose I have:

        tla delete `somecmd`

If somecmd outputs escaped filenames, then `delete` sees the right
number of arguments, but would have to unescape those arguments
itself.

If somecmd outputs unescaped filenames, then `delete` will be handed
the wrong number of arguments, some of which are bogus.

I see no good solution to that in /bin/sh-world.  You can work around
it using xargs.

The Right Thing is a shell that doesn't suffer from these ambiguities,
such as SCSH.



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

-t