Command Lines | Hacker News Reader

Command Lines

directwebremoting.org

The only good ideas I saw in this post were shell-known argument semantics (perhaps via standardized --help output) and pipe inspection. The second idea is already available with the pv command.

> What other things could we do to trick out the command line?

The reason I use a command line is specifically because it's not tricked out.

I agree - the more 'tricked out' it is, the more cpu it hogs. The computer I have now is practically a supercomputer compared to what I worked on 10 years ago, and yet my workflow is still interrupted when my system practically freezes so that it can switch to a different window. I would so much rather work in an ugly environment if I could just be in control of where my computing power gets spent.

bash-completion does the argument thing as well.

One of the points the article makes is not that it can be done (by whatever shell) but that any context dependent completion that happens with current shells needs to manually track details of each command to some degree.

I don't even buy the pipe inspection idea. We can already do it with tee, and to be honest I only ever use that because I need to persist the data mid-chain, rather than inspect it.

As he mentions, zsh also knows argument semantics. So does bash. He never explains how Bespin implements this feature, but I don't see how you can get a significant improvement on the way these shells do it (which he says is probably not the best way) without abandoning the standard toolchain altogether. (zsh uses scripts to do it, which can use --help output if desired. ISTR that they're rather complicated, but then they're also rather powerful. I think they become much simpler in degenerate cases, but I've only ever dabbled and that was over a year ago.)

For the pipe inspection, I got the impression he might have been talking about "look at the data that's being sent". Which can be done with tee, but both that and pv require that you insert them into the chain beforehand. I think there's room for improvement there. (I suspect it's possible to do something with /proc/$$/fd, but I'm not sure and I wouldn't know how.)

I do think shells and terminal emulators should interact better with each other. I often wish my rxvt knew about my GNU screen windows, so that the scrollbar and mouse wheel worked consistently and I could navigate tabs on the status bar by clicking on them.

The reason I use a command line is specifically because it's not tricked out.

That's valid, but the reason I use one is that it lets me get certain tasks done much faster than I can get them done with the gui. I don't think we've reached the pinnacle of the form, though -- I'd much rather we could expand the areas where it's the fastest way to get the job done.

One weakness with the standard unix cli is in discoverability. The MPW environment for the original Mac had a great system for this -- option-enter on any command would bring up a gui with that allowed you to build up the options and flags. It was the perfect mix of GUI: invisible when you didn't need it, but vastly easier for the first use of an unfamiliar command.

That said, I think the people who think like you are in the majority of CLI users, so innovations like these will struggle to get traction. Sucks to be me :)

I agree - the CLI's biggest weakness is discoverability, and the feature you describe is nice way to address it. And it's the right way to add a frill - there if you need it, invisible if you don't.

Bespin's interface, on the other hand, is just obnoxious. It's great eye candy, but there's so much visual noise and wasted space that I could easily see it affecting productivity. I'll call it eye diabetes.

eyeabetes?

Or as Wilford Brimley might say, "eyeabeetus."

I agree that the main weakness of the unix cli is in discoverability. This would require at least a limited standard interface (for declaring options and help) but it would not be enought for specific usages. So the overkill solution is real introspection abilities (from what I understood MS did this thanks to .net in its cli), but you loose simplicity and text everywhere.

Every AIX admin has used SMIT in a similar way (tho' it is curses rather than a full GUI).

"that's valid, but the reason I use one is that it lets me get certain tasks done much faster than I can get them done with the gui."

May I introduce you to goosh.org for web-search?

So it's an "improvement" to have half your screen taken up by "chrome" with little buttons that you have to switch to the mouse to interact with? I'll pass.

A better example of integration like this is eshell:

http://www.xemacs.org/Documentation/packages/html/eshell_1.h...

Huh, half the time, I use shell over ssh, on servers that do not even have X installed. How would all that eye-candy in Bespin be rendered? In ASCII?

I can't imagine using this Bespin thing. Looks completely counter productive. Might as well just use GUI tools in conjunction with a plain ole' CLI. (best tool for whatever particular job you're doing -- the way most people use CLIs these days I suspect)

I am quite found of the fish shell as a slightly more modern approach to command lines. Having tab completion on apt-get for example is a huge time saver for me since I can't seem to remember exact package names to save my lives.

This is nice, but seeing no mentions of Hotwire or PowerShell leaves me with a feeling of NIH.

I can't use Windows PowerShell on my Mac, and Hotwire also seems difficult to install because it requires GTK+. Bespin is doing something that I've been thinking about for some time - using the browser for a "desktop" UI. Maybe they could reuse the Hotwire backend, though.

I think the point of this article was to show pictures of rounded corners. Your shell needs those, don't ya know...

Reply on news.ycombinator.com