4 ms·

Much of the simplicity which renders multi-command, single-line pipe chains facile to the posix shell user would be lost if the interchange format was any more

Much of the simplicity which renders multi-command, single-line pipe chains facile to the posix shell user would be lost if the interchange format was any more complex than plain text. If you need fields, then separate them with a text delimiter, if you need something more complicated, then maybe you should be using a programming language, or piping between scripts in a language with good text serialization.

CoffeeDregs 16y ago
Putting aside the fancy words, I agree. Given the power of any computer (even those 30 years old), it's enormously powerful to be able to drop one segment of a pipe-chain and look at the output. Funny that I'm facing a similar issue now that some of the server world is going Javascript: "console.log(X);" doesn't necessarily tell you the whole story about X. Exchanging objects is 14% too complicated and anything more than 0% too complicated is too complicated.
- danssig 16y ago
  > it's enormously powerful to be able to drop one segment of a pipe-chain and look at the output. But having more complex objects instead of text doesn't stop us from having that. The objects just need to have some kind of to-string method that the shell uses.
  - wahnfrieden 16y ago
    It does hinder you, since string serializations will usually be an incomplete (or worse, inconsistent) view of an object. With Unix pipes, their string serialization is all that it is.
    - rtaycher 16y ago
      besides the toString if we could get a decent amount of the objects to be public we might have simpler formatting rules.
nwmcsween 16y ago
What simplicity? http://news.ycombinator.com/item?id=2229833 http://news.ycombinator.com/item?id=2229833. Structured data will give much more simplicity as everything (yes everything) requires some form of structure to parse. As a snarky example: for f in /usr/bin; do $f --help; done now tell me that these don't need structure. Also how is structured data any less parsable than unstructured data? It's all text one has a known format the other doesn't
adobriyan 16y ago
> Much of the simplicity It's not simple, it's primitive rounded in the corner. If all you have is raw blobs of data in pipes, you can't grow up when you suddenly realize need for something more complex. See the story with adding UTF-8 BOM support before #! in Linux kernel.
actf 16y ago
I think this depends a lot on how you define simplicity. If we define simplicity as: a plain text interchange format, then clearly by definition a text based shell is simpler. Piping objects instead of text allows a single command to do more, as it can operate on any of the object's properties that it understands. From a user's perspective, I believe, that this is simpler - however I will acknowledge that this is somewhat subjective. For example: The command ls | sort LastWriteTime would print a list of files sorted by their LastWriteTime. The command ls | sort Length would print a list of files sorted by their size. Doing this in bash is more difficult as it requires additional commands to parse the output of ls.

CoffeeDregs 16y ago

Putting aside the fancy words, I agree. Given the power of any computer (even those 30 years old), it's enormously powerful to be able to drop one segment of a pipe-chain and look at the output. Funny that I'm facing a similar issue now that some of the server world is going Javascript: "console.log(X);" doesn't necessarily tell you the whole story about X. Exchanging objects is 14% too complicated and anything more than 0% too complicated is too complicated.

danssig 16y ago
> it's enormously powerful to be able to drop one segment of a pipe-chain and look at the output. But having more complex objects instead of text doesn't stop us from having that. The objects just need to have some kind of to-string method that the shell uses.
- wahnfrieden 16y ago
  It does hinder you, since string serializations will usually be an incomplete (or worse, inconsistent) view of an object. With Unix pipes, their string serialization is all that it is.
  - rtaycher 16y ago
    besides the toString if we could get a decent amount of the objects to be public we might have simpler formatting rules.

nwmcsween 16y ago

What simplicity? http://news.ycombinator.com/item?id=2229833 http://news.ycombinator.com/item?id=2229833. Structured data will give much more simplicity as everything (yes everything) requires some form of structure to parse. As a snarky example: for f in /usr/bin; do $f --help; done now tell me that these don't need structure. Also how is structured data any less parsable than unstructured data? It's all text one has a known format the other doesn't

adobriyan 16y ago

> Much of the simplicity It's not simple, it's primitive rounded in the corner. If all you have is raw blobs of data in pipes, you can't grow up when you suddenly realize need for something more complex. See the story with adding UTF-8 BOM support before #! in Linux kernel.

actf 16y ago

I think this depends a lot on how you define simplicity. If we define simplicity as: a plain text interchange format, then clearly by definition a text based shell is simpler. Piping objects instead of text allows a single command to do more, as it can operate on any of the object's properties that it understands. From a user's perspective, I believe, that this is simpler - however I will acknowledge that this is somewhat subjective. For example: The command ls | sort LastWriteTime would print a list of files sorted by their LastWriteTime. The command ls | sort Length would print a list of files sorted by their size. Doing this in bash is more difficult as it requires additional commands to parse the output of ls.