“It's easier to port a shell than a shell script” (1998) • Hacker News Board

Re: “It's easier to port a shell than a shell script” (1998)

#41

Post by Sir_Cmpwn » Sun, Aug 23, 2015, 2:23 PM UTC

kazinator wrote: post #40

Sir_Cmpwn wrote: post #39

Earlier quoted context omitted.

>why are you Unix people making a POSIX standard which covers the shell command language, if you're going to insist on one reference implementation being used on everyone? Just dump the source code listing of that into a document, add a few comments here and there, and call it the standard. Any shell that isn't compatible with the _reference_ implementation of that shell is flawed.

The POSIX standard that came into effect in 1990 doesn't contain or assert any reference implementation. A reference implementation accompanying a document can be at odds with the specification. If a document says that a reference implementation shall be held correct if there is any discrepancy, then specification is greatly diminished in value. It's obviously just a best effort to describe the reference implementati…

Well, your comments are valid. To be fair, though, if Microsoft was truly aiming to be compatible, they'd implement POSIX and you could use whatever shell implementation you wanted to.

Re: “It's easier to port a shell than a shell script” (1998)

#42

Post by kazinator » Sun, Aug 23, 2015, 2:30 PM UTC

MrQuincle wrote: post #28

tatterdemalion wrote: post #22

Earlier quoted context omitted.

"Text" only makes a good lowest common denominator on UNIX because the designers of UNIX decided that ASCII would be the lowest common denominator of the system. The designers of modern Windows decided that MSIL objects would be their lowest common denominator. If the UNIX designers had chosen some other lowest common denominator, all of these diverse utilities would be communicating over that protocol instead of ASC…

Can you explain me a bit the difference if you mind (I don't know much about Windows). In Linux/Unix I can also pipe audio to /dev/audio for example. And image processing through a sequence of steps by pipes is quite often done. Are these objects coming with default metaparameters to make piping easier? Or are there other things implemented that might be cool?

"objects" means data structures. It means you can have some structure with fields, or list or array or whatever as the output of one command, and input of the next one, so the next one doesn't have to do character-level parsing.

Of course, this kind of piping is present in nice languages that precede the PowerShell.

A one page Lisp macro will give you a left-to-right syntactic sugar for filtering. Clojure has a threading operator, Ruby has cascades of dots: object.{ blah }.foo().bar() ... and so on.

Re: “It's easier to port a shell than a shell script” (1998)

#43

Post by kazinator » Sun, Aug 23, 2015, 2:42 PM UTC

Sir_Cmpwn wrote: post #41

kazinator wrote: post #40

Earlier quoted context omitted.

The POSIX standard that came into effect in 1990 doesn't contain or assert any reference implementation. A reference implementation accompanying a document can be at odds with the specification. If a document says that a reference implementation shall be held correct if there is any discrepancy, then specification is greatly diminished in value. It's obviously just a best effort to describe the reference implementati…

Well, your comments are valid. To be fair, though, if Microsoft was truly aiming to be compatible, they'd implement POSIX and you could use whatever shell implementation you wanted to.

But that environment would have to provide a shell that users would need in order to build whatever shell they want.

In the discussed scenario, it appears Microsoft were working with the MKS vendor, relying on them to provide compatibility.

Microsoft eventually bought something called OpenNT in the late 1990's and renamed it Interix.

Microsoft also had their own licensed and branded AT&T Unix called Xenix in the 1980's:

https://en.wikipedia.org/wiki/Xenix

They helped make Unix popular: Xenix had the biggest installed base among Unixes.

In the mid 1990's, I visited a computer animation school which had a classroom for learning Unix. It was equipped with some vanilla PC box which ran Microsoft Xenix, and about a dozen terminals attached to it. Students would sit at these terminals and follow the instructor along, running shell commands, editing with vi and so on.

Re: “It's easier to port a shell than a shell script” (1998)

#44

Post by vezzy-fnord » Sun, Aug 23, 2015, 2:49 PM UTC

kazinator wrote: post #38

I could have easily put Korn in his place if I had been that Microsoft person. Ah, but no; I would end up saying some things that would have been too ironic to come from a Microsoft person, such as: - why are you Unix people making a POSIX standard which covers the shell command language, if you're going to insist on one reference implementation being used on everyone? Just dump the source code listing of that into a…

You think these are zingers, but they're really just worthy of cringing.

a) Red herring. No one is talking about a reference implementation of Unix shells, but about Korn shell compatibility in particular.

b) Red herring. Don't imply it's a Korn or Korn-compatible shell - that's the issue here.

c) Red herring. Though the conversation was never recorded, it's implied that nothing was said about "portability", per se, but in particular compatibility with the Korn shell language specification.

d) Red herring and an insult. Stephen Bourne didn't write the first Unix shell. Ken Thompson did. Is your implication that no one should iterate or create new designs? Microsoft creating a Unix shell is fine, but the issue at hand is that it wasn't a Korn shell like they claimed it to be.

Re: “It's easier to port a shell than a shell script” (1998)

#45

Post by kazinator » Sun, Aug 23, 2015, 2:58 PM UTC

vezzy-fnord wrote: post #44

kazinator wrote: post #38

I could have easily put Korn in his place if I had been that Microsoft person. Ah, but no; I would end up saying some things that would have been too ironic to come from a Microsoft person, such as: - why are you Unix people making a POSIX standard which covers the shell command language, if you're going to insist on one reference implementation being used on everyone? Just dump the source code listing of that into a…

You think these are zingers, but they're really just worthy of cringing. a) Red herring. No one is talking about a reference implementation of Unix shells, but about Korn shell compatibility in particular. b) Red herring. Don't imply it's a Korn or Korn-compatible shell - that's the issue here. c) Red herring. Though the conversation was never recorded, it's implied that nothing was said about "portability", per se,…

Microsoft wasn't creating anything; they were working with MKS:

https://en.wikipedia.org/wiki/MKS_Inc

MKS claimed to have a Korn-shell workalike, AFAIR.

> The MPM asserted again that the shell was pretty compatible and should work quite well

which sounds reasonable, and isn't an assertion that MKS has the Korn shell in it such that it is 100% compatible. (And could anything even be 100% compatible, if not running on Unix? The Korn shell source ported to DOS woudln't be 100% compatible with the Korn shell, just "pretty compatible" so that many things work "quite well".)

They probably had some good reasons to with MKS, because in fact it isn't easy to port a shell: not to the DOS environment. Or Windows. The minimal example of doing this reasonably well might today be the MSYS environment used by MinGW, which has to re-create significant infrastructure (a whole C library from the ground up and other things).

Maybe Microsoft also had favorable licensing with MKS, avoiding the AT&T license.

Re: “It's easier to port a shell than a shell script” (1998)

#46

Post by AnthonyMouse » Sun, Aug 23, 2015, 3:17 PM UTC

tatterdemalion wrote: post #22

kbenson wrote: post #20

Earlier quoted context omitted.

It has it's pros and cons, but in the end it's fundamentally different . Powershell wouldn't work nearly as well on a UNIX system, where much of the tooling is already just text, provided by many different sources , and uses a much more diverse set of utilities. Text makes a good lowest common denominator in that situation.

"Text" only makes a good lowest common denominator on UNIX because the designers of UNIX decided that ASCII would be the lowest common denominator of the system. The designers of modern Windows decided that MSIL objects would be their lowest common denominator. If the UNIX designers had chosen some other lowest common denominator, all of these diverse utilities would be communicating over that protocol instead of ASC…

> "Text" only makes a good lowest common denominator on UNIX because the designers of UNIX decided that ASCII would be the lowest common denominator of the system. The designers of modern Windows decided that MSIL objects would be their lowest common denominator.

"Text" makes a good lowest common denominator because it's low. Everything, including humans looking at it, can deal with text. Essentially all programming languages on all platforms provide basic primitives analogous to getline(), find_first_of(), substr(), etc. You can take text from Unix and easily do something useful with it on any arbitrary platform.

MSIL assumes an entire infrastructure that isn't universally available. You can't take MSIL from Windows and easily do something useful with it on any arbitrary platform. It requires you to have a solid .NET virtual machine for your operating system, an API for dealing with MSIL, bindings for that API in every language you want to use, etc.

Re: “It's easier to port a shell than a shell script” (1998)

#47

Post by ChristianBundy » Sun, Aug 23, 2015, 3:32 PM UTC

brisance wrote: post #10

fresleven wrote: post #6

Seeing a link to a gopher:// site and discovering that Safari in iOS still supports it made my day.

I might be missing something; isn't the machine named gopher but it is using HTTP to access it on port 70?

This is correct.

Re: “It's easier to port a shell than a shell script” (1998)

#48

Post by integraton » Sun, Aug 23, 2015, 3:56 PM UTC

MrQuincle wrote: post #28

tatterdemalion wrote: post #22

Earlier quoted context omitted.

"Text" only makes a good lowest common denominator on UNIX because the designers of UNIX decided that ASCII would be the lowest common denominator of the system. The designers of modern Windows decided that MSIL objects would be their lowest common denominator. If the UNIX designers had chosen some other lowest common denominator, all of these diverse utilities would be communicating over that protocol instead of ASC…

Can you explain me a bit the difference if you mind (I don't know much about Windows). In Linux/Unix I can also pipe audio to /dev/audio for example. And image processing through a sequence of steps by pipes is quite often done. Are these objects coming with default metaparameters to make piping easier? Or are there other things implemented that might be cool?

PowerShell's object pipeline only exists within the PowerShell/.NET runtime and is functionally analogous to method/function chaining in languages like JavaScript and Ruby. The object pipeline does not exist outside of the PowerShell/.NET runtime.

Pipelines in Unix shells use OS-level functionality to connect standard streams of data, often encoded as text, between arbitrary executables written in any language.

The reason this is confusing is because one of the main tactics used in PowerShell promotion is to disingenuously compare PowerShell's "object pipeline" to Unix pipelines in order to try to make it appear to be more novel than it is, when they should be comparing it to what it's functionally equivalent to, which is function chaining within a single runtime.

Re: “It's easier to port a shell than a shell script” (1998)

#49

Post by integraton » Sun, Aug 23, 2015, 4:12 PM UTC

dkarapetyan wrote: post #23

kbenson wrote: post #20

Earlier quoted context omitted.

It has it's pros and cons, but in the end it's fundamentally different . Powershell wouldn't work nearly as well on a UNIX system, where much of the tooling is already just text, provided by many different sources , and uses a much more diverse set of utilities. Text makes a good lowest common denominator in that situation.

I don't think it is fundamentally different. When I think of a shell I think of pipes and interactivity. What you pass between through the pipe is secondary. The fundamental nature of the shell is those two things and everything else is just sugar on top. PowerShell has that and more so I'd say it is not fundamentally different and in fact it is objectively better.

The word "shell" in this context already means something. A text shell is a command line interpreter (https://en.wikipedia.org/wiki/Shell_(computing)#Text_.28CLI....). There are many shells that do not use the pipeline convention (e.g., irb), so your attempt to redefine it to promote PowerShell fails from the start.

PowerShell's object pipeline is functionally analogous to function chaining in languages like Ruby, Python, and JavaScript, not Unix pipelines. PowerShell's object pipeline does not exist outside of the .NET runtime and you can not stream objects between arbitrary executables outside of the .NET runtime.

You can't compare an apple to an orange and say one is "objectively better," no matter how hard PowerShell advertisers try to pretend their apple is an orange.

Re: “It's easier to port a shell than a shell script” (1998)

#50

Post by integraton » Sun, Aug 23, 2015, 4:19 PM UTC

tatterdemalion wrote: post #29

MrQuincle wrote: post #28

Earlier quoted context omitted.

Can you explain me a bit the difference if you mind (I don't know much about Windows). In Linux/Unix I can also pipe audio to /dev/audio for example. And image processing through a sequence of steps by pipes is quite often done. Are these objects coming with default metaparameters to make piping easier? Or are there other things implemented that might be cool?

I have never used PowerShell, so I don't know a lot about the details. But PowerShell pipes .NET objects from one command to the next, which are not just bytestreams but are objects, with methods and such. It's fundamentally different. In UNIX, you have bytes, and the underlying system doesn't know what they represent. Most tools assume they're ASCII or UTF-8 (or whatever) encoded text, but that's all they agree on.…

> It's fundamentally different.

That's because the object pipeline is functionally analogous to function chaining within a single runtime like in Python or Ruby, not streaming data between arbitrary executables like in Unix pipelines.

This would be a lot clearer if PowerShell advocates compared it to things that it's actually functionally analogous to, but they are trying to position it as a Unix shell competitor.