Hacker News new | past | comments | ask | show | jobs | submit login

> 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 interesting, and worth reading.




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.

[0] https://linux.die.net/man/1/top


The "aux" vs "ef" thing is a Berkeley vs. System V unix thing. SunOS wanted "aux", while Solaris wanted "-ef", iirc. Linux ps will do either. From the man page:

       This version of ps accepts several kinds of options:

       1   UNIX options, which may be grouped and must be preceded by a dash.

       2   BSD options, which may be grouped and must not be used with a dash.

       3   GNU long options, which are preceded by two dashes.
And:

Note that "ps -aux" is distinct from "ps aux". The POSIX and UNIX standards require that "ps -aux" print all processes owned by a user named "x", as well as printing all processes that would be selected by the -a option. If the user named "x" does not exist, this ps may interpret the command as "ps aux" instead and print a warning.

Edit: On my system, "ps -aux" does the same thing as "ps aux" and no warning is printed, despite the what the man page says. I'm not going to try to create a user named 'x' though.


My favorite example: `cp -r` is recursive. `scp -r` is recursive. `chmod -r` removes read permissions; `chmod -R` is recursive.


I have done chmod -r plenty times by mistake and never known it removed read permissions. Oh God.


I ever use chmod without specifying at least one of ugoa. Helps with that mistake.


Meant to say *never, too late to edit.


`ssh -p` specifies a port number. `scp -p`/`sftp -p` copies the mtime. You need to use -P for the latter two.


Why would anyone remember those options? That’s what man pages are for. You only need to remember the ones that you use most often.


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.


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')


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.


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


The Verb-Noun convention isn't that bad once you learn the approved verbs well enough to know which one the command you're looking for would be using. After you have the right verb, tab-completion works fine. Also, `Get-Command` (built-in alias `gcm`) is very helpful. E.g.

  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
Or find everything from a module:

  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
And at least if you use `MenuComplete` for tab (`Set-PSReadLineKeyHandler -Key Tab -Function MenuComplete` in your profile), you can also just write `*<noun>` and hit tab. It will offer completions regardless of the verb.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: