Christian Couder <christian.cou...@gmail.com> 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
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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html