4 ms·

It's impossible to “redesign” shell fundamentals in Unix because it will be incompatible with all other old-style utilies. And classic pipes are not so bad as P

It's impossible to “redesign” shell fundamentals in Unix because it will be incompatible with all other old-style utilies. And classic pipes are not so bad as PS evangelists saying. PS “objects” are basically .Net objects and you can't easily write python or perl applications compatible with PS features.

coldtea 12y ago
>It's impossible to “redesign” shell fundamentals in Unix because it will be incompatible with all other old-style utilies So? For one, you could redesign the basic utilities too. Or offer a sumplementary revamp versions of some. Second, you could use them in a less capable "text mode" and still get all the other benefits from the new shell. >And classic pipes are not so bad as PS evangelists saying. Well, they are not that relevant to 2014 either.
skrebbel 12y ago
> It's impossible to “redesign” shell fundamentals in Unix because it will be incompatible with all other old-style utilies. This is not true. In fact, despite its many flaws, PowerShell did solve this particular one: any object stream can also be rendered as a string. This is exactly what happens when you just type `ls` into a PowerShell window. I can completely imagine that a UNIX `ls` implementation would return a stream of objects (not necessarily .NET objects - just some runtime's native object format) that, when called .toString() on, would return exactly the same textual output as common UNIX `ls`. Then, you'd need a way to differentiate between two pipes. Maybe with syntax (i.e. | for string pipes, [] for object pipes, whatever) or maybe through magic ("hey, these two processes both have the capability to pipe objects instead of characters, let's tie them together as objects" somewhere at the shell level). I'm not sure how feasible either are, but I'm sure you can imagine that this problem could be solved. Then, if the shell sees that whichever process accepts the output of `ls` doesn't understand objects, just text, then it calls `.toString` on every object and renders that to oldschool character stdout.
mercurial 12y ago
Colin Walters tried with Hotwire Shell [1]. However, it has been abandoned for years. 1: http://blog.verbum.org/2008/03/23/hotwire-hypershell-0-721-released/ http://blog.verbum.org/2008/03/23/hotwire-hypershell-0-721-r...

coldtea 12y ago

>It's impossible to “redesign” shell fundamentals in Unix because it will be incompatible with all other old-style utilies So? For one, you could redesign the basic utilities too. Or offer a sumplementary revamp versions of some. Second, you could use them in a less capable "text mode" and still get all the other benefits from the new shell. >And classic pipes are not so bad as PS evangelists saying. Well, they are not that relevant to 2014 either.

skrebbel 12y ago

> It's impossible to “redesign” shell fundamentals in Unix because it will be incompatible with all other old-style utilies. This is not true. In fact, despite its many flaws, PowerShell did solve this particular one: any object stream can also be rendered as a string. This is exactly what happens when you just type `ls` into a PowerShell window. I can completely imagine that a UNIX `ls` implementation would return a stream of objects (not necessarily .NET objects - just some runtime's native object format) that, when called .toString() on, would return exactly the same textual output as common UNIX `ls`. Then, you'd need a way to differentiate between two pipes. Maybe with syntax (i.e. | for string pipes, [] for object pipes, whatever) or maybe through magic ("hey, these two processes both have the capability to pipe objects instead of characters, let's tie them together as objects" somewhere at the shell level). I'm not sure how feasible either are, but I'm sure you can imagine that this problem could be solved. Then, if the shell sees that whichever process accepts the output of `ls` doesn't understand objects, just text, then it calls `.toString` on every object and renders that to oldschool character stdout.

mercurial 12y ago

Colin Walters tried with Hotwire Shell [1]. However, it has been abandoned for years. 1: http://blog.verbum.org/2008/03/23/hotwire-hypershell-0-721-released/ http://blog.verbum.org/2008/03/23/hotwire-hypershell-0-721-r...