Command Line and User Friendliness(terminally-incoherent.com)
terminally-incoherent.com
Command Line and User Friendliness
http://www.terminally-incoherent.com/blog/2012/05/30/command-line-and-user-friendliness/
39 comments
This is supported by some individual applications. For instance, firefox will let you open a new tab in a running browser, ratpoison will let you run a bunch of commands against it, etc.
I'm still not thrilled because it's usually still difficult to move data the other way (although xclip or xsel can certainly help).
I'm still not thrilled because it's usually still difficult to move data the other way (although xclip or xsel can certainly help).
AutoCAD has a simultaneous GUI and CLI. SketchUp has a partial implementation of a similar model.
You could argue that Vi and emacs do both. Certainly the primary mode is a (curses-based) GUI, and the command modes operate on the same data. They're not quite always-on, but close enough.
I often wish more applications would do this!
You could argue that Vi and emacs do both. Certainly the primary mode is a (curses-based) GUI, and the command modes operate on the same data. They're not quite always-on, but close enough.
I often wish more applications would do this!
I believe this is the idea behind Ubuntu's HUD: http://www.markshuttleworth.com/archives/939
AppleScript?
Typing in a particular phrase in the Google search box won't delete all of your mail and files, so you could think of it as a "safer" or "immutable" shell.
CLI in contrast can modify things, not just give you back information.
CLI in contrast can modify things, not just give you back information.
In some sense, the omnibar in Chrome is the CLI interface for Google. It both manipulates your browser and does searches. Probably wouldn't take much for Google to expand on this and add commands to help you send emails, interact on G+, and more.
I am one of those people who thing that CLIs are not user friendly. The premise - giving a computer instructions via Natural Language (NL) - is very sound. However, the way CLI is done right now (from the ground up) - is broken. The most obvious example - why are CLIs ASCII-based? I want to pass around objects - "ls" should only give me just that, an array of objects (which can be serialized for output in any graphical way, including ASCII). There shouldn't be any ASCII flags or switches - those (if really needed) should be an array of objects as well.
Another example, piping, something that UNIX proponents are quite proud of, is a good concept, but it isn't perfect. I can't even count the number of times I wanted to pipe an output of one program to multiple others, or pipe multiple programs into one. The list goes on and on.
CLI is the best tool that exists at the moment for a few things, but I definitely see how there could be a superior, semi-graphical, non-"scrolling-ASCII-buffer" alternative.
Note: I have tried Linux as my main OS for almost a year, I've done extensive dev under Linux, customized the hell out of my .profiles and *rcs, etc. Still, I see it as flawed. If someone comes up with a sane CLI, I'll be the first in line.
CLI is the best tool that exists at the moment for a few things, but I definitely see how there could be a superior, semi-graphical, non-"scrolling-ASCII-buffer" alternative.
Note: I have tried Linux as my main OS for almost a year, I've done extensive dev under Linux, customized the hell out of my .profiles and *rcs, etc. Still, I see it as flawed. If someone comes up with a sane CLI, I'll be the first in line.
> I can't even count the number of times I wanted to pipe an output of one program to multiple others
For multiple inputs, similarly:
ls | tee >(frob x) | grep y
For multiple inputs, similarly:
grep foo <(ls dir1) <(cat somefile)Thanks! I didn't know about tee.
My gripes were from working with something like this ( http://i.imgur.com/LnAvV.jpg ), and then trying to emulate that in CLI. (The picture shows a graph-based image processing system, Blender's compositing mode)
---
Source: http://www.blender.org/typo3temp/pics/ca33eb4833.png
That should probably get a domain-specific tool regardless; Generalizing the command line UI is probably going to end up getting too hairy for the common case.
"I can't even count the number of times I wanted to pipe an output of one program into multiple others ... "
There's nothing stopping you from doing that. Back in college I wrote a Unix shell (as part of a class project in Unix Systems Programming) that, in theory, could do that but I lacked a decent syntax for doing so. Perhaps that's an argument for a GUI, but what you ask for is certainly possible (although the semantics of piping multiple programs into one is hard to resolve, at least in my mind. Do you interleave by characters? By line? User specified? How?).
Also, writing an "ls" that output "objects" is also quite trivial, but the tooling required to convert (or write from scratch) existing command line tools is large. Also, the semantics can get quite rough.
"There shouldn't be any ASCII flags or switches-those (if really needed) should be an array of objects ... "
Again, I can go back to the shell I wrote in college. The arguments to a program were stored in an array. In fact, that's how you had to specify the arguments, as an array. It was an interesting shell, enough to get me an A in the class, but I never used it as an interactive shell. Typing commands (which were first class objects, by the way) was a pain. But boy could I sure could pipe stderr to more and stdout to a file.
Perhaps what you need to do is try to implement your own shell that works the way you think it should work. You could be the one to implement a sane CLI ...
There's nothing stopping you from doing that. Back in college I wrote a Unix shell (as part of a class project in Unix Systems Programming) that, in theory, could do that but I lacked a decent syntax for doing so. Perhaps that's an argument for a GUI, but what you ask for is certainly possible (although the semantics of piping multiple programs into one is hard to resolve, at least in my mind. Do you interleave by characters? By line? User specified? How?).
Also, writing an "ls" that output "objects" is also quite trivial, but the tooling required to convert (or write from scratch) existing command line tools is large. Also, the semantics can get quite rough.
"There shouldn't be any ASCII flags or switches-those (if really needed) should be an array of objects ... "
Again, I can go back to the shell I wrote in college. The arguments to a program were stored in an array. In fact, that's how you had to specify the arguments, as an array. It was an interesting shell, enough to get me an A in the class, but I never used it as an interactive shell. Typing commands (which were first class objects, by the way) was a pain. But boy could I sure could pipe stderr to more and stdout to a file.
Perhaps what you need to do is try to implement your own shell that works the way you think it should work. You could be the one to implement a sane CLI ...
Have you looked at Windows PowerShell? That's exactly what it does. You don't pass around ASCII streams. You pipe .Net CLR objects between programs. I haven't seen much done with it that you couldn't do with a non-graphical shell, but, in theory, you could write filters for e.g. image data that worked exactly like text filters in bash.
I have no idea what you mean by "passing around objects", and I guess that wouldn't make it any more friendly. An "object" is an abstract concept that must be known beforehand, and is just one in a myriad that could exist in the context of interacting with a computer.
Have you heard of TermKit? It was an experiment in intertwining graphical and command-line interfaces: https://github.com/unconed/TermKit/
Have you heard of TermKit? It was an experiment in intertwining graphical and command-line interfaces: https://github.com/unconed/TermKit/
If I want to work with e output of ls, why do I need to manually parse fragile strings?
It would be neat to have basic stringable primatives, like maps and tables, that scripts could write and read.
It would be neat to have basic stringable primatives, like maps and tables, that scripts could write and read.
You can't approach things from a programmer's perspective when thinking about interfaces. I mean, I see your point, but how would that make it any more user-friendly? More powerful, sure, but it would require an extra layer of abstraction, which is going in the directly opposite way of user-friendliness.
Besides, you already have all that right now, by using the dynamic language of your choice + file system APIs.
Besides, you already have all that right now, by using the dynamic language of your choice + file system APIs.
I personally prefer the CLI over the GUI since that's primarily what I'm used to. I also dislike control panels (a type of GUI) because they tend to restrict what I can and can't do, but at the same time, I get frustrated when using someone else's CLI. I go into a bit more detail in a blog entry I wrote a few years ago: http://boston.conman.org/2007/05/29.2
As I wrote: "GUIs, on the other hand, restrict the language available to the user, thus enforcing an interactive conformity—much like L'Académie française does for the French langauge (or rather, tries to do). It's not so much about enhancing productivity as it is usability in general (or communication, take your pick)."
As I wrote: "GUIs, on the other hand, restrict the language available to the user, thus enforcing an interactive conformity—much like L'Académie française does for the French langauge (or rather, tries to do). It's not so much about enhancing productivity as it is usability in general (or communication, take your pick)."
But you are missing something...
Try photo manipulation with a CLI. Art requires spatial interaction, not merely "conversational" expressions.
Try photo manipulation with a CLI. Art requires spatial interaction, not merely "conversational" expressions.
Not just art. Try writing and editing text with nothing but shell tools.
One thing that I'd love to see in all GUIs is a unified "search box" for commands, settings, and tasks. The OS X help menu comes close (but it only searches help and menu bar items); the "Control-Q" box in the Visual Studio 11 beta comes even closer (but it only works in Visual Studio).
Neither, however, go beyond basic substring matching, and they really should. As an example, help searching for "disable Flash" in Safari could easily point me to the appropriate preference pane and the Safari extensions Web site before falling back to a general Web search as a last resort.
One thing that I'd love to see in all GUIs is a unified "search box" for commands, settings, and tasks. The OS X help menu comes close (but it only searches help and menu bar items); the "Control-Q" box in the Visual Studio 11 beta comes even closer (but it only works in Visual Studio).
Neither, however, go beyond basic substring matching, and they really should. As an example, help searching for "disable Flash" in Safari could easily point me to the appropriate preference pane and the Safari extensions Web site before falling back to a general Web search as a last resort.
Interestingly, this is what Unity tries to achieve but has been overshadowed for other reasons.The search box in the Windows 7 Start Menu also does a great job at searching programs, files, and the control panel.
Right. Even Vim and Emacs in the terminal are actually GUIs.
There have been quite a few times I've gotten hopelessly frustrated trying to do simple photo manipulation tasks with GUI software and just jumped back to ImageMagick.
There's a lot to be said for the quiet simplicity of `convert -scale 25% foo.jpg smallfoo.jpg`.
There's a lot to be said for the quiet simplicity of `convert -scale 25% foo.jpg smallfoo.jpg`.
[deleted]
The biggest difference between, bash and, for example, Google, Quicksilver, etc, is the level of fuzziness that they will accept. With Google, you can enter damn near anything you want, and it will accept it and try to do something sensible. With the shell, you get cryptic errors if you have a small typo.
None of this means that the command line is useless or a bad idea, but it does make it relatively unfriendly towards newbies. Even if the concept is more intuitive, the current incarnation can be scary.
ls foo(bar)
None of this means that the command line is useless or a bad idea, but it does make it relatively unfriendly towards newbies. Even if the concept is more intuitive, the current incarnation can be scary.
What seems to be getting lost is that "user-friendly" has the word "user" in it. And "user" is relative to the situation.
A Formula 1 car is not designed for novices, but it gives the driver maximum control in a very high-stress situation. I would suggest that the interface is as "friendly" to the intended user as millions of $cash and hours of research can possibly make it.
The CLI is the result of 30-40 years of similar evolution, and the fact that it has survived this long, and mutated in the helpful ways mentioned by the article, would similarly suggest that many users find it useful. I know I do, and I'm a user.
A Formula 1 car is not designed for novices, but it gives the driver maximum control in a very high-stress situation. I would suggest that the interface is as "friendly" to the intended user as millions of $cash and hours of research can possibly make it.
The CLI is the result of 30-40 years of similar evolution, and the fact that it has survived this long, and mutated in the helpful ways mentioned by the article, would similarly suggest that many users find it useful. I know I do, and I'm a user.
The command line may be efficient, but it is far from intuitive.
I work with command line tools every day, and I am still constantly searching Google and man pages whenever I need to do something outside of my normal flow.
I work with command line tools every day, and I am still constantly searching Google and man pages whenever I need to do something outside of my normal flow.
How is checking a man page logically different than digging through menus? Either you know how to do what you want to do, or you need to find out how, regardless of your interface.
That's also what happens to me quite frequently -- when I'm using a GUI.
Agree that CLI are powerful but also scary to novice users.
So who's going to make cliacademy.com to ensure that everyone learns how to use a CLI?
So who's going to make cliacademy.com to ensure that everyone learns how to use a CLI?
Who's going to make a lighttable for the CLI?
Twitter is effectively a CLI. Posts that start with "D" form a direct message rather than normal status update. You can also issue other commands which follow people, edit your profile, and more.
http://support.twitter.com/articles/14020-twitter-sms-comman...
http://support.twitter.com/articles/14020-twitter-sms-comman...
It's a CLI with terrible feedback. So many people (including people whose jobs are in some way related to Twitter) don't know that when you start a message with an @reply, only your followers who also follow that other person will see it.
A few years back, when more people used the SMS interface to post, it was common to see people occasionally slip and post what was supposed to be a direct message. I don't see that anymore now that people use GUIs.
A few years back, when more people used the SMS interface to post, it was common to see people occasionally slip and post what was supposed to be a direct message. I don't see that anymore now that people use GUIs.
There was a lovely gaffe last year when @neilhimself accidentally did a public tweet of his hotel phone number in what was supposed to be a DM to his wife.
Also, I did not know that about the @reply. Twitter needs to come with a --help.
Also, I did not know that about the @reply. Twitter needs to come with a --help.
"You type something in, and the machine either executes your command, or goes “I have no clue what you just said, did you by any chance mean XYZ?”"
What sort of wizardry is this? My shell (BASH) does not say "did you by any chance mean XYZ?" It stops after saying "I have no clue what you just said" and then stares at me like I'm an idiot.
What sort of wizardry is this? My shell (BASH) does not say "did you by any chance mean XYZ?" It stops after saying "I have no clue what you just said" and then stares at me like I'm an idiot.
>What sort of wizardry is this?
[Redacted]@[Redacted]:~$ nncat
No command 'nncat' found, did you mean:
Command 'sncat' from package 'sn' (universe)
Command 'ncat' from package 'nmap' (main)
Command 'uncat' from package 'socklog' (universe)
nncat: command not foundZsh has an autocorrect feature that suggests different spellings of your command if it can't find anything exactly matching it. I'm sure that I recall hearing of similar functionality available for bash, too.
Also, recent versions of Ubuntu include shell aliases that will search for packages related to missing commands. I'm sure that if you don't use Ubuntu, you could rip this functionality out and port it to whatever packaging system you use.
Also, recent versions of Ubuntu include shell aliases that will search for packages related to missing commands. I'm sure that if you don't use Ubuntu, you could rip this functionality out and port it to whatever packaging system you use.
Have you considered zsh? Much better autocomplete options available (and enabled by default).
Good, as far as it goes, but misses (IMHO) the biggest advantage of the shell, which is composability. In the shell, you can interleave and connect any actions you have access to. In the GUI, programs can typically only interact in ways explicitly supported.
TOPS-20
Autocomplete.
Autocomplete.
I think that would be the next greatest thing in non-mobile What I think would be interesting would be some strongly-coupled CLI-GUI interactions. For instance, let's take Word as a start. What if you could swap to your CLI and say "load letter template" and it would walk over to Word and do that for you in the GUI? Or in Excel, instead of clicking through the charting wizard, instead have a CLI that lets you configure the options at will?
I think that would be the next greatest thing in non-mobile UI design. (But I'm a heavy CLI user, so I'm kinda biased.)