On Thu, 28 Feb 2002, Garrett Rooney wrote:
> On Thu, Feb 28, 2002 at 03:49:23PM -0000, Peter Fox wrote:
>
> > If you have cygwin on Win32 then you have xargs. Most PC developers
> > (including myself) tend to abandon the command line pretty quickly, or they
> > install cygwin.
>
> That's not good enough. Subversion is intended to run on Win32 as an
> actual Win32 application, without cygwin. We have developers now who
> develop Suversion on Win32 without having cygwin installed. The
> extremely small limit on the length of a command on Win32 is one of
> the reasons that this option is being written.
There has been recent discussion of the addition of a similar feature in
Vim on the vim-dev mailing list, as well as discussion about how it should
work on the Jikes mailing list. The idea brought up much debate and worry
about how it should work exactly. I'll try to summarize some of the
points here so that we don't start that discussion from scratch.
First, Jikes (IBM's open source java compiler), and several other
DOS programs it seems, use an @file option to mean "read this file for
arguments". From the Jikes man page:
An argument may have the form @file; each line of file is
then interpreted as an argument, except that lines begin-
ning with @ are not expanded recursively.
So, using an @file argument seems more standard in the Win/DOS world than
using a --targets option. On the other hand, I don't know if @- is
standard or just weird.
The difficulty comes up with processing files with spaces in their names.
Question 1: Do you require each "target" to reside on a different line in
the file? If not, then you need to worry about quoting file names. E.g.
Does this file represent one or three targets:
trunk\My Documents\Word Document.doc
How about this:
"trunk\My Documents\Word Document.doc"
Is that a file whose name ends in " ? Three files, the last of which ends
in " ? What if you had a file with " in its name? Then you'd need
backslash escaping ability. But then all the \ would have to be doubled:
"trunk\\My Documents\\\"The Refrigerator\" Perry - bio.doc"
Nobody wants that.
So, it seems, the answer is to keep one, unquoted argment per line. If
we're not offering Jikes functionality of "the file contains arguments",
but rather "the file contains targets", this isn't so bad. (But maybe we
should stay away from the @file notation, if it implies that any argments
can be put in the file. I'm not really a Win/DOS user so I don't know
what @file implies to most people.) If we are using Jikes definition of
@file, then you couldn't write this in a file:
-m "commit message"
file 1.doc
file 2.doc
Instead it would have to be:
-m
commit message
file 1.doc
file 2.doc
Which looks a little weird but seems functional (except you can't have
multi-line commit messages this way).
Secondly, the debate on the vim list was whether or not to add such
functionality at all, since various shell tricks already offered it.
"xargs" is not a good substitute for @file args in vim because vim needs
to read the stdin from the user, and xargs is already eating stdin from
the command being piped to it. I don't know whether committing with svn
has the same problem... I would guess that when it pops up vi to edit a
commit message, you don't want stdin to be wasted on the xargs.
Using shell backticks has problems with spaces again. Assume that you
have added files "file 1.doc" and "file 2.doc"
svn ci `svn --list added`
There is no way (I've ever seen) to have the shell correctly pass the
right arguments (two instead of four) to svn ci.
So, it seems that we need a way to read arguments or targets from a file,
and having a special case to read them from stdin can be very useful.
Probably the arguments need to be one-per-line with no quoting or
escaping. This leaves open the questions: "--targets file" or "@file" or
both. And, do we take extra options in the file, or just target
filenames?
Hope the input is helpful. Please correct me if I've jumped to any
conclusions I shouldn't have.
-David Mankin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:10 2006