4 ms·

>the argument used to be you used Windows instead of Linux because on Linux you might occasionally have to use the scary terminal to fix an issue This always a

by opan 9mo ago

>the argument used to be you used Windows instead of Linux because on Linux you might occasionally have to use the scary terminal to fix an issue This always annoys me because you're really handicapping yourself by ignoring the CLI on any OS. Sure I use it more heavily on GNU/Linux than I did on Windows as a kid, but that's because it's so good. If I'm ever in front of a Windows machine now I still like to have a terminal handy (and it's even better/more-familiar on macOS, of course), and I've learned things like "type is like cat", "robocopy is like rsync", "tasklist is kinda like ps and taskkill like kill/pkill" which help me to do things better on Windows than when I used it fulltime. I'm glad Microsoft invested more in the CLI with Windows Terminal, OpenSSH in the default install, winget, PowerShell, etc. I think it's better for everyone. I fear the CLI hate is spreading anti-intellectualism. Some people seem annoyed when they even have to use their keyboard instead of their mouse for something.

ndsipa_pomu 9mo ago
GUIs are great for when you're new to a bit of software as you can see the various options and get a feel for the possibilities. CLIs are nearly always more flexible once you've read the man page, but is a steeper learning path. Automation/scripting is when CLIs really come into their own as otherwise you end up becoming a GUI click monkey. The best is when there's both a GUI and CLI (as long as they work the same way).
- graemep 9mo ago
  I wonder how good CLIs could have been if a fraction of the resources that have gone into GUIs had gone into making CLIs more user friendly. A sequence of words is a pretty natural way of conveying what you want done.
  - kingstnap 9mo ago
    The problem with CLI isn't typing, its discoverability. Keep in mind conveying what you want done requires knowing what can be done first.
    - graemep 9mo ago
      That is exactly the sort of thing I think could have been improved. We have very little at the moment - autocomplete and some help.
      - ndsipa_pomu 9mo ago
        Along with the "-h,--help" options, an option to show common usage examples would be useful. I find it much easier to learn from an example as you can modify and build upon it. Otherwise, it's a case of skimming through the man page and then switching back and forth between the man page and the command that I'm writing. (This is most common with tools that I don't use all the time, yet have expert features such as "ffmpeg")
        1718627440 9mo ago
        > an option to show common usage examples would be useful. That's what the man page is supposed to be (and most do contain example) and why GNU wanted to split it into info (tutorials and exhausting documentation) and man (reference and examples).
        ndsipa_pomu 9mo ago
        Yep, the examples on man pages are helpful, but I'd like a slimmed down option to just show the examples and a one-line description for the examples. I usually end up just doing a quick web search for the command if it's not one that I'm familiar with (i.e. where I have read the man page). An extreme example of my issue would be trying to find BASH examples of how to process a list of files - the man page on BASH is fairly lengthy. Meanwhile, Greg's wiki provides this example of processing mp3 files: while IFS= LC_ALL=C read -r -d '' file; do some command "$file" done < <(find . -type f -name '*.mp3' -print0)
        1718627440 9mo ago
        Why do you serialize and then deserialize the list of files? Even if you do disable the splitting on reparsing the list, why don't you just do this: find . -type f -name '*.mp3' -exec some command {} ';' That sounds just unnecessary and bug prune. Unless you target some odd platform where find doesn't support '-exec', but it is even in POSIX. I think due to your use of process substitution, your code has a higher chance of being unportable, so why do you want to complicate your code? Stuff like that is why I personally prefer the man pages to random websites. Honestly for something as complex as a shell (which describes both a language, an editor, and an implementation) the man page is surprisingly short. (6418 lines for me) I have just found the section on process substitution in <1min, without even using the search, just by reading. I looked it up, because I didn't knew the name of that syntax, so I needed to actually look for what I wanted and I do not use the man page of bash often.
whatevaa 9mo ago
If CLIs functioned as LLM and you could talk freely with it, there would be no problem. In reality, CLIs are inconsistent and basically function as robotic interfaces, a lot of them not that far of programming.
- socialcommenter 9mo ago
  > If CLIs functioned as LLM and you could talk freely with it, there would be no problem. On face value, I find this suggestion hilarious. People are having sandboxing issues left, right and center with AI agents and MCPs, so clearly there would be enormous problems with giving an LLM full unscoped terminal access. Remember the guy who had his hard drive wiped? Do you just mean that the ABIs are inconsistent and you want a more unified way to specify what you want (but the user still more-or-less spells out what command will be invoked)? I have some sympathy for that concern, yes.
- autoexec 9mo ago
  If CLIs functioned as LLM and you could talk freely with it, it would kiss your ass while it hallucinates about the files on your hard drives, invent command line switches that either don't do anything or does something other than what you want, and every command that used to take just 5-10 characters would now require you to type paragraphs. No thank you.

by opan 9mo ago

ndsipa_pomu 9mo ago

GUIs are great for when you're new to a bit of software as you can see the various options and get a feel for the possibilities. CLIs are nearly always more flexible once you've read the man page, but is a steeper learning path. Automation/scripting is when CLIs really come into their own as otherwise you end up becoming a GUI click monkey. The best is when there's both a GUI and CLI (as long as they work the same way).

graemep 9mo ago
I wonder how good CLIs could have been if a fraction of the resources that have gone into GUIs had gone into making CLIs more user friendly. A sequence of words is a pretty natural way of conveying what you want done.
- kingstnap 9mo ago
  The problem with CLI isn't typing, its discoverability. Keep in mind conveying what you want done requires knowing what can be done first.
  - graemep 9mo ago
    That is exactly the sort of thing I think could have been improved. We have very little at the moment - autocomplete and some help.
    - ndsipa_pomu 9mo ago
      Along with the "-h,--help" options, an option to show common usage examples would be useful. I find it much easier to learn from an example as you can modify and build upon it. Otherwise, it's a case of skimming through the man page and then switching back and forth between the man page and the command that I'm writing. (This is most common with tools that I don't use all the time, yet have expert features such as "ffmpeg")
      - 1718627440 9mo ago
        > an option to show common usage examples would be useful. That's what the man page is supposed to be (and most do contain example) and why GNU wanted to split it into info (tutorials and exhausting documentation) and man (reference and examples).
        ndsipa_pomu 9mo ago
        Yep, the examples on man pages are helpful, but I'd like a slimmed down option to just show the examples and a one-line description for the examples. I usually end up just doing a quick web search for the command if it's not one that I'm familiar with (i.e. where I have read the man page). An extreme example of my issue would be trying to find BASH examples of how to process a list of files - the man page on BASH is fairly lengthy. Meanwhile, Greg's wiki provides this example of processing mp3 files: while IFS= LC_ALL=C read -r -d '' file; do some command "$file" done < <(find . -type f -name '*.mp3' -print0)
        1718627440 9mo ago
        Why do you serialize and then deserialize the list of files? Even if you do disable the splitting on reparsing the list, why don't you just do this: find . -type f -name '*.mp3' -exec some command {} ';' That sounds just unnecessary and bug prune. Unless you target some odd platform where find doesn't support '-exec', but it is even in POSIX. I think due to your use of process substitution, your code has a higher chance of being unportable, so why do you want to complicate your code? Stuff like that is why I personally prefer the man pages to random websites. Honestly for something as complex as a shell (which describes both a language, an editor, and an implementation) the man page is surprisingly short. (6418 lines for me) I have just found the section on process substitution in <1min, without even using the search, just by reading. I looked it up, because I didn't knew the name of that syntax, so I needed to actually look for what I wanted and I do not use the man page of bash often.

whatevaa 9mo ago

If CLIs functioned as LLM and you could talk freely with it, there would be no problem. In reality, CLIs are inconsistent and basically function as robotic interfaces, a lot of them not that far of programming.

socialcommenter 9mo ago
> If CLIs functioned as LLM and you could talk freely with it, there would be no problem. On face value, I find this suggestion hilarious. People are having sandboxing issues left, right and center with AI agents and MCPs, so clearly there would be enormous problems with giving an LLM full unscoped terminal access. Remember the guy who had his hard drive wiped? Do you just mean that the ABIs are inconsistent and you want a more unified way to specify what you want (but the user still more-or-less spells out what command will be invoked)? I have some sympathy for that concern, yes.
autoexec 9mo ago
If CLIs functioned as LLM and you could talk freely with it, it would kiss your ass while it hallucinates about the files on your hard drives, invent command line switches that either don't do anything or does something other than what you want, and every command that used to take just 5-10 characters would now require you to type paragraphs. No thank you.