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

61–70 of 101 posts

Re: Rich Command Shells

#61

Post by rsync »

aduitsis wrote: post #20
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…

"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."

Is that true ? For instance, I am not aware that (for instance) the OSX terminal app does mouse reporting or geometry reporting.

Does default xterm ?

Re: Rich Command Shells

#62

Post by felixgallo »

mwcampbell wrote: post #55
felixgallo wrote: post #52

Earlier quoted context omitted.

so in one corner: the ability to compose small, comprehensible functions with data streams, delivering staggering riches to the world. in the other corner: the complaint that sometimes, people can put carriage returns in their filenames and screw up the output of `ls -1`. With no suggestion of what would replace composed functional streams. Nice try Lennart.

> in the other corner: the complaint that sometimes, people can put carriage returns in their filenames and screw up the output of `ls -1`. With no suggestion of what would replace composed functional streams. How about functions that operate on data structures such as lists and maps? These can include generic functions that can slice and dice data structures regardless of what type of data those structures contain.…

The unix dataset already works on list and map data structures.

lists: ls -1 | wc -l

maps: ps -ef | grep 'tobekilled' | grep -v grep | awk '{ print $2 }' | xargs kill

would unix be better if it were

cwd.files.count

and

processes.filter{name = 'tobekilled'}.map(kill)

?

maybe for the newbie who paradoxically already understands functional and object-oriented programming, I'll grant.

But the 'pipe' ("this is a bucket brigade") has always been pretty easy for people to grasp.

The Lennart bit was a joke. The OP's post was so histrionically overwrought that I responded sardonically. Apologies if you were offended.

Re: Rich Command Shells

#63

Post by rsync »

BruceM wrote: post #2

I will probably write a "More Rich Command Shells" to cover things I missed here that are important in some way (like Apple's MPW). The next thing I want to write though is about building something that has a command shell UI today and thinking about how to do so in a flexible way that works with multiple output devices.

Please do - I liked this first article very much and would look forward to a follow-up.

Re: Rich Command Shells

#64

Post by anon1385 »

rsync wrote: post #57
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…

"Like the C memory and integer model makes writing secure C code borderline impossible, the Unix "single pipe of bytes that defaults to being commands" paradigm makes writing secure shell scripts borderline impossible. Unix needs to be taken out back and shot." What alternative do you advocate/propose ? Genuinely curious ...

For the interactive general purpose data munging and quick execution of simple commands that the shell is best at, I really don't know what a better system would look like. It seems like a really hard problem. Anything purely text based ends up being fairly cumbersome to use for simple commands if it has to use real data structures (consider having to type (["a", "b"]) instead of a b to pass arguments with json style syntax or whatever). At least that was my experience of trying to write a very simple shell. There are a hell of a lot of people a hell of a lot smarter than me though.

It seems to me that a lot of shell scripts could be ported to other languages. Does DHCP on Linux need to use a shell script instead of python or something like that? The benefits of the shell grammar and semantics which are designed to make interactive use easy seem more like hindrances in a lot of those kinds of use cases. I assume it's largely done to make it easier for sysadmins to customise things. If I was a sysadmin I'd much rather learn python (and feel like I actually understood it) than the crazy byzantine grammar of bash. Maybe that's why I'm not a sysadmin.

This paper by Rob Pike might also be of interest: http://doc.cat-v.org/bell_labs/structural_regexps/se.pdf

>The current UNIX® text processing tools are weakened by the built-in concept of a line.

Re: Rich Command Shells

#65

Post by vinodkd »

the-tomster wrote: post #56
vinodkd wrote: post #42

Earlier quoted context omitted.

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.

The problem there is that every application needs to implement a macro recorder, and every application needs to implement history and undo. With small programs that all handle text the shell takes care of history and automation, while the other programs can focus on solving a new problem. Why have macros and history reimplemented badly by every application when one application could do it well?

True, such a feature should really be system-wide - something like OSX's Automator, maybe.

That doesnt take away from the point, however, that GUI actions can be stored in history, composed, etc.

Re: Rich Command Shells

#66

Post by mw42 »

pyre wrote: post #51
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…

> Take a read of some of the earlier threads on HN about Shellshock, and you will find numerous people blaming Apache for not "escaping" the data it was putting in a shell variable. It seems to me that this is the result of Cargo Cult Programming. People know that SQL strings, and user input need to be 'escaped,' so they just think "Obviously this needs to be escaped too! It's user input!" Yet they don't realize that…

SQL injection is not avoided by escaping arguments, but by never mixing the command and user supplied arguments in the first place. The equivalent to your example would be

  execlp("mv", "mv", src, dest, NULL);
which does not rely on the shell to try to untangle your arguments from a single string.

Edit: Fixed, thanks!

Re: Rich Command Shells

#67

Post by lispm »

BruceM wrote: post #8
mozmark wrote: post #7

If you found this interesting, you may also like GCLI (as featured in the Firefox dev tools command line - or you can play with it here: http://mozilla.github.io/gcli/ ).

GCLI is interesting, but I didn't mention it because I feel like it focuses more on the issue of command parsing / completion. That said, that's a great topic to cover! I think GCLI does a pretty good job of command completion. The Lisp Machine did as well. I have friends who love some of the router CLIs, but not sure which one(s).

Cisco's IOS is an example.

Re: Rich Command Shells

#68

Post by vram22 »

richardjdare wrote: post #24
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…

That's a very interesting question. I'd guess that the technical decisions that differentiated early unix from the lisp machines etc. were based on hardware and cost limitations.(the development of unix is something I'd be interested in reading more about) Then as unix took off, these technologies became entrenched, with a kind of apologetics developing amongst users who liked those systems, or never used anything el…

>the development of unix is something I'd be interested in reading more about

http://www.levenez.com/unix/ has a good amount of info and links on the history of Unix and the people who worked on it. I came across the site a while ago and browsed it some. Interesting stuff, some of it at least. Recursively traversing the links should give even more.

Re: Rich Command Shells

#69

Post by Crito »

rsync wrote: post #61
aduitsis wrote: post #20

Earlier quoted context omitted.

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…

"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." Is that true ? For instance, I am not aware that (for instance) the OSX terminal app does mouse reporting or geometry reporting. Does default xterm ?

Yes. For instance, Vim necessarily knows how large the terminal it is in is. Vim also supports mouse input, allowing you to click around in different windows and whatnot.

Re: Rich Command Shells

#70

Post by anon1385 »

felixgallo wrote: post #62
mwcampbell wrote: post #55

Earlier quoted context omitted.

> in the other corner: the complaint that sometimes, people can put carriage returns in their filenames and screw up the output of `ls -1`. With no suggestion of what would replace composed functional streams. How about functions that operate on data structures such as lists and maps? These can include generic functions that can slice and dice data structures regardless of what type of data those structures contain.…

The unix dataset already works on list and map data structures. lists: ls -1 | wc -l maps: ps -ef | grep 'tobekilled' | grep -v grep | awk '{ print $2 }' | xargs kill would unix be better if it were cwd.files.count and processes.filter{name = 'tobekilled'}.map(kill) ? maybe for the newbie who paradoxically already understands functional and object-oriented programming, I'll grant. But the 'pipe' ("this is a bucket br…

I'm honestly not sure if your post is meant to be satire or not.

>lists: ls -1 | wc -l

The computer has taken a real array (probably an array in C), joined all the items together into one big string using magical characters as dividers, and then split it again on those magic characters to try and reconstruct the metadata that it threw away. I think the problem is pretty obvious and well known.

>would unix be better if it were cwd.files.count

Well, at least that is going to give you the correct result. Correctness seems like it should be pretty important, no?

Are you really arguing for shells being easier to learn using an example of a complicated command with 4 pipes, 2 different quoted strings, several single letter arguments, and that requires implicit knowledge about the structure of the output from several commands? Compared to a much shorter, simpler, type safe, and self documenting bit of code?

Also, yes my original post was hyperbolic. That was because I was responding to a histrionically overwrought post claiming that unix is perfect.

Post reply on HN