Hacker News Reader

Comment by Diti | Hacker News Reader

Something that irks me is how PowerShell’s default aliases take precedence over binaries in the PATH. To be able to use the GNU utils, you have to put this in your profile.ps1:

  Remove-Item Alias:cat
  Remove-Item Alias:cp
  Remove-Item Alias:curl
  Remove-Item Alias:echo
  Remove-Item Alias:ls
  Remove-Item Alias:man
  Remove-Item Alias:mv
  Remove-Item Alias:pwd
  Remove-Item Alias:rm
  Remove-Item Alias:wget

View on HN

Isn't that always the case, that shell built-ins take precedence over things elsewhere in the system? On Unix you have to call them with their full path, e.g. to get the system echo instead of bash's you need /bin/echo, I guess. On Windows you can add the extension, i.e. use ls.exe instead. Even cmd shadows programs that have the same name as a built-in, e.g. echo.exe must be called as such and just echo will use the built-in command.

That is correct. Most people do not notice because the buildings in bash are almost completely equivalent to the standalone binaries.

I've only ever really noticed with 'time' and 'echo'

I have noticed this with echo too. In specific, the bash echo built in does not drop support for -n and -e when bash is forced into standards compliance mode as /bin/sh. That causes breakage on systems that use more strictly compliant shells when code was written against bash as sh under the assumption that either -n or -e work. I spotted a regression in Linus' tree a while back where this very thing happened in the build system for perf. Sadly, my patch to fix it was ignored:

http://www.gossamer-threads.com/lists/linux/kernel/2218440

If it is still an issue you want to fix, you may need to resend the patch periodically. It doesn't look like you got any response at all.

LKML gets hundreds of messages every day. When I used to read it I had a set of search filters to prioritize it. Anything I didn't get to I simply marked Read. There's no way to catch everything on there.

Maybe get it passed through by someone who is in Linus's email filters.

Although it's been a year and you probably don't care anymore. :)

The time builtin is often less functional than the /usr/bin/time and does not have functionality like the -v parameter.

"command echo" instead of just "echo" should bypass the shell builtin.

How would an alias work otherwise? That's pretty much the way it behaves in Unix, too (e.g. 'ls' in most default configs).

Although I'd still consider curl/wget to be specific tools and not generic commands, so emulating them seems a bit weird.

The point is that they're defined by default. See this story for more background:

https://news.ycombinator.com/item?id=12319670

Edit: the RFC intended to address the curl author's issue was rejected.

https://github.com/PowerShell/PowerShell-RFC/blob/master/X-R...

Yeah, because it would represent a breaking change.

There are use-cases where globally removing aliases isn't an option (e.g. scripting for use on a machine that isn't yours).

For those, it's also possible to evade the aliasing just by explicitly appending the .exe onto the command. 'pwd.exe' gets you the GNU version.

Wait, the Linux subsystem on Windows inherits that stupid convention of deciding if a file is executable by its name?

No, this is in powershell not the linux subsystem. In powershell they defined a bunch of aliases to internal powershell functions like cp, mv, cat ... that don't work like the original unix version. If you install the GNU version on the system and try to use them in powershell that won't work by default. You either remove the alias or use the trick above to force powershell to use the .exe of the utility.

Oh, ok. That was GNU tools compiled for Windows, not the Linux subsystem. I was surprised for a while, but yes, I shouldn't.

No, Windows does not decide whether files are executable by looking at their name.

Windows just failed on running my text file because it didn't have the correct header.

"is executable" is different from "is an executable". Your other comment was worded to say the former, while this one seems to refer to the latter.

For example, a .jpg image can be marked as executable, but it is not an executable. This can happen on both Linux and Windows, and I believe it is handled by the filesystem. I supposed the term "marked as executable" could be used for this, while "is executable" could mean the OS will grant it a PID using the correct system call, but this is uncommon.

On Linux, you can attempt to execute any file using a system call like execve(). Similarly, on Windows you can also attempt to run a JPEG using CreateProcess(). I know the Windows shell probably won't run a JPEG even if it is marked executable(there are a collection of Registry entries that map file extensions to programs that run them, for the shell), but I don't know if the CreateProcess() API function rejects files without the correct extension.

If both CreateProcess() and GetBinaryType() fail to detect a PE file with the incorrect extension, then you can reasonably say that Windows uses the extension to determine whether a file is an executable(though not whether it is executable). The behavior of the shell isn't sufficient.

CreateProcess() doesn't care what the file extension is when you pass the executable filename into the lpApplicationName parameter.

I used this feature when I worked on a VR app written in Unity, and I had a little launcher program that checked for updates and then started the main program. I didn't want people to bypass the launcher, so I renamed the main program to have a .VR extension instead of .exe, preventing it from being run directly from File Explorer. The launcher had a .exe extension and could be run normally, and then it used CreateProcess to run the FooBar.VR executable.

Windows has an execute permission, it's just rare for a file's permissions to be set granularly.

It's GUI shell does. Theoretically you can create a process from any binary blob. But to invoke it the gui way you need to have it either with an .exe or another self executing ext defined in the registry.

The key here is not so much the ".exe" suffix as that it's not "pwd". Think:

  alias some-command='some-command.sh --arg'

and then running "some-command" versus "some-command.sh". (The Window's shell does interpret stuff with the ".exe" suffix differently, just it's not the key factor here.)

That's a bad idea - the inbuilt 'ls' (aka get-childitem - it also works on registry paths) will output real file objects, with properties you can access with 'select' and 'forEach' etc, whereas the GNU tool will output text you'll have to scrape.

I would use `Get-ChildItem` directly in that case. When I use `ls`, I expect it to be POSIX `ls`.

I don't think this is a good default for posh on nix platforms but I would argue that it's a good thing on Windows. The output of PowerShell ls is an object with typed properties and methods that you can interact with in a much richer way.

Not to mention user experience. Adding these aliases made moving back-and-forth between nix and Windows much less jarring for me. They also really helped drive home the difference between something like bash and posh because investigating the differences between the aliases and their nix namesakes revealed their respective strengths and weaknesses.

I imagine changing aliases would be out of the question since they should have priority over PATH but perhaps a special conditional case for these the first time they're run interactively would be to check for the nix equivalent in your PATH and prompt to see if you'd like to remove them.

I don't really het the point of powershell making everything an object. If I wanted that I'd probably be in a python REPL.

I think if you'd asked me a few years ago I might have agreed. But the Python REPL is a terrible shell.

If you have a lot of experience with something like bash and you can run circles with it PowerShell probably doesn't add a lot of short term value.

There was a long argument about this in a thread previously but in my opinion they should not change this now.

The weird thing was that Powershell for Mac doesn't do this.

Possibly because by the time the makers put out the Mac version, they were already aware of the issue, and also because the Mac has the GNU coreutils as part of the main OS, rather than being third-party installs, so the problem was immediately obvious to the first tester who actually used it.

It's not that weird, they put the alias' in so new admins on windows fresh from linux don't hit a complete roadblock at the first command they type. Its to make powershell less punishing to learn, not emulate a different system.

So imagine when they packaged that for Mac, that assumption is no longer true.

They got removed in the open-source version of PowerShell and only remain in the Windows build.

They should have implemented these with a missing command handler. So if the ls wget etc exist they work. But just before the command line complains of unknown program name it should check that list and execute the alias.

A new "bottom of the stack" alias instead of the current one that takes precedent over executables.

I would argue that for scripting portability, this should be the same. With wget equivalent in Powershell being so different for example, scripts that use aliases will be broken.

Granted, don't use aliases in scripts and all that.

FWIW, I always thought of it as being for portability of humans, and was very grateful for it on Windows. A large chunk of my time is spent on *NIX systems, so my fingers automatically type "ls" and "rm" instead of "dir" and "del". The fact that Powershell worked, rather than throwing a "eh, what?" error made my time on Windows suprisingly more pleasant.

Reply on news.ycombinator.com