MS-Windows: shell might not invoke the expected executable in the contrived case of a file with a double executable extension

[ikappaki]

version

[ Please specify which version of babashka you're using. You can find this with babashka --version. The documentation on the master branch may be ahead of the most released version. ]

babashka v0.6.6

[ Please specify which platform you are using babashka on, so you can test a
new binary when the issue is resolved. ]

MS-Windows 10

[ Please provide a short and to the point description of the problem ]

babashka.tasks/shell does not invoke the executable with the expected extension, in the extreme case where there are two executables with the same name and extension, but one of them has the extension repeated once. i.e. the following invokes io.bat.bat instead of the expected io.bat

[ Please provide a minimal working reproduction of the problem ]

D:\bbtest>dir 1
 Directory of D:\bbtest\1

29/11/2021  11:42    <DIR>          .
29/11/2021  11:42    <DIR>          ..
29/11/2021  11:41                 8 io.bat
29/11/2021  11:42                 8 io.bat.bat
               2 File(s)             16 bytes

D:\bbtest>type 1\io.bat
REM :1

D:\bbtest>type 1\io.bat.bat
REM :2

D:\bbtest>set PATH=d:\bbtest\1

D:\bbtest>c:\windows\system32\where io.bat
d:\bbtest\1\io.bat
d:\bbtest\1\io.bat.bat

D:\bbtest>io.bat

D:\bbtest>REM :1

D:\bbtest>C:\Users\ikappaki\scoop\shims\bb.exe --version
babashka v0.6.6

D:\bbtest>C:\Users\ikappaki\scoop\shims\bb.exe "(:cmd (babashka.tasks/shell ""io.bat""))"

D:\bbtest>REM :2
["d:\\bbtest\\1\\io.bat.bat"]

expected behavior

The same as if we invoke the same from the command prompt or the the first outcome of the where tool (i.e. io.bat in the above contrived example).

---

Also I've noticed that fs\which does not return the executable if given with the complete extension:

D:\>bb "(fs/which ""java"")"
#object[sun.nio.fs.WindowsPath 0x4163ceb "C:\\Program Files\\Common Files\\Oracle\\Java\\javapath\\java.exe"]

but the following returns nothing

D:\>bb "(fs/which ""java.exe"")"

[borkdude]

@ikappaki The latter one has been fixed on master an hour or so ago

Also I've noticed that fs\which does not return the executable if given with the complete extension:

You can test the fix with https://ci.appveyor.com/api/buildjobs/6n5ab26rede54lsw/artifacts/babashka-0.6.7-SNAPSHOT-windows-amd64.zip.

About the io.bat.bat case: is this a contrived example or a bug you encountered in real usage?

[ikappaki]

@ikappaki The latter one has been fixed on master an hour or so ago

Also I've noticed that fs\which does not return the executable if given with the complete extension:

You can test the fix with https://ci.appveyor.com/api/buildjobs/6n5ab26rede54lsw/artifacts/babashka-0.6.7-SNAPSHOT-windows-amd64.zip.

About the io.bat.bat case: is this a contrived example or a bug you encountered in real usage?

Thanks! It was a contrived example trying out different ext combinations, but that commit has also fixed it too (you are one step ahead 😎) :

babashka/fs#40

D:\bbtest>.\bb.exe --version
babashka v0.6.7-SNAPSHOT

D:\bbtest>.\bb.exe "(:cmd (babashka.tasks/shell ""io.bat""))"

D:\bbtest>REM :1
["d:\\bbtest\\1\\io.bat"]

D:\bbtest>.\bb.exe "(:cmd (babashka.tasks/shell ""io.bat.bat""))"

D:\bbtest>REM :2
["d:\\bbtest\\1\\io.bat.bat"]

D:\bbtest>.\bb.exe "(:cmd (babashka.tasks/shell ""io""))"

D:\bbtest>REM :1
["d:\\bbtest\\1\\io.bat"]

D:\bbtest>.\bb.exe "(fs/which ""io.bat"")"
#object[sun.nio.fs.WindowsPath 0x3aac4678 "d:\\bbtest\\1\\io.bat"]

D:\bbtest>.\bb.exe "(fs/which ""io.bat.bat"")"
#object[sun.nio.fs.WindowsPath 0x62feb3d5 "d:\\bbtest\\1\\io.bat.bat"]

D:\bbtest>.\bb.exe "(fs/which ""io"")"
#object[sun.nio.fs.WindowsPath 0x42d0571f "d:\\bbtest\\1\\io.bat"]

[borkdude]

It seems where also searches in the current working directory, whereas which only searches on the PATH.

[ikappaki]

It seems where also searches in the current working directory, whereas which only searches on the PATH.

Indeed. A few days back while I was doing the research for the original PR, I noticed that powershell does not include the current path when searching for the command to execute for security reasons:

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_command_precedence?view=powershell-7.2

As a security feature, PowerShell does not run executable (native) commands, including PowerShell scripts, unless the command is located in a path that is listed in the Path environment variable $env:path or unless you specify the path to the script file.

To run a script that is in the current directory, specify the full path, or type a dot .\ to represent the current directory.

IMHO is better to follow the *nix which logic in this respect even on MS-Windows. Thanks.

[borkdude]

Cool, I'll leave it like this. Fixed another edge case on master. Will do another release.