Unix command line conventions over time

Post by JadeNB » Sat, May 07, 2022, 1:57 PM UTC

GuB-42 wrote: post #64

pseudostem wrote: post #4

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

Post by mike_hock » Sat, May 07, 2022, 2:00 PM UTC

mort96 wrote: post #29

kzrdude wrote: post #9

The 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); With only `--config-file=x`, you would have to allocate memory for the option: ch…

Post by juki » Sat, May 07, 2022, 2:18 PM UTC

bbkane wrote: post #72

morelish wrote: post #23

Earlier 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…

I really find it difficult to find the specific command I want. The verb-noun convention doesn't really lend itself to nested subcommands. At least with the Azure CLI I can generally navigate to the command and action I want with tab completion

  PS> gcm *build*

  CommandType     Name                                               Version    Source
  -----------     ----                                               -------    ------
  Alias           Build-Checkpoint                                   5.8.6      InvokeBuild
  Alias           Build-Parallel                                     5.8.6      InvokeBuild
  Alias           Invoke-Build                                       5.8.6      InvokeBuild
  Application     mcbuilder.exe                                      10.0.2200… C:\Windows\system32\mcbuilder.exe

  PS> gcm -m InvokeBuild

  CommandType     Name                                               Version    Source
  -----------     ----                                               -------    ------
  Alias           Build-Checkpoint                                   5.8.6      InvokeBuild
  Alias           Build-Parallel                                     5.8.6      InvokeBuild
  Alias           Invoke-Build                                       5.8.6      InvokeBuild

Post by loudmax » Sat, May 07, 2022, 2:25 PM UTC

wchar_t wrote: post #46

nohackeratall wrote: post #45

And then you have ImageMagick where the order of flags and options is a science by itself.

Indeed, I passionately hate programs where the order of the options and files/arguments matter just as much as the options themselves.

  $ find -type f Data/
  find: paths must precede expression: `Data/'
  find: possible unquoted pattern after predicate `-type'?

Post by Tijdreiziger » Sat, May 07, 2022, 2:26 PM UTC

bfrankline wrote: post #74

I was at Bell during the options “debate.” I think something that this otherwise wonderful article misses is that some believed that commands were never intended to be the only way to use the system as the shell was intended to be just one of the many user interfaces that Research Unix would provide. From that perspective, it was entirely reasonable to believe that if a command was so complex that it needed options t…