[metif12]

The other build style: one binary containing several tools, dispatched by
name, alongside the per-tool binaries build.vsh already emits.

What this is

src/multicall/main.v holds a map from tool name to that tool's run
function. It dispatches on argv[0] first, so a hard link or symlink named
after a tool runs it with no sub-command, the way busybox does. A tool name
as argv[1] works too, which is how the earlier coreutils dispatcher was
invoked. build.vsh compiles the multicall and hard links each converted
tool's name to it, so bin/pwd and bin/multicall are one executable. That
is what GNU's --enable-single-binary=hardlinks does.

A tool joins by being converted from module main with its own fn main()
to a module exposing pub fn run(args []string) int. That conversion is the
part worth doing: both build styles then call the same function, so they
cannot drift apart, which is the usual way a multicall rots — the single
binary quietly implements something the per-tool binaries do not.

Eight of 83 tools so far

arch, hostid, logname, pwd, true, tty, whoami, yes. The
remaining tools need the same mechanical conversion, and the list of what is
left is the tools map in src/multicall/main.v against bin/.

false is deliberately excluded: V rejects module false because false is
a keyword and a module name must match its directory, so the tool cannot be
imported into a multicall without renaming its directory. bin/false still
builds on its own and is unaffected.

Two bugs fixed on the way

whoami did not compile. The conversion added module whoami to
src/whoami/lib_default.c.v but deleted the body of whoami() with it,
leaving fn whoami() !string { uid := os.geteuid() and no closing brace:

src/whoami/lib_default.c.v:15:1: error: unexpected eof, expecting `}`

lib_windows.c.v, the other variant, kept its body, so this only showed up
off Windows. Restored; the module whoami header is now the only difference
from main.

argv[0] dispatch never matched on Windows. os.base(os.executable())
carries the extension, and the map is keyed on bare names:

$ copy multicall.exe pwd.exe && pwd.exe
pwd.exe: no tool given, and pwd.exe is not itself a tool

Every per-tool name missed. Dispatch on argv[1] was fine, which made it look
like a missing tool rather than a matching bug. Now stripped before the
lookup.

Verified

All eight converted tools compile, and v fmt -verify is clean on all 17
files. Dispatch, with the binary copied to each name:

true.exe            exit 0, no output          (argv[0])
multicall.exe true  exit 0                    (argv[1])
notatool.exe        'no tool given, and notatool.exe is not itself a tool'
                    'available: arch, hostid, logname, pwd, true, tty, whoami, yes'

Not verified, and one known gap

• The full build.vsh run, and the hard-link layout it produces. I built the
  multicall and the tools directly instead.
• Anything on Unix. The .exe strip is a no-op there, but I have no Unix to
  check that on.
• src/arch and src/whoami tests. Both already fail on pristine main,
  identically, so this is not a regression — but the conversion makes them
  stay failing in a new way. common/testing's rig builds a tool's
  directory as a standalone binary, and a converted tool is module arch
  rather than module main, so there is no main module to build. When those
  two suites are fixed, the rig will need to build the multicall instead. The
  other six converted tools have no tests, so nothing else is affected yet.
  Every remaining tool converted this way will hit it, so it is worth fixing
  before the remaining 75, not after.
• CI is red for every PR in this repo because V's own bootstrap fails before
  any of this compiles; see tcc: error: unresolved reference to 'remainder' when compiling v_stage.exe v#30551, #30598 and #30753. So nothing here
  has a green signal behind it, and the checks above were run by hand.