Hacker News Reader

Comment by fsniper | Hacker News Reader

isn't this a bit hard pushing the shell prompt? Shell's intention is not being a repl or programming environment. It's intended to command basic io operations. (At least whenever it was invented) It has programing like constructs because, that helps while automating.

And because of this, unices come with at least one accompanying higher order scripting language like perl or python.

View on HN

My problem with the shell is that the output of commands is often irregular. You never know what you're going to get. Newlines? Maybe... CRLF? Tab delimited? And it often varies between operating systems and environments. I'd much rather every command dumped XML or JSON that I could parse.

You are right about that. It would be better to have common sense in outputting. Only common sense currently is clear text.

It's hard to consider clear text to be the best option when you're trying to parse file names. What tool will properly generate your delimiters? How do you get your tool (or bash loop) to parse on that delimiter?

Filenames with spaces (or quotes, or unicode characters, or control characters, or...) have wreaked many a seemingly ideal program which needs to iterate over files.

I did not mean that it's best option. I meant current defacto command line minimum is cleartext.

The shell itself is a programming language, it has construct and everything because well, it is a programming language.

I am not a fan of the bourne shell syntax but you can write fairly large programs on it, and the idea itself of using other programs and piping it at the core and heart of unix.

Perl is tied with any modern unix for historical reasons, but it has been criticized for not really following the principles of unix really well.

Yes it's full fledged programming language right now but it was not intended to be. It grew to be one.

Yes, heavily-adopted things are often pressured to grow to their logical conclusions. One logical conclusion of a commandline+commands is REPL+procedures.

One critique of the worse-is-better [1] philosophy (Unix), is the design starts cracking more as it's pushed to scale to its logical conclusion.

Of course, maybe the worse-is-better essay is inapplicable (and the author himself argued both sides under a pseudonym or two). And good design is a matter of degree; we could all critique the-right-thing representatives. But here I think it's a useful model to describe what's going on.

[1] http://www.jwz.org/doc/worse-is-better.html

In this case, we should also argue about, should software evolve into their any of it's logical conclusions?

I'm a cli ninja (at least for many tasks I need to do daily for a measure.) even though I nearly never ever need it's expanded use cases like arrays or process substitution. For example the latest shellshock was the result of an extended use case where implications of it was not well thought.

"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." - Look at the samples: Emacs, MATLAB, Mozilla, Opera, Trillian, and Drupal. Really?

http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law...

Reply on news.ycombinator.com