Open file from Windows with -e bash --login -c "..." / mbsToWcs: invalid string

[florianfeiertag]

I want to open a file from Windows in vim through a Powershell-Script because cmd doesn't handle files with umlaut.

Steps to reproduce

Powershell code

[Console]::OutputEncoding = [System.Text.UTF8Encoding]::new($false) # because powershell won't give UTF-8 to external programm see https://github.com/PowerShell/PowerShell/issues/12107#issuecomment-598061488

$stopparser = '--%' # because i want to use variables after parsing stop see http://mscodingblog.blogspot.com/2013/09/use-powershell-variables-after-escaping.html
[string]$command = 'c:\Users\Florian\AppData\Local\wsltty\bin\mintty.exe'
[string]$1 = '--WSL="Debian" --configdir="C:\Users\Florian\AppData\Roaming\wsltty" --size 105,57 --position 0,7 -t "'
[string]$2 = '" -e bash --login -c "vim "$(wslpath '''
[string]$3 = ''')""'
[string]$file=$args[0]
[string]$filepath = Get-ChildItem -File $file | % { $_.FullName }

Write-Host $filepath

& $command $stopparser $1 $filepath $2 $file $3;

Expected behavior

Opens file in vim in WSL from Windows.

Actual behavior

Environment

mintty 3.4.5 WSL1

GNU bash, Version 5.0.3(1)-release (x86_64-pc-linux-gnu) florian@E495  ~  locale LANG=de_DE.UTF-8 LANGUAGE= LC_CTYPE=de_DE.UTF-8 LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=

Microsoft Windows [Version 10.0.19042.804]

Powershell 7.1.0 PS C:\Users\Florian\Documents> $OutputEncoding

Preamble : BodyName : utf-8 EncodingName : Unicode (UTF-8) HeaderName : utf-8 WebName : utf-8 WindowsCodePage : 1200 IsBrowserDisplay : True IsBrowserSave : True IsMailNewsDisplay : True IsMailNewsSave : True IsSingleByte : False EncoderFallback : System.Text.EncoderReplacementFallback DecoderFallback : System.Text.DecoderReplacementFallback IsReadOnly : True CodePage : 65001

[mintty]

This is not the place to analyse PowerShell code, so let's try to boil down the issue to be demonstrated without it. Effectively, it seems you're sending something to the terminal that does not pass wslbridge2. Please try to reproduce that without PowerShell. You may use some logging tool like tee or screen or tmux to that aim. Also, can the issue be reproduced from an established (working) WSL session when you invoke something then? @Biswa96, any idea what may be going on?

[mintty]

can the issue be reproduced from an established (working) WSL session

On the other hand, your title suggests it might be related to the invocation (-e bash --login -c "...") which however you describe very incompletely. What is the exact target command line in your desktop shorcut and what is "..."? Does anything change if you replace "..."?

[florianfeiertag]

Thank you for your reply.

First time i tried to open the file through this command:

c:\Users\Florian\AppData\Local\wsltty\bin\mintty.exe --WSL="Debian" --configdir="C:\Users\Florian\AppData\Roaming\wsltty" -t '%1' -e bash --login -c "vim $(wslpath \"%1\")"

Which gives me the following result for files without umlauts

When i do the same with another file i get this

That made me think of an encoding problem. I could solve that partly with the powershell-script.

[mintty]

Please be clear about your setup. The command line with embedded %1 looks like an Explorer context menu entry in the registry. Could also be a .bat/.cmd file though. Please confirm/clarify.

[mintty]

OK, test scenario can be reduced like this, running from a cygwin command line, without vim or option -t: mintty -h alw --WSL=Debian -e bash -l -c "cat täst.txt" I guess the error message may be misleading (and it's different with the Alpine distribution), I have the suspicion that the error may occur in bash, due to a character encoding mismatch of the effective locale with the command line contents. To be analysed further.

[florianfeiertag]

Please be clear about your setup. The command line with embedded %1 looks like an Explorer context menu entry in the registry. Could also be a .bat/.cmd file though. Please confirm/clarify.

Yes it's a registry entry. Also tried a batch file as shown her:

@echo on & setlocal
chcp 65001>nul
set DATEI="%~1"
configdir="C:\Users\Florian\AppData\Roaming\wsltty" -t "%1" -e bash --login -c "vim \"$(wslpath '%1')\""
set DATEI=%DATEI:"='%
c:\Users\Florian\AppData\Local\wsltty\bin\mintty.exe --WSL="Debian" --configdir="C:\Users\Florian\AppData\Roaming\wsltty" -t "%~1" -e bash --login -c "vim \"$(wslpath %DATEI%)\""

[Biswa96]

First, how can I type those thingy without copy paste? Can't we just settle on ASCII char 😭 @mintty Try to add setlocale(LC_ALL, "") in the main function in wslbridge2.cpp. If this fixes the issue make sure it does not affect the previous locale issues.

[mintty]

Minimal test case: wslbridge2 echo täst @Biswa96, yes, setlocale(LC_CTYPE, "") as the first thing in main() fixes the issue.

[Biswa96]

Did you find any regression with old locale issues? The recent one I can remember is something related to CJK characters.

[mintty]

As there was no setlocale call before, the affected part of wslbridge2 (probably only the command line handling) must have been supporting ASCII only, so there cannot have been a CJK issue at the same level, I think.

[Biswa96]

Done.

[mintty]

OK, I'll add that to my patch for now. Or can we agree on a reworked patch that you would integrate in the repository? (Conditional if you prefer.)

[Biswa96]

Do you mean a new patch for wslbridge2 v0.7.1? I can create a small tag with this change.

[mintty]

Released 3.4.7.