Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CLI Guidelines – A guide to help you write better command-line programs

clig.dev

Post reply on HN
Print view View original

41–50 of 217 posts

Re: CLI Guidelines – A guide to help you write better command-line programs

#41

Post by klodolph »

I think we should abolish different prefixes for short/long flags except for core POSIX programs (like ls, cp, rm, mkdir, etc.) In other words, "-flag" should be interchangeable with "-flag". The ONLY reason I can think of why you would not recognize "-flag" as equal to "--flag" is because you want to recognize it as "-f -l -a -g", which makes sense for programs like ls, but for 99% of newer programs, don’t do it. Just make "-flag" and "--flag" equivalent.

Re: CLI Guidelines – A guide to help you write better command-line programs

#42

Post by attractivechaos »

klodolph wrote: post #41

I think we should abolish different prefixes for short/long flags except for core POSIX programs (like ls, cp, rm, mkdir, etc.) In other words, "-flag" should be interchangeable with "-flag". The ONLY reason I can think of why you would not recognize "-flag" as equal to "--flag" is because you want to recognize it as "-f -l -a -g", which makes sense for programs like ls, but for 99% of newer programs, don’t do it. Ju…

> for 99% of newer programs, don’t do it

The majority of recent tools in my circle follow this Unix convention. That is a natural result when you use getopt_long().

Re: CLI Guidelines – A guide to help you write better command-line programs

#43

Post by kevincox »

dllthomas wrote: post #29

Loving this! As a nit: > Let the user escape. Make it clear how to get out. (Don’t do what vim does.) If your program hangs on network I/O etc, always make Ctrl-C still work. If it’s a wrapper around program execution where Ctrl-C can’t quit (SSH, tmux, telnet, etc), make it clear how to do that. For example, SSH allows escape sequences with the ~ escape character. I find it confusing that vim is considered less disc…

I agree, if you press Ctrl-C vim (with default settings) literally tells you how to quit. `\n~` in SSH is completely unrecoverable.

Re: CLI Guidelines – A guide to help you write better command-line programs

#45

Post by cle »

resonantjacket5 wrote: post #39
whelming_wave wrote: post #34

Earlier quoted context omitted.

I know you're talking about how it's repeated three times, but something else here really bothers me. I understand if they're deprecating it because they plan to replace it with something else, but if they don't then I'll be pretty disappointed. From their docs, it looks like some of their other subcommands have shorthands which conflict with `-h'? Fine, I guess, but that just means when `-h' does work it'll shoot pe…

I mean if you did that how would you access 'quit' if it is defined? It's a bit more complicated than it seems. Though I get your general point.

You just access it, it's just a normal variable.

    $ python3
    Python 3.8.6 (default, Nov 18 2020, 23:56:33)
    [GCC 9.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> quit
    Use quit() or Ctrl-D (i.e. EOF) to exit
    >>> q = quit
    >>> quit = "foo"
    >>> quit
    'foo'
    >>> quit()
    Traceback (most recent call last):
      File "", line 1, in 
    TypeError: 'str' object is not callable
    >>> q()
    $

Re: CLI Guidelines – A guide to help you write better command-line programs

#48

Post by jcynix »

dllthomas wrote: post #30
mmalone wrote: post #18

Earlier quoted context omitted.

They're not saying you shouldn't provide command-line help. Just that you should deliver them through a `help` subcommand and/or through a `--help` flag (like `git` does) because people don't find man pages and because man pages don't work on every platform.

Man pages improve discoverability. You only find --help contents if you already know which command you want. Man pages are searchable (with `man -k` or `apropos`). This is most relevant when it's a tool that isn't going to be immediately obvious anyway (if I'm trying to figure out how to do XYZ on heroku, it's not unreasonable to expect me to look at the heroku program I installed), and especially when it's a tool th…

Agreed. And man page content is searchable too, even with regular expressions while in a pager like less.

Re: CLI Guidelines – A guide to help you write better command-line programs

#49

Post by dllthomas »

jcynix wrote: post #48
dllthomas wrote: post #30

Earlier quoted context omitted.

Man pages improve discoverability. You only find --help contents if you already know which command you want. Man pages are searchable (with `man -k` or `apropos`). This is most relevant when it's a tool that isn't going to be immediately obvious anyway (if I'm trying to figure out how to do XYZ on heroku, it's not unreasonable to expect me to look at the heroku program I installed), and especially when it's a tool th…

Agreed. And man page content is searchable too, even with regular expressions while in a pager like less.

Sure, but they advise pulling up a pager anyway if the content is long.
Post reply on HN