[darcs-users] Re: [darcs-devel] [darcs #477] darcs replace error message not too informative

David Roundy droundy at abridgegame.org
Sat Jul 30 19:00:05 UTC 2005


Ccing this to darcs-users to see if anyone objects to my suggestion (see
end) that we accept flags in any order (as long as they're after the darcs
command itself).  I don't think this'll cause trouble, but it's a rather
major change, and there may be a problem that I don't see.

David

On Sat, Jul 30, 2005 at 02:41:12PM -0400, VMiklos via RT wrote:
> $ dr replace foo@ bar@ fwmakepkg --token-chars '[A-Za-z0-9_@\.]'
> darcs failed:  'foo@' is not a valid token!
> fwmakepkg is the test file
> 
> dr replace --token-chars '[A-Za-z0-9_@\.]' foo@ bar@ fwmakepkg
> 
> and this works. so that if --token-chars is given at the end of the 
> command line, it doesn't get parsed

Thanks for the bug report!

> i think there are two solutions:
> 
> 1) fix the error message, so that it would print that you shouldn't use 
> --token-chars at the end of the command line
> 2) parse that command line that way to acceppt --token-chars this way, too

The problem here is two-fold (matching the two solutions you propose).

The way darcs uses getopt to parse its command line, "flags" have to come
before "arguments", where "arguments" are things that getopt doesn't know
about--in this case files.  Getopt then treats everything after the last
valid flag as an "argument".  Your solution number two would involve
changing how we call getopt to allow intermingled flags and arguments.  I'm
not sure how hard that would be, but when I last tried it (years ago) it
seemed hard.  And I don't like working on getopt.

The other problem is that we give a terrible error message here.  I'm not
sure the best solution to this.  Perhaps we should make out getopt
configuration smart enough to look for out-of-order flags and warn the
user.  We could also eschew getopt, and just check the files to see if any
of them look suspiciously like flags, and give a warning in that case,
something like

$ darcs replace foo@ bar@ fwmakepkg --token-chars '[A-Za-z0-9_@\.]'
Warning: suspicious filename '--token-chars', beware that all flags must
         come immediately after 'darcs replace'.
darcs failed:  'foo@' is not a valid token!

This would be easier than either of the the two comprehensive solutions.

Another option would be to migrate to a different command-line parsing
library that might be easier to configure.

A quick look at the docs suggests that solution (2) may just consist of
swapping RequireOrder for Permute in run_command.  I'm not sure why I
thought this was so confusing...

The question then is whether we *want* to accept arguments in any order? I
lean towards this solution... I think I've wanted it for some time, but
didn't want to touch getopt again.

Any other opinions?
-- 
David Roundy
http://www.darcs.net




More information about the darcs-users mailing list