3

In Windows Terminal, you can create a profile and add some start-up command (through commandline option in settings.json file. So when you start your profile, WT is executing the command, but then it's exiting (we can see for a second the new tab).

When starting a wsl profile in Windows Terminal, how can I execute linux commands AND keeping the current shell open? (so I can see the result, and keep on typing commands).

NB: I want to keep the current shell. This workaround start another shell, so that does not work here:

"commandline": "wsl -e bash -c \"foobar=`ls -a`; echo $foobar; exec bash\"",

. .. .bash_aliases .bash_history .bash_logout .bashrc .lesshsQ .lesshst .profile .ssh .viminfo .vimrc
test@xxx:~$ echo $foobar

test@xxx:~$

If the profile is Powershell, we have -NoExit:

"commandline": "powershell.exe -NoExit \"<Your command goes here>\"",

If the profile is CMD, we have the /k flag:

"commandline": "cmd /k \"<Your command goes here>\"",

I didn't find the wsl equivalent.

Related:

Windows Terminal version: 1.15.3465.0 - Wsl 2 running Debian bullseye 11.6

4wk_
  • 185
  • This isn't exactly a wsl problem. With -c bash will not remain once the command line passed is executed (similar to running the line with exec I think). --rcfile is the only workaround I can think of that fulfill your need. – Tom Yan Jan 11 '23 at 12:05
  • Based on the example you provided, can you just change it to export foobar=$(ls -a); echo $foobar; exec bash? foobar would then be available in the replacement shell. – NotTheDr01ds Jan 11 '23 at 13:11
  • @TomYan If I'm not mistaken, /f cmd flag and -NoExit powershell option are doing exactly what I need, so yes it is definitely related to wsl . I will look into --rcfile but using a file is not really convenient. Thanks! – 4wk_ Jan 11 '23 at 13:24
  • @NotTheDr01ds Yes, I know, but my point was giving an example to show that this is not the same shell ;) – 4wk_ Jan 11 '23 at 13:24
  • 1
    @4wk_ The role of wsl in this matter is like a "runner" that starts / run the Linux shell (bash or anything you like) ; even if wsl had something like -NoExit, it cannot change the way how bash runs a command or determine whether the shell will exit, unless bash itself has a switch for you to change how it works (so that e.g. wsl can translate its -NoExit to a switch that gets passed to bash). Put it in another way, even if wsl allows you to prevent itself from quitting, you'll just get an "empty" terminal or whatever that has no shell / process running. – Tom Yan Jan 11 '23 at 13:42
  • Thanks Tom Yan and @NotTheDr01ds, your comments here helped me resolve my similar question on passing environment variables to wsl – DuncG Jan 11 '23 at 13:58
  • @TomYan oh, very interesting indeed, thank you. So can we say (oversimplifying): terminal start wsl => wsl start bash => bash run commands and terminal start powershell (or cmd) => powershell (or cmd) run commands? – 4wk_ Jan 11 '23 at 14:55
  • Yes, pretty much like that. – Tom Yan Jan 11 '23 at 15:29

1 Answers1

2

As mentioned by @TomYan in the comments, the --rcfile option is probably the only real way to do this. You mentioned that you'd like to avoid the use of a file, though, which can also be accomplished (courtesy a WSL/WT-modified version of this SO answer and process-substitution )with:

wsl -e bash -c "exec bash --rcfile <(echo 'source ~/.bashrc; foobar=$(ls -a)')"

Keep in mind that Windows Terminal profiles seem to use CMD quoting and escaping rules. So keep an eye out for any "gotchas" if your command fails, and test it from the Command Prompt (CMD) profile first to see errors reported.

If you were doing this from PowerShell, the quoting/escaping rules would be a bit different. I'd recommend using Here-strings:

wsl -e bash -c @'
exec bash --rcfile <(echo 'source ~/.bashrc; foobar=$(ls -a)')
'@

For most users, however, try the following first to see if it meets your needs:

wsl -e bash -c \"export foobar=$(ls -a); echo $foobar; exec bash\""

If the need is to get a variable injected into the new shell, then export'ing the variable before running the new shell may be the best bet. In your use-case, however, you mentioned that this wasn't a viable option.

There are a few more ideas in this Unix & Linux question.

NotTheDr01ds
  • 21,923