[webuser321]

A more interesting comparison would be glibc vs other libc.

What are the significant differences?

Is "flexibility", for lack of a better word, really a desirable property for entering command line arguments?

Should parsing, cf. entering, arguments be simple or complex?

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

Besides config files, which themselves may introduce parsing complexities.

Consider passing "arguments" as environmental variables, e.g., as in daemontools, envdir. Variables can be read from "files" in a chroot directory.

[vram22]

I don't remember seeing this explicitly stated anywhere, but based on stuff I've read, I think there is loose / informal Unix convention that some command-line programs follow, about how they can be configured at runtime:

- command line options override environment variables, which in turn override config files (meaning applied to all three, for the same config setting).

I thought this was a good idea and can lead to flexibility, though also some complexity.

I think this might be a good scenario for the use of those three methods of configuration:

- config file settings for common values for options, or values that rarely change. So you set them to those values and change them rarely, when you need to make the new values permanent for a while.

- env. var settings for say, a session of work - in that session you want to override the config file value, and use it for (most of) the duration of your work session

- command-line options to override either of the previous two, say for just a command invocation or two (setting will automatically then revert to either of the two previous methods's values).

Interested to know if others have noticed this pattern (or think it is one) and any comments, since as I said, I don't remember seeing it written down anywhere.

[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.