Hacker News Reader

Comment by AimHere | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com