Fossil Forum

fossil all i displays nothing
Login

fossil all i displays nothing

fossil all i displays nothing

(1.2) By KIT.james (kjames3411) on 2022-06-23 08:55:59 edited from 1.1 [source]

fossil all i displays nothing. (v2.18)

I expected it to give me ~~the info output, or~~ some error message, but is this a bug due to a conflict with the ignore special command or something?

(2) By Stephan Beal (stephan) on 2022-06-23 03:42:08 in reply to 1.1 [link] [source]

but is this a bug due to a conflict with the ignore special command or something?

Run "fossil i" without the "all" part and it will list the four ambiguous commands which start with that letter.

(3) By KIT.james (kjames3411) on 2022-06-23 07:06:02 in reply to 2 [link] [source]

I know about this, but how is it related to the question/bug report?

(4) By Heiko (scheit) on 2022-06-23 08:20:18 in reply to 2 [link] [source]

I think this is really a bug.

For instance, also

  fossil all s

instead of emitting an error message that the command is ambiguous (server setting sync) it just decides to run the 'server'...

As for 'i', yes, I think fossil just picks 'ignore'.  Since nothing is set the output is empty.

If the command is ambiguous, the correct behaviour is to emit an error message.

To pick a (random) matching command is a bug.

(5) By Warren Young (wyoung) on 2022-06-23 08:37:45 in reply to 4 [link] [source]

I doubt it’s “random.” The subset of valid commands under “all” is restricted. A single letter may suffice in that context where it’d require more in the wider context.

(6) By KIT.james (kjames3411) on 2022-06-23 08:53:57 in reply to 5 [link] [source]

I think the same too.

In the case of i there are two commands that match though. It might not be random from the POV of Fossil, but that is no reason for picking a command without consulting the user.

(7) By Stephan Beal (stephan) on 2022-06-23 09:22:50 in reply to 5 [link] [source]

My apologies for the terse response earlier - it was sent one-handed from a tablet from bed while falling asleep. It is exactly as Warren says:

I doubt it’s “random.” The subset of valid commands under “all” is restricted

See the all help for the list of commands which may apply in that context.

As to Heiko's example of "s" running server instead of generating an error, yes, that's arguably a bug, but so it using single-letter commands. When one runs a command across their 30-50 repositories, it seems fair to expect that they'll enter precisely the command they want to execute, rather than just a single letter. Abbreviated commands may be invalidated at any time via the addition of new commands, so relying on them in any sort of automation is definitely not recommended.

As this issue with "all" has never (to the best of my recollection) come up before, it would seem to fall into the category of "mostly hypothetical" problem, as opposed to something which is likely to happen in practice. Yes, a bug, but a low-priority one. Patches to improve the ambiguity handling would be thoughtfully considered.

(8) By KIT.james (kjames3411) on 2022-06-23 12:36:37 in reply to 7 [link] [source]

Well I never said that single letter commands were good or anything. But if you think they're bad then it's the perfect occasion for patching things up :) (sorry that I'm just reporting here)

(10) By Heiko (scheit) on 2022-06-23 12:53:27 in reply to 7 [link] [source]

Any issues reported here very very likely "has never (to the best of my recollection) come up before".

The code to handle this exists already (as when running fossil w/o 'all').  I don't know why the same code is not used for the 'all' situation...

(12) By Stephan Beal (stephan) on 2022-06-23 13:01:22 in reply to 10 [link] [source]

Any issues reported here very very likely "has never (to the best of my recollection) come up before".

That's not true: we've seen a lot of repeats in my 14+ years here ;).

The code to handle this exists already (as when running fossil w/o 'all'). I don't know why the same code is not used for the 'all' situation...

Because in "all X", X is a subcommand, and subcommands do not participate in short-form dispatching.

(14) By Andy Bradford (andybradford) on 2022-06-23 16:40:47 in reply to 7 [link] [source]

> Yes, a bug, but a low-priority one.

I would call it an inconsistency bug, not necessarily a functionality bug.

Fossil's ambiguous command resolution code usually only applies to one level
of command. For example:

fossil sta
fossil up
fossil co

However, it may not have been consistently applied to all nested levels of sub-commands withing Fossil.

In other words, it's a "nice to have".

What's odd, however, is that "fossil all i" doesn't return an error!

Andy

(9) By Heiko (scheit) on 2022-06-23 12:50:18 in reply to 5 [link] [source]

Under 'all' the commands "server" "setting" "sync" are allowed, so the user (stupid, or not careful, or whatever the reason) should be warned in the same way as if he/she had entered 'fossil s' (without 'all').

$ fossil s
fossil: ambiguous command prefix: s
fossil: could be any of: safe-html scrub search self-register server settings sha1sum sha3sum shell sitemap-extra sql sqlar sqlite3 ssh-command ssl-ca-location ssl-config ssl-identity stash status sync
fossil: use "help" for more information

(11) By Stephan Beal (stephan) on 2022-06-23 12:59:03 in reply to 9 [link] [source]

... should be warned in the same way as if he/she had entered 'fossil s'

A quick glance at the code shows that it does not support short-form commands at all. Only the initial command to fossil, not subcommands, support short-forms. Ah, and that is what's causing the bug:

  n = strlen(g.argv[2]);
...
  zCmd = g.argv[2];
...
  if( strncmp(zCmd, "ui", n)==0 || strncmp(zCmd, "server", n)==0 ){

Those strncmp()s are using the length of the argument for the comparison, which leads to a bug when it compares only the first byte of "server". That will be easy to fix - expect a fix in trunk the next hour or so.

(13) By Stephan Beal (stephan) on 2022-06-23 13:11:28 in reply to 1.2 [link] [source]

fossil all i displays nothing. (v2.18)

This is now fixed in trunk:

[stephan@nuc:~/fossil/fossil/src]$ f all pu
"all" subcommand should be one of: add cache changes clean dbstat extras fts-config git ignore info list ls pull push rebuild server setting sync ui unset
[stephan@nuc:~/fossil/fossil/src]$ f all pul
"all" subcommand should be one of: add cache changes clean dbstat extras fts-config git ignore info list ls pull push rebuild server setting sync ui unset
[stephan@nuc:~/fossil/fossil/src]$ f all pull
/home/stephan/fossil/fossil/fossil pull -autourl -R /home/stephan/fossil/althttpd.fossil
Pull from https://sqlite.org/althttpd
Round-trips: 2   Artifacts sent: 0  received: 1
...

(15) By Heiko (scheit) on 2022-06-28 11:08:17 in reply to 13 [link] [source]

Thanks for the quick fix!