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

41–50 of 101 posts

Re: Rich Command Shells

#41

Post by rkrzr »

pjmlp wrote: post #21
astrobe_ wrote: post #18

Earlier quoted context omitted.

> 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 emu…

Except REPLs are CLIs on steroids. UNIX shells can only seem powerful for those that never had the luxury of playing with Smalltalk, Lisp, Mesa/Cedar or Oberon environments. Where you have a CLI and GUI experiences interact together to create a composable workflow experience. Where I can do function composition on my REPL over data that I just selected with my mouse on a word processor, just to give a possible exampl…

IPython already makes for a pretty good bash/zsh/etc replacement for many things. You can get a GUI using the IPython notebooks as well. While I haven't made the switch completely yet, I always keep an IPython session around in an extra tab, since it is very often just much simpler to do something there than in bash.

Re: Rich Command Shells

#42

Post by vinodkd »

a3n wrote: post #25
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…

For me, because I can't compose strings of gui clicks into an ad hoc list of transformations on text. And I do that a lot in the shell. There is also no command history for my gui clicks; once you've clicked on something, there's no way to reuse that click in some slightly different way.

well, not at that minute level, but every application worth its name has an undo log - and that's a pretty close functional equivalent, IMO.

And: applications that have Macro recorder features (Office and many text editors) allow you to actually record your actions - clicks or otherwise - into code that can be rerun.

Re: Rich Command Shells

#43

Post by jschwartzi »

anon1385 wrote: post #34
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…

Text isn't the universal interface in Unix, byte streams are. You can quite happily send non-textual control characters and such around in Unix, or pipe data containing NULLs from one process to another. 'Text' is a very seductive abstraction, but it's one of the most brutal to work with once you start interacting with the real world and have to give up on ascii and deal with encodings and unicode and so on. Putting…

I would not be half as capable of troubleshooting in my work as I am if I couldn't parse random byte strings on the command line. That alone is why I use Unix for embedded development. Powerful things are often dangerous. For instance, consider nuclear power, motor vehicles, rocket engines, medicine, plastics, et. al..

So how do you provide the same level of capability as C and UNIX but without mixing data and commands? Is there some alternative paradigm that is just as powerful but safe?

Re: Rich Command Shells

#44

Post by BruceM »

userbinator wrote: post #31
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…

It's also far easier to help someone over the phone/other "blind" medium of communication with a CLI than a GUI, as you can tell them to press keys on the keyboard and read back the output that shows up, instead of asking them to find and click on things - followed by their thousand-word response (a picture is worth...) describing in exquisite detail everything on the screen except for the exact information you wante…

Okay.

But sometimes, the logical output format for the response from a command is going to be an image. And sometimes, you'd like to view that inline with your commands in the terminal.

That isn't that radical a suggestion. And it doesn't turn anything into a big old GUI suddenly. :)

Re: Rich Command Shells

#45

Post by BruceM »

jschwartzi wrote: post #43
anon1385 wrote: post #34

Earlier quoted context omitted.

Text isn't the universal interface in Unix, byte streams are. You can quite happily send non-textual control characters and such around in Unix, or pipe data containing NULLs from one process to another. 'Text' is a very seductive abstraction, but it's one of the most brutal to work with once you start interacting with the real world and have to give up on ascii and deal with encodings and unicode and so on. Putting…

I would not be half as capable of troubleshooting in my work as I am if I couldn't parse random byte strings on the command line. That alone is why I use Unix for embedded development. Powerful things are often dangerous. For instance, consider nuclear power, motor vehicles, rocket engines, medicine, plastics, et. al.. So how do you provide the same level of capability as C and UNIX but without mixing data and comman…

Watch the Mathematica-backed StrangeLoop 2014 keynote by Stephen Wolfram. That's one way to think about it. There are others like how things work on the Lisp Machine (and somewhat similarly in CLIM).

Re: Rich Command Shells

#46

Post by mwcampbell »

anon1385 wrote: post #34
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…

Text isn't the universal interface in Unix, byte streams are. You can quite happily send non-textual control characters and such around in Unix, or pipe data containing NULLs from one process to another. 'Text' is a very seductive abstraction, but it's one of the most brutal to work with once you start interacting with the real world and have to give up on ascii and deal with encodings and unicode and so on. Putting…

> Putting commands and data inline is a recipe for disaster and a million command injection exploits. The Unix philosophy has broken the minds of generations of programmers. It leads them to doing things like concatenating strings to build SQL queries or doing IPC with ad-hoc regex-parsed protocols or using a couple of magical characters to indicate that the contents of a variable should be parsed and executed instead of just stored.

Yes! And then to compensate, they have to "sanitize" untrusted input to their systems. I had a meeting yesterday with a developer and a project manager at an organization that wants to work with my company to integrate one of our products with one of theirs. I mentioned the possibility of submitting some data in JSON format to a web API on their end, and the project manager asked about the risk of code injection attacks, by which he apparently meant SQL injection. I had to assure him, based on my knowledge of their tech stack (Node.js, CouchDB, and naturally, JSON) that code injection wouldn't be an issue. My point is that the common abuses of strings by Unix and web developers have led to well-known and widely feared security vulnerabilities which just don't exist in software that's built on a foundation of properly structured data.

See also this classic by Glyph Lefkowitz:

https://glyph.twistedmatrix.com/2008/06/data-in-garbage-out....

Re: Rich Command Shells

#47

Post by vinodkd »

Slightly off-topic, but the recent surge in responsive UI had me thinking thus: If we are now driven to merge UI logic across different graphical devices, can we think of apps that span both textual and graphical devices?

After all, the core functionality of the application remains the same. To use a simple example: when you search for a product online, get a search result list and then select one from the list, couldnt this flow be modeled just the same in both gui and text interfaces?

I'm thinking back to the turbo-pascal style applications of the past that produced full-blown IDEs in text, or the wordstars/wordperfects of yore: the UI model that sits behind those apps cannot be much different in principle from the modern day equivalents.

Even farther back, there was a time (and probably still is for college assignments) when cli applications had a prompt-read user input-respond cycle, replete with text-based choices to select from and so forth.

What if we were to merge the two worlds instead of trying to get one to confirm to the other?

Re: Rich Command Shells

#48

Post by cpach »

lispm wrote: post #40

If you come to Freiheit.com next week (16. Oct 2014) to the Clojure User Group Meeting in Hamburg/Germany, I'll demo the Dynamic Windows user interface of a real Symbolics Lisp Machine. Including its command shell called 'Dynamic Lisp Listener'. http://www.meetup.com/ClojureUserGroupHH/events/207314372/

Cool! Do you know if the demo will be recorded?

Re: Rich Command Shells

#49

Post by tbrownaw »

userbinator wrote: post #31
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…

It's also far easier to help someone over the phone/other "blind" medium of communication with a CLI than a GUI, as you can tell them to press keys on the keyboard and read back the output that shows up, instead of asking them to find and click on things - followed by their thousand-word response (a picture is worth...) describing in exquisite detail everything on the screen except for the exact information you wante…

Clearly, the proper solution for this is pervasive hi-def videoconferencing. :)

Re: Rich Command Shells

#50

Post by lallysingh »

josephg wrote: post #5

I miss TermKit[1]. Its a real shame that the developer abandoned it after it got a lot of hype. There's a huge opportunity for someone to come along and make either a new terminal encoding which allows rich, interactive output or extend VT somehow to which allows the same. If you could extend the terminal protocol, you might even be able to get it to work over SSH. HTML+JS seem like the obvious way to do it - even th…

> HTML+JS seem like the obvious way to do it > I think the hardest part would be figuring out how to reconcile browser-like UI events and file streams.

How about Chrome Apps? They've got a mix of file I/O capability and HTML/JS.

Post reply on HN