rmyorston / busybox-w32

WIN32 native port of BusyBox.
https://frippery.org/busybox
Other
670 stars 124 forks source link

[Question] Any way to make mintty work better with busybox-w32 ash? #420

Closed shunf4 closed 3 months ago

shunf4 commented 3 months ago

I would be very glad if I can use mintty with busybox-w32, like:

C:\cygwin64\bin\mintty.exe -e busybox ash

It opens busybox ash, but it has a wrong $HOME, given by mintty/cygwin-newlib:

C:/Users/shunf4 $ echo $HOME
C:\cygwin64\home\shunf4
C:/Users/shunf4 $

Cancelling $HOME and relaunching it doesn't work:

C:/Users/shunf4 $ HOME= ash
~ $ echo $HOME

~ $

This breaks many use cases of mine.

Digging into the code, I found it's because of this:

https://github.com/rmyorston/busybox-w32/blob/5c1a3b00e235da31b2c73bae18aa5622d820b68a/shell/ash.c#L15843-L15864

https://github.com/rmyorston/busybox-w32/blob/5c1a3b00e235da31b2c73bae18aa5622d820b68a/shell/ash.c#L15804-L15819

Mintty(or newlib?) "standardize"s all env vars to upper case for its child process, so "mixed_case" is not detected, and login-related env vars' initialization is also skipped. so no HOME and USER env vars available in ash:

https://github.com/rmyorston/busybox-w32/blob/5c1a3b00e235da31b2c73bae18aa5622d820b68a/shell/ash.c#L15894-L15900

Knowing this, then I can workaround by reverting the case of PATH and COMSPEC:

C:\cygwin64\bin\mintty.exe -e busybox ash -c "env -u HOME -u PATH -u COMSPEC Path=\"$PATH\" ComSpec=\"$COMSPEC\" ash"

Is there a better, more direct way? Or, a better way to detect busybox ash launching from another busybox invocation other than looking at the case of environment variables?

rmyorston commented 3 months ago

Things I've noticed so far:

It isn't necessary to revert the case of both PATH and COMSPEC. One would suffice.

Mintty doesn't make all environment variables uppercase: ProgramData, for example, remains mixed case. It would be possible to add this to the list in mixed_case_special_name() as an additional ~hack~ heuristic.

It would still be necessary to unset HOME. That seems to be set by mintty before the shell is started. The shell in busybox-w32 refuses to set HOME if it's already set (so the user can override the default value).

ale5000-git commented 3 months ago

Doesn't it works like this? (after the fix of ProgramData) mintty.exe -e busybox ash -s -c 'unset HOME'

shunf4 commented 3 months ago

Doesn't it works like this? (after the fix of ProgramData) mintty.exe -e busybox ash -s -c 'unset HOME'

More like this:

mintty.exe -e busybox ash -c "env -u HOME ash"
shunf4 commented 3 months ago

Doesn't it works like this? (after the fix of ProgramData) mintty.exe -e busybox ash -s -c 'unset HOME'

More like this:

mintty.exe -e busybox ash -c "env -u HOME ash"

Or this:

mintty.exe -e busybox env -u HOME ash

Considering mintty is more of a Cygwin thing and much used in mintty.exe /bin/bash -il form (which needs to read files in cygwin home ~/.bashrc etc), I may have to live with mintty's setting HOME, and unavoidably using unset HOME or env -u HOME in my use case.

rmyorston commented 3 months ago

I've added a hack to try and detect the use of mintty.

Try the latest prerelease (PRE-5349 or above).

shunf4 commented 3 months ago

Neat, now C:\cygwin64\bin\mintty.exe -e busybox.exe ash runs well.

shunf4 commented 3 months ago

Neat, now C:\cygwin64\bin\mintty.exe -e busybox.exe ash runs well.

Only when invoked from cmd.

If invoked from a cygwin envrionment like $ mintty -e busybox bash, then PS1 breaks, all backslashes replaced by a slash. May PS1 be excluded from setwinxp?

rmyorston commented 3 months ago

If you don't want backslashes to be converted use $ mintty -e busybox bash -X.