6 ms·

Don't get me wrong! I love command line apps. But I wonder if we all have a bit of an Stockholm syndrome... there are several things that suck about them... Wh

Don't get me wrong! I love command line apps. But I wonder if we all have a bit of an Stockholm syndrome... there are several things that suck about them... While writing this I'm thinking on my experience trying to do anything with ffmpeg or imagemagick... or even find. * For any sufficiently complicated cmd line app, the list of arguments can be huge and the --help so terse as to be become useless. For man pages, the problem is the opposite... the forest hides the tree! I'm sure we all end up using google to look for example invocations. * Very often completion doesn't work, since custom per-app machinery is needed. For instance: git-completion for with bash-completion. * Sometimes I end up passing the help output through grep, then copy-pasting the flags from the output, and then hoping I got the right flag. * ...how about things like regular expressions parameters... always so hard to remember the escaping rules! (and the regex flavor accepted by each different app). * Not to talk about more complicated setups involved -print0 parameters or anything involving xargs, tee, and formatting with sed and cut, etc. Is there a better way? Not sure. I like powershell a bit but some of the things I mention above still apply. I think we may be able to get a workflow that is a bit closer to the tooling we use for writing programs while not being perceived as verbose and heavy (I'm thinking, the kind of workflow I get with a Clojure repl).

NeedMoreTea 8y ago
For a quick args reminder, without having to dig through man pages, try tldr: https://tldr.sh/ https://tldr.sh/
forkerenok 8y ago
Speaking for myself of ffmpeg and imagemagick, I don't find the CLI itself difficult, I find that their application domain is a bit complicated for a layman. Meaning I usually struggle to comprehend what particular options mean rather than how they bind to CLI. Maybe indeed a good intuitive UI would give more intuition about the more obscure options. But then again, a good intuitive UI is a quest of its own.
- tajen 8y ago
  What is difficult with ffmpeg is the sub-language in each argument, which depends on the filter you’re using. I can learn to lookup the manual, but if I have to go to the internet to learn the syntax of the filter, I’m better off googling my usecas.
  - pleasecalllater 8y ago
    And using multiple filters in one call is even more funny. Getting the output and parse it too, as it can be different in different versions and it's terribly inconsistent between filters.
- voltagex_ 8y ago
  Merge a separate video and audio file without looking it up - I've got a document stored that lists all the different commands I've used and hopefully some context about what they do.
de_watcher 8y ago
> I'm sure we all end up using google Which is kinda a CLI application.
- oblio 8y ago
  But done the right way. With autocompletion based on your frequent searches, recent searches, machine learning based suggestions using what the whole internet searches, etc. It's qualitatively different from your average CLI experience. As such, I don't think you can actually compare the two.
  - Retra 8y ago
    It is a command-based line-input UI. Just because it is different in other ways doesn't mean it a comparison is unwarranted.
    - oblio 8y ago
      My argument was that the "other ways" it is different in are more important than the similarities.
Already__Taken 8y ago
Powershell made 2 things gospel and I'm just sad it's going to take 20 years for other operating systems to realize that's the way to do it and something that replaces linux to see it in practice (i.e. it just won't) 1. Auto-complete is by-design part of the language/shell 1. Pre-approved Verb list that prefix commands helps discoverability and usability no end. Still learning? Get-<anything> will literally never cause a problem. Because of the above get-help <function> can automatically create some fairly useful documentation right away and whoever wrote the code didn't need to do anything. They can significantly add to to help though. Because that mechanism is part of the language it's worth doing literally every user is going to access it, not some blog your wrote 5 years ago I hope is still online. Passing objects rather than string, whatever maybe it's not the best way, I think it's great. But That's not the only thing PS has to learn from. If anyone uses the cli and doesn't know how the PS help system works, it's certainly a breath of fresh air to learn.
- agumonkey 8y ago
  I never really found the verb list to be entirely satisfactory. It's great that they gave boundaries but I find it too verbose. There are other kinds of syntactic ergonomics with concise vocabulary (lisp has ! xxx p$ for instance, they're a bit harder to swallow but I find the code a bit more poetic and easier to remember as a pattern). About the objects vs strings, Kalman Reti (of Symbolics IIRC) talked [1] about how an OS passing pointers could enjoy a much easier time instead of serializing everything as strings then deserializing, especially when done ad-hoc through sed/grep/perl/whatever .. It pains me to see this. It pains me to see how linux basic utils are 30% --usage, 30% output formatting (and they all share this). MS did a great thing with PS. [1] https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=o4-YnLpLgtk
  - guhidalg 8y ago
    The verb list is, in practice, 90% Get-* and Set-* , so for most users that will cover the case where they need to read and modify some system state in a script. It may not cover your particular use case (I want to foo this bar), but as restriction on the language it helps your users not have to discover esoteric commands.
Meai 8y ago
I think that the solution is clear, make a language server for the command line. Each and every single command line interface is its own language so they all need their own language server that can provide meaningful completions. Then bash and other shells can add support for language servers and we have the problem solved.
- sgeisler 8y ago
  I imagine this to be a little bit over the top in most cases. A standard flag like --complete-rahyeiB1 (with a sufficiently long random string to avoid collisions with existing flags) which takes the already written argument list as an argument and prints possible completions would be nice though.
larkeith 8y ago
> Sometimes I end up passing the help output through grep, then copy-pasting the flags from the output, and then hoping I got the right flag. man x | grep -P y -C 3 | less ...is my standard here (-C 3 includes the pre- and succeeding 3 lines). For all the delights of CLIs, man pages are by default opaque walls of text. And dear lord the number of regex variants... - at this point, if at all possible, I'll avoid application-specific flavours entirely, and just pipe to grep -P (perl-style regex). I might suggest, however, that image/video manipulation is a case for which CLIs are uniquely unsuitable. There surely are better ways (as you mentioned, Powershell appears to be a step or three in the right direction, though I have little familiarity with it), but it seems as though the greatest difficulty is in maintaining full backwords compatibility, while still encouraging new applications to make full use of novel features - not to mention the effort of modifying old applications to fit new standards that would need be expended.
- azernik 8y ago
  If you're already piping to less, just use its search functionality; type '/', the regexp, and then enter.
  - pdpi 8y ago
    For that, you might as well just use the regex functionality in man itself too. But that misses the point. The goal of grepping in that snippet is that you're `less `ing through precisely the parts that matter, and no more, rather than wading through the whole man page, and you're using -C to control how much context you (think you) need around the search results. This is a much better setup for skimming through potential hits than going through the man page wall of text.
    - azernik 8y ago
      'man' has no regex functionality; on most Unix systems, it just uses 'less' as its pager.
      - pdpi 8y ago
deleted 8y ago
[deleted]
AnIdiotOnTheNet 8y ago
At this point I'm not really sure what makes command-line so great. We should have something like it in the GUI sapce that works much better but, like you said, "stolkholm syndrome". Why can't a pipeline be a more complicated multi-io workflow? In a 2D GUI this would be trivial to construct and read, but in a 1D command line it would get confusing in a hurry. And the concept works much better with AV, I can easily construct and reason about complicated arrangements of audio and video inputs and outputs, with mixers, compositors, filters, shaders, splitters, etc. between them. Instead we worship text. Is that because manipulating text is actually more useful, or because our tools are only good for working with text?
- Retra 8y ago
  The command line is great because it makes it easy to automate tasks involving multiple arbitrary applications. It's why we still use it even after GUIs basically became mandatory on all user-facing computers.
  - vram22 8y ago
    Yes. IOW, GUI's are not as easily scriptable as CLI programs, to compose operations from combinations of other operations, even though some tools to do stuff like that do exist, e.g. AutoHotKey and others like it. A classic CLI command composition (a.k.a. pipeline) example: More shell, less egg: http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/ http://www.leancrew.com/all-this/2011/12/more-shell-less-egg... After reading that post, I wrote about it here: https://jugad2.blogspot.com/2012/07/the-bentley-knuth-problem-and-solutions.html https://jugad2.blogspot.com/2012/07/the-bentley-knuth-proble... with a couple of solutions in Unix shell and Python. Related: Why you should learn just a little Awk (2010) (gregable.com) https://news.ycombinator.com/item?id=17322412 https://news.ycombinator.com/item?id=17322412 A comment by me there: https://news.ycombinator.com/item?id=17324572 https://news.ycombinator.com/item?id=17324572
- 0x445442 8y ago
  I think we (cli advocates) worship text because language happens to be a very powerful user interface. What we need is a ubiquitous command interface where the output of any command is a tree set of typed objects and any command is free to consume any of those sets of typed objects. The typed objects in this pattern would not be limited to text. This paradigm removes the restraints of GUI applications but satisfies a great many use cases with the obvious exceptions being any program that requires a lot of mouse or pointing device input like photo manipulation.
fiatjaf 8y ago
Writing is GUI takes time. With CLI you can provide much more functionality with much less time. You're free to write GUIs for all CLIs in this world, however.
falcolas 8y ago
> I wonder if we all have a bit of an Stockholm syndrome I used to agree with you on this point, but then came Bender. Chatbots singlehandedly liberated the CLI from the terminal and made them ubiquitous once again. So yeah, it's not just the terminal where we're creating CLI applications anymore.
gambler 8y ago
Most people who claim that command line is the best tool for power users know nothing about history of GUIs. They think that laughable garbage that Windows calls user interface is "how it's supposed to work", and proceed to smugly lecture everyone on how command line is the only interface that can be composed and easily recorded. (The following paragraph is not directed at the author of the parent post. It's fully rhetorical.) Did you know that icons were supposed to be live representations of in-memory objects? That objects were more fundamental for the OS than files? Did you know that windows were views onto those objects? Did you know that interactions to and between icons were synonymous with OOP polymorphism? https://www.youtube.com/watch?v=Cn4vC80Pv6Q https://www.youtube.com/watch?v=Cn4vC80Pv6Q And this isn't the best UI, it's simply the first modern UI.
- twic 8y ago
  And how you do operate on the data in those objects? How do you filter, project, sort, stash for later, combine with data from elsewhere, edit, etc? How do incrementally build up a composition of operations from repeated experimentation? How do you record that composition in a script?
  - gambler 8y ago
    >And how you do operate on the data in those objects? You don't. Your question makes as much sense as asking how to do polymorphism in shell commands Not operating on data was the whole point of OOP. (Or at least one of the key points.) http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... "I wanted to get rid of data. The B5000 almost did this via its almost unbelievable HW architecture. I realized that the cell/whole-computer metaphor would get rid of data, and that "<-" would be just another message token (it took me quite a while to think this out because I really thought of all these symbols as names for functions and procedures." -- Alan Kay The way to integrate unrelated objects in fully OOP UI would be by making them send messages to one another, either directly or indirectly. The way to store this integration for later use would be by creating, modifying and serializing an object that represents it. Look into Pharo or Squeak, at least watch some demos on YouTube.
diroussel 8y ago
If your command line tool has a man page then fish shell can parse it to automatically know about command line arts for auto completion.

NeedMoreTea 8y ago

For a quick args reminder, without having to dig through man pages, try tldr: https://tldr.sh/ https://tldr.sh/

forkerenok 8y ago

Speaking for myself of ffmpeg and imagemagick, I don't find the CLI itself difficult, I find that their application domain is a bit complicated for a layman. Meaning I usually struggle to comprehend what particular options mean rather than how they bind to CLI. Maybe indeed a good intuitive UI would give more intuition about the more obscure options. But then again, a good intuitive UI is a quest of its own.

tajen 8y ago
What is difficult with ffmpeg is the sub-language in each argument, which depends on the filter you’re using. I can learn to lookup the manual, but if I have to go to the internet to learn the syntax of the filter, I’m better off googling my usecas.
- pleasecalllater 8y ago
  And using multiple filters in one call is even more funny. Getting the output and parse it too, as it can be different in different versions and it's terribly inconsistent between filters.
voltagex_ 8y ago
Merge a separate video and audio file without looking it up - I've got a document stored that lists all the different commands I've used and hopefully some context about what they do.

de_watcher 8y ago

> I'm sure we all end up using google Which is kinda a CLI application.

oblio 8y ago
But done the right way. With autocompletion based on your frequent searches, recent searches, machine learning based suggestions using what the whole internet searches, etc. It's qualitatively different from your average CLI experience. As such, I don't think you can actually compare the two.
- Retra 8y ago
  It is a command-based line-input UI. Just because it is different in other ways doesn't mean it a comparison is unwarranted.
  - oblio 8y ago
    My argument was that the "other ways" it is different in are more important than the similarities.

Already__Taken 8y ago

Powershell made 2 things gospel and I'm just sad it's going to take 20 years for other operating systems to realize that's the way to do it and something that replaces linux to see it in practice (i.e. it just won't) 1. Auto-complete is by-design part of the language/shell 1. Pre-approved Verb list that prefix commands helps discoverability and usability no end. Still learning? Get-<anything> will literally never cause a problem. Because of the above get-help <function> can automatically create some fairly useful documentation right away and whoever wrote the code didn't need to do anything. They can significantly add to to help though. Because that mechanism is part of the language it's worth doing literally every user is going to access it, not some blog your wrote 5 years ago I hope is still online. Passing objects rather than string, whatever maybe it's not the best way, I think it's great. But That's not the only thing PS has to learn from. If anyone uses the cli and doesn't know how the PS help system works, it's certainly a breath of fresh air to learn.

agumonkey 8y ago
I never really found the verb list to be entirely satisfactory. It's great that they gave boundaries but I find it too verbose. There are other kinds of syntactic ergonomics with concise vocabulary (lisp has ! xxx p$ for instance, they're a bit harder to swallow but I find the code a bit more poetic and easier to remember as a pattern). About the objects vs strings, Kalman Reti (of Symbolics IIRC) talked [1] about how an OS passing pointers could enjoy a much easier time instead of serializing everything as strings then deserializing, especially when done ad-hoc through sed/grep/perl/whatever .. It pains me to see this. It pains me to see how linux basic utils are 30% --usage, 30% output formatting (and they all share this). MS did a great thing with PS. [1] https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=o4-YnLpLgtk
- guhidalg 8y ago
  The verb list is, in practice, 90% Get-* and Set-* , so for most users that will cover the case where they need to read and modify some system state in a script. It may not cover your particular use case (I want to foo this bar), but as restriction on the language it helps your users not have to discover esoteric commands.

Meai 8y ago

I think that the solution is clear, make a language server for the command line. Each and every single command line interface is its own language so they all need their own language server that can provide meaningful completions. Then bash and other shells can add support for language servers and we have the problem solved.

sgeisler 8y ago
I imagine this to be a little bit over the top in most cases. A standard flag like --complete-rahyeiB1 (with a sufficiently long random string to avoid collisions with existing flags) which takes the already written argument list as an argument and prints possible completions would be nice though.

larkeith 8y ago

> Sometimes I end up passing the help output through grep, then copy-pasting the flags from the output, and then hoping I got the right flag. man x | grep -P y -C 3 | less ...is my standard here (-C 3 includes the pre- and succeeding 3 lines). For all the delights of CLIs, man pages are by default opaque walls of text. And dear lord the number of regex variants... - at this point, if at all possible, I'll avoid application-specific flavours entirely, and just pipe to grep -P (perl-style regex). I might suggest, however, that image/video manipulation is a case for which CLIs are uniquely unsuitable. There surely are better ways (as you mentioned, Powershell appears to be a step or three in the right direction, though I have little familiarity with it), but it seems as though the greatest difficulty is in maintaining full backwords compatibility, while still encouraging new applications to make full use of novel features - not to mention the effort of modifying old applications to fit new standards that would need be expended.

azernik 8y ago
If you're already piping to less, just use its search functionality; type '/', the regexp, and then enter.
- pdpi 8y ago
  For that, you might as well just use the regex functionality in man itself too. But that misses the point. The goal of grepping in that snippet is that you're `less `ing through precisely the parts that matter, and no more, rather than wading through the whole man page, and you're using -C to control how much context you (think you) need around the search results. This is a much better setup for skimming through potential hits than going through the man page wall of text.
  - azernik 8y ago
    'man' has no regex functionality; on most Unix systems, it just uses 'less' as its pager.
    - pdpi 8y ago

deleted 8y ago

[deleted]

AnIdiotOnTheNet 8y ago

At this point I'm not really sure what makes command-line so great. We should have something like it in the GUI sapce that works much better but, like you said, "stolkholm syndrome". Why can't a pipeline be a more complicated multi-io workflow? In a 2D GUI this would be trivial to construct and read, but in a 1D command line it would get confusing in a hurry. And the concept works much better with AV, I can easily construct and reason about complicated arrangements of audio and video inputs and outputs, with mixers, compositors, filters, shaders, splitters, etc. between them. Instead we worship text. Is that because manipulating text is actually more useful, or because our tools are only good for working with text?

Retra 8y ago
The command line is great because it makes it easy to automate tasks involving multiple arbitrary applications. It's why we still use it even after GUIs basically became mandatory on all user-facing computers.
- vram22 8y ago
  Yes. IOW, GUI's are not as easily scriptable as CLI programs, to compose operations from combinations of other operations, even though some tools to do stuff like that do exist, e.g. AutoHotKey and others like it. A classic CLI command composition (a.k.a. pipeline) example: More shell, less egg: http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/ http://www.leancrew.com/all-this/2011/12/more-shell-less-egg... After reading that post, I wrote about it here: https://jugad2.blogspot.com/2012/07/the-bentley-knuth-problem-and-solutions.html https://jugad2.blogspot.com/2012/07/the-bentley-knuth-proble... with a couple of solutions in Unix shell and Python. Related: Why you should learn just a little Awk (2010) (gregable.com) https://news.ycombinator.com/item?id=17322412 https://news.ycombinator.com/item?id=17322412 A comment by me there: https://news.ycombinator.com/item?id=17324572 https://news.ycombinator.com/item?id=17324572
0x445442 8y ago
I think we (cli advocates) worship text because language happens to be a very powerful user interface. What we need is a ubiquitous command interface where the output of any command is a tree set of typed objects and any command is free to consume any of those sets of typed objects. The typed objects in this pattern would not be limited to text. This paradigm removes the restraints of GUI applications but satisfies a great many use cases with the obvious exceptions being any program that requires a lot of mouse or pointing device input like photo manipulation.

fiatjaf 8y ago

Writing is GUI takes time. With CLI you can provide much more functionality with much less time. You're free to write GUIs for all CLIs in this world, however.

falcolas 8y ago

> I wonder if we all have a bit of an Stockholm syndrome I used to agree with you on this point, but then came Bender. Chatbots singlehandedly liberated the CLI from the terminal and made them ubiquitous once again. So yeah, it's not just the terminal where we're creating CLI applications anymore.

gambler 8y ago

Most people who claim that command line is the best tool for power users know nothing about history of GUIs. They think that laughable garbage that Windows calls user interface is "how it's supposed to work", and proceed to smugly lecture everyone on how command line is the only interface that can be composed and easily recorded. (The following paragraph is not directed at the author of the parent post. It's fully rhetorical.) Did you know that icons were supposed to be live representations of in-memory objects? That objects were more fundamental for the OS than files? Did you know that windows were views onto those objects? Did you know that interactions to and between icons were synonymous with OOP polymorphism? https://www.youtube.com/watch?v=Cn4vC80Pv6Q https://www.youtube.com/watch?v=Cn4vC80Pv6Q And this isn't the best UI, it's simply the first modern UI.

twic 8y ago
And how you do operate on the data in those objects? How do you filter, project, sort, stash for later, combine with data from elsewhere, edit, etc? How do incrementally build up a composition of operations from repeated experimentation? How do you record that composition in a script?
- gambler 8y ago
  >And how you do operate on the data in those objects? You don't. Your question makes as much sense as asking how to do polymorphism in shell commands Not operating on data was the whole point of OOP. (Or at least one of the key points.) http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... "I wanted to get rid of data. The B5000 almost did this via its almost unbelievable HW architecture. I realized that the cell/whole-computer metaphor would get rid of data, and that "<-" would be just another message token (it took me quite a while to think this out because I really thought of all these symbols as names for functions and procedures." -- Alan Kay The way to integrate unrelated objects in fully OOP UI would be by making them send messages to one another, either directly or indirectly. The way to store this integration for later use would be by creating, modifying and serializing an object that represents it. Look into Pharo or Squeak, at least watch some demos on YouTube.

diroussel 8y ago

If your command line tool has a man page then fish shell can parse it to automatically know about command line arts for auto completion.