I am working in WSL Ubuntu
When i execute command directly, show wrong path
C:\Users\Administrator>bash -c 'pwd'
/
Expected output :
C:\Users\Administrator>bash -c 'pwd'
/mnt/c/Users/Administrator/
How to fix this
I'm not able to reproduce this on any of my systems. Is it possible that you have a cd / (or equivalent) somewhere in one of your startup scripts?
First, let's change that to use wsl.exe command in place of the deprecated bash.exe command:
wsl pwd
That should give you the same (wrong) result that you are already seeing, but let's confirm that.
Then, to start WSL and tell Bash to not execute your startup scripts, try:
wsl -e bash --noprofile --norc -c pwd
Then try the shorter:
wsl -e pwd
The -e/--exec argument tells WSL to run the command in place of the shell, so Bash (and its startup files) should never get called in the first place.
Related
I was assigned an account for log in to a remote server, and I want to change my default shell.
I tried chsh command but it says: chsh: "/public/home/{my_id}/bin/zsh" is not listed in /etc/shells.
If you don't have permission to install zsh system wide, a quick fix is to append exec ~/bin/zsh -l to ~/.bash_profile (if bash is the current shell), or an equivalent rc file for the current login shell.
zsh -l starts zsh as a login shell.
exec COMMAND replaces the current process with COMMAND, so you'll only have to type exit (or press ctrl+d) once.
~/.bash_profile is executed when bash starts as a login shell, you can still run command bash normally.
Depending what is in ~/.bash_profile (or equivalent), you may wish to avoid executing its other contents, by putting exec ~/bin/zsh -l at the start of the file (not the end), and copy/port anything important over to the zsh equivalent, $ZDOTDIR/.zprofile.
I might also do export SHELL="$HOME/bin/zsh", although I'm unsure of the full effects of setting SHELL differently to that specified for your user in /etc/passwd, to a shell not in /etc/shells, and to a shell binary in your home path.
First check all the shells available on your linux system
cat /etc/shells
Use chsh command line utility for changing a login shell with the -s or –shell option like this.
# chsh --shell /bin/sh tecmint
I am currently using ssh to access a linux computer. I use the command:
ssh -t user#hostaddress 'cd ~/Desktop && bash'
When I get there, I see that neither ~/.bash_profile nor ~/.profile are sourced. What are the rules surrounding when these are sourced in? The reason I call bash is because I am able to get terminal colors when I do bash (blue folders, etc) that I otherwise cannot get just by using ssh user#hostaddress.
You're not running bash as a login shell -- using bash -l should source .bash_profile. Otherwise you can use .bashrc.
I'm using GNU bash that is installed as git bash. On startup I need to change directory, so I'm doing it like this:
"C:\Program Files\Git\bin\sh.exe" --rcfile "./cd.sh"
Where cd.sh just contains cd /d/ command. Everything works fine here. Now I'm trying to get rid of cd.sh file and pass command to the shell as a parameter yet I want it to remain interactive, so I'm doing like this:
"C:\Program Files\Git\bin\sh.exe" -ic "cd /d"
It executes the command (tested with echo command) but then exits. Why doesn't it stay interactive?
From man bash:
An interactive shell is one started without non-option arguments and without the -c option ...
From man dash:
If no args are present and if the standard input of the shell is connected to a terminal (or if the -i flag is set), and the -c option is not present, the shell is considered an interactive shell.
Just updated cygwin to 1.7.28 on Windows 7.
Previously when starting X, the xterm would open with bash. For some reason it is now opening with sh?
What configuration changes do I need to make so that bash is the default shell again?
Not sure why this change happened.
The shortcut to open the xterm is the same as it was during my initial installation.
C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
But it still starts with the default shell set to sh.
I don't understand what changed.
My passwd file is the same as it was before.
It appears that everything starts fine with the standard shortcuts, but the X and xterm startups are not sourcing /etc/profile
I had /etc/shells already (upgraded from ??? to 1.7.29), might have been new with upgrade, but still didn't work (xterm running sh instead of bash). Changed permissions on bash to fix.
It was 700 changed to 755
chmod 755 /bin/bash
xterm seems to need the /etc/shells file to be present to work. Add an /etc/shells file with the following contents:
# /etc/shells: valid login shells
/bin/csh
/bin/sh
/bin/bash
/bin/tcsh
/usr/bin/csh
/usr/bin/sh
/usr/bin/bash
/usr/bin/tcsh
Chris
Run following command to set bash as default shell.
set shell=C:/cygwin/bin/bash
Note path C:/cygwin/bin/bash may vary.
(Removed answer regarding /etc/passwd)
I tried your command on my cygwin and got the same behavior, i.e. xterm loaded with /bin/sh.
However, if I simply ran startxwin.exe directly, I get an xterm loaded with /bin/bash.
Dunno if this works for you, but, worth a try.
I had the same issue with sh launching, but managed a different workaround after having issues with /etc/shells
I also wanted to get rid of the default white /bin/sh xterm that startxwin.exe created.
It turns out there's a .startxwinrc that startxwin.exe sources, so I had it do this:
# Launch prettier xterms with bash
. ./.profile
# Exit the cruddy white xterm launched by startxwin
exit
The dot-space syntax above is equivalent to "source" in bash, but is more shell-independent.
If I open a shell into a machine with: putty -load session_name and then execute a command to add a job to a Grid queue on a linux system (qsub -cwd -b hostname), everything works fine.
But if I add the command to a text file, and then do putty -load session_name -m file.txt, I get qsub: command not found
If I back out and simplify the text file to be only the command hostname and use the -m option, it also works fine.
If I use the Connection->SSH->Remote command, and do something similar as the -m command, I get the same results as from the command line.
I'm very much a novice at linux systems, and this seems like it should be a simple fix to tell something that 'qsub' exists somewhere. Either that or there are some restrictions on these remote access things...
Edit:
Ok, so the initial question was how to run it--and I figured that out (add an absolute path), but there are other environment variable issues as well. It appears that qsub requires the SGE_ROOT variable to be set, but that isn't set for the remote commands window either.
So, a better question is, how do I get the putty remote commands shell (using -m) to open with the same properties and setup as a manual command line shell?
qsub is on your path when you log in interactively, but in the non-interactive shell it is not. Give the full path in the script, or set PATH in the script, and you ought to fix your problem.
It seems you need to run your command in the context of an interactive session, but the sshd protocol doesn't directly do that. So try invoking the command indirectly through /bin/sh.
/bin/sh -i -c "qsub -cwd -b hostname"
The -i makes the shell initialize itself like an interactive one, so it will load all the environment variables in your .profile or .bashrc that are loaded in a real interactive shell. The -c provides a command to run within that interactive shell.
You shouldn't have to explicitly set any paths this way since it works in an interactive session.