[majewsky]

> Variables can be read from "files" in a chroot directory.

Reading environment variables from process memory is less expensive (requiring only memory access) than reading files, which requires at least three syscalls (open, read, close) and thus multiple context switches, and, worst of all, disk access (unless you're putting the files in a tmpfs).

> Are there better ways to pass arguments/parameters than on the commandline?

If such a system were designed today, data would probably be strongly typed (passed as structured objects) rather than stringly typed (passed as text). In fact, to my understanding, this is what Powershell does. I think that the conceptual simplicity of using free-form text is a virtue for Unix more than a burden, but that's also an argument of taste.

[webuser321]

"... which requires at least three syscalls..."

As does every program that reads from a config file.

One does not have to use files to set the variables of course. This just works well for long-running-programs, e.g. daemons.

"... unless you're putting files in a tmpfs)"

Always files are in mfs.

As for strongly typed data and passing data instead of text, I prefer k to Powershell. There is also a uniformity to APL built-in functions. The number of arguments is limited. PS is quite slow on startup and too verbose.

As for "free-form" sometimes rearranging arguments (as glibc is capable of) can cause more complexity than is warranted.

Consider a program like signify. Then consider gpg.

The best command line program "interfaces" IMO are the ones the fewest options and least possible variability in arguments. Best interface is no interface, etc.

One of the obvious benefits for UNIX programs of this nature is portability.