
“It's easier to port a shell than a shell script” (1998) - beshrkayali
http://gopher.quux.org:70/Humor%20and%20Fun/Microsoft_KSH.txt%7C/MBOX-MESSAGE/1
======
rawdisk
I thought this was quite amusing when I read it back in the late 90's. At one
point their proposed shell was called "Monad". I wondered "Why do they want to
do this?"

I have gone to a number of conferences with MS employees over the years,
especially MS lawyers, and with respect to software, they often seem like they
have been indoctrinated into a cult. As if the existence of software outside
of MS Windows does not exist and as if MS holds the key to solving all
problems. But MS does not offer solutions. They create problems (e.g., for
anyone who has to deal with their licensing) and then offer "solutions" to the
problems they created. It is like someone who proposes to "simplify" something
by introducing more complexity.

The idea of MS embracing a proper shell seemed laughable to me. Windows users
expect pointing and clicking (and today they want to be able to touch the
screen).

Now fast forward to 2015 and it seems like PowerShell has a significant number
of users. I am sure it is helping Windows users greatly. Good for them.

But I still think it is laughable. The name still makes me laugh.

I'd rather use something like Back Orifice (which has a simple UNIX client) to
control Windows from a proper shell on a computer running UNIX. Or SSH via
Cygwin. Or even SUA which has ksh and tcsh. Alas no simple Bourne shell
(better for writing portable scripts).

~~~
dkarapetyan
You should try powershell. It's actually pretty good and is much better than
unix shells.

~~~
kbenson
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.

~~~
tatterdemalion
"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
ASCII. The choice to use "text" came first and the ecosystem came afterward.

~~~
MrQuincle
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?

~~~
tatterdemalion
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. In practice, you're working almost always
working with structured data - tables or lists or mappings - but you have to
remember that for the output of this program, you want to cut on '=' and take
-f4, and first you need to pipe it through head and tail to clean up some junk
output[1], and this other thing for that program, and whatever.

[1] This is a way to get the `time` field from the output of `ping`.

~~~
integraton
_> 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.

~~~
useerup
> That's because the object pipeline is functionally analogous to function
> chaining within a single runtime like in Python or Ruby

No it is not. See my response below.

------
kazinator
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
document, add a few comments here and there, and call it the standard.

\- isn't it healthier to have multiple implementations rather than a
"monoculture"? Do we all use the same C compiler?

\- the MKS shell could be made to diagnose and reject the use of Korn shell
extensions, helping the programmer write a more portable script.

\- wait, did you say your name was Korn, or Bourne? I didn't quite hear you
from the back. If you're Mr. Korn, I would appreciate it if Mr. Bourne would
now stand up, if present, and ask you why you don't just use the shell with
_his_ name on it.

~~~
vezzy-fnord
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.

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

[https://en.wikipedia.org/wiki/MKS_Inc](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.

------
vezzy-fnord
Also covered by WikiWikiWeb:
[http://c2.com/cgi/wiki?KornShellStory](http://c2.com/cgi/wiki?KornShellStory)

------
digi_owl
So the title of this link is from the title of the email. That in turn is a
quote from Larry Wall, who do not seem to be present in the story at all.

~~~
beshrkayali
Well, I assumed that the point of the quote is that it's fitting for the
story, mentioning Larry was for attribution (which I see got removed from the
title, I don't mind but I think it should've stayed in there for credit)

~~~
digi_owl
Yeah, i just came expecting to see something about the issues of porting
scripts between shells or something. especially as there has been a whole lot
of pro/con shell scripts as of late.

------
readme
And then microsoft's feelings were hurt so badly that one day they decided to
write powershell.

~~~
_Ogre
Somehow I doubt it took them more than 8 years to write Powershell.

~~~
steve-howard
Maybe not, but it does take me 8 hours to get a Powershell script right.

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

~~~
blahedo
Alas, it's not a gopher:// link; gopher is just the name of the host. (Perhaps
it _also_ is a gopher server, or once was.)

~~~
lindner
It's running pygopherd

[http://gopher.quux.org:70/devel/gopher/pygopherd](http://gopher.quux.org:70/devel/gopher/pygopherd)

~~~
beshrkayali
Exactly, that's how I stumbled upon this. PyGopherd has a very nice feature
that supports serving gopher and http on the same port...

------
S4M
1998

------
nickpsecurity
I wish I saw that. That would've been epic.

