Fossil Forum
Post: Suggestion: use argv[0] to run some subcommands
There's a few commands Fossil bundles that might be useful to run standalone, and being able to link/copy the Fossil binary to alternative names to use them as such could be handy. Among them:
- md5sum
- pikchr
- sha1sum
- sha3sum
- sqlite3
- All commands in system, as of 2.28 these include:
- date
- ls
- pwd
- stty
- unzip
- which
- zip
sqlite3 in a standalone mode should run as if used like fossil sqlite3 --no-repository (to replicate the behavior of the standard sqlite3 program). All the other commands might be good candidates to move into the system subcommand rather than being top-level. None of them show up in the standard fossil help output and risk of compatibility breaks should be low.
to replicate the behavior of the standard sqlite3 program
Yup, especially useful on hosts where you need a Fossil binary but don't want to drag in all the rest:
$ cat ~/bin/sqlite3
#!/bin/sh
fossil sql --no-repository "$@"
Reducing that kind of thing to a symlink would be welcome.
I just have exactly that command set up as a shell alias to sqlite3
That would be a nice thing for sure.
Currently implemented in the argv0_as_subcommand branch.
(with the exact list of command you proposed..)
Reply: Suggestion: use argv[0] to run some subcommands
That's a good start, thanks.
Mind that fossil zip and fossil system zip are two wholly different commands. argv[0]=="zip" should only run the latter. Your code presently does the former.
sqlite3 also doesn't do anything special apart from fossil sqlite3 (it'll inform to use --repository or -R to specify the repository database when run by itself). Ideally it should behave like the normal sqlite3 binary, default to :memory: or connect to a database via a file name. (To be honest, I was a little surprised by the first couple of replies noting the usefulness of this running mode. I made the original request primarily with pikchr in mind.)
For zip, it really does "fossil system zip", but the usage message is wrong. It's the same with "fossil system zip".. usage say "fossil zip ...".
For sqlite3, I'll see if I can add an exception to and use the --no-repository flag.
Thanks for your reply.
the usage message is wrong. It's the same with "
fossil system zip".. usage say "fossil zip ...".
I'm glad to be wrong. :-)
sqlite3 also doesn't do anything special apart from fossil sqlite3 ...
Now sqlite3 will call "fossil sqlite3 --no-repository"
I created the "fossil system" command because I wanted commands like "ls", "zip", and "which" on Windows-ARM. I also have an alias for "fossil sys ls" on my Macs, in as much as the "fossil sys ls" command, though limited, works better than the native "ls" on Macs.
The idea is that, when confronted with a new system that is not set up to be developer-friendly, I can bring in Fossil and quickly get access to commands I use frequently.
However, I remain skeptical of the idea of using argv[0] to dispatch these commands. I'm using BAT files on Windows, and shell scripts on Mac, to alias the commands I want to use. That works fine, without unnecessary complication of the Fossil sources, and having to create and keep track of links.
Fair, was a fun experiment, it’s not something I would have use an lot anyway. May be sqlite3 alias on my zynq boards, but bash alias does the job too. Z
What if we took inspiration from Busybox, which fossil sys was already trailing, spiritually? Its INSTALL doc suggests:
fossil sys --install # make hard links by default
fossil sys --install -s # make symlinks instead
fossil sys --install -b # make .bat files
It should not be a sub-command ("fossil sys install") because there may one day be an install(1) implementation.
The symlink method works even on Windows these days, for several years, now that they've finally removed the restriction that only Administrator can create them. 🙄
Z
I'm using BAT files on Windows, and shell scripts on Mac, to alias the commands I want to use.
That's a pretty good counter, though it's notable Windows does allow hard links, and was part of the motivation of my request. (On my WinXP system, I have fossil.exe and f.exe as hard links so I can use either form.)
Even if argv[0] meddling isn't accepted, I still think the (older) pikchr, md5sum, sha1sum, and sha3sum subcommands could be moved under system. I think they're more logically placed there.
It is possible there are scripts depending on their existing locations in the subcommand scheme, but I think you are right to guess that they are rare. This is an excellent time to try the experiment, immediately after the prior release was cut.
I omit src/system.c from my Fossil builds, but would like to keep the other commands -- please don't move them!
Reply: Suggestion: use argv[0] to run some subcommands
I'm a little curious, what do you gain by omitting it? I must admit I never use the commands, but the binary having them as an option doesn't hurt me either.
Decluttering.