I have an Ubuntu-18.04 WSL instance installed and have a large set of scripts installed in it at /home/username/bin/scripts.
I have also updated the $HOME/.bashrc, $HOME/.bash_profile, /etc/bash.bashrc, /etc/profile and /etc/environment files to update $PATH to include /home/username/bin/scripts in the path.
*I'm well aware i only usually need it in my $HOME/.bash_profile, lots of places from experimenting
Say I have a script called sampleScript in /home/username/bin/scripts, when i try to run the command:
wsl sampleScript
It gives the error: /bin/bash: sampleScript: command not found
If I open up wsl in interactive mode I can run it just fine, but I would like to be able to expose the script to not be run in interactive mode.
I've tried making an environment variable SPATH='/home/username/bin/scripts' and setting WSLENV=SPATH/p, but it also does not show up if i do wsl echo $PATH.
*I'm doing this all in command line instead of powershell b/c powershell doesn't appear to be able to do wsl echo $PATH at all, it just returns empty
I have also tried: wsl -u username sampleScript; with no luck
Is there a way to customize the PATH for wsl interop mode or am i doing something incorrectly with WSLENV?
Related
I'm using VSCode and the official remote-ssh extension.
I would like to be able to write code /path/to/file in an ssh terminal or in the vscode integrated terminal in a remote window in order to open a file/folder in vscode remote.
I am aware that I can use code --folder-uri=vscode-remote://ssh-remote+ADDRESS/path/to/file from the local machine's terminal, but I want to be able to run a command from within the integrated vscode terminal and any other terminal session where I've ssh'd into the remote machine)
Currently, if I run code from a remote terminal it opens up a new vscode window on the remote machine.
To achieve this goal, in the past I've used the following alias on the remote machine:
alias code="${VSCODE_GIT_ASKPASS_NODE%/*}/bin/code"
Which looks for the code executable in ~/.vscode-server/bin/<COMMIT_ID>/bin before defaulting to the local /bin/code.
I got that alias from this related stackoverflow question.
However, this doesn't seem to work right now.
Upon closer inspection, it appears that there is no code executable in the vscode-server directory.
How can I fix this?
Both machines are running MacOS and visual studio code version f80445acd5a3dadef24aa209168452a3d97cc326, if that's relevant.
I also wanted to be able to run code from the integrated terminal when running VSCode with the "remote ssh" extension. In my case, the "remote" is a Linux box (named "aorus" below), and I want to use VSCode from a laptop running macOS (named "mbp").
As for you, I used to use the VSCODE_GIT_ASKPASS_NODE trick. Recently, I had to change the alias since code (or code-insiders in my case) wasn't available in bin/ anymore. It seems it has been moved to bin/remote-cli. The correct alias (tested with vscode 1.64.2):
alias code="${VSCODE_GIT_ASKPASS_NODE%/*}/bin/remote-cli/code"
If you also want this to work from other ssh sessions (not just inside the integrated terminal), you can create a short script that I called coder (r for "remote") which I have in ~/bin on my remote ("aorus"). Note that you need to be able to reach the local machine from your remote (I do that with Tailscale). The script looks like this:
#! /bin/bash
set -ex
remotehost=$(hostname)
localhost=mbp
cmd="code"
while [ $# -gt 0 ]; do
if [ -f "$1" ]; then
cmd+=" --file-uri \"vscode-remote://ssh-remote+$remotehost$(readlink -f "$1")\""
elif [ -d "$1" ]; then
cmd+=" --folder-uri \"vscode-remote://ssh-remote+$remotehost$(readlink -f "$1")\""
else
cmd+=" $1"
fi
shift
done
exec ssh $localhost -q -t -x "exec bash -l -c '$cmd'"
On my Mac, when running VSCode connected remotely to my Linux box, I can type this in the integrated terminal to open the file main.go present on my remote Linux box:
coder main.go
The reason I have to wrap code in bash -l is due to the fact that ssh, by default, runs in a non-login shell, which means that the ~/.bashrc on my Mac isn't picked up, meaning code isn't in the PATH. The error message looks like this:
bash:1: command not found: code
Another note: there is a shorter syntax documented here:
ssh -q -t -x mbp bash -l -c "code --remote=ssh-remote+aorus main.go"
I don't use this syntax is because this method isn't able to know whether you are opening just a single file (which should be open in the most recent VSCode remote session) or a folder (which should be open as a new VSCode remote session).
Finally, if you are using VSCode Insiders, you can create a symlink so that the command code works on your local machine (in my case, on my Mac):
sudo ln -sf /usr/local/bin/code-insiders /usr/local/bin/code
As already explained by maelvls the path has been changed.
But if you use it outside integrated terminal you will got message
Command is only available in WSL or inside a Visual Studio Code terminal
To avoid this you need to export VSCODE_IPC_HOOK_CLI in your .bashrc .
Use this script in your .bashrc
export VSCODE_IPC_HOOK_CLI=`ls -t /run/user/1012/vscode-ipc-* | head -n1`
alias code="~/.vscode-server/bin/*/bin/remote-cli/code"
If you want to open your file in your current visual studio use -r option.
code -r tes.txt
Note :
I can't call VSCODE_GIT_ASKPASS_NODE so I use full path, it is working well
I don't know if VSCODE_IPC_HOOK_CLI will show in different location, just check it in your integrated terminal visual studio code
tested on remote server Centos 7
local macOS Monterey version 12.2
Visual Studio Code Version: 1.64.2 (Universal)
Commit: f80445acd5a3dadef24aa209168452a3d97cc326
extension : remote-ssh
So I have two WSLs (version 2). Kali and Ubuntu. The code command works in Kali but Ubuntu says Command not found. Since it works in WSL, CMD and PowerShell, it is there in PATH variables. Any help?
edit: Ubuntu doesn't read VS Code in PATH variables, while Kali does. I opened the Environment Variables Wizard. VS Code is there.
In a "normal" case, like you are seeing in your Kali instance, WSL's init appends the Windows path to your Linux path. There are two things that I can think of that would cause that to not be happening correctly under your Ubuntu instance:
You or a script that you ran in Ubuntu modified your shell's startup files (assuming Bash, typically ~/.bashrc or ~/.profile) to edit the PATH, possibly removing the Windows elements, or at least the VSCode element.
Try running that instance without any Bash startup files (from PowerShell or CMD) with:
PS> wsl -d Ubuntu -e bash --noprofile --norc
and then try code .. This, of course, assumes that your Ubuntu instance is named Ubuntu. If it's named something else (wsl -l) then edit the -d Ubuntu as needed. You might also try launching it as wsl -d Ubuntu -e sh -c 'code .'
If that works, examine your startup files for any modifications to PATH.
Less likely (because you should know if you did this one), is that you can disable the WSL feature that appends the Windows PATH in a particular distribution/instance. Check for the existence of a /etc/wsl.conf file -- If it exists, the line appendWindowsPath=false would cause the behavior that you are seeing as well. Simply change the offending setting to true. Exit your Ubuntu instance, run wsl --terminate Ubuntu (again, substituting the correct distro name) and then restart. Check your PATH and try code . again then.
I've been trying to write a powershell script that automates my windows workspace setup and configuration and am currently stuck trying to redirect input to WSL when executing it for the first time. The core of the problem is that Ubuntu's first launch prompts for a username and password, then logs in to a bash shell. I tried writing down the input lines into a text file like so:
Username
Password
Password
exit
Then, I tried redirecting the input of wsl to the file:
Start-Process ubuntu2004.exe -RedirectStandardInput stdin.txt -NoNewWindow -Wait
The above didn't work as executing WSL just starts spamming Enter new UNIX username: adduser: only one or two names allowed. I tried doing same in CMD with the < input redirection, but the result is the same.
This is not exactly the answer to your question, but in my opinion, ansible is better suited for such a task.
I myself recently became interested in assembling a workspace in wsl and ansible seemed to me the best solution.
Before starting the build, you will need to perform minimal steps (create a user and install several packages, all this can be placed in the readme), but then there will be no restrictions.
You can find several ready-made examples of wsl assembly via ansible on github.
A few ideas for setting the username/password in a new Ubuntu WSL instance:
First, a "PowerShell sendkeys" via COM or Interop might work for this. It's probably the closest in behavior to what you are actually asking.
Second, and perhaps most promising, I just tried this with a new Debian WSL installed from the Store (since I didn't want to mess with my Ubuntu install).
When running debian.exe (like ubuntu2004.exe), I let it run the install, then I Ctrl+C'd out of it when it started asking for the default username/password. At that point, the WSL instance is installed, but with only root. I assume that your script can let the command run for a certain period of time, then kill the process to replicate this.
From your script, you should then be able to run wsl -u root useradd --create-home --user-group --groups adm,dialout,cdrom,floppy,sudo,audio,dip,video,plugdev,netdev --password "encryptedPassword" username (see here for creating the encrypted password). I think that will get you a stock Ubuntu user the way that WSL sets it up.
You'll then need to either create a /etc/wsl.conf file (instructions) letting the instance know that that user is the default, or LxRunOffline lists this as one of its features.
But I'd also throw in that you might just want to keep a "backup" of an existing WSL instance that you start from. Do a wsl --export <distroname> <imagename.tgz>, then you can import it when setting up the new Windows host by copying the tgz over and doing a wsl --import <DistroName> <DirectoryWhereYouwantItToLive> <imagename.tgz>.
If you want, you can keep this image up to date with your desired WSL configuration, so that you don't have to recreate it when you rebuild the Windows hosts. That said, this is where I do follow #Mystic's suggestion of using Ansible to store my WSL "configuration as code". It allows me to not only recreate my WSL instances, but also that same configuration when I set (or reset) a Linode host or another Linux system.
I can open a powershell and type
> Ubuntu
to open a WSL ubuntu shell on windows 10. This will always take me to the WSL home directory. How would I instead open the terminal in the same location that the powershell is currently in?
FYI. I need this for creating a right click "open terminal here" type registery key for windows explorer.
If we look at what running ubuntu.exe actually does:
PS C:\> ubuntu.exe /?
Launches or configures a Linux distribution.
Usage:
<no args>
Launches the user's default shell in the user's home directory.
install [--root]
Install the distribution and do not launch the shell when complete.
--root
Do not create a user account and leave the default user set to root.
run <command line>
Run the provided command line in the current working directory. If no
command line is provided, the default shell is launched.
config [setting [value]]
Configure settings for this distribution.
Settings:
--default-user <username>
Sets the default user to <username>. This must be an existing user.
help
Print usage information.
We can see that it by default launches the WSL shell inside the home directory. If we want run inside it inside the current directory open in PowerShell, we need to specify the run option. So the full command will be ubuntu.exe run.
Another option is to just run wsl.exe or bash.exe. These commands will by default open WSL in the current working directory.
Note: We don't need to specify the .exe after the commands. Running ubuntu, wsl and bash all work as well. PowerShell knows how to run executables without specifying the extension.
method 1:
set Ubuntu to wsl default distribution by wsl --set-default Ubuntu
just type wsl and you are in the current Powershell directory
method 2:
open other folder
wsl.exe --cd $pwd or wsl.exe --cd "path"
I have script lets say:
C:\foo.bsh
I want to be able to run this command via the windows run command:
Start -> Run
Windows Key + R
and type something small like 'foo' and hitting return.
However, I do not want a cmd prompt to be visible. This script does some preprocessing for an IDE. I do not want the cmd prompt to be open for the lifetime of the IDE process.
I have tried:
1) Creating a bat file with the following contents:
c:\cygwin\bin\bash --login "C:\foo.bsh" (this fails because it keeps a cmd open)
2) Converting the above bat file to an exe using bat_2_exe_converter (does not make the cmd silent)
thoughts?
EDIT: The solution so far suggests something to type from an actual cygwin shell. I am trying to get a faster solution by having something short I can type in the Windows run command. Also, the nohup command; exit doesn't automatically kill the box - however I can manually kill it without killing the IDE process. The run command accepts shortcuts (.lnk's), bat's, exe's.
Try the run.exe command of cygwin. It is a big install, a complete unix environment for your Windows machine. Suppose you installed it at c:\cygwin\.
No mystery, just run c:\cygwin\bin\run.exe <your command here> and you will have your no dos window execution.
You can run it from any DOS window (run cmd.exe from the start menu). You don't need to run it from cygwin.
To make it easier, append C:\cygwin\bin to your %PATH% env var (My Computer → Properties → Advanced → Environment Variables) (Kudos to Felipe Alvarez comment).
Now you can just type
c:\cygwin\bin\run.exe "C:\foo.bsh"
You must create a link in your Start Menu with this command so will be able to run it with Win-R.
Here is the man page of the runcommand:
$ man run
RUN(1) run 1.3.0 RUN(1)
NAME
run - start programs with hidden console window
SYNOPSIS
run [ -p path ] command [ -wait ] arguments
runcommand [ -p path ] [ -wait ] arguments
DESCRIPTION
Windows programs are either GUI programs or console programs. When
started console programs will either attach to an existing console
or create a new one. GUI programs can never attach to an exiting con‐
sole. There is no way to attach to an existing console but hide it if
started as GUI program.
run will do this for you. It works as intermediate and starts a pro‐
gram but makes the console window hidden.
With -p path you can add path to the PATH environment variable.
Issuing -wait as first program argument will make run wait for program
completition, otherwise it returns immediately.
The second variant is for creating wrappers. If the executable is
named runcommand (eg runemacs), run will try to start the program (eg
emacs).
EXAMPLES
run -p /usr/X11R6/bin xterm
run emacs -wait
runemacs -wait
run make -wait
AUTHORS
Charles S. Wilson
Harold L Hunt II
Jehan Bing
Alexander Gottwald
Version 1.3.0 November 2005 RUN(1)
You can use either...
c:\cygwin\bin\bash -l /path/to/script_to_interpret.sh
...or...
c:\cygwin\bin\bash -l -c /path/to/executable_script.sh
Note: the -l flag tell bash to "act as if it had been directly invoked by login" and use Bash Startup Files. This is important in that it sets your $PATH and other things you rely on when you launch a cygwin terminal. If you don't include -l or --login you will get "command not found" when you try to call anything except of a bash builtin.
The difference between the 2 is like the difference between doing...
bash script_to_interpret.sh
...and...
./executable_script.sh
...in *nix. The former interprets the script using bash. The latter executes the script (only if it has chmod +x executable_script.sh) and interprets it according to its "shebang" line. The latter method is also what you want to do if your executable is not a script at all, like a *nix binary compiled from source.)
It has been bugging me for a while I couldn't find the solution for this, but I finally got the right mix together.
You can simply do the following if you have cygwin on your PATH:
run bash test.js
If cygwin is not on your path, you can do this:
c:\cygwin\bin\run.exe -p /bin bash test.js
If you are looking for more control over the created window (maximize, etc) it looks like you can use cygstart also.
Sources:
- neves answer above (though that wasn't enough by itself for me personally to figure it out)
- http://cygwin.com/ml/cygwin/2008-09/msg00156.html
As the terminal can't close while your script is still running, try the command:
"nohup C:\foo.bsh; exit"
This way your script will be backgrounded and detached from the terminal, and it should exit quickly so the terminal goes away. I think that the window may still 'flash' with this approach, but the results should be better than what you're getting.
I'm running Cygwin64 and the xwin server link points to:
C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
This creates an icon AND a notification on the taskbar. I don't like that. The icon is rather useless, the notification has all your menu options from .XWinrc.
So... I wrote a .vbs script to silently run this command and make the icon go away:
Set objShell = CreateObject("WScript.Shell")
objShell.Run("C:\cygwin64\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe"), 0
Another imperfect possibility is to run the script via a shortcut and set the shortcut's Run option to "minimized".
Go to the directory where you have installed cygwin(on my machine it is c:/cygwin64/bin)
Once there simply type "bash.exe"