D 2019-09-27T14:31:29.317
L branch/double-dash-flag
N text/x-markdown
P 6075be4e19e9dbe94c3b4691dc005625381afca76e4b1bea44bdb82d1b558b47
U stephan
W 3067
# Management Summary
The `double-dash-flag` branch aims to add support for the conventional interpretation of a `--` flag: all arguments after the first instance of `--` are to be treated as non-flag arguments (e.g. file/wiki/branch/whatever names).
This feature request is from: <https://fossil-scm.org/forum/forumpost/64acc6b653>
The implementation is not *100%* compliant with POSIX/Unix conventions because it cannot be without *Breaking Stuff*, but it "should" be close enough to be useful/conventional for the contexts where using `--` makes sense in Fossil. For example, `uv add` treats a filename of `-` as `stdin` by default (and has valid use cases enabled by that), and `--` could be used to make `uv add` treat `-` as a filename ([that's the original use case for which conventional `--` support was proposed](https://www.fossil-scm.org/forum/forumpost/d6fa7422db)).
# Compatibility vs. Historical Behaviour
Fossil's [historical handling of `--` is really weird](/artifact?ln=925-928&name=a35b33b329ab2038): the *first* time `find_option()` encounters `--`, it *removes* that flag and stops processing arguments. Subsequent calls to `find_option()` then never see `--` and thus treat all arguments as potential flags (even those after the prior position of `--`). Since that behaviour was never useful, and potentially confusing, it is unexpected that the changes made in this branch will break any historical usage of the CLI commands.
For example:
fossil foo -- -a -b -c
The current (trunk, as of this writing) interpretation of `-a -b -c`, because of the "one-time-swallowing" of `--`, depends on what order those flags are checked for via `find_option()`. It seems highly unlikely that anyone could have reliably depended on that, and therefore seems unlikely that this change will break anyone's scripts.
Commands which accept a filename as the value of a flag are unaffected by these changes, provided the flag comes before `--`:
fossil foo -R - -- -a -b -c
Would (both before and after this change) treat `-` as a repository file name, but this change will cause the subsequent `-a -b -c` flags to be interpreted as non-flags (it's then up to the `foo` command to deal with them).
# (ONGOING) List of commands/subcommands extended to support `--`
(Please keep this list alphabetized by command/subcommand name.)
* `branch new`: you might recall Johnny Cash's song *The Branch Named --Sue*.
* `uv add`: unconditionally reads in its contents via `blob_read_from_file()`, which internally treats `-` as stdin. Thus adding `--` support here requires (A) that `uv add` know that `--` was provided, (B) that `--` was provided *before* `-`, and (C) special-casing `-` in that case (only) to not read from `stdin`. Hopefully we don't have many such cases.
* `uv cat | edit | export | rm` (noting that `export` has one pathological(?) corner case which we can't 100% accommodate: double-dashing the UVFILE name without applying double-dash to the output file name).
* `wiki commit | create | export`
Z 7a088aa0161de5bf03a9497fd02aa290