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
