Hacker News Reader

Comment by AnIdiotOnTheNet | Hacker News Reader

> powershell's principle is based on the principle of most surprise.

I don't think that's true at all. Compare powershell command names to UNIX command names for example. You can rest assured that Get-X will not change things and that there is almost certainly a Set-X that will, for example. You can tab complete variable names, cmdlet names, cmdlet switches, etc. Additionally, by piping objects instead of text, you aren't caught off guard by things like spaces in a path name.

> Like when I tell it to download something, I don't expect to have to futz with IE browser settings (WTF?!?!).

It definitely does have some flaws though, I'll give you that.

As an aside, you can use Invoke-WebRequest with the `-UseBasicParsing` switch to leave IE out of it. They definitely should have done that the other way around.

View on HN

I was teaching a class on algorithms to some engineering students. They needed to sort a file of random integers using a few different algorithms.

This is the bash I wrote to check their results were sorted properly on Linux:

    diff <(cat output.txt) <(cat input.txt | sort -n)

This is the PowerShell I wrote to check their results were sorted properly on Windows:

    cat input.txt | foreach-object { [Int] $_ } | sort-object | out-file -encoding ascii sorted.txt
    diff (cat output.txt) (cat sorted.txt)

The casting felt a little painful, but it seemed straightforward. The sorted result was generated correctly.

Unfortunately, I was surprised to discover that PowerShell's diff found no differences between a sorted file of numbers and the unsorted file of numbers.

That's because `diff` is an alias of `Compare-Object`, which works radically differently than UNIX `diff` because of the defaults. In some circumstances you could see how this behavior would be more useful, though obviously not this one.

For reference, `Compare-Object -SyncWindow 0` would give the behavior you wanted. The default is [Int32]::MaxValue.

Aliasing UNIX command names is another one of PowerShell's mistakes in my opinion, because it creates the expectation that they work the same way when they often very much don't. Ultimately rather than help UNIX users, as was probably intended, this just confuses and annoys them.

> rather than help UNIX users, as was probably intended, this just confuses and annoys them.

Compatibility layers are great, when they're actually compatible. Almost-compatible layers are a nightmare.

> Compatibility layers are great, when they're actually compatible. Almost-compatible layers are a nightmare.

That's why you should not use them. You decided to use them.

I wasn't just blindly assuming the alias worked the same. I actually read the Compare-Object documentation [1], which contains that exact command as an example of how to compare files. I just didn't understand the sort of comparison it did.

If you search "PowerShell compare two files", it becomes pretty clear this is a common confusion even among people using the name Compare-Object. For example, the top serverfault question has an incorrect top-voted, accepted answer [2].

[1]: https://docs.microsoft.com/en-us/powershell/module/microsoft...

[2]: https://serverfault.com/a/5604

Well, perhaps some hypothetical "you" uses them:) To be clear, I run 100% genuine Bourne-family shells on unix-like systems, and merely visit MS-land for sightseeing;)

> You can tab complete variable names, cmdlet names, cmdlet switches, etc.

UNIX shells can do all that too.

> Additionally, by piping objects instead of text, you aren't caught off guard by things like spaces in a path name.

Not just spaces, to be fair. Files that begin with a hyphen can cause major issues too.

There’s definitely a lot of weird edge cases with UNIX shells but on the whole I still find them easier to work with than Powershell. But that’s just me

What about UNIX shells that allow to call public functions in dynamic libraries as if they were shell commands?

Or interact with running applications using the OS APIs like Powershell allows with WMI, COM, OLE Automation and .NET?

Yes, there is DBUS, but isn't really integrated across the whole stack.

> What about UNIX shells that allow to call public functions in dynamic libraries as if they were shell commands?

dlcall

> Or interact with running applications using the OS APIs like Powershell allows with WMI, COM, OLE Automation and .NET?

Depends what you need. You can use nc -U /var/run/socket or pipes with expect. If you have root permissions you can use gdb scripting/ebpf to communicate with user-space/kernel-space data of your application.

> Yes, there is DBUS, but isn't really integrated across the whole stack.

DBUS is a bus for desktops/mobile. I never saw that someone use it for server applications. The main idea(after KISS) of the Linux shell is that if you can't write something in awk it will be better to use python. Actually, in the Linux world, GRPC/REST is more common than OS-level API.

So a couple of Linuxisms not portable across UNIX, which was my point.

Unix sockets and pipes are portable across all Unix(POSIX, because Linux is not Unix, but OS X is). Furthermore Unix sockets and pipes backwards compatible to 4.4BSD Unix or older OS.

Actually, this comparison is not correct. Windows and Unix have a different philosophy of kernel<->user level interaction. While Windows tries to add all functionality to the kernel, Unix does this on user level. Remember the KISS principle. So If you comfortable with Windows OS level API it's good for you, but for Unix world, it's not necessary to do something because we already have a different inter-process communication approach.

Which is why UNIX shells are a poor man's REPL quite far from what a Xerox inspired user/developer interaction aspired to achieve.

Pipe based interactions work properly only across CLI based applications, and even then the applications need to be explicitly written to accept and parse the data.

PowerShell or other Xerox inspired shells don't need kernel support to achieve their workflows.

> Which is why UNIX shells are a poor man's REPL quite far from what a Xerox inspired user/developer interaction aspired to achieve.

Unix shells are quite good for their purpose. It's not a full-featured programming language. Can you explain what is "poor man's REPL"?

> Pipe based interactions work properly only across CLI based applications

Yes. If you want to find something in logs or looking at any other text data pipes is a good solution. In any other case(like binary data) it will be better to choose GRPC(or any other RPC). I never have seen GUI apps on servers, sorry.

> PowerShell or other Xerox inspired shells don't need kernel support to achieve their workflows.

Good for them :)

A poor man's REPL is a shell that fails short of everything that was possible to do across the OS infrastructure with what Lisp/Smalltalk/Oberon/XDE/Cedar REPLs allowed to do.

An approximation of it would be to have a shell that is a Jupyter netbook with access to the whole set of OS APIs, shared libraries and applications, with the ability to jump into the debugger at any given step of the pipeline, and redo the current step.

I bet you saw GUI apps on UNIX workstations, though.

Then again, maybe Steve Jobs was right after all.

https://www.usenix.org/blog/vault-steve-jobs-keynotes-1987-u...

https://www.cake.co/conversations/rZXhqtP/that-time-i-had-st...

> A poor man's REPL is a shell that fails short of everything that was possible to do across the OS infrastructure with what Lisp/Smalltalk/Oberon/XDE/Cedar REPLs allowed to do.

Shell is a command-line interpreter with additional functionality like scripting. Why it should have fully functional REPL? Lisp/ST/etc are programming languages, they are uncomfortable for copying files, moving directories, calling curl or using tar.

> An approximation of it would be to have a shell that is a Jupyter netbook with access to the whole set of OS APIs, shared libraries and applications, with the ability to jump into the debugger at any given step of the pipeline, and redo the current step.

You can use python for this purpose. I don't understand why Unix shell should have all this functionality.

> I bet you saw GUI apps on UNIX workstations, though.

Yes, of course, I have GUI apps on my MacBook, but they don't use piping for inter-process communication because bi-directional pipes are not quite useful like an ordinary RPC.

> Shell is a command-line interpreter with additional functionality like scripting. Why it should have fully functional REPL? Lisp/ST/etc are programming languages, they are uncomfortable for copying files, moving directories, calling curl or using tar.

Lisp is an interactive programming language. On can run functions like COPY-FILE, RENAME-FILE, ...

The Listener of the Symbolics Lisp Machine has commands which allow prompting of arguments, input menus, completion, object reuse, etc. It's also integrated in Lisp. For example you can list a directory using a command and then use the pathname objects in calls to Lisp functions. One can also use the output of Lisp functions as input to commands. It's an interesting mix of a command interpreter and a Lisp REPL.

I guess we'll have to agree to disagree.

Nope. Your point was to argue personal preference as fact rather than simply accepting that some people like apples and others prefer oranges.

I get so utterly sick of stupid arguments where people compare their tools and then proceed to makes claims that one is objectively better than another when it’s clearly just a matter of personal taste

If I want that level of control I wouldn’t want to be writing a shell script in the first place.

That’s the problem with Powershell for me, it’s taken the REPL concept but made it too feature rich and too verbose so you lose the speed of writing the code and simplicity of piping predictable streams of data.

The thing with Linux / UNIX is it’s very command line driven from the outset. So if you wanted to do the function calls from shared libraries et al you could write a wrapper in C, Python, Perl, whatever and still use Bash etc to interface with it. You’re not tied to using Bash to solve all of your problems. Bash just provides a convenient interface for chaining all those tools in other languages together. Now I know the same can be said for command prompts on Windows but for whatever reason that seems to be less common than it is on POSIX.

That is where you get it wrong, because the REPL concept as introduced by Smalltalk and Interlisp-D/Lisp Machines it is exactly what Powershell tries to achieve.

UNIX shells are a poor imitation of it.

I never said UNIX invented the REPL concept (though I’d have thought time sharing systems predated LISP machines) and this a conversation about personal preference so there is not right or wrong answers (aside arrogant comments from techies who feel they should belittle others for having differing preferences).

I don’t happen to like Powershell. That doesn’t make me wrong. That literally just means I don’t happen to like Powershell. Period.

(and voting me down for personal preference is really just pathetic)

I am not the one downvoting you, I rather have discussions, even when I might not be right.

> REPL concept

the interactive REPL was introduced by Lisp around 1962 way before Lisp Machines, Smalltalk...

Yes, but not with the capabilities that their graphical sucessors brought into the computing world.

You surely could not display inline structured data and interact with it graphically on an IBM 704 teletype.

Well, you had Lisp structure editors already in the 60s. Doing it graphically doesn't really add too much to it. If you read the manual for BBN Lisp, you can see that it did end 60s / early 70s more than many current systems do - like managing source code, working with images, structure editors for code and data, sophisticated user-level error handling, etc..

Which one did you learn to use first? Wondering if that has much of an impact. I've only used Powershell for a bit while I work with *nix shells daily so I'm definitely biased towards them but wonder if I'd cut my teeth on Powershell if I'd think the same way.

Neither. I leaned the CLI from DOS (or it might have been CP/M?).

Unless you count BBC BASIC?

The last point is the point really.

The entire objectivity of it is ruined by weird edge cases and knowledge. The car only goes straight if both rear windows are open. You have to say "beetlejuice" three times before putting it in reverse etc etc.

You sure you aren't describing an average UNIX command?

No because you don't have to google for an hour to find the "don't punch me in the dick" flag.

Instead you just have to google how to use `tar` properly. Again.

You can tab complete powershell cmdlet switches. And MSDN has extensive and good documentation. Here's the page for Invoke-WebRequest. Notice the very first switch listed. Further note that Microsoft realized they screwed this up and deprecated the switch in PS 6.0 since it is now the default.

https://docs.microsoft.com/en-us/powershell/module/microsoft...

No googling because it hasn't changed in the last 20 years.

How do you unzip a 20 gig file in powershell?

1. You can use the windows shell via complicated series of calls. This runs like ass as the windows built in decompression is terrible. Also it only works properly if there's a desktop session running so over WinRM it does with a COM error.

2. Find out which version of powershell you have, hope it's 5.0 or later or install the right WMF version and then run expand-archive. And it still runs like ass. But oh no we can't because now we have to push WMF 5.0 to 150 servers which is going to take DAYS with SCCM. Some kit is on Windows 2012, some on 2012 R2 and some on 2016 because it's so damn hard migrating stuff as it has to be done by hand so you have a mix of stuff leading to a nightmare from hell.

3. Import System.IO.Compression and call .Net to do it then wrap it in a cmdlet called Expand-Archive, then wonder why it breaks when someone pushes out WMF 5.0+

4. Push 7za.exe out with ansible and run that.

This is the problem. No good outcome for really simple tasks. Friction for all of them.

Edit: I'm being 100% honest here and say I hate it with such a passion because I've lived in the same building as it for several years, not because I'm not aware of how it works.

> Import System.IO.Compression and call .Net to do it.

...and? Why is that a problem? It is an advantage that PowerShell can call on the CLR directly (including its C FFI).

Because half the time it slings

Exception calling "ExtractToDirectory" with "2" argument(s): "End of Central Directory record could not be found."

7zip works fine!

(copied straight from my MASSIVE OneNote book of weird powershell and .Net errors and workarounds). Also they just deprecated OneNote desktop other than the turdy UWP app. Another thing to be angry about.

But you're completely willing to forgive UNIX's toolset's problems because you're used to them after working with them for decades. I get it, but that does not make them better.

Working properly == better in my mind.

Consistency, trust over everything.

"properly" in this context meaning "the way I am used to, warts and all", right? Because otherwise I can't see why you'd be so upset about Invoke-WebRequest doing exactly what it was designed and documented to do.

Consistency? In UNIX tools? No. What you have is familiarity. Don't get me wrong, there's a lot to be said for working with tools you're familiar with, but again that doesn't mean they are actually objectively better tools.

Properly as in it does the intended job.

Consistently as in it stays doing the intended job in as an idempotent manor as possible.

Whether or not it’s ugly or elegant don’t matter if it doesn’t work or stay working.

You can argue semantics but this is a turd that can’t be glittered.

Another way to look at powershell is that the idea is good but the implementation isn’t. Unix style shells the implementation is excellent but the idea is mediocre. All productivity and therefore business value is really tied to the implementation quality.

> Another way to look at powershell is that the idea is good but the implementation isn’t.

I wouldn't entirely disagree with that statement.

> Unix style shells the implementation is excellent but the idea is mediocre.

This I would. The idea was a really good one... in the 70s. It has utterly failed to evolve since then. The implementation is actually pretty horrible. If you don't have a lot of familiarity with it it is undiscoverable, full of footguns, and consistency is an afterthought.

You learn to really appreciate POSIX implementations when you do things like grep and pipe results over 100GB+ text files. and no, these text files were not created due to unix philosophy, I’m talking about xml generated in Java as an example. grep&co are a godsend trying to tackle these without ripping out every hair on your body.

Specially when one is adventurous to write them in a portable way across multiple POSIX implementations.

forget about it *nix has won. No matter hiw bad some of it's design might have been. The was some nix fanatics act makes me worry about open source in general

The only two tar commands most people will ever need:

Equivalent of "zip": `tar cjf OutputFile.tar.bz2 InputFileOne InputFileTwo InputFileThree`

Equivalent of "unzip": `tar xf InputFile.whatever.extension`

(This works whether `InputFile.whatever.extension` is bzipped, gzipped, or not compressed at all)

I would strongly suggest that you use the `a` flag rather than `j`, to automatically select file type.

What can be simpler than tar? ‘tar eXtractZipFileVerbose $file’, done!

```tar --help | grep <thing I am trying to do>```

Fun thing about Invoke-WebRequest is that it uses TLS1.0 by default and doesn't understand anything newer unless you enter an incantation beforehand:

[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12

It’s even worse thatn that as the behaviour is defined by a weird combination of the OS, the .net framework, powershell version and local policy settings.

Yes, I imagine a lot of .NET devs don't realize their apps are TLSv1.0 only. I've worked with one vendor who was surprised when I told them.

Exactly that. Some vendors have only just got rid of SSLv3 in financial services as well. It’s slightly scary.

> As an aside, you can use Invoke-WebRequest with the `-UseBasicParsing` switch to leave IE out of it. They definitely should have done that the other way around.

They have made that change:

> This parameter has been deprecated. Beginning with PowerShell 6.0.0, all Web requests use basic parsing only. This parameter is included for backwards compatibility only and any use of it will have no effect on the operation of the cmdlet.

6.0.0 was released on 10 January 2018.

Reply on news.ycombinator.com