What is the difference between calling a command via “wsl [command]” and opening a wsl shell and calling “[command]”?

by

To be honest, when I first looked at this question, I thought it would be an easy answer. Oh how wrong I was. There are a lot of nuances to how this works.

Let’s start with the fairly “easy” part, though. The main difference between the first method and the second:

  • wsl by itself launches into a login (and interactive) shell
  • the shell launched with wsl echo $PATH is neither a login shell nor an interactive shell

So the first will source both login scripts (e.g. ~/.profile) and interactive startup scripts (e.g. ~/.bashrc). The second form does not get to source either of these.

You can see this a different way (and get to the solution) with the following commands:

  • wsl -e bash -c 'echo $PATH'
  • wsl -e bash -li -c 'echo $PATH'

The -li forces bash to run as a login and interactive shell, thus sourcing all of the applicable startup scripts. And, as @bovquier points out in the comments, a single quote is needed here to prevent PowerShell from interpolating the $ before it gets to Bash. That, or escape it.

You should be able to run TeX Live the same way, just replacing the “echo $PATH” with the startup command you need for TeX Live.

A second option would be to create a script that both adds the path and runs the command, and just launch that script through wsl /path/to/script.sh

That said, I honestly don’t think that your current login/interactive PATH is coming from /etc/environment. In my testing, at least, /etc/environment has no use in WSL, and that’s to be expected. /etc/environment is only sourced by PAM modules, and with no login check performed by WSL, there’s no reason to invoke PAM in either the wsl nor the wsl echo $PATH commands.

I’d expect that you still have the PATH setting in ~/.bashrc or somewhere similar), and that’s where the shell is picking it up from at the moment.

While this isn’t necessarily critical to understanding the answer, you might also wonder, if /etc/environment isn’t used for setting the default (non-login, non-interactive) path in WSL, what is? The answer seems to be that it is hard-coded into the init that starts up WSL. That init is also what appends the Windows path (assuming you don’t have that feature disabled in /etc/wsl.conf).

More Related Contents:

  1. Does WSL 2 really support 32 bit program?
  2. How to set up working X11 forwarding on WSL2 [closed]
  3. Exec format error 32-bit executable Windows Subsystem for Linux?
  4. Assembly compiled executable using INT 0x80 on Ubuntu on Windows Subsystem for Linux doesn’t produce output
  5. How can nodemon be made to work with WSL 2?
  6. How do I use Bash on Ubuntu on Windows (WSL) for my VS Code terminal?
  7. Connecting to WSL2 server via local network
  8. Docker – failed to compute cache key: not found – runs fine in Visual Studio
  9. Get err_connection_refused accessing django running on wsl2 from Windows but can curl from Windows terminal
  10. Show matplotlib plots (and other GUI) in Ubuntu (WSL1 & WSL2)
  11. Enable Systemd in WSL 2
  12. How can I run a Windows executable from WSL (Ubuntu) Bash
  13. Access a localhost running in Windows from inside WSL2? [closed]
  14. chmod WSL (Bash) doesn’t work
  15. WSL Redis encountered System has not been booted with systemd as init system (PID 1). Can’t operate [closed]
  16. No internet connection on WSL Ubuntu (Windows Subsystem for Linux) [closed]
  17. Running graphical Linux desktop applications from WSL 2 – “Error E233: cannot open display” [closed]
  18. Why is WSL extremely slow when compared with native Windows NPM/Yarn processing?
  19. How to remove the Win10’s PATH from WSL
  20. How to check if a program is run in Bash on Ubuntu on Windows and not just plain Ubuntu?
  21. Volume mounts not working Kubernetes and WSL 2 and Docker
  22. WSL run linux from windows without spawning a cmd-window

Leave a Comment