Are there any discussions about proposing a new filesystem hierarchy standard

Unfortunately there is no guarantee of anything being available.

However, most systems will have GNU coreutils. That alone provides about 105 commands. You can probably rely on those unless it's an embedded system, which might use BusyBox instead.

You can probably also rely on bash, cron, GNU findutils, GNU grep, gzip, iproute2, iputils, man-db, module-init-tools, net-tools, passwd (passwd or shadow), procps, tar, and util-linux.

Note that some programs might have some differences between distributions. For example /usr/bin/awk might be gawk or mawk. /bin/sh might be dash or bash in POSIX mode. On some older systems, /usr/bin/host does not have the same syntax as the BIND version, so it might be better to use dig.

If you're looking for some standards, the Linux Standard Base defines some commonly found programs, but not all distributions claim to conform to the standard, and some only do so if you install an optional LSB compatibility package. As an example of this, some systems I've seen don't come with lsb_release in a default install.

As well as this, the list of commands standardized by POSIX could be helpful.

Another approach to your problem is to package your script using each distribution's packaging tools (e.g. RPM for Red Hat, DEB for Debian, etc.) and declare a dependency on any other programs or packages you need. It's a bit of work, but it means users will see a friendlier error message, telling them not just what's missing, but what packages they need to install.

More info:

• RPM - Adding Dependency Information to a Package
• Debian - Declaring Relationships Between Packages.

Adapted from the POSIX standard's "Utility Argument Syntax" section:

utility_name [-a] [-b] [-c option_argument]
             [-d|-e] [-f[option_argument]] [operand...]

The utility in the example is named utility_name. It is followed by options, option-arguments, and operands.

The arguments that consist of - characters and single letters or digits, such as a, are known as options (or, historically, flags). Certain options are followed by an option-argument, as shown with [-c option_argument]. The arguments following the last options and option-arguments are named operands.

The standard also defines "argument" as

In the shell command language, a parameter passed to a utility as the equivalent of a single string in the argv array created by one of the exec functions. An argument is one of the options, option-arguments, or operands following the command name.

All things after the utility_name on the command line are the utility's arguments, and they all show up in the positional parameters if it's a shell script. The terms option, option-argument, and operand are more specific names for these arguments on the command line.

"Flag" and "switch" are common synonyms to "option".

In the case of

utility -a b=c

• -a and b=c are arguments,
• -a is an option if the utility recognises it as such (the ln utility has no -x option, so -x is not an option to ln, strictly speaking, and ln -x would trigger a diagnostic message),
• b=c is an option-argument if the -a option takes an argument, otherwise it's an operand,
• b and c are not options, option-arguments and not operands in themselves.

As you notice from my text above, working from the synopsis of a utility (as given by the manual of the utility) would have been easier than trying to decode a generic command typed on the command line. The manual will clearly state what options takes option-arguments and what arguments are operands etc.

To call c a "value" is IMHO perfectly ok. It's not a something that is standardised, but very few would misunderstand you if you say "c is the value given to b". It would be clear from the context of the utility in question.

For example

$ awk -v var="d" '...' data.in

Anyone who knows about awk would say that -v var="d" means "the awk variable var is assigned the value d on the command line".