> Initially, GNU used the plus (+) to indicate a long option
Some tools still use +options, like dig(1).
Unix command line conventions over time
21–30 of 222 posts
Re: Unix command line conventions over time
#22And then there is also the case of CLIs that aren’t written in C: they don’t get the benefits of a unified getopts lib. One oddity not explained is tar allowing multi options crammed together without any dash, that nobody can ever remember (eg. tar xvf archive.tar)
> One oddity not explained is tar allowing multi options crammed together without any dash, that nobody can ever remember (eg. tar xvf archive.tar)
This is a BSDism, and it's deprecated even there. bsdtar allows it for compatibility with old scripts.
GNUtar has long-switches for all options, which makes it considerably easier to use and understand, for example:
gtar --create --file etc.tar --verbose /etc
Re: Unix command line conventions over time
#23> we could introduce a completely new syntax that is systematic, easy to remember Is it really difficult to learn that e.g. "rm" stands for "remove"? I've known very few people who found it difficult to learn the key things very quickly. And not having to type (and spell) full words is a relief. (I know a shell can take care of spelling, but not all unix commands are entered interactively.) Still, the article is inte…
Tbh I’ve found powershell approach better and also more verbose. Powershells commands are all named in the same way, with built-in support to make finding commands straightforward. Though it takes a while to get used to it. Explorability is better IMO with an approach like powershell. The downside is even though you can setup aliases, it still seems like powershell scripts are longer to input that bash and sometimes not as powerful.
Re: Unix command line conventions over time
#24> I believe the oldest program that uses subcommand is the version control system SCCS, from 1972
IIUC, other non-Unix operating systems commonly used the subcommand style for normal interactive use; it was the style used by the normal command shell, and all commands in those operating systems therefore followed this style. The operating system (or its shell) was responsible for enabling easy use of this style by adding completion support (commonly using the ESC key, IIRC). This older style can still today be seen in Unix tools like ftp and telnet, which uses this style for its internal command line interface. Another tool using this style, which many might be familiar with, is the multi-platform Kermit.
Unix therefore has been rather late in adopting this style, first in gradually adopting tools which uses the subcommand style (ip, git, etc.), and later with support in shells for programmable completion support where a program can optionally register completion hooks for the user shell to use, making it finally come up to the level of those older operating systems.
Re: Unix command line conventions over time
#25> Initially, GNU used the plus (+) to indicate a long option Some tools still use +options, like dig(1).
And others use option -long such as ffmpeg.
Re: Unix command line conventions over time
#26> we could introduce a completely new syntax that is systematic, easy to remember Is it really difficult to learn that e.g. "rm" stands for "remove"? I've known very few people who found it difficult to learn the key things very quickly. And not having to type (and spell) full words is a relief. (I know a shell can take care of spelling, but not all unix commands are entered interactively.) Still, the article is inte…
Tbh I’ve found powershell approach better and also more verbose. Powershells commands are all named in the same way, with built-in support to make finding commands straightforward. Though it takes a while to get used to it. Explorability is better IMO with an approach like powershell. The downside is even though you can setup aliases, it still seems like powershell scripts are longer to input that bash and sometimes…
Powershell defines tons of aliases to mimic bash, eg rm is an alias for remove-item, ls for get-childitems, cat for get-content, etc. What I like about Powershell is that arguments gets aliases too, for example -cf is the standard alias for -confirm.
Re: Unix command line conventions over time
#27> --mail=ADDR > The --email bit is a joke. what's the context of the joke?
Zawinski's Law of Software Envelopment, also known as Zawinski's Law, states: Every program attempts to expand until it can read mail.
Caught me out!
I assumed it meant to send the output of the command as mail. That's vaguely useful instead of piping to a cmdline MUA. I couldn't believe I'd been missing this for 30 years and so I tried it on few things like
ps aux --mail=me@domain
error: unknown gnu long option
Looked in my inbox. Nothing.
Then I got to the bottom of the page for the punchline.
grrrr
Re: Unix command line conventions over time
#28> we could introduce a completely new syntax that is systematic, easy to remember Is it really difficult to learn that e.g. "rm" stands for "remove"? I've known very few people who found it difficult to learn the key things very quickly. And not having to type (and spell) full words is a relief. (I know a shell can take care of spelling, but not all unix commands are entered interactively.) Still, the article is inte…
I don't think remembering rm is the issue. It's remembering all the options in all their variations. Take the ps command. I tend to use it as "ps aux" - but I have no idea what the a, the u, or the x stand for individually. I know other people who use "ps -ef". (Also note the difference : the aux doesn't require a dash, and if you accidentally put it in, it doesn't do what you want it to do.)
As another example : the -v option. In most tools this means "verbose". In some tools, but not all, you can pass it multiple times to increase the level of verbosity. But then there are a few tools, e.g. top, where -v seems to mean "version" [0]. Or take the -h option. On many tools it stands for "help". But on tools like ls or sort, it stands for "human-readable".
To me personally this is not an issue - I know by heart a few combinations of options that I use frequently, and I know where to find out the details of those, as well as other options I use less frequently. But I can see how it would be easier for people to pick it up if those things were just a little more standardised.
Re: Unix command line conventions over time
#29The GNU conventions are terribly convenient. If we were redesigning it from scratch, I'd like to keep all of them except for removing duplicated functionality. One of --long x and --long=x have to go, and that means we only can keep --long=x. And so on.
I disagree with getting rid of `--long x`. It's really common to build command argvs programmatically, where you have a string representing some option (such as a file path), and you need to pass that as a long option. With `--long x`, you can do like:
char *argv[] = {"my-program", "--config-file", config_file, NULL};
run_command(argv);
char *config_file_opt = asprintf("--config-file=%s", config_file);
char *argv[] = {"my-program", config_file_opt, NULL};
run_command(argv);
free(config_file_opt);
char config_file_opt_buf[1024];
char *config_file_opt;
size_t config_file_opt_len = snprintf(config_file_opt_buf, sizeof(config_file_opt_buf), "--config-file=%s", config_file);
if (config_file_opt_len >= sizeof(config_file_opt_buf)) {
config_file_opt = malloc(config_file_opt_len);
snprintf(config_file_opt, config_file_opt_len, "--config-file=%s", config_file);
} else {
config_file_opt = config_file_opt_buf;
}
char *argv[] = {"my-program", config_file_opt, NULL};
run_command(argv);
if (config_file_opt != config_file_opt_buf) {
free(config_file_opt);
}
I think we should keep `--long x`. If anything, `--long=x` is the one which should go. There will always be ambiguity; the meaning of something like `-ab` also depends on whether `-a` takes an argument or not.
Really though, I think there are enough situations where `--long=x` is useful that I think keeping both versions makes sense.
Re: Unix command line conventions over time
#30> Initially, GNU used the plus (+) to indicate a long option Some tools still use +options, like dig(1).
And others use option -long such as ffmpeg.
And Java with the infamous `-version` (only after JDK11 I think it started recognizing also `--version`) and `-cp` meaning `--classpath`, not `-c -p`!