Interesting. When did redirections got added?
Very early, before the pipes.
Unix command line conventions over time
61–70 of 222 posts
Re: Unix command line conventions over time
#62Earlier quoted context omitted.
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.
The cool part about those aliases is that invoking Get-Help on them (say, Get-Help ls) will show you the relevant documentation of the non-aliased full commandlet name.
Re: Unix command line conventions over time
#63Earlier quoted context omitted.
`--long x` is potentially ambiguous. `x` could be referring to a file if `--long` doesn't take any options, so parsing it correctly depends on this knowledge. The equals sign removes this ambiguity.
If we were starting from scratch, we could require some marker on flags which take values. Perhaps it would have to be `--long: x`. `--verbose x` would be read as a flag with no argument, followed by a positional argument.
Isn’t that just replacing “=“ with “:”?
Re: Unix command line conventions over time
#64Unix history is always fascinating. >None of this explains dd. This one really made me think. I have never thought about dd before. Although I have wondered about other commands. Perhaps the author should also have added some command options not requiring a minus prefix, e.g. tar, ps. The manpage [0] reads: In the first (legacy) form, all option flags except for -C and -I must be contained within the first argument t…
dd is fine, at least fine as a disk destroyer can be. It is not standard for UNIX but it is understandable.
tar is a bit messy but the worst is definitely ps. It has dash and non-dash options, and they don't have the same meaning and interact in a weird way.
Edit: the command is "ps", I somehow managed to mess up the most important word...
Re: Unix command line conventions over time
#65I pretty like the consistency of esbuild CLI [1]. It has three kinds of options: 1. no-valued option: --example 2. single-valued option: --key=value 3. multi-valued option: --elements:1st --elements:2nd Short options are ruled out, although it accepts the short option -h for discoverability. I particularly like the repeated option pattern for multi-valued options. This avoids ambiguities such as: cli --elements 1st 2…
This is largely what the Azure CLI does. It simplifies even further by eliminating the no-value option. Instead, you pass "true" or "false" as the value ( --example true ). It's a little more verbose but very easy to parse/write/generate. I like this convention so much I stole it for my homemade Golang CLI parsing library https://github.com/bbkane/warg/ .
Re: Unix command line conventions over time
#66Interesting is also find. It took me some time to accept that the directory must come first.
E.g.
find /path/to/dir -type f
find -type f /path/to/dir
Re: Unix command line conventions over time
#67Earlier quoted context omitted.
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.
The best thing with parameters in PS is what you don't need to write parameter name fully, and it is supported everywhere, while only some *nix tools support it (most notably 'ip')
Re: Unix command line conventions over time
#68Earlier quoted context omitted.
If we were starting from scratch, we could require some marker on flags which take values. Perhaps it would have to be `--long: x`. `--verbose x` would be read as a flag with no argument, followed by a positional argument.
Isn’t that just replacing “=“ with “:”?
No, there's a space in there too!
Re: Unix command line conventions over time
#69Interesting is also find. It took me some time to accept that the directory must come first. E.g. find /path/to/dir -type f works, while find -type f /path/to/dir does not.
Yup, always seems to take a bit more conscious effort to remember that detail for find.
Re: Unix command line conventions over time
#70And 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
> that nobody can ever remember
These have gone a long way for me:
tar xzf eXtract Zipped File
tar czf Create Zipped File