Live data from Hacker News

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

gopher.quux.org

21–30 of 68 posts

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

#21
post #19

Earlier quoted context omitted.

It might be better than Bourne or C-derived shells, but I have a hard time conceding it beats for instance Inferno shell, es or rc.

I know enough and have had enough tangential contact with PowerShell to know that it works on a fundamentally different paradigm, as it does not pipe text, but objects. As such, it's hard to say it's "better" since it's so different. I would hazard that it's better some respects for some things, and the reverse is true as well. It fits well into windows, but would not fit well into UNIX systems, where most things are…

That said, if they are easily comparable to bash, ksh, etc

I specifically contrasted them against Bourne or C-like shells, so I thought that much was clear that they are not.

I have tried PowerShell. I think this comment summarizes it well: https://lobste.rs/s/vzjalp/why_i_dislike_systemd/comments/sh...

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

#22
post #20

Earlier quoted context omitted.

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

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

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

#23
post #20

Earlier quoted context omitted.

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

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.

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

#24
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…

man locale(1)

Non-ASCII has been supported for a long time.

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

#25
post #24

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…

man locale(1) Non-ASCII has been supported for a long time.

This is obviously not what I was talking about. I was talking about data representations heterogenous to the idea of "text".

I used "ASCII" instead of "text" to stress that "text" is just a protocol like anything else. The UNIX I'm running is set to use UTF8.

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

#26

Earlier quoted context omitted.

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

It's petty but I can't get over the case sensitive command names with capital letters in it. They are honestly too long.

It has aliases for 90% of those commands, though.

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

#27

Earlier quoted context omitted.

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

It's petty but I can't get over the case sensitive command names with capital letters in it. They are honestly too long.

PowerShell is not case sensitive.

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

#28
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…

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?

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

#29

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?

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`.

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

#30
post #13
post #5

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 e…

Rumor has it, that a somewhat big bank, somewhere in Europe used batch files to drive it's business back in the day...

There was once a time when I as a junior employee was left to create a backup system out of shared drives on the Novell server, XCOPY and AUTOEXEC.BAT.

It worked better than one might expect. You'd get emails about failed backups (backup flag files removed after a successful backup), backups were versioned, and restore was quick & easy (execute a simple script from the shared drive, then sys c: from a boot disk).

Post reply on HN