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

71–80 of 101 posts

Re: Rich Command Shells

#71

Post by a3n »

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

Earlier quoted context omitted.

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.

But right now, they aren't. :)

Re: Rich Command Shells

#72

Post by vertex-four »

jcheng wrote: post #60
rsync wrote: post #57

Earlier quoted context omitted.

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

I've hardly used it myself, but apparently Microsoft's PowerShell pipes typed objects between processes: http://technet.microsoft.com/en-us/library/dd347728.aspx

Actually, not between processes - all Powershell commands run in the same address space as the shell, and must be implemented in .Net. I don't think you can easily write an external process which takes a Powershell object directly as input.

Re: Rich Command Shells

#73

Post by felixgallo »

anon1385 wrote: post #70
felixgallo wrote: post #62

Earlier quoted context omitted.

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

So your argument is that ls is not efficient enough in its implementation, but that you would suggest replacing all of that with an object model that implements the equivalent of Ruby's enumerable. Got it.

Shell is easy to learn because people innately understand "and then do this with it". You can start with ls, get to ls -1, then think, I want to count these, and get to wc -l.

Yeah, there are exceptions -- e.g., files with newlines in their name -- and yeah, the interface could use some cleanup. But pedagogically, I can assure you that teaching people shell is easier than teaching them map-reduce.

Re: Rich Command Shells

#74

Post by hderms »

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 agree with you to some degree. It's incredibly easy to write insecure software if it ever touches a shell.

Re: Rich Command Shells

#76

Post by wtetzner »

felixgallo wrote: post #73
anon1385 wrote: post #70

Earlier quoted context omitted.

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

So your argument is that ls is not efficient enough in its implementation, but that you would suggest replacing all of that with an object model that implements the equivalent of Ruby's enumerable. Got it. Shell is easy to learn because people innately understand "and then do this with it". You can start with ls, get to ls -1, then think, I want to count these, and get to wc -l. Yeah, there are exceptions -- e.g., fi…

I didn't see any argument about performance. I only saw an argument about correctness.

Re: Rich Command Shells

#77

Post by Gracana »

a3n wrote: post #35
Dewie wrote: post #30

Earlier quoted context omitted.

It's perfectly possible for a GUI to have a command history, if the GUI is just a front end to a CLI. Then you can click around when you want to explore, and can go to over to the CLI when you know what you want to do and want to establish a more streamlined workflow. Or even click around and do stuff, and then extract a script from that recent history of clicks and interactions. Some R (programming language) GUI fro…

Not sure why, but I'm reminded of the old WordPerfect dual mode, with rendered text on top and raw mode on the bottom. It was a little annoying because sometimes that was the only way to get something done, but it was also fairly powerful. It would be kind of cool to have gui interfaces (including the general desktop gui) have something like this dual mode.

Some CAD programs do this. You could execute a command with fully defined parameters to make something happen, or maybe you'd execute the command and enter the parameters by selecting things in the GUI when prompted. It is a very powerful way to work, but the learning curve is often steep.

Re: Rich Command Shells

#78

Post by nitrogen »

mw42 wrote: post #66
pyre wrote: post #51

Earlier quoted context omitted.

> 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!

Similarly, no amount of escaping would protect you from Shellshock.

P.S. Doesn't execlp() require a NULL at the end of the parameter list?

Re: Rich Command Shells

#79

Post by nitrogen »

anon1385 wrote: post #64
rsync wrote: post #57

Earlier quoted context omitted.

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

The reason the shell is used everywhere is because it's guaranteed to be installed (although DHCP used Bash explicitly), is much faster to start and run a simple script than Python, and its syntax is the command line that everybody should be familiar with.

Re: Rich Command Shells

#80

Post by deeviant »

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…

I agree with you and disagree at the same time.

Command line interfaces are extremely powerful, simple to implement, extend and leverage, but, GUI's have their own advantages mainly in information density, context clues, and ease of operation. There is a world for them to both live in, but I would disagree with OP's approach of bring graphics to command line and suggest the approach of bringing command lines to GUIs.

I have already embedded a command line terminal in several GUI's I've built for industrial machines. The users can see the corresponding command line command pop up in the terminal when they click a GUI button and are free to type commands into the terminal. They can also define a script or batch of commands and easily assign it to a GUI button.

It was amazingly efficient for engineers to work with prototype machines whose functionality and controls were constantly in flux.

Downsides are that exposing a terminal to a potentially non-expert operator is a potentially dangerous, and I had to spend a good deal of time validating and sanitizing inputs(and risk missing something).

In the end, the terminal was removed in the production GUI, but was extremely helpful in the creation of a functional GUI that worked for the operator, rather than the opposite. In the case where the operator is always going to be an expert and is working with a complicated or constantly changing process, I could see a CLI/GUI interface working well.

Post reply on HN