Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rich Command Shells

waywardmonkeys.org

Post reply on HN
Print view View original

11–20 of 101 posts

Re: Rich Command Shells

#11

Post by akavel »

Given all of that, and also Oberon -- '80s too, and even the Engelbart's Demo -- '68!, I totally every day wonder and can't understand why in 2010's all of the "modern" OSes still provide the developer just with text-only consoles??... okay, maybe for end-users there was a jump (in interfaces and features), and maybe it was significant indeed (movies editing, 3d modelling/sculpting, possibility of instant communication with significant fraction of all the people in the world, to bring up some). But it still feels like even for them, some things were there, and now are not (sorry for vagueness, but I don't have much time now to think about examples, unfortunately. When I'm gonna finally start this blog thing, one day...).

Any theories, anyone? I'm really curious. Still believe this can be improved, and work on some ideas in my free time, but I often wonder why I have to, and I can't already use those beautiful ancient features?

Re: Rich Command Shells

#12

Post by qznc »

tubelite wrote: post #10

If I might plug a rich command shell I'm developing: http://pigshell.com (Source at https://github.com/pigshell/pigshell ) It provides - A shell for the web. Runs in the browser, pure client-side. - File-like abstraction for URLs and other entities exposed by web APIs - Unix-like style of composing commands using pipes. - Visualization using HTML For instance, cp -r /gdrive/ /home will backup the contents of your Goo…

Interesting. Why do you think that files are good abstraction for a web shell?

Re: Rich Command Shells

#14

Post by pjmlp »

akavel wrote: post #11

Given all of that, and also Oberon -- '80s too, and even the Engelbart's Demo -- '68!, I totally every day wonder and can't understand why in 2010's all of the "modern" OSes still provide the developer just with text-only consoles??... okay, maybe for end-users there was a jump (in interfaces and features), and maybe it was significant indeed (movies editing, 3d modelling/sculpting, possibility of instant communicati…

Because many seem to be willing to go back to the 70's (vi/sh) instead of embracing the progress you mention.

Since I discovered UNIX, with Xenix in 1994 followed by many other variants, I always looked for ways to replicate such workflows in UNIX.

At the end of the day, Mac OS X and Windows communities are more welcoming to such ways of working.

Re: Rich Command Shells

#15

Post by tubelite »

qznc wrote: post #12
tubelite wrote: post #10

If I might plug a rich command shell I'm developing: http://pigshell.com (Source at https://github.com/pigshell/pigshell ) It provides - A shell for the web. Runs in the browser, pure client-side. - File-like abstraction for URLs and other entities exposed by web APIs - Unix-like style of composing commands using pipes. - Visualization using HTML For instance, cp -r /gdrive/ /home will backup the contents of your Goo…

Interesting. Why do you think that files are good abstraction for a web shell?

It's the old "if you have a hammer, everything looks like a nail". Since I'm a filesystem engineer, everything looks like a file :)

Seriously though: the file is a powerful and familiar abstraction. The primary motivation for pigshell was to provide a common minimum abstraction across different web APIs which would enable basic data movement and backup.

That said, pigshell commands actually pass objects across the pipeline; files are a kind of object. For instance,

  cat http://pigshell.com/sample/life-expectancy.html | table2js -e "tr" foo country data | head | printf
extracts data from an html table, converts them to plain Javascript objects and prints their json representation.

Re: Rich Command Shells

#16

Post by zorbo »

Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It's compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it.

The command line works with text. The command line remains the best interface I've ever used. It's user friendly, composable and available everywhere. It's easy to automate and easy to extend.

I wish the "command line with pictures" idea would just go away already. It adds nothing for the general public. I can already view pictures on remote machines with X forwarding.

Command line with pictures never made it, because there are ten competing standards. With text, everybody just agreed on ASCII and now Unicode/UTF8. Text has hundreds of ugly clutches on top of it (Extended ASCII, ANSI, Escape codes, etc, etc). It still works. It's still simple. It has its problems, but nowhere near as many problems as GUIs.

Those who don't understand Unix are doomed to reimplement it... poorly.

Re: Rich Command Shells

#17

Post by akavel »

pjmlp wrote: post #14
akavel wrote: post #11

Given all of that, and also Oberon -- '80s too, and even the Engelbart's Demo -- '68!, I totally every day wonder and can't understand why in 2010's all of the "modern" OSes still provide the developer just with text-only consoles??... okay, maybe for end-users there was a jump (in interfaces and features), and maybe it was significant indeed (movies editing, 3d modelling/sculpting, possibility of instant communicati…

Because many seem to be willing to go back to the 70's (vi/sh) instead of embracing the progress you mention. Since I discovered UNIX, with Xenix in 1994 followed by many other variants, I always looked for ways to replicate such workflows in UNIX. At the end of the day, Mac OS X and Windows communities are more welcoming to such ways of working.

But, again, why? this can still have many reasons: not willing because of technological obstacles? complexity? because they shown in fact to be somehow worse? (e.g. pure text easier to read, mold, and more universal?) because of some social obstacles? (if yes, of what kind?) what else could that be? (those are just a few of my random quick theories, have I described all possibilities?)

edit: the comment by zorbo seems an interesting answer to my question, but I'm still not 100% convinced; also, I must still ask how can we be sure we're not victims of a text-mode "Stockholm Syndrome" in this regard?

Re: Rich Command Shells

#18

Post by astrobe_ »

pjmlp wrote: post #14
akavel wrote: post #11

Given all of that, and also Oberon -- '80s too, and even the Engelbart's Demo -- '68!, I totally every day wonder and can't understand why in 2010's all of the "modern" OSes still provide the developer just with text-only consoles??... okay, maybe for end-users there was a jump (in interfaces and features), and maybe it was significant indeed (movies editing, 3d modelling/sculpting, possibility of instant communicati…

Because many seem to be willing to go back to the 70's (vi/sh) instead of embracing the progress you mention. Since I discovered UNIX, with Xenix in 1994 followed by many other variants, I always looked for ways to replicate such workflows in UNIX. At the end of the day, Mac OS X and Windows communities are more welcoming to such ways of working.

> Because many seem to be willing to go back to the 70's (vi/sh) instead of embracing the progress you mention.

Just because it's old, doesn't mean it's only about nostalgia.

Besides, I for one can't have this kind of nostalgia because in the '70, my fingers were a bit too short.

There is something extremely convenient to be able to use the same environment everywhere, with minimum prerequisites, because terminal emulation software is very common (probably as common as Web browsers).

I also find it more natural to deal with the system with a CLI when you spend your time editing source code or doing sysadmin stuff; it doesn't break the flow. Of course it's totally different if you're a graphic artist or a Web developer.

Sometimes CLI makes more sense, sometimes GUI makes more sense. But accusing people of being stuck in the past, that makes no sense.

Re: Rich Command Shells

#20

Post by aduitsis »

zorbo wrote: post #16

Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It's compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it. The command line works with text. The command l…

Exactly as you indicate, even in "classic" terminals we have features like unicode support, color, geometry reporting, mouse reporting, window title manipulation, arbitrary cursor movement, etc. All these are in widespread use today. These features could not have been implemented in a real tty, but nowadays I think it makes sense to have them. Maybe some are a little kludge-ish, but are we really arguing about their usefulness?

So why shouldn't we have a couple of extra escape sequences where the terminal could, e.g. draw an arbitrary bitmap? You are right, that would certainly require some sort of standard becoming prevalent, but why would a little extra capability (that doesn't break compatibility) be a bad thing?

Post reply on HN