Feature Request: Add support for busybox64.exe when named busybox64.exe, busybox.exe, sh.exe

[doctorpangloss]

Description

Support invoking sudo ln ..., sudo cp ... and other Busybox for Windows applets with gsudo.

I suggest looking for busybox64.exe, busybox.exe, sh.exe, since bash.exe is sometimes WSL bash.

Resolves rmyorston/busybox-w32#313

Also resolves unrelated pain points like #198 . MSYS2 bash is more painful than busybox for Windows due to things like the slashes.

Proposed technical details

sudo touch C:/Windows/System32/test.txt

when invoked from busybox64.exe sh -il shell should Work. Currently it does not, because no such command touch.exe exists, it is a built-in.

[gerardog]

Well,
If busybox is named bash.exe or sh.exe, it can work.

But if it is named busybox, or busybox64.exe, how do I know if it is running sh or bash or ash ?
Does busybox have different implementations for sh, ash, and bash? or is just one implementation for the 3 of them?

Like, if inside one of those shells you run gsudo echo $0, gsudo wont be able to identify sh/bash/ash and the most it can do is to elevate busybox sh -c "echo $0"

Or, if you just call gsudo, shall it elevate busybox sh , busybox bash or busybox ash?

[rmyorston]

Does busybox have different implementations for sh, ash, and bash? or is just one implementation for the 3 of them?

There's just one shell implementation, with three aliases. They all work exactly the same.

But if it is named busybox, or busybox64.exe, how do I know if it is running sh or bash or ash ?

The name of the shell doesn't really matter. The behaviour of the shell doesn't depend on the name used to invoke it.

Like, if inside one of those shells you run gsudo echo $0, gsudo wont be able to identify sh/bash/ash and the most it can do is to elevate busybox sh -c "echo $0"

That should be fine.

Or, if you just call gsudo, shall it elevate busybox sh , busybox bash or busybox ash?

Any of those will work. Standardising on sh would be fine.

The binaries I ship are named busybox.exe and busybox64.exe. However, the program works with any name starting with busybox. So busybox_whatever.exe is equally valid. You might wish to account for that.

Support for ash.exe would also be nice.

[gerardog]

Could you please test this build
https://github.com/gerardog/gsudo/actions/runs/4798754914

Scroll down to Artifacts -> Binaries

[rmyorston]

Works for me on 64-bit Windows 10.

I tried it with busybox.exe and ash.exe. In both cases gsudo without arguments successfully started an elevated shell. gsudo echo $0 reported sh for busybox.exe and the full path to the ash.exe binary.

I'm not a user of gsudo, though, so I could be missing something. You might want to hear what @doctorpangloss thinks about it.

[gerardog]

Released in v2.0.7

[doctorpangloss]

All works for me thanks so much.