Closed 636C6F776E closed 6 months ago
Why Windows 10?
Not just Windows 10, Windows 10 Version 1903 and above.
The mechanism used for UTF-8 support is a manifest. This makes UTF-8 available without having to fiddle with wide-character APIs, which would have required much more work.
Unfortunately the manifest is only supported in recent versions of Windows. Indeed, Windows XP refuses to run applications with the UTF-8 manifest.
An alternative way to read a profile in a non-login shell is to set the ENV
environment variable to point to a script. Any interactive shell will run this on startup. ENV
is specified in POSIX and works in the busybox-w32 shell.
The shell option -X
prevents the conversion of backslashes to forward slashes in environment variables.
For further information on UTF-8 and the -X
shell option, see the release notes for FRP-5181. It's a coincidence that both those items happen to be mentioned in the same release.
The release notes are recommended reading for anyone with a serious interest in busybox-w32.
Thank you for the quick reply! ENV
was exactly what I needed!
Also thanks for BB_OVERRIDE_APPLETS
which I've put to use.
The shell option
-X
prevents the conversion of backslashes to forward slashes in environment variables.
However, I'd think PS1 be added to the exclusion list even without -X.
But also, typically PS1 is set from ~/.profile, and IIRC converting to slashes only happens for new shell - NOT at the shell which just executed ~/.profile.
@636C6F776E are you by any chance invoking several nested instances of the shell without setting PS1 in the profile?
@avih No, I am not. Maybe there is a misunderstanding: my PS1
backslash problem was caused by me defining PS1
as an environment variable in Windows.
Computer (right-click) -> Advanced system settings ->Advanced -> Environment Variables...
was caused by me defining
PS1
as an environment variable in Windows.
Ah, right, that would indeed convert \
to /
. Thanks.
Out of curiosity, why not set that in your ~/.profile
instead?
Regardless though, I still think PS1 should be excluded from this conversion, like some other vars names are.
Out of curiosity, why not set that in your
~/.profile
instead?
Because I use BusyBox from Total Commander and open it directly in the current folder. Equivalent functionality in Linux: Krusader opening Konsole with "F2 Term" or "F9 Term".
Regardless though, I still think PS1 should be excluded from this conversion, like some other vars names are.
That doesn't affect me right now. What does affect me is Unicode chars in filenames. For now I'm happy with what I have.
First, thank you for porting BusyBox to Windows. It's a great lightweight replacement to MSYS2. BusyBox has become my new favorite shell, replacing the venerable cmd.exe.
Second, sorry for using the Issues forum to start this topic but I'm not yet aware of a better location for it.
My problem is I'm using Windows 7 and do not want to upgrade to 10. It seems strange to me that busybox64u.exe requires Win10 or later. Even good old Windows XP has Unicode support and it is vital for a program to be able to handle Unicode filenames. Out of curiosity I would like to know how come the requirements for supporting Unicode are so high. Why Windows 10?
I would like to customize the BusyBox shell with a
~/.profile
file. However that requires passing the-l
parameter which in turn changes the working directory to the$USERPROFILE
. Is it possible to load the profile without changing directory? Equivalent option in MSYS2:CHERE_INVOKING=1
.I've noticed that BusyBox likes to replace all backslashes
\
with forward slashes/
. That wouldn't be a problem if not for the fact that it's applied to environment variables as well. So if I tried to be "clever" and define an environment variable:PS1='[\[\e[1;34m\]\W\[\e[m\]] \$ '
it will be mangled by BusyBox into the nonsensical:PS1='[/[/e[1;34m/]/W/[/e[m/]] /$ '
This will be a non-issue if problem no. 2 is solvable.Thank you for your time and I'm looking forward to future releases!