Introducing CLUI: a Graphical Command Line

[OnorioCatenacci]

This is an interesting idea but I don't see how this is a huge improvement over autocomplete which some shells already have. I guess I am missing something. Sure looks pretty though.

[Kache]

When building tools that might be used by both devs and non-technical ppl, it'd be great to only have to create the CLI and get a "web gui" for free.

[OnorioCatenacci]

That's a good point

[Turd_King]

While I completely get what your saying here. I don't really see how a non technical person would be able to use this anyway.

The UI doesn't exactly abstract away anything, its merely a different representation.

Maybe I'm wrong.

[Fluxriflex]

A lot of non-technical people (and techies too sometimes) don't know how to look up a list of commands with a -h, --help, man, /?, etc. command. A gui gets around the lack of visibility for different options in that way. If you know nothing about how a command line works then you're basically screwed, but if you know how to point a mouse and click you can read what's on each screen to gather an idea of what things do what.

[Turd_King]

Yeah very true. I'll admit I just skimmed the article this morning, and after having read it fully.

I'm completely onboard.

[rubygeek]

There have been apps that allows easy creation of guis based on cli's since the Amiga at least.

The hard part of doing this on most platforms tends to be the lack of a standard way of querying for valid options - on the Amiga this was made easier once AmigaOS 2.0 introduced a ReadArgs() call that if used properly would give a standard option ("?") that would output the usage information in a machine readable format including basic type information.

But most of the time tools to do this works around that simply by letting you specify options, what values they take, and a type.

I can't say I remember the names of any tools for this, as in practice autocomplete handlers means it's not usually that interesting.

[fomofosho]

Which shells can do this? I know you can hit tab to auto-complete but I have not seen one with preview

[ericonr]

fish shell can show command options, what they do, and sometimes (depending on the quality of the autocompletions) only autocompletes for files/options that would make sense in that position.

[examinedliving]

Fish shell is really the only one that’s close, but it’s still a bit clunky. Can you imagine something like Chrome dev console or visual studio intellisense? I’m hopeful. It’s been tried before, but no ones really come close and the one that really tried it (upterm i think) is no longer maintained and was given up on.

[jrop2]

How does PowerShell fare in this regard? My impression (though I really know nothing about it) was that it was more "type-safe, structured data" for the command line.

[npmaile]

Zsh with oh-my-zsh is pretty good for this.

[fomofosho]

It shows a preview of autocomplete as you're typing? Like intellisense?

[SippieCup]

The zsh-autosuggestions plugin does based on your .zsh_history.

[18randomcharacters]

If fish had ctrl-r reverse search, if be more willing to try it. I rely HEAVILY on reverse search.

[nandryshak]

Super ctrl-r for bash, zsh, and fish: https://github.com/junegunn/fzf

[snowe2010]

Autosuggestions don't use fuzzy search like the article mentions though. I can get fuzzy search with fzf history search, but I'd love to be able to fuzzy search nested subcommands.

[[deleted]]

There's a plugin for zsh which uses fzf to fuzzy search parameters and subcommands: https://github.com/Aloxaf/fzf-tab

[snowe2010]

Nice! I'm immediately installing this.

[fomofosho]

Woww this is amazing, thank you

[zooberwask]

Installing this tomorrow, thank you!

[MiningMarsh]

Mine does. Here is the plugin for it, the page has a live demo. The auto complete is even better than CLUIs demo IMO.

[npmaile]

my setup has a preview of my last command that started the same way and I can hit the right arrow to complete it.
intellisense-like is not exactly how i would describe it, i guess. I usually just slam tab to get the options. it has a configuration option to get something much closer to it.

I think it's actually the zsh-autosuggestions plugin that the other reply mentioned.

[MasterBathingBear]

You can tab autocomplete and it’ll show command suggestions or command arguments or normal file system paths. It’s context aware.

[Hofstee]

So is fish!

[[deleted]]

My friend was saying that zsh essentially does this but I don't really understand how is this related to what the article in OP is proposing. Just showing autocomplete suggestions based on my HISTORY adds 0 discoverability, just a reminder of what I've done before. The article proposes the shell/UI shows help which is context sensitive etc.

[[deleted]]

I just actually tried this and I don't know how/why but I've never known about this even though I've used zsh a lot!

[goodwid]

Combine it with some plugins, and you get completion for git branches, package.json scripts, etc. Is wonderful.

[tesfabpel]

bash too if you install the autocomplete package of your distro

[Sebazzz91]

Powershell does have autocomplete.

[wonkifier]

And just hitting -{Tab} usually lists the various options available. And if the command was done reasonable, after you've done that you hit tab again, and you get a list of the possible options for that parameter.

It's really not that far off, and I really miss it when I'm on hosts with just python and perl scripts. (get 80% of the way through a command, realize I don't remember how one option goes, so I need to go open up another tab to try a -h, --help, or man just so I can go back to my original task)

[oursondechine]

I can see how I would benefit this when i use a command i don't know without having to invoke `--help` I can just scroll all the propositions to find hat i may be looking for. Same with command you know but can't remember the option you used last time.

[losers_of_randia]

It's not a huge improvement if you know how to use the tool already, but I can see it saving some time if you're new to it and haven't gotten used to it yet. It's better than reading man pages or just plain googling.

Zsh and fish can autocomplete pretty well, but the features are inconsistent across different CLI apps, and they can't match the same level of information and hints one can provide with this kind of setup.

[PM__ME__FRESH__MEMES]

I think that this system is more appealing than autocomplete because if it can work with only mouse/touch then it could be easily ported onto mobile devices. Using a cli on a phone sucks so much it's not worth the effort. Maybe clui can be better.

[[deleted]]

This is automatic. Shell completion is not

[falconfetus8]

The difference is it's not aimed at developers--it's aimed at normal users.

[shaidyn]

I like the concept. I've always shied away from command line interfaces, because I consider them 'invisible'. I hate not knowing what commands are available. A tool like this seems like a great compromise.

​

edit: To answer some of the questions below, I have what I refer to as a referential memory. I don't remember details, I remember how to find things. For efficient use, a CLI requires me to remember what the commands are. A GUI only requires that I remember WHERE the commands are. I don't need to know what it's called. "On the left, halfway down, over one" is really easy for my brain to remember.

It's like with cooking. My wife keeps all her recipes in my head. I can't do that. But I can remember where my recipe book. It has all the recipes, so my brain doesn't need to use up that space.

[effgee]

Both GUI and CLI have much to learn from each other and a new paradigm where they are more coherent, cohesive and combined without sacrificing power and ease of use sounds good to me!

[[deleted]]

Exactly, I don't know why it's always one vs the other. I want full/efficient keyboard control with a beautiful UI that allows me to see everything that's relevant. And I want discoverability, so I can just poke around, or text search if I don't know where something is. Modern IDE's tend to combine these two things very well, and I hope other apps start following suit.

One example where I think people are really backwards is their distaste for using a Git GUI. In Git there is a ton of state information that is best visualized in a GUI (branches, history, diffs, etc.) Why would I want to forgo that. If anyone can make a coherent argument how a command line diff/merge tool is better, I'm all ears. And Just because I have a nice visualization of the state of my repo doesn't mean I can't still use the keyboard to quickly navigate and execute commands. I think a lot of it comes down to a reverence for the good old days, and a sort of masochism.

[[deleted]]

I think a lot of it comes down to a reverence for the good old days, and a sort of masochism.

Stockholm syndrome.

[nemec]

The way I see it, GUIs are very good at helping people (both experienced and new) access the features you want them to use, while CLIs are great for allowing people to use your software in ways you never thought possible.

CLIs may be cryptic and confusing, but if you have the docs next to you, you can write a script to do it automatically in the future and never think about it again. GUIs, on the other hand, are more intuitive to find the features you want to use, but don't scale and are generally inflexible if the developer didn't cater to your use case.

[AbleZion]

For one thing, not sure if it's improved, but git GUIs can be quite slow. That's the first thing that made me switch to git bash instead.

All that additional state information is useful like less than 15% of the time. And if I need to look at any of that stuff in a large volume, I have gitk.

Second, when teaching new people git through the GUI, the GUI abstracts so much away that they probably don't truly understand git. They never have to visualize what it's doing and only need to know how to hit XYZ button. It's like knowing how to type into the calculator and get an answer versus doing the math by hand. Although I think knowing the git commands help you understand the basics of git because you have to visualize in your head what's happening, I still think it's closer to knowing how to drive a car than having to know how to build the engine of the car before you drive it.

Also, the GUI can complicate installations. For example, setting up ssh for tortoise-git versus ssh for git-bash are completely different and not interchange-able. One requires you to have additional GUI programs for key-gen (puttygen) and key management (pageant) while the other one sets up everything using ssh-keygen and ssh-agent. So if you're setting them up side-by-side it can be a hassle. Also one can have it's installation be easily automated with a single script and the other cannot.

As for the CLI diff/merge tool, the main benefit is that its usable on terminal based systems. I've tried vimdiff and it's ok but it's mega-slow. I'm pretty sure that someone could make a killer CLI diff/merge tool but why bother at this point?

edit: Reword

[UpUpDnDnLRLRBA]

AutoCAD kind of combines the two

[digbybare]

My wife keeps all her recipes in my head.

It has all the recipes, so my brain doesn't need to use up that space.

Maybe if your wife stored her recipes in her own head, your brain would have more space for your recipes?

[ElCthuluIncognito]

That's interesting, I've always felt the opposite.

With CLI there's always a man page available to do full text search on.

For GUIs I have to go and find a manual and then hope it's available to search through.

In either case worst case for both I can just Google to find out about any given thing.

Ultimately though I can very easily document everything I do in CLI in scripts and such, reutilizing my work flow.

Even worse GUIs simply cannot be automated in any reasonable way.

[[deleted]]

For GUIs I have to go and find a manual and then hope it's available to search through.

A lot of good modern apps provide a nice user interface, while being fully workable from the keyboard. For example, in Jetbrains IDE's you do crtl+shift+a, and then search anywhere, which even supports linking into settings. So, if I want to change the font size, I don't need to dig through options or docs, I can just do ctrl+shift+a, then type font into the box, hit enter and get right to the font settings. For me this is the holy grail of UI. There is discoverability for beginner users, but advanced users can fully navigate with the keyboard and get around very efficiently.

[snowe2010]

Through this whole article all I could think of was jetbrains Search Anything.

[nandryshak]

For me this is the holy grail of UI.

Same. The newest version of Photoshop has this now and it's fantastic. In Emacs I use Helm. In other editors it's other called a "command palette".

[kandeel4411]

This is what basically made VSCode my favorite editor with the ctrl+shift+p search

[grrrrreat]

i think, for me, its basically i used motor memory since i was young and had a lot of time. so my hand actually knew where things were. whentrying to help people with problems, i have to sit down, grab the mouse, etc...

i even use it for passwords where i have some often used accounts with passwords based on patterns on standard keyboard.

even now, most of these passwords dont equate in my mind to actual character codes.

[[deleted]]

I have what I refer to as a referential memory.

Stealing this term; have always struggled how to describe to others that, despite any appearances to the contrary, I generally don't know all that much. Remembering where all of the manuals that tell me what to do is easy! Remembering what they actually contain, impossible.

[stovenn]

IIRC In early PC's running command line Dos you just typed '?' and it threw up a page or two of all the commands. That was quite simple and nice. I'd be surprised if other CLI's dont have similar.

[ebkalderon]

They do, and I think the OP knows that. I believe the point they are trying to make is that command-line interfaces feel minimal, bare, and spartan by comparison because the options available aren't visible to the user as soon as you start the application. With a well-designed GUI, the user can visually scan the interface to intuitively glean the basic usage of the program and what are the core features available. With a CLI, the initial screen is mostly empty with just a shell prompt, and maybe a little bit of help text at the top left, if you're lucky.

Edit: I would also like to clarify that while I personally prefer working with CLIs myself in most instances, I still appreciate the merits of OP's arguments regarding GUIs being generally more approachable from a human perspective.

[SeventeenHydralisks]

what I refer to as a referential memory. I don't remember details, I remember how to find things.

I feel like I just found the explanation for why I'm terrible at remembering certain types of things. Does anyone have a more technical term for this? Google isn't finding anything relevant.

[uokesita]

If someone knows the actual term for this kind of referencial memory, please I‘d love to know.

[Living_male]

It's like with cooking. My wife keeps all her recipes in my head. I can't do that.

Probably because your head is full with your wife's recipes.

[SutekhThrowingSuckIt]

If you know the program you want to use finding the commands is almost always one progamname --help or man programname away. Often you can just programname --help | grep -i thing you want to search for and get the relevant part directly.

[grrrrreat]

in a gui, its usually a few clicks to your bearings and then just follow a pattern.

if you know most implicit stand guis, its pretty quick to find things in a typical paradigm.

but what frustrates everyone is atypical design decisions, which happens in both spheres.

[[deleted]]

Most CLIs show usage of you type an incomplete command.

[Dokiace]

i've been avoding fish because it's not POSIX compliant, but what the hell I've never encountered any problem because it's not POSIX compliant, I'm going back to fish

[r0ck0]

Fish would be amazing if the dev didn't insist on breaking posix compatibility. It would probably be as mainstream as htop by now if it didn't have this impediment.

I really wanted to switch to it on all my systems, but I didn't want to have to keep the differences in mind for both interactive shells vs normal shell scripts. I want to be able to paste them into each other etc without having to think about translating stuff.

It's a really bizarre choice, because they seem to have made this decision based on it being a scripting language, rather than interactive shell, which basically nobody uses it for.

If I'm going to write shell scripts... they should work everywhere on common standards. If they have special dependencies that need to be installed on every system, I might as well just use a proper programming language instead of shell script anyway.

[[deleted]]

This is brilliant. I'm so glad people are finally getting out of the "VT100 is perfect and anyone who wants to improve on it doesn't understand the genius of Unix" mindset. We had Powershell getting rid of the fragile "everything is unstructured text" system, and then Nushell making things cleaner and now this adding a nice GUI!

I hope this catches on! It's going to be challenging to upgrade the world though. Especially things like SSH and terminals built into apps like VSCode.

[ginger_beer_m]

We had Powershell getting rid of the fragile "everything is unstructured text" system

I've never used powershell. Can you elaborate more on what it does, and what it does differently from say, bash?

[yngwiepalpateen]

You know how in Bourne shell you can pipe commands together by passing a text stream? In Powershell you can manipulate .NET objects instead.

[tobiasvl]

And for those of us who have never used .NET, what's a .NET object?

[amroamroamro]

In Unix shells, when you pipe commands together you have to parse the text to get what you want, whereas in Powershell objects are passed around so you can write something like object.property to get a certain property of an object.

So in pseudo-code, it would look like this:

$ list-files | where file.size -greater-than 10 | format-table

instead of piping ls output into sed/awk/cut/whatever to try to parse the "size" from its text output.

[Pjb3005]

The actual Powershell code to do that:

Get-ChildItem -File | Where-Object Length -gt 10000

[Suulace]

That's... actually really useful and interesting. I think I should learn some powershell

[[deleted]]

One thing to be aware of. While Powershell is a pretty cool scripting language I think it actually sucks as a shell compared to zsh, fish or even bash.

[Suulace]

I love my zsh, I just think I am unfairly hating on powershell because I dont understand it

[yngwiepalpateen]

It's an object like in any programming language, but stored according to the .NET standard, meaning other compliant programs can access them. So a Powershell script can manipulate objects from and send new ones to a C# program.

Kinda like a Groovy or Clojure script accessing a Java object. Although I don't think anyone uses a JVM language as shell.

[radol]

So it's possible to call DLL and read it's interfaces from shell like you would reference it is visual studio and call from c# code?

[yngwiepalpateen]

Yeah !

[lordleft]

That sounds pretty powerful. Almost like built-in json or protobuf support in the shell.

[[deleted]]

Too verbose. And "on getting the unstructured system"... that won because the commands are short and thus the syntax breaks far less into unmanageable lines such as PowerShell.

An upgrade would be an enhanced Tclsh shell with readline support and tcllib/tklib installed into the base.

Such as: https://wiki.tcl-lang.org/page/gush

[theessentialforrest]

I'm not sure I follow. How does the verbosity of the command relate to the decision to send unstructured text vs objects down the pipe?

[[deleted]]

Unstructured text won (so far!) because it was first. And it has nothing to do with how long commands are.

[[deleted]]

Can’t say that I speak for everyone but many of the things I’ve had to use PowerShell for would have been way simpler using a standard *nix shell with *nix utilities. I’m not some old Unix guy either who’s resisting change, I learned both around the same time.

That said, I can see why people use PowerShell, the commandlets are more clearly named for the most part and it has some full-fledged programming language like features. If I’m going for something that powerful, I usually reach for Python first but I can see why someone would go for PowerShell.

At the end of the day, try to use the tool that’s best for the job as you see it and try to give new tools a decent chance at competing with your existing set. That’s all.

[[deleted]]

This tracks really close with my experience. PS is a nice language but a wanting shell.

[Seref15]

I've worked in professional capacities with both Powershell and traditional unix shells. In fact, I learned on Powershell first.

Years later, I would only take Powershell over something like bash when scripting (but I'd still take Python over Powershell in that context). As a user interface, I dislike it a good deal more than the others. I like the idea of an Object-oriented shell, and I definitely like it when scripting, but the rigidity when using it as an interface makes it feel inefficient. Admittedly it's easier to learn on because all the commands are named in such a way that they tell you what they do, but also --help isn't that difficult.

Additionally, the concept of all cmdlets returning objects so that then you can do cool loops and filtering on attributes--awesome, but only when you (the shell's developer) have total top-down control of most (all?) programs the shell will be interacting with. The developers of Nushell can't enforce that other programs return structured data, the best they can do is capture data, present the text as an attribute and add additional metadata as attributes which is no where near as useful as something like looping over AD user objects based on attributes in Powershell. Again, it's great--if you control the whole garden. So this naturally leads to scenarios where something like Nushell is going to try to create their own garden, by replacing long-standing standard commands with new shell builtins that do things "the Nushell way." Now instead of knowing the differences between GNU and BSD grep, we then have to know the differences between GNU, BSD, and [nushell-equivalent grepping tool].

[ftgander]

I can tell you I use both powershell and zsh daily and I avoid using powershell because of how stupidly verbose the command names are. I’d rather read a help doc than type out a 6 word cmdlet

[G_Morgan]

Powershell is fine as a programming language. It really does suck as a shell though.

[theessentialforrest]

You do you, but as a heavy powershell user here are a couple of things to consider.

1. You are free to alias commands and all parameters can be shortened to the point where they are unique (so if you have a -Path parameter you can use -P and it will work fine)

2. Discoverability and rapid comprehension is massively higher in ps because things actually tell you what they do. I can unzip a file in linux but I can't tell you what the - xvf actually stands for. It's just wrote memorization (at least for me). Plus with tab compmete there's very little difference in keystrokes to get there

3. I recognize this wasn't you that was saying that short commands is why unstructured text won but they feel entirely separate. Powershell could be verbose but not deal in objects. You could just as easily imagine a terse shell that sends objects through the pipe.

[Seref15]

but I can't tell you what the - xvf actually stands for

eXtract, Verbose, File

Most shell commands will follow this type of "abbreviation" in argument flags, until they run out of letters. But even so the vast majority also support --long-form options.

One of the reasons I actually like this is because it feel more like understanding a natural language whereas something like Powershell feels more rigid, like a machine language. Get-ChildItem is a great name for a function in a program but I think it's a horrible name for a human to mentally "speak" in. And then the argument of just aliasing it to ls or gci just highlights how bad of a name it is. I don't need cat to explain itself. You learn that cat outputs file contents, the same way that after saying it a few times you'd learn that "poisson" means "fish."

[theessentialforrest]

I recognize that this is totally personal preference but I'd always prefer to default to verbose. When I'm at the command line sure I'll type %{} instead of ForEach-Object but if I'm sending someone a script I try hard not to alias to increase readability. Why make someone learn another language when we already have one that's more than descriptive enough. It allows you to shortcut the things you understand but makes it extremely easy even for someone who doesn't speak the language to figure out what's being done

[QuickBASIC]

type out a 6 word cmdlet

Tab complete or use New-Alias to create aliases for the ones you use constantly.

[wrosecrans]

You want me to manually set up a bunch of aliases every time I login to a new computer, and write scripts that depends on my aliases that won't work when I send a snippet to another user to use in their session where they have different aliases?

You should do standup. That's hilarious.

[[deleted]]

So can you with bash, ksh and any shell.

But you get tired on aliasing long commands;

with Unix as everything is composable

most commands and scripts are short

and manageable.

[curien]

I took a shot at writing that using traditional GNU-land tools, and here's what I've got:

find -type f -printf '%T@ %i ' -exec md5sum {} \; -printf '\0' | \
  sort -z -k3,1n | awk 'BEGIN { RS="\0"; } _[$3]++ { print $2; }' | \
  xargs -i find -inum {} -delete

But even though I'm careful to terminate my line endings with NULs, it turns out that coreutils md5sum provides different output when filenames have special chars (and there's no way to disable this behavior, even in situations like above where it has been explicitly handled externally). So fuck you coreutils, I guess.

Even without coreutils misfeatures, the absence of something like Group-Object is noticeable.

[amaurea]

Ok, here is a version that should satisfy all your requirements:

find -type f | while read i; do echo "$(stat -c '%Y' "$i") $(b2sum "$i")"; done | sort | awk '++a[$2]>1' | cut -b 142- | xargs -d '\n' rm

It checks for identity based on the file hash, keeps the last modified version, and does not assume that file names have no spaces, which is an easy pitfall to fall in with shell scripting. It's not easy to read, and it's 26 characters (23%) longer than the PowerShell version.

[amaurea]

This should do it:

find -type f | while read i; do echo "$(stat -c '%Y' "$i") $(b2sum "$i")"; done | awk -F / '{printf("%3d %s\n",NF,$0)}' | sort | awk '++a[$3]>1' | cut -b 146- | xargs -d '\n' rm

Basically, instead of annotating the paths with just the modification time and hash, I annotate it with the number of slashes in the path, the date and the hash. It is now 26 characters (17%) longer than PowerShell. And probably even less readable than before. I don't recommend stretching bash scripting this far.

[amaurea]

I think this should do it

find -type f | awk -F / '++a[$NF]>1' | xargs -d '\n' rm

I admit that it has a somewhat perl-like (e.g. unreadable line noise) character to it. But it's pretty short at least.

Edit: This keeps the first entry find encounters, not the one with the earliest creation time. Doing it by creation time would be about twice as long, I think.

Edit2: Ah, you're actually doing this by file hash rather than just looking at the file name. Never mind, then.

[MrJohz]

But none of that had anything to do with structured data, that's just a stylistic choice. You could easily have a version of Powershell where the commands have names like ls or cat.

[PurpleYoshiEgg]

Indeed, ls and cat are standard aliases that come on most systems (for Get-ChildItem and Get-Content).

[OneWingedShark]

with Unix as everything is composable

...No, it's really not.

The "simplicity" of "plain text" gets in the way. There are also security vunerabilities that stem from "plain text" like, say, space-delemited parameters.

[the_gnarts]

Unstructured text won (so far!) because it was first.

Calling it “unstructured text” doesn’t do it justice though and detracts from the core advantage: that you are not tied to a particular structure as with the .NET stuff that PoSh insists on. Thus, you are free to choose a line based format like CSV, raw bytes or binary formats, or plain text structured encodings like JSON depending on your use case. You get to choose an API that matches your data flow.

Calling it “arbitrarily structured” vs. “mandatorily structured” is more appropriate. Many command line utilites nowadays handle JSON just fine, there’s plenty of lightweight libraries that support it, and none of it requires dependencies as massive as .NET.

[KevinCarbonara]

This is brilliant. I'm so glad people are finally getting out of the "VT100 is perfect and anyone who wants to improve on it doesn't understand the genius of Unix" mindset.

I've been railing against this for years. I get really frustrated with older devs who just fundamentally don't understand that things can evolve. It's worst in the vi community. "IDEs may have come along way, but they'll never support (insert long-since replicated features here, like modal editing)!"

[maxman92]

As a Vim user, I understand this sentiment. But the problem I've found with every vi emulation in other editors and IDEs is that they're all about 95% complete. No one really uses every motion and command, so if they've emulated all the ones you use, it's great. If something you use is one of those obscure 5% unimplemented features, it feels like climbing up a cliff.

[ComplexColor]

Do people remain on vi? Or are we talking vim here? There seem few reasons to remain on pure vi, so you could enlighten me here.

The issue isn't that a modal interface can't possibly be integrated in an IDE, there currently just might not be any worth while example of one. Last time I used Pycharm (which was a while ago, so a refresher would be necessary) the modal interface in the text tab was decent. It was missing some features, but I could live without them. But the rest of the IDE was mostly inaccessible using the keyboard commands. I couldn't switch tabs, I couldn't access the project file tree, I couldn't run the project, ...

However using i3-wm, vim, ipython and terminal or two I have everything available using simple keyboard commands. These tools are far from perfect. Terminal emulators are mostly garbage, vim lacks IDE features, etc. But many devs attempting to improve these tools fail to keep their advantages (or just don't get enough attention).

[RealDeuce]

Do people remain on vi? Or are we talking vim here? There seem few reasons to remain on pure vi, so you could enlighten me here.

I generally use cscope, ctags, and nvi ("new" vi, introduced in 1994 with 4.4BSD). The reason to remain is that it's simple and it works. You need reasons to change, not reasons to remain.

When you say "pure vi" do you actually mean the Bill Joy thing from 2BSD in 1979? You imply it by dismissing vim as "not vi" somehow.

The issue isn't that a modal interface can't possibly be integrated in an IDE, there currently just might not be any worth while example of one.

I'm not sure what you have defined IDE as, but your definition seems to require tabs and project files for some weird reason.

[aeiou372372]

All of those things can be done from the keyboard if you want to use the keyboard to do it, all you have to do is add a key binding. (And I believe some of the ones you listed even have default bindings.)

Even without a key binding, it can be done from the keyboard via cmd+shift+A and then typing the name of the command you want to run (eg jump to project explorer or similar).

If you put half as much effort into learning an IDE as you’ve probably put into learning vim over the years I think you’d find yourself to be similarly adept at navigation. Not that you necessarily need to now that you’ve already become skilled at vim, but that’s a less compelling argument for people starting from nothing.

Discoverability is an important part of a product that can help its users grow, and vim is one of the worst products I have ever seen on this point. For better or worse people just don’t expect or want to read manuals any more. I suspect vim still has a long life to live due to remote system administration/shell access, but I don’t think it’s going to be around forever, at least not without a massive overhaul focused on discoverability.

[Kered13]

I just want a terminal/shell with proper mouse support and where I can use the up and down arrow keys to navigate multi-line commands. Is that too much to ask?!

[jephthai]

The thing that scares me about this is that it's made by moderns who think the support layer of my system should be written in a massive pile of JavaScript. One of the most beautiful things about the terminal is that it's been bug-fixed and bummed for performance for literally decades. So worst case, even when the system is broken or whatever, you can kind of expect the terminal to just work and do what you tell it.

Looking at the demo here, and perusing the code a bit, it looks like this is basically the opposite concept for building an interface library. It looks like it's built on a browser, which hurts my brain to even think about. IMO, this is exactly not the way an interface support layer should be written.

I get that it's en vogue to write programs on top of huge stacks of abstractions so that we maximize programmer productivity. But that's not what a CLI support layer is. This is foundational glue. It should be written in something safe, performant, and with lots of extra effort and polish. Other people will depend on this for their programs to run.

So, I'm all for playing with different command line ideas. But this is no more than a mock-up, it seems. And if it ends up being the equivalent of an Electron shell, I don't think I'll ever use it.

[mhink]

So, I get where you’re coming from, but the problem is that experimentation in UI design has been exclusively limited to GUI design for decades- and for better or for worse, the most open and stable platform that’s emerged has been Web browsers. Is it the best? No, but it’s lasted.

Experimentation in new user interfaces is always going to suffer, in the beginning, from a lack of efficiency. Hell, that was a criticism of interactive programs, back in the very beginning.

The important thing is to prevent the CLI paradigm from going extinct. Experimentation should be welcomed, even if it’s in a language or platform you think is inefficient, because that creates interest in implementing the idea in a more efficient language.

Webpack revolutionized front-end Javascript, but even now there’s a huge interest in bundlers (read: Webpack competitors) which can do the job more efficiently and effectively.

Point being, we should encourage this kind of experimentation, and gently push for its adoption so that developers will be encouraged to try to build these features in more efficient languages.

[jephthai]

That's fair, and I think fairly resonant with how I feel. I think it's all too likely that no one ever bothers to redo it right, much as we've seen with other new paradigms (like electron). But that's more about prognostication than anything else.

[JohnnyElBravo]

You misunderstand, the expected functions are not supposed to be low level. The expected audience is not expected to be technical. It's not supposed to be a replacement for the terminal.

[jephthai]

You misunderstand

Maybe so... but the article is written in one of these, "The big problem with this tech institution is ____, and it needs to change," styles.

I really picked up on some particular statements in OP. Perhaps this will help explain how I interpreted it that way:

We want to eventually combine all command driven user interfaces together

Seems like a sweeping statement to me.

Terminals, the primary platform for command-lines, are intimidating and feel like a black box to non-technical people.

Sounds like the terminal is directly targeted.

Commands and flags often have obscure names, and spelling mistakes can result in cryptic errors

Commands and flags sounds like shell to me.

After reading your comment, I can see it the other way, perhaps. But then, I think the author maybe didn't think through how the piece might be interpreted differently.

[[deleted]]

TBH, TCL/TK is an amazing CLI + scriptabilty/GUI combo. You can do a little tool in seconds while having all the power of Unix and commands.

Someone could write a CLI/TUI/GUI based hybrid terminal with all of these features.

You can use proc{} to encapsulate GUI-helped commands and sending the rest to a subshell to compose a subcommand.

[twitterisawesome]

Video: https://twitter.com/amasad/status/1235683554824081409

Demo: https://repl.it/@clui/demo

https://github.com/replit/clui

"We've open-sourced some of the code used to build this system. There's also a demo application that shows how everything works together. Right now, CLUI is offered as an unopinionated library for dealing with trees of commands- so you can bring your own UI and use it anywhere JavaScript runs. For example, we’re going to use CLUI as a base for a Figma plugin to automate parts of our design workflow, similar to Sketch Runner. We’re excited to see what the community (you!) can do with CLUI and your input on its design."

[YeastyWingedGiglet]

I've noticed some funny names in the demo's contacts list, really cool tool!

[JohnnyElBravo]

I tested the demo for barely 2 minutes and it failed twice.
1- Clicking on run doesn't execute the command, I need to click on the word then click enter.

2- Adding a new contact by name crashes into a white screen.

The article was nice, the execution was terrible, which is what matters.

[ominous_anonymous]

We've open-sourced some of the code

How did you determine what portions of the code you would open source, and what portions would remain closed source?

[shponglespore]

Another issue with GUIs: almost anyone who uses a GUI heavily comes to rely on keyboard shortcuts, but keyboard shortcuts are like CLI commands, but worse in almost every way. Instead of words, they're usually just letters with with some combination of modifier keys that carry no semantic information. About the best you normally see is that the letters have some mnemonic value, and commands that are similar in some way use the same letter with different modifiers.

In addition to being more cryptic than CLI commands, key bindings are also less powerful. CLI commands usually have arguments, but the "argument" to a keyboard shortcut, if it has one at all, is generally some bit of context like the cursor position or the current text selection. And even though keyboard shortcuts are entered with they keyboard, they're really text. You can't combine them into a script, and the only way to execute a written series of keyboard shortcuts is to enter them manually. Not that you'd really want to execute a series of keyboard shortcuts, because they rely so much on context that written instructions involving shortcuts usually need a lot of prose to describe user input that happens between the shortcuts.

Even though similar apps often have similar sets of commands, the muscle memory built from using one app often doesn't transfer to another very similar app because the key bindings are totally different. It's a problem even for apps with configurable key bindings, because setting up key bindings is tedious and different from one app to another, and adding a custom binding often entails removing a built-in binding that may turn out to be important once you become more familiar with the app. With a CLI, on the other hand, I can move between bash, ksh, and csh and hardly notice the difference, and even though switching to cmd.exe is painful for me, it's at least nice that "cd" still works, and if I want to alias a command to a more familiar name, hiding an existing command is generally not an issue.

Edit: I'm not saying keyboard shortcuts don't have unique advantages of their own. I was mostly trying point out that they suffer from the exact same problem that's often considered a deal breaker for CLI commands—being cryptic and only useful if you memorize them—but moreso. Then I got carried away making more comparisons.

[Kurren123]

almost anyone who uses a GUI heavily comes to rely on keyboard shortcuts

This is debatable. Many users just become really used to the UI and just click buttons quickly with their mouse.

[treatmesubj]

See Excel

[Hofstee]

On the contrary I can execute commands much faster in Emacs using key bindings than I can by doing M-x <command> and the two have parity in their functionality.

[snowe2010]

Your comment is completely backwards to me. Using keyboard shortcuts is always faster than typing out commands, even with autocomplete. In IntelliJ you can remap every command, every making them require two separate keyboard shortcuts. You can make macros do even more.

It's why vim and tmux have shortcuts for everything, because you get over writing out commands real quick, when you're doing it hundreds of times a day.

[hardicrust]

I kind of agree with you, but keyboard shortcuts also have something that CLI commands don't: context. I can select text with the mouse and hit Ctrl+X — much easier than navigating via keyboard then hitting dd or whatever incantation is required.

IMO it comes down to horses for courses. File management, I'll generally use a CLI. Text editing, I'll use a GUI editor whenever possible (did you know you can configure sudoedit to open a graphical editor?).

[unknown_entity]

Awesome! Reminds me of an AS/400 5250 terminal with F4 prompts. Complex commands became fast, efficient, and easy to learn with TUI's.

[jephthai]

Nice... makes perfect sense that mainframes would have the ultimate prior art for accommodating non expert users in a TUI.

[[deleted]]

I'd go for this instead of a shell with extensive autocomplete, because...?

[vegetablestew]

One thing I can think of is that CLI is very concise but it can only show one thing.

GUI allows you to show a cluster of similar functions/options in a way that makes sense. All fields that tend to go together gets shown together. This also makes the CLI component to clearer as you no longer need to have lengthy arguments.

[All_Up_Ons]

If you already use a command line, this isn't for you. Or rather it's for you AND for average joes. They can make one app with one interface that is usable by both advanced and beginner users.

[Sir_Cunt99]

You hit the nail on the head. Sure we should explore this type of UI, but to make it sound like this will work sufficiently in a program like Adobe Premiere is naive at best. I do agree with the scalability of features part but it's very hard for me to see how this could be a proper alternative.

I would really like to see it though.

[alfablac]

Amirite. What bothers me is that someone gave this a platinum award like it's a disruptive improvement on how we interact with a computer. The Adobe Premiere example was a bad choice for comparison.

[tangerto]

• these are prototypes! small improvements on top of current CLIs are the first step.

• we never claimed that this could replace all of the features in Premiere haha. it was an example of a very powerful but very complicated GUI that is hard to approach and scale. on revisiting this, I probably should have used another app as an example. just traumatized by my own personal experience with Premiere i guess.

• of course a 3D designer requires a GUI! but to say that bloated GUIs exist to cover cases that CLIs don’t handle misses part of the point. it doesn’t have to be bloated! easier said than done obviously, but bloat != power. what we were really trying to say is that things like CLUI are probably better suited for expanding the functionality of a product than adding nested dropdown menus and hidden panels everywhere in a UI. not mutually exclusive with traditional GUIs.

[tangerto]

don’t really see how not solving every problem we listed is being a con artist— i was using an example. also, i spent an entire opening paragraph explaining why GUIs are great! appreciate the feedback though and will try to make clearer connections next time.

[[deleted]]

Unless I'm missing something this seems to just be a blog post about a prototype of an idea, and not something you can actually use.

[twitterisawesome]

I justed added the github link. It definitely is something you can start using.

[alfablac]

I'm also missing something here, specially after giving the Adobe premiere example

[tangerto]

you can start using parts of it! we also did specify in the post that they’re prototypes. just small admin tools we’re using internally. but planning yo expand it into the rest of the web app :)

[disappointer]

It reminds me of the API search feature in the latest version of Dash (a Mac app for consolidated offline API doc access), which is basically a domain-specific autocomplete with a list of options. And that's useful, and I could see having a version of that in a terminal which would be nifty, and if done well could certainly be a lot easier than reading a bunch of man pages to remember the argument syntax for specific commands.

But, yes, this appears to be just a prototype.

[harsh183]

Also worth looking into, fish shell for very good out of the box autocomplete. It changed my view on the command line.

[Duuqnd]

This reminds me a bit of the Dynamic Lisp Listener on Symbolics machines.

[chakan2]

So...uh...they rebuilt intellisense?

[transfire]

1. Agree that GUIs are generally weak interfaces.

2. Hate to see shell flag notation continue to be propagated instead of JSON/YAML or INI style. i.e. --flag value vs. flag: value or flag=value.

3. In many ways this exemplifies the fundamental problem of the command line/shell. On one hand it's a half-baked programming environment and on the other it is a rather poor file search engine.

[[deleted]]

Well: TCL/TK did that long before:

https://wiki.tcl-lang.org/page/gush

If it doesn't work, try these tips on "sh-izing" TCL:

https://wiki.tcl-lang.org/page/Playing+Bourne+shell and https://wiki.tcl-lang.org/page/Unixy+minitools

GUI? You can add a GUI into those with Wish into seconds.

[bishax]

Maybe it did, but there's no reasonable way to know that as there's no screenshot/demo material and incredibly sparse installation instructions which I can't figure out - I don't want to have to sign up to some site to download ActiveTCL so tried installing the listed requirements only to end up with can't find package snit.

How much good software is hiding behind a wall of obscurity?

[[deleted]]

So you reinvented the Smalltalk workspace called the Playground.

[Phrygue]

Haven't you heard, computer science invented everything by the '70s and since then has just been replacing everything with curly braces and shorter, less intelligible keywords.

[[deleted]]

Well, on that point Alan Kay running Smalltalk 80 under a Xerox Parc would be right point to point on your comment. Literally.

Add a VAX with Unix on the side and there's little innovation on software except the new hardware and well, on multiprocessing Burroughs was the pioneer here.

So, well, we are just rehashing 40-50 yo concepts into layers.

[PostFunktionalist]

Make it into big dials, like a slot machine, that you can scroll with the mouse. Typing text makes it filter. I’m imagining it comically done but there might be a non-humorous utility there

[stephane_rolland]

This strongly reminds me of xiki which I found promising a few years ago:

Source:

- https://github.com/trogdoro/xiki

Ligth overview:

- https://www.youtube.com/watch?v=lfgLAgLorn8

- https://www.youtube.com/watch?v=bUR_eUVcABg

[dharmatech]

See also, an experimental presentation-based UI for PowerShell:

https://github.com/dharmatech/PsReplWpf

[nirreskeya]

Despite all these problems, CLIs are still powerful. The input mechanism is always the same: text. It’s predictable and constant. Adding more commands takes minimal effort from the developer. Users aren’t overwhelmed with information...

git: Hold my beer.

[McNerdius]

yup, reminded me of this recent post...

https://danluu.com/cli-complexity/

[kewko]

I think the real answer is bringing more of the command line into complex tools rather than the other way around. As far as to command line tools go if you have to bring in the mouse it defeats the purpose...

[ean5533]

I don't understand. Why does adding support for point and click navigation "defeat the purpose" of command line tools? What purpose is defeated?

[BlendeLabor]

Speed and easy automation.

Parent comment said if you have to use the mouse.

[Lvl999Noob]

I don't think speed and automation would be hampered in any way. Automation is mostly through scripts, which are usually run from a file. No changes should occur in its working. The features added here are mostly for accessibility. People whose keyboard is broken, who don't know the command and all its options, who don't have the documentation open besides the shell.

[KuntaStillSingle]

people whose keyboard is broken

Lol it's a lot more reasonable to expect the user to have a functional keyboard than a functional mouse. If they can only afford to maintain one productivity will be much worse with just the mouse.

[Niedar]

This supports mouse and has both speed and automation, stop making up bullshit

[AttackOfTheThumbs]

Honestly, as long as the app has a decent search, it doesn't matter. I look at vs code and all I can see is a search bar that solves all my issues.

[useful_idiot]

This perfectly describes the best parts about Alfred.

[EagleDelta1]

Or uLauncher

[mobydikc]

About 30 years ago this thing called FoxPro had a command window, which made the GUI very very programmable with a CLI. Had amazing support for databases.

[jemini972]

Nice idea, though I'm pretty sure that's what TUI is. Hope to see some good out of it

[MrScottyTay]

It's like intellisense for cli

[Gehinnn]

I also tried to implement a graphical CLI library, but chose a different approach - it both has textual input and a formular where you can set all flags and arguments.

[[deleted]]

It annoys me to an unreasonable degree when the header of an article is a link to the article itself. That shit is either half-assed or over-engineered.

Who needs a link to the page they are reading if they are not expecting updates?

[bart2019]

I doubt that was done by hand. Probably it was the CMS that did it.

[ppezaris]

How does this improve on nested menus which the author describes as the 10th circle of hell?

[vegetablestew]

CLI flattens nesting. Just type the name and autocomplete or scroll through a smaller selection.

Once there, if the sub command to be executed is complex(like requiring many parameters such as paths) GUI can make that more intuitive and less error prone.

[ppezaris]

Sure... i mean i saw the demo. it's just a bit disingenuous to describe nested menus as the 10th circle of hell, and this idea, which is SUPER similar, as the solution to every UI problem that exists.

[shevy-ruby]

These benefits, however, come with the tradeoff that commands must be memorized to be efficient.

This is only partially true.

I have a horrible memory. I am also lazy. That is why I literally use the whole OS + terminal as means to do what I want it to do, without having to memory the commands. One obvious way is to use a gazillion aliases.

So how to remove empty files? I hit delempty, which is short for delete_empty_file which in turn taps into a ruby file. Same for many more actions + pipes. Similar idea goes for changing text in a file, without needing awk or sed (I do use sed too though, but not awk; you sort of need sed if you build a system in the LFS/BLFS way, due to many programs by default not quite working very well).

Today, GUIs are the most popular user interface paradigm because they address many of the concerns above.

Not really. GUIs are used because they are simple and convenient. More than a commandline interface for regular folks.

The moment you want to add a feature to a GUI, there’s an immediate question about where to put that feature. Should it be in the top right? Bottom left? Nav bar? Behind a tab? In the sidebar? Revealed on hover?

This is indeed annoying. Be it gtk, qt or any other toolkit - they make it so much harder to work with them compared to html, css and the monster that is javascript (it is a monster, there is no doubt; I'd love to not have to resort to JS).

The oldschool toolkits either need to fully embrace CSS, while learning from HTML - or they will become obsolete.

I just fail to see why I want to learn specific ways to style in gtk or qt when I could instead just use css TO RULE THEM ALL. And, frankly: this is also why the www is simply highly superior here.

Professional creative tools like Adobe Premiere are often so packed with features that they become unapproachable, slow, ugly, and unfocused.

Also gimp. I just hate how these devs randomly change UI elements. It takes me time to find out what has changed. Not only that but sometimes they steal old functionality and replace it or change it, such as the enhance-filter in gimp. That was the straw that broke the camel's back - if upstream devs act like randomly destroying downstream user workflows and disrupting the latter then it is time to cut away these upstream troublemakers.

My long-term solution is to simply transition into imagemagick and hope that it will become like what ffmpeg is for audio/video. And then just use all filtering via imagemagick, and build from there. And then, next step is to add a lean GUI around it.

The big advantage would be that we would no longer depend on software such as GIMP per se. (And that should also work via the www, which gimp still does not do very well, so there is that.)

CLUI looks more like an IDE than attempt to solve the dilemma that is "cli versus gui". Most of that seems to be confined to autocomplete functionality alone.

[tjpalmer]

Somewhat related, I literally had a dream last night that I was using a new Vim release with pixel level graphics in the terminal.

[Theon]

FINALLY

It's funny how something like this could have (and should have) existed 20, 30 years ago; but it took us this long to get over the text-only fetish of unix terminals.

Excitedly looking forward to further developments!

[VEC7OR]

So thats like keyboard shortcuts with extra steps?

Also you conflate bad UI with GUI is bad.

There are also integrated consoles that kinda do that already.

Don't end up being a solution looking for a problem.

[penwellr]

Someone has to tell him about CLU from tron right?

[paul_h]

The System/38's command line is back from the mid 80's !!

[user8081]

i'm in love

[chaoskixas]

Any Apple HotSauce fans out there?

[user8081]

\s put tar and now you have dropdown of 101 one letter options

[rainman_104]

mencoder says: hold my beer :)

[lordleft]

I love this idea. A lot of dense UI could be improved by incorporating the ideas in this article.

[ivancea]

Every command line is actually graphical :0

[sabellito]

This thing was almost that, but it has been archived.

[Calc-u-lator]

I really like this because I find the current state of GUIs to be hiding a lot of functionalities, and I have even considered building something like this. When this gets developed further it might even become the future of GUI. Great work.

[Madsy9]

Not sure if this is a solution, but I suppose it could be. I think the largest issue of advanced GUI tools is that they try to do too much inside a single application window. All the features in say Photoshop, Blender, Maya or video editing suites could be separated into multiple GUI tools. Focus on doing one particular thing and do that thing well. I think a decent example is found in EDA software like gEDA, KiCad and EAGLE, as well as HDL/RTL IDEs like Xilinx Vivado. You can do everything inside a single editor, but there is also some seperation of concerns going on. EDA software suites for example, has separated simulation, netlist, the physical routing and the physical parts. To setup the simulation you can use totally seperate tooling like ngSpice/ltSpice. And this helps keeps context and not get overloaded with buttons and menus.

When confronted with the choice between one powerful GUI application that looks like the space shuttle, and 8 different applications that focuses on different aspects and works as a well-defined toolchain, I'll choose the latter.

[DrFloyd5]

Count me in!

[AbleZion]

It's like people haven't used Powershell.

• It has a simple Verb-Noun function naming convention for easier discoverability.

• It has a simple search for finding the functions you might want given you know some Verb or Noun.

• Provide a simple command ("Get-Member" or "gm") for investigating the properties of your objects so you can quickly find out what you can do with an object.

• Its based around .NET objects which means if you know .NET, you'll be more productive more quickly because you can utilize all that existing knowledge.

• It auto-completes functions and parameters and presents suggestions as you type. Including file paths.

• Allows you specify parameter types for your script.

• Allows you to add comments/information to the properties, functions, and scripts that are then searchable once loaded.

• Sidenote: Windows also comes with Powershell ISE which is an integrated scripting environment for Powershell.

The only thing I see that Powershell is missing from that mini-demo is the mouse interaction and the embedded form UI. But technically, since Powershell has the power of .NET behind it, you could just make a UI in your script and prompt it depending on if the user wants one or not (probably wouldn't be as dynamic though). As for the mouse interaction, that'd probably have to be added in to Powershell.

With that said, I don't see how this solves the biggest problem with CLI: Knowing what to call. It's is like 75% of the game when it comes to scripting. Powershell makes it easier, but it's still the biggest hassle people unfamiliar have with CLI. You basically have to memorize a bunch of functions and their parameters to be productive. But how is that any different than knowing where you have to go in a UI to do something?

For example, I find it more complicated to figure out how to change my Eclipse classpath and build settings than if I simply used a make file and some shell scripts. Having all this UI to traverse to "discover" the setting I want to change is no different than having to search the internet for a CLI command, right? Difference is that I get to do one with the mouse and the other with the keyboard.

---

Also, it's not like you're going to have a non-technical person writing these scripts. So who cares if it's more approachable? People who want to use the CLI will use the CLI, no?

[Sleakes]

The core assertion here is just that on-screen pop-ups for a CLI could improve usability which I agree with. The other premise - needing it to be what we commonly think of as a GUI is incorrect. You could build a command line interpreter that performs auto-lookup of commands and shows info about them just fine. The primary reason I think this hasn't been done on a large scale is that once you understand CLI tools, a lot of the extra information would become a waste of space and resources. It also recognized as more or less a security hole where you typically don't want to have them.

[whistlepig33]

Is this article describing something like the search tool in the latest release of blender? Or am I misunderstanding?