This has been frustrating me for two days and it seems like it should be a very simple thing. I was just created an account on a Solaris machine. Sun OS 5.10 I believe.
The default is Bourne shell which I don't want. I did a cat /etc/shells which results in:
/bin/sh
/sbin/sh
/bin/ksh
/usr/bin/ksh
Looks like Korn shell is all I can use.
I created a .profile file and wrote:
export SHELL=/usr/bin/ksh
Then I did a env and it looks like /bin/sh is still listed as my shell. I logged off, logged back on and now I get:
-sh: SHELL=/usr/bin/ksh: is not an identifier
I've tried adding #!/usr/bin/ksh at the beginning of the .profile. That didn't work. I've tried adding a semicolon at the end of the export. That didn't work. I've tried: SHELL=/bin/ksh and that didn't work either.
My end goal is to get this environment to a point where I can operate productively. I'm used to BASH where I have tab-completions, up-arrow for history, etc and this Bourne shell doesn't have any of that and it frustrates me to no end.
I know this must be simple but all my Googling comes to no avail. Can someone help me?
/etc/shells is not a standard Solaris file, you probably shouldn't rely on its contents.
On the other hand, bash is part of the default Solaris 10 installation. It should already be present as /bin/bash (/usr/bin/bash actually but /bin is a symlink to /usr/bin anyway).
If bash is not there, you might want to ask to the administrator to install the SUNWbash package from the Solaris_10/Product directory in the installation media.
Then, to update your shell, the regular way is to have the shell defined for your account updated. If it is local, that's the last field in your /etc/passwd entry.
Alternatively, you might use that hack at the end of your .profile:
[ ! "$BASH_VERSION" -a -x /bin/bash ] && SHELL=/bin/bash exec /bin/bash
In descending order of preference
ask the sysadmin to install bash and update /etc/shells and update your login shell
see if the chsh program is installed that will allow you to change your own login shell
ask the sysadmin to change your login shell to /usr/bin/ksh
modify your ~/.profile:
if type [[ >/dev/null; then
: # this is ksh
else
# not ksh
export SHELL; SHELL=/usr/bin/ksh
exec $SHELL
fi
Related
I am trying to install Anthos Service Mesh (ASM) for a Kubeflow installation and need /bin/bash to be v5+. MacOS comes with Bash v3.2.57 which doesn't work. Simply installing Bash v5+ in "/usr/local/bin" doesn't work either as several shell scripts for the install points to "/bin/bash" and thus I still get the old version.
I had hoped I could just temporarily move the new bash v5+ to "/bin/bash" and then revert after completing the ASM install - something like this:
>>>$sudo mv /bin/bash /bin/bash_old
>>>$sudo cp /usr/local/bin/bash /bin
>>>$make install_asm
>>>$sudo mv /bin/bash_old /bin/bash
>>>mv: rename /bin/bash to /bin/bash_old: Operation not permitted
So that doesn't seem to be possible
What would be the best way to get around this? It doesn't seem to work just adding an alias to .zshrc in the hope that whenever I execute a shellscript with "#!/bin/bash" it would actually call "/usr/local/bin/bash":
~/.zshrc:
alias /bin/bash="/usr/local/bin/bash"
>>>$/bin/bash --version
>>>GNU bash, version 5.1.8(1)-release (x86_64-apple-darwin19.6.0)
test_bash.sh:
#!/bin/bash
/bin/bash --version
>>>$sh ./test_bash.sh
>>>GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)
Perhaps there is a way for me be permitted to move the binaries as in the example above?
By the way already the "/usr/local/bin/bash" is a link - not sure if that has any influence on what I am trying to do.
>>>$ll /usr/local/bin/bash
>>>/usr/local/bin/bash -> ../Cellar/bash/5.1.8/bin/bash
Any hints are warmly welcomed!
I used a combination of adding my new shell location to the list of approved shells in /etc/shells, then changing my user's default shell with:
chsh -s /path/to/new/bash/version
as well as making sure my new bash location was exported to the front of my path not the end, so commands looking for just any bash find that first:
export PATH=/opt/homebrew/bin/bash:$PATH
No issues with this for far but this is a new machine and I'm just getting it set-up. If you have a SHELL environment variable set in any of your bash start-up scripts make sure to change it to your new bash binary also.
It is possible to view shorter path in my terminal (VS Code & Hyper) with WSL (Ubuntu). On top of the Ubuntu, I have installed zsh. Currently, I am using a git bash and path looks Lukas#Y50-70 ~/Coding but with the Ubuntu, I have something like this lukas#Y50-70 /mnt/c/Users/Lukas/Coding. When I have a project in another 2 folders or so and I have a long branch name it is annoying to have a full row unnecessary info (for me).
Here is a comparison of Ubuntu and git bash:
Thanks
I was able to solve this using Named Directories - by adding this line to your ~/.zshrc file
hash -d c=/mnt/c
you will see '~c/' in your prompt rather than '/mnt/c/' which I think is a lot nicer.
This has a similar effect to setting an alias for the directory but the name is reflected in how your path is displayed.
As an added bonus you can then switch to that directory at any time by typing ~c
Check if the zsh installation guide under WSL can help (from neurogenesis):
Install zsh with sudo apt-get install zsh
bash.exe is the entrypoint to the WSL / linux subsystem. You'll have to modify the windows shortcut to specify bash -c --login or modify ~/.bashrc with exec /bin/zsh to properly load a different shell.
/etc/passwd isn't consulted because it's not a full login process. Be sure to set your SHELL env var as well. See #846 for details.
Fix your umask before you start installing things, otherwise tools like zsh will complain.
Specifically, "group" and "other" permissions will have the same privileges that owner do. This causes zsh's compaudit and compinit to fail (both are related to command completion).
See #352 for details. umask 022 can be added to your ~/.bashrc.
NOTE: This should be done before trying to install zsh plugin managers like antigen (otherwise the directory/file permissions issues from git clones).
You should also do this before installing RVM or rbenv.
I ended up inserting a few lines to the top of my ~/.bashrc, something like the following:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
## Fix missing umask value
umask 022
## Launch Zsh
if [ -t 1 ]; then
cd $HOME
export SHELL=/bin/zsh
exec -cl $SHELL
fi
Issue 846 (mentioned in point 2) includes the comment:
A normal -c zsh symlink opened up in the wrong directory to me, but I managed using this (note the tilde):
C:\Windows\System32\bash.exe ~ -c /bin/zsh
See also "How to Use Zsh (or Another Shell) in Windows 10".
I know this isn't exactly the fix you were hoping for. I was looking to solve the same issue. The prompt was just too long and it was causing some of my commands to wrap to the next line. After seeing the comments on VonC's answer, I'm deciding to keep my next-best solution.
What I did in my ~/.bashrc file is this:
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u#\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\n\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u#\h:\w\n\$ '
fi
I added a \n right before the \$
So when I'm at my Windows home folder, it looks like this
ryan#DESKTOP-RSKAA4F:/mnt/c/Users/ryank
$
And I start typing my commands after the $. It takes up more vertical space, but at least I don't have to maximize my terminal window just to avoid text wrap.
It appears to me that just running 'cd' after starting the terminal session, re-bases the prompt to the normal '/home/(user)'
there should be no need for installing zsh or anything else. It works for me anyway.
also when starting the session at the root folder from windows, seems to do the trick.
I keep my sessions under
C:\vms
sample:
cd -d C:\vms\minikube\ubu_jenkinsX\rootfs
C:\vms\minikube\ubu_jenkinsX\rootfs>wsl -d ubu_jenkinsX
Yours may be under your userprofile in local data. Search for the rootfs folder
The reason your WSL prompt shows such a long path is because you're not actually in your home directory. You see, WSL has its own virtual filesystem separate from Windows, and Windows paths (like your C:\Users\Lukas\...) are stored under /mnt/c/Users/Lukas/.... Your WSL home directory would be /home/Lukas (since your WSL username is capitalized), but of course, that's not where your project is.
The fish shell has a prompt_pwd function that shortens a path to something like this:
0 ---- /m/c/U/L/Documents cd Something
0 ---- /m/c/U/L/D/Something prompt_pwd
/m/c/U/L/D/Something
Is that something you're interested in? You could port the function to Bash, or just switch to Fish, or just display the current directory name instead of path.
I use vim's :! external command function all the time, usually providing % as an argument to the shell command. For example :
:!psql -f %
I also have a lot of bash shell functions in my .bashrc that I use. For example:
psql-h1 ()
{
/usr/bin/psql -hh1 -d mydb "$#"
}
These bash functions aren't available from :! inside of vim. Is there a way to make them available?
Export your functions. That is:
psql-h1() { /usr/bin/psql -hh1 -d mydb "$#"; }
export -f psql-h1 ### <-- THIS RIGHT HERE
This will make them available to any copy of bash run as a child process, even if it's a noninteractive shell and so doesn't read .bashrc.
An alternative to exporting your functions (which may no reach Vim is there's a non-Bash shell in between; see here for such a case), you can instruct Vim to start an interactive shell, so that your .bashrc is read. Just pass the -i flag to Bash, via Vim's :help 'shellcmdflag'.
:set shcf=-ic
This answer assumes your vim isn't actually using bash to invoke the remote commands - this can be tested by running :!echo $0 in vim.
Specifically for vim, add:
set shell=/bin/bash
to your .vimrc.
In general, there's two strategies I've found to sometimes work when trying to get other programs to invoke my preferred shell:
export SHELL=/bin/bash
in eg. the .profile file, or:
ln -fsn /bin/bash /bin/sh
which updates the sh symlink to point to bash instead.
On many systems (certainly Ubuntu), /bin/sh is a symlink to a sh-compatible shell (such as bash), rather than the sh shell itself. Given this fact, some programs (I've seen this behaviour in GHC) seem to invoke /bin/sh, so changing where it points to will cause the programs to use bash instead.
The accepted answer didn't work for me. I'm going to go with setting shcf, as suggested elsewhere:
:set shcf=-ic
but another solutions is
!source ~/.bashrc && psql ...
Unfortunately, no solution allows the auto-completion for the command I'm creating to work properly. (The auto_completions suggested are for names of files in my current directory, rather than the ones I specified as follows in .bashrc
complete -F _generate_foo_completions foo
I have read so many suggestions about, not putting your customization aka commands in ".profile" file. Rather, create a .bash_profile for yourself and add your alias and etc.
But,when I open the new terminal, if there is only .bash_profile, OS X is not exporting/sourcing the commands mentioned in it. I have to manually source the .bash_profile.
If I create .profile file, on opening a new terminal, all my commands in .profile are executed and will be available readily.
Could you please help me in understanding, how does it works? Also, when to use .bashrc/.profile/.bash_profile files.
Thanks!
According to Apple,
zsh (Z shell) is the default shell for all newly created user accounts, starting with macOS Catalina.
So you should verify your default shell with the command:
$ echo $SHELL
If the result is /bin/bash your default shell is BASH, and if the result is /bin/zsh the default is ZSH.
Go to home with $ cd ~/ and create the profile (if it does not exist) and edit it with the commands:
For bash:
$ touch .bash_profile
$ open .bash_profile
For ZSH:
$ touch .zprofile
$ open .zprofile
According to the manual page that ships with OS X:
... it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.
It should only read ~/.profile as a last resort if neither ~/.bash_profile nor ~/.bash_login are readable.
On all of my OS X systems, I have my ~/.bash_profile set to:
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
It is highly recommended that you do this on OS X in order to get bash to read your ~/.bashrc file like you would expect.
It's also possible that your terminal shell is defaulting to sh instead of bash. You can verify this first:
$ echo $SHELL
/bin/tcsh
To change this to bash, you can go into your Terminal -> Preferences -> Startup tab, and change "Shell Opens With:" from "Default login shell" to Command and value "/bin/bash".
Alternately, you can change your default shell by executing the following command at the command prompt:
chsh -s bin/bash
After you do one of these, open a new shell window, and your .bash_profile should be sourced.
For anyone else who finds this, instead of bash_profile, for new versions of mac you can use .zshrc. I.E., do
open .zshrc
and add what you need there.
You can use zsh to fix the problem.
The Z shell (also known as zsh) is a Unix shell that is built on top
of bash (the default shell for macOS) with additional features. It's
recommended to use zsh over bash.
Installation
Install zsh using Homebrew: $ brew install zsh
Install Oh My Zsh: $ sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
Move to .bash_profile setting .zshrc file
To apply the changes you make you need to either start new shell
instance or run: source ~/.zshrc
If you are using zsh, you can source to .bash_profile by adding the following line to .zprofile
if [ -f ~/.bash_profile ]; then
source ~/.bash_profile
fi
It should be mentioned that bash will first look for a /etc/profile file, as stated in the Bash man pages.
When bash is invoked as an interactive login shell, or as a non-inter-
active shell with the --login option, it first reads and executes com-
mands from the file /etc/profile, if that file exists. After reading
that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile,
in that order, and reads and executes commands from the first one that
exists and is readable. The --noprofile option may be used when the
shell is started to inhibit this behavior.
I solved by simply adding bash (in a newline) into ~/.bash_profile file.
How can I tell what type my shell is? ie, whether it's traditional sh, bash, ksh, csh, zsh etc.
Note that checking $SHELL or $0 won't work because $SHELL isn't set by all shells, so if you start in one shell and then start a different one you may still have the old $SHELL.
$0 only tells you where the shell binary is, but doesn't tell you whether /bin/sh is a real Bourne shell or bash.
I presume that the answer will be "try some features and see what breaks", so if anyone can point me at a script that does that, that'd be great.
This is what I use in my .profile:
# .profile is sourced at login by sh and ksh. The zsh sources .zshrc and
# bash sources .bashrc. To get the same behaviour from zsh and bash as well
# I suggest "cd; ln -s .profile .zshrc; ln -s .profile .bashrc".
# Determine what (Bourne compatible) shell we are running under. Put the result
# in $PROFILE_SHELL (not $SHELL) so further code can depend on the shell type.
if test -n "$ZSH_VERSION"; then
PROFILE_SHELL=zsh
elif test -n "$BASH_VERSION"; then
PROFILE_SHELL=bash
elif test -n "$KSH_VERSION"; then
PROFILE_SHELL=ksh
elif test -n "$FCEDIT"; then
PROFILE_SHELL=ksh
elif test -n "$PS3"; then
PROFILE_SHELL=unknown
else
PROFILE_SHELL=sh
fi
It does not make fine distinctions between ksh88, ksh95, pdksh or mksh etc., but in more than ten years it has proven to work for me as designed on all the systems I were at home on (BSD, SunOS, Solaris, Linux, Unicos, HP-UX, AIX, IRIX, MicroStation, Cygwin.)
I don't see the need to check for csh in .profile, as csh sources other files at startup.
Any script you write does not need to check for csh vs Bourne-heritage because you explicitly name the interpreter in the shebang line.
Try to locate the shell path using the current shell PID:
ps -p $$
It should work at least with sh, bash and ksh.
If the reason you're asking is to try to write portable shell code, then spotting the shell type, and switching based on it, is an unreliable strategy. There's just too much variation possible.
Depending on what you're doing here, you might want to look at the relevant part of the autoconf documentation. That includes an interesting (and in some respects quite dismal) zoology of different shell aberrations.
For the goal of portable code, this section should be very helpful. If you do need to spot shell variants, then there might be some code buried in autoconf (or at least in one of the ./configure scripts it generates) which will help with the sniffing.
You can use something like this:
shell=`cat /proc/$$/cmdline`
Oh, I had this problem. :D
There is a quick hack, use ps -p $$ command to list the process with PID of the current running process -- which is your SHELL. This returns a string table structure, if you want, you can AWK, or SED the shell out...
The system shell is the thing you see when you open up a fresh terminal window which is not set to something other than bash (assuming this is your default SHELL).
echo $SHELL
Generally, you can find out all the constants defined by running
set
If the output is a lot of stuff then run
set | less
so you can scroll it from the top of the command line or
set > set.txt
To save the output to a file.
Invoking a different interactive shell to bash in your terminal does not mean that your system shell gets changed to something else i.e. your system shell is set to bash although you invoke a csh shell from a bash shell just that one session.
The above means that typing /bin/csh or /bin/python in bash or whatever does not set the system shell to the shell you invoked, at all.
If you really want to see the SHELL constant change then you need to set it to something else. If successful you should see the new shell whenever you open a fresh terminal...
It's old thread but...
In GNU environment You can sh --help and get something like
BusyBox v1.23.2 (2015-04-24 15:46:01 GMT) multi-call binary.
Usage: sh [-/+OPTIONS] [-/+o OPT]... [-c 'SCRIPT' [ARG0 [ARGS]] / FILE [ARGS]]
Unix shell interpreter
So, the first line is shell type =)