Christian Couder <> writes:

> If the input comes from stdin, then I agree that the command should be
> a filter, so its output should be on stdout. But if the input comes
> from files given as arguments, then I would say that the command
> should behave as an editor and by default it should edit its input
> file inplace.

I do not see where that "should" comes from.  I am looking at this
more from the angle of obtaining a useful building block, while you
seem to be thinking of this as a specialized tool for a narrow set
of specifkc tasks.

Thinking of examples in "sort" and "sed", I would say "read multiple
files, futz with the contents and spit out a single output stream"
is the way people expect a command to operate without being told to
operate in some other way.  Overwriting existing files should never
be the default for safety---otherwise you would require people who
want safety to do something like:

    cp realfile tmp
    futz tmp
    verify tmp
    mv tmp realfile

On the other hand, a usual "sort/sed/cat"-like command, even without
the "in-place edit" option, can be used as in-place with

    mv realfile tmp
    futz tmp >realfile

easily, and is more flexible as a building block.  Of course, that
does not rule out an option to work in-place (e.g. in a similar way
to "sort -o file file", or "perl -i -e 'y/a-z/A-Z/' frotz nitfol").

> Its input and output files should be different only if
> it is given one or more special option,
> Otherwise the example you gave:
>     $ git format-patch -5 --cover-letter -o +my-series/ my-topic
>     $ git interpret-trailers "some args" ./+my-series/0*.patch
> would result in having on stdout all the patches edited by "git
> interpret-trailers".

Didn't I mention that I do not mind "-i" already if in-place edit is
desired?  Add "-i" to the command line arguments among "some args",
and your complaints will disappear, no?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to