5 ms·

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.

by fsniper 12y ago

z1mm32m4n 12y ago
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.
- fsniper 12y ago
  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.
  - zer0rest 12y ago
    what new rule?
    - fsniper 12y ago
      http://blog.ycombinator.com/new-hacker-news-guideline http://blog.ycombinator.com/new-hacker-news-guideline
- goalieca 12y ago
  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.
calibraxis 12y ago
If Unix's commandline were critiqued as a REPL (and its commands as functions/procedures), problems like impoverished datatypes would be more commonly considered.
- fsniper 12y ago
  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.
  - zer0rest 12y ago
    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.
    - fsniper 12y ago
      Yes it's full fledged programming language right now but it was not intended to be. It grew to be one.
      - calibraxis 12y ago
        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 http://www.jwz.org/doc/worse-is-better.html
amelius 12y ago
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.
- falcolas 12y ago
  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.
imron 12y ago
>Isn't it a solution for a non-problem? Perhaps this is for enterprise shells, so yes :-)
coldtea 12y ago
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.
- fsniper 12y ago
  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)
  - coldtea 12y ago
    >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).

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.

by fsniper 12y ago

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.

z1mm32m4n 12y ago

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.

fsniper 12y ago
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.
- zer0rest 12y ago
  what new rule?
  - fsniper 12y ago
    http://blog.ycombinator.com/new-hacker-news-guideline http://blog.ycombinator.com/new-hacker-news-guideline
goalieca 12y ago
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.

calibraxis 12y ago

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

fsniper 12y ago
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.
- zer0rest 12y ago
  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.
  - fsniper 12y ago
    Yes it's full fledged programming language right now but it was not intended to be. It grew to be one.
    - calibraxis 12y ago
      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 http://www.jwz.org/doc/worse-is-better.html

amelius 12y ago

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.

falcolas 12y ago
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.

imron 12y ago

>Isn't it a solution for a non-problem? Perhaps this is for enterprise shells, so yes :-)

coldtea 12y ago

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.

fsniper 12y ago
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)
- coldtea 12y ago
  >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).