3 ms·

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.

by 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
    - fsniper 12y ago
      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_of_software_envelopment http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law...
meddlepal 12y ago
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.
- fsniper 12y ago
  You are right about that. It would be better to have common sense in outputting. Only common sense currently is clear text.
  - falcolas 12y ago
    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.
    - fsniper 12y ago
      I did not mean that it's best option. I meant current defacto command line minimum is cleartext.

by fsniper 12y ago

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
  - fsniper 12y ago
    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_of_software_envelopment http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law...

meddlepal 12y ago

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.

fsniper 12y ago
You are right about that. It would be better to have common sense in outputting. Only common sense currently is clear text.
- falcolas 12y ago
  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.
  - fsniper 12y ago
    I did not mean that it's best option. I meant current defacto command line minimum is cleartext.