Bundled wslvar command should not show spurious error message

[djneades]

Describe the bug Following a recent update (i.e. sudo dnf -y --refresh upgrade), the wslvar -s command has started showing a spurious error message relating to its invocation of which. For example:

$ wslvar -s LocalAppData
which: no C:\Users\djn\AppData\Local\Microsoft\WindowsApps\WhitewaterFoundryLtd.Co.FedoraRemixforWSL_kd1vv0z0vy70w\fedoraremix.exe in (/mnt/c/Program Files/Araxis/Araxis Merge:/mnt/c/Program Files/Araxis/Araxis Merge:/home/djn/Git/CTE/git:/home/djn/Git/CTE/hg:/mnt/c/Program Files/Araxis/Araxis Merge:/home/djn/Git/CTE/git:/home/djn/Git/CTE/hg:/home/djn/.local/bin:/home/djn/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Program Files/Araxis/Araxis Merge:/mnt/c/Program Files/Git/mingw64/bin:/mnt/c/Program Files/Git/bin:/mnt/c/Program Files/Git/usr/bin:/mnt/c/Program Files (x86)/Common Files/Oracle/Java/javapath:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/dotnet/:/mnt/c/Program Files/Microsoft SQL Server/130/Tools/Binn/:/mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/d/Program Files/Process Lasso/:/mnt/c/Program Files (x86)/Calibre2/:/mnt/d/Windows Kits/10/Windows Performance Toolkit/:/mnt/c/Program Files/Git/cmd:/mnt/c/Program Files/Git/mingw64/bin:/mnt/c/Program Files/Git/usr/bin:/mnt/d/Git/CTE/hg:/mnt/d/Git/CTE/git:/mnt/c/Users/djn/AppData/Local/Programs/Python/Python38/Scripts/:/mnt/c/Users/djn/AppData/Local/Programs/Python/Python38/:/mnt/c/Users/djn/scoop/apps/python/current/Scripts:/mnt/c/Users/djn/AppData/Local/Programs/Python/Python37/Scripts/:/mnt/c/Users/djn/AppData/Local/Programs/Python/Python37/:/mnt/c/Users/djn/AppData/Local/Microsoft/WindowsApps:/mnt/c/Program Files/Mercurial:/mnt/d/Users/djn/AppData/Roaming/Programs/Microsoft VS Code/bin:/mnt/d/WindowsApps:/mnt/d/Program Files (x86)/Microsoft Visual Studio/2017/Professional/Common7/IDE:/mnt/d/Program Files (x86)/Microsoft Visual Studio/2017/Professional/Common7/Tools:/mnt/c/Users/djn/AppData/Local/Microsoft/WindowsApps:/mnt/c/Program Files/Git/bin:/mnt/c/Program Files/Git/mingw64/bin:/mnt/c/Users/djn/scoop/shims:/mnt/c/Users/djn/scoop/apps/python/current:/home/djn/.go/bin)
C:\Users\djn\AppData\Local

The line beginning which: no … in the above output should not be shown.

Looking at the source of the /usr/bin/wslvar command included with Fedora Remix for WSL, this problem appears to be the result of the last elif in the following block of code:

# generate base exe locaiton
if [ ! -f ~/.config/wslu/baseexec ]; then
    # if it is not generated
    baseexec_gen
elif grep -q "/" ~/.config/wslu/baseexec; then
    # if baseexec is using the old linux style, regenerate
    baseexec_gen
elif ! which "$(cat ~/.config/wslu/baseexec)" >/dev/null; then
    # if baseexec cannnot be executed, regenerate
    baseexec_gen
fi

The Windows-style path in baseexec is not being converted to a Unix-style path prior to its being passed to which as an argument, resulting in the errors I am seeing. This change appears to have been introduced recently via this commit to wslutilities/wslu. I have left a suitable comment there suggesting a fix, but this problem is present in the current Fedora Remix for WSL and so I am raising this issue.

To Reproduce Run the wslvar command. See above for an example.

Fedora Remix for WSL Version 1.31.9.0

Windows Build

OS Name:                   Microsoft Windows 10 Pro for Workstations
OS Version:                10.0.19041 N/A Build 19041
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
BIOS Version:              American Megatrends Inc. 2001, 2019-07-31

[crramirez]

@djneades Thank you for the help. With your suggestion, WSLU can be fixed quickly

[patrick330602]

Thank you for the feedback. I am currently outside, will check it as soon as possible

[patrick330602]

Sorry for the late update, I am a bit busy recently. The problem is fixed and the update will be available tomorrow. Sorry for the long wait.