Hacker News Reader

Comment by fsniper | Hacker News Reader

Isn't it a solution for a non-problem?. I wish people would let alone unix shell and clear text.

edit: new "Avoid Gratuitous Negativity" complience.

If Unix's commandline were critiqued as a REPL (and its commands as functions/procedures), problems like impoverished datatypes would be more commonly considered.

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.

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

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.

I wouldn't say it's a non-problem, but I agree that there is a certain elegance to line-oriented text processing. It's the same design problem as choosing a data structure; sometimes you can get by with a list, but some problems benefit from non-linear data structures.

Problem is not xml, json or any other non linear data structure. It's trying to use shell to manipulate data that it's not intended to.

Shell will always have problems with handling bloated/overheaded data structures. In these situations using intermediary higher level languages would help.

PS: I'm sorry my first post is unintentionally against new rule. I just realized.

what new rule?

http://blog.ycombinator.com/new-hacker-news-guideline

I would say its a non-problem. It's not hard at all to grab columns using awk, do replace using sed and find using grep. Programs that output plain structured text are simple and versatile.

No, it's a solution for a quite big problem (having structured data), that people sidestep and deal with subpar tools and text-mangling, mainly because it would take tons of coordination, effort and work to change the situation.

It was not a problem for nearly 45 years since epoch. Shell is not intended for high level data processing.

Also there are repls or shells intended to have common data structures for input and output. (look into powershell)

>It was not a problem for nearly 45 years since epoch.

What I mean is, this sentense you wrote is content-free. What does it mean "it was not a problem"? That they managed to do and be productive without it?

In the same sense not having computers was not a problem for nearly 2 millenia since Christ. They've managed to get by without them.

Not having something is not a problem in general, when you don't know what you're missing. You only see the problem when you compare the faster and more productive workflow and the possibilities you'd get if you had something compared to coping without it.

Which is how inventions are made, compared to "well, what we got works for us".

>Shell is not intended for high level data processing.

That's a limitation of the shell, that could very well be bypassed, not some physical law.

One could imagine shells very well intended for high level data processing (and in fact people have built some of those -- heck, even the Lisp Machines qualify).

If you have ever used the -print0 option to find, and the -0 option to xargs, you know that this is not really a non-problem.

Agreed. If you want to iterate over blobs of Unicode text which contains a lot of various formatting (such as file names), then you absolutely need something other than tabs, commas, and spaces to delimit elements.

Even -0 fails with some file contents due to null bytes embedded in Unicode characters.

>Isn't it a solution for a non-problem?

Perhaps this is for enterprise shells, so yes :-)

Reply on news.ycombinator.com