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
Related
If I start ksh manually by typing
/usr/bin/ksh
in bash, then ksh starts in interactive mode. So far so good. But, since it isn't a login shell, it won't execute its $HOME/.profile, which I need it to do. I tried running
/usr/bin/ksh $HOME/.profile
but then it just executed .profile and exited back to bash, without going into interactive mode. I've tried using the -i flag to force ksh to go into interactive mode, but it doesn't seem to work when I also give it .profile to execute.
I am using ksh93 on Raspian Linux.
When you want the settings in .profile (or any other shellscript), make sure the file is processed in the current shell, not a subshell. Start the commandline with a dot.
. $HOME/.profile
This is not a login shell, just an environment with your .profile executed.
You can use $HOME/.kshrc just like .bashrc for Bash.
What does this command do?
exec bash -l
I found this command as part of a reminder text file were I wrote some instructions regarding how to create a ssh key and clone a git repo, but I wrote it a long time ago and I can't remember what it does.
exec executes a specified command, replacing the current process rather than starting a new subprocess.
If you type
bash -l
at a shell prompt, it will invoke a new shell process (the -l makes it a login shell). If you exit that shell process, you'll be back to your original shell process.
Typing
exec bash -l
means that the new shell process replaces your current shell process. It's probably slightly less resource intensive.
The reason for doing it is probably so that the new shell sets up its environment (by reading your .bashrc, .bash_profile, etc.).
See the bash documentation for more information:
Bash Startup Files for how a login shell differs from a non-login shell
Bourne Shell Builtins for documentation on the exec command.
(You should be able to read the manual on your own system by typing info bash.)
This will replace your current shell with a new bash shell run as a login shell.
I changed .bashrc file on my web server a little bit, to color links on ls -la and so on. But when I log in using ssh: ssh user#server and type ls -al nothing is coloring, seems like my .bashrc file has not been applied on login. When if I just type bash and then again ls -la - all works fine. In short, all my rules in .bashrc only apllied when I type bash just after authorization, a little boring.
When you log in via ssh, you invoke a login shell. When you type bash in an existing shell, you invoke an interactive shell.
.bash_profile is read when a login shell is invoked, and .bashrc is read when an interactive shell is invoked.
Try adding this to your .bash_profile:
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
See bash(1) for more details.
~/.bashrc is only read if the shell is interactive and not a login shell:
When an interactive shell that is not a login shell is started, bash reads and executes commands from
/etc/bash.bashrc and ~/.bashrc, if these files exist.
Furthermore:
Bash attempts to determine when it is being run with [...] sshd. If bash determines it is being run in this fashion, it reads and executes commands from ~/.bashrc and ~/.bashrc, if
these files exist and are readable. It will not do this if invoked as sh.
So:
your remote shell must be bash, not sh,
it must not be a login shell, and
it must be an interactive shell.
In my Debian server, all users run sh, but root runs bash;
when i start a ssh connection, i log in with my personal account that does not have root privileges;
i've installed rvm and I want to use it as root because using it from my personal user, it fails installing everything since the user does not have permissions to write where is neeeded; so everytime i need to type
source /usr/local/rvm/bin/rvm
before being able to use rvm; to avoid typing source command everytime, in sh i know i can put the command in /etc/profile file; is there something similar for bash?
I've tried to add "echo aaa" to /etc/profile, to see what happen;
when i login as my personal user, i get the "aaa" output; but when i type su and login as root, nothing happens... I think that when i use "su" command and login as root, the /etc/profile is not read
The same happens after installing by rvm a ruby release: I setup the default ruby version (as root) and then the ruby command is available for my personal user (but if i do "su" again and try to type "ruby -v" as root, i get "command not found"
Another thing: after login with my personal user, the rvm command is available; after typing "su", no more; if I add the source command to /etc/profile, once login is done with personal user, i can see a screen output from rvm (some kind of doc); the same happens after using the source command as root
bash -- being an extension of sh -- also reads /etc/profile.
bash specific alternatives include ~/.bash_profile for login shells, and ~/.bashrc and for non-login shells.
/etc/bash.bashrc is the global config for bash, though /etc/profile is usually sourced by bash as well.
You may need to run the command with 'sudo' in order to actually run it as root. I believe the shell config scripts for any shell will run as the user that is launching the shell. If you prefer, you could also run the binary in an 'sh' shell as well:
sudo /bin/sh -c /usr/local/rvm/bin/rvm
Here's some more info, just in case: https://wiki.debian.org/sudo
I've been editing .bashrc files and other init files, and it seems that I've left behind a few code snippets or two that are causing a few errors at the prompt (e.g. file missing), but I can't find them.
How do I debug the prompt to find out what init scripts I've carelessly hacked?
Most of the shells have debug flags that show the commands being executed. Bash may even have one that shows a command before expansion of variables and after. Have you tried checking (I believe) -c -x or -X flags and see if they show the information you are looking for.
You can set them as first thing in the rc files (most global one) or just pass it down into bash command by invoking it from another shell.
In fact, if you invoke bash from another shell, you can also use script command to record everything you see and do into the file, which makes postmortem analysis so much easier.
Try invoking bash with the -x flag, then sourcing your .bashrc or .bash_profile or whatever you're using. That ought to be prolix enough to find your problem
ie:
bash -x
source .bashrc
The easiest way to get a clean initial state is to SSH into your current host, but instead of letting SSH launch your shell with default settings, you provide an explicit command which prevents .bashrc from being read.
ssh -tt localhost /bin/bash --norc
The -tt forces SSH to allocate a TTY, which is what would normally happen when you open a shell connection, but is not default when running an explicit command.
The --norc prevents bash from reading your settings file (since we want to do that ourselves).
You should now be at a bash prompt, in a clean environment. This is useful for examining what variable are set to before your .bashrc runs etc. Enable tracing and source your .bashrc:
set -x # Enable tracing
source .bashrc
Try to see where you've defined prompt - probably it in some dot file in your home directory:
grep PS1 ~/.*
You can see current value of prompt by just printing it:
echo $PS1
HTH
Check the .bash_history file in your home directory to find out what commands you have been running. If you used commands like vi filename to open the init scripts, it will find them in the command history.