EXECLINE(1)

💅 EXECLINE(1) — bestie's guide to the multicall binary 💅

ok so this is execline, from the General Commands Manual, section 1, and it's literally the multicall binary for the whole execline suite. sit down, grab a strawberry drink 🍓, let's go.

---

✨ NAME ✨

execline — multicall binary for the execline suite. that's it, that's the name 🎀

---

🌸 SYNOPSIS 🌸

execline subcommand subcommand_arguments...

like, you give it a subcommand and then the args for that subcommand. iconic behavior.

---

🦋 DESCRIPTION 🦋

okay so first thing you need to know: the execline program is only available when the --enable-multicall option has been given to the configure program at build time. no option, no multicall binary, periodt. 💅

in this configuration, execline is a multicall binary that implements the functionality of all the programs in the execline package — and the other programs, instead of being executables of their own, are symbolic links to the execline binary. one binary to rule them all, no cap 👑

execline will run the subcommand with its arguments. for instance, execline cd / ls will run the equivalent of the execline-cd(1) program, so this command will list the contents of the / directory. cute and efficient ✨

alternatively, if execline is called with the name of an existing command, it will run the equivalent of that command. for instance, if the /usr/bin/cd file is a (hard or symbolic) link to the execline binary, /usr/bin/cd / ls will list the contents of the / directory. same energy, different entrance 🚪

the --enable-multicall option is a user-requested feature to save disk space. its goal is purely to save disk space — functionality-wise, the execline package should be the exact same whether it has been built with --enable-multicall or not. that means: any execline script should work the exact same way. fr fr, no behavioral surprises. 🫶

---

😭 the part where we get real about multicall binaries 😭

multicall binaries have a number of issues, most of them hidden from regular users. one user-visible issue is that their behaviour changes depending on how they are called, which is not good practice (it breaks naming agnosticism) despite being common in traditional Unix. 🙈

other, more important issues are only visible to software authors and maintainers: for instance, they make it difficult to add functionality to a software package without inadvertently blowing up the amount of RAM used by the software, and they encourage bad engineering practices to work around specific problems created by this configuration. yeah. 💀

I am not a fan of multicall binaries at all.

(the author said it, not me. quoted directly. respect the honesty.)

however — and this is the plot twist — it just so happens that the execline package already was a good candidate for a multicall configuration, and several users had been asking for it (and complaining about the amount of disk space that the traditional execline package uses). so the author did an experiment, and it turned out that a multicall execline binary does save a huge amount of space. 🔥

depending on your shared/static library configuration and your libc, the gain in disk space on Linux can range from 66% to 87%! the results were contrary to expectations — and simply too good to pass up. like, genuinely ate. 💖

so now, the multicall configuration is supported for execline. do not expect anything similar for other skarnet.org packages such as s6[1], because they're not as good candidates and it would require a tremendous amount of work for less benefit. that's a hard no, bestie. 🚫

---

👑 SEE ALSO 👑

• [1] https://skarnet.org/software/s6/
• This man page is ported from the authoritative documentation at: https://skarnet.org/software/execline/execline.html

---

💜 AUTHORS 💜

• Laurent Bercot
• Alexis <flexibeast@gmail.com> (man page port)

---

and that's the whole vibe check 🌈 this page came from Debian, dated February 19, 2023, bestie — go save some disk space, mwah 💅✨🎀