On Fri, Aug 9, 2013 at 1:36 PM, j. van den hoff
<veedeeh...@googlemail.com>wrote:

> fossil --user joedoe ci filename
>
> fossil ci --user joedoe filename
>
> the second version looks "normal" in that `ci' apparently takes a `--user'
> option plus argument. the first one is the "problem" for the `fsl'
> wrapper since it of course cannot (and should not need to) mimic the
> complete command line parsing of `fossil' in order to get it correctly
> interpreted.


A side-note on WHY that happens, for those who are interested... when
find_option() is used to fetch a flag, the caller has to tell it the name
of the flag and whether or not that flag expects a value. The the above
case the name would be "user" and it does expect a value. So fossil starts
looking through g.argv (an array of strings) to find the option. If it
does, it _removes_ it from g.argv (and decrements g.argc: the count of
items in g.argv). If the argument expects a value, it also removes the
_next_ entry from g.argv and decrements g.argc. So after calling that,
fossil effectively has fewer arguments than it had before, which means that
the command can then simply look at g.argc to figure out if the user passed
in the right number of arguments (for many cases, anyway, though some
require more advanced logic).

Anyway... i found those details highly interesting when i started work on
the JSON API. At first the update-g.argv behaviour annoyed me (on a
philosophical level), but now that i understand why it works that way, i'm
good with it.


> bottom line: I really would be grateful if someone could clarify whether
>
> fossil COMMAND ?args and files?
>
> is actually the only "valid" syntax for command line usage (ignoring the
> `--args FILENAME' way of feeding `fossil' commands from a file)
> and that things like
>
> fossil --user joedoe ci filename
>
> are not guaranteed to work/should be avoided?
>

The current code can't make such a guaranty. It can guaranty that the above
two variants are functionally equivalent, but ONLY if the specific command
handler does its argument/flag checks in such a way that makes them
equivalent. i.e. the commands which do all flag-checking up front, before
examining other arguments will treat the above as equivalent because the
flag-checking filters out g.argv for their later processing.

In case you don't know about it, there's another seldom-used feature which
potentially adds even more confusion/combinations to your examples: the
--args FILENAME option, which basically replaces the (--args FILENAME) args
with the contents of the given filename:

http://fossil-scm.org/index.html/artifact/952d72d35e5ab9ea4815d68e7820d9deae701433?ln=357-366

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to