TekWizely
Error on Windows
Hi!
I wanted to use Bingo. It required Run. So I compiled it. Compilation works, but any Runfile with fail with this error:
exec: "/usr/bin/env": file does not exist
The culprit is this line https://github.com/TekWizely/run/blob/27ff98d949e278bf7dcd3c391a33ce4565e1b477/internal/exec/exec.go#L68
Possible solution: Check if GOOS == 'windows' and execute shell directly, without using /usr/bin/env.
hi @rashil2000 and thank you for your interest in my projects.
re: Bingo - Bingo is built on Bash so I don't know if the command's scripts will run in standard Windows.
I suspect it would work fine in WSL.
re: Run on Windows ...
I would expect, outside of special language tools like python, etc, we would want to support batch files and powershell scripts.
I suspect that python.exe <filename> would probably work as expected.
But for executing batch files, not sure if we would try to execute <filename> directly or if something like cmd.exe /c <filename> is needed.
re: Powershell
From my research, you can't just invoke powershell like powershell.exe <filename>.
You need something like powershell.exe -file <filename>.
There's also considerations like -NoLogo, -NoProfile -NonInteractive ...
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_powershell_exe?view=powershell-5.1
Since you have the source code for Run hand already, maybe you can play around with this a bit and see what seems to function as expected?
I'm thinking I'll need to extend Run to allow each shell alias to also configure its execution format, i.e
.SHELL.bat.exec := "cmd.exe /c {}"
my_command(bat):
; bat file script
Thanks for taking the time to report an issue and lemme know how your local discovery goes!
-TW
Hi!
Here's what I know.
(Note that none of the below applies to WSL - both Bingo and Run already work in WSL, because well it's just Linux)
Bash Scripts
Since Bingo is written in Bash, my initial intent was to use bash itself. Bash can be run natively on Windows via MSYS2. So, the most straightforward and simple solution is to simply look for sh.exe or bash.exe in the PATH.
Addendum No. 1
Since Git is written primarily in 3 languages - C, Perl and Bash, anyone who uses Git on Windows already has Bash (and also Perl) installed. Git on Windows uses MSYS2's Bash. So the above method will require no additional setup.
Batch Scripts
Of course for proper Windows support it would be good to not rely on external programs such as MSYS2. Batch scripts (with extensions .cmd and .bat) can be called/run directly, or, for completeness, called like cmd.exe /d /c <filename>.cmd (notice the /d flag, this is somewhat equivalent to PowerShell's -NoProfile).
PowerShell Scripts
PowerShell scripts can be run by calling powershell.exe <filename>.ps1 (or pwsh.exe <filename>.ps1 for PowerShell versions greater than 5.1). The only relevant flag is -NoProfile (or -nop in short), which will defer loading of the user's settings and such. So, in essence, powershell.exe -nop <filename>.ps1 and pwsh.exe -nop <filename>.ps1 will work.
Shebangs and Associations
Windows does not have the concept of shebangs. Instead, it relies on file extensions and filetype associations. Each file extension has a program associated with it. So the file can be directly run in the terminal (by simply calling it), or by double-clicking it. Windows will pass the filename to the associated program and run it.
(This allows for very weird tricks that can't be done in Unix - try running calling the command test.docx or index.html in the terminal, and they will open nicely 😅)
Addendum No. 2
The Unix shells available in MSYS2 (bash, zsh, fish, tcsh etc.) do support shebangs, and unix scripts will run fine, but only under those shells.
Addendum No. 3
As I mentioned, most files (which have program associations defined for them), can be executed directly. Heck, for some files, you don't even need to specify the file extension, thanks to the PATHEXT environment variable. So batch scripts can be run by just executing their filename, without extension! This is also the reason why Windows users don't have to specify .exe every time they call a binary.