How can I get iTerm to use the newer version of bash that brew shows? Change a user's shell on OSX -


when brew upgradei see have newer version. how can use it?

$ bash -version gnu bash, version 3.2.51(1)-release (x86_64-apple-darwin13) copyright (c) 2007 free software foundation, inc. $ brew upgrade bash error: bash-4.2.45 installed $ bash /bin/bash 

i see have

/usr/local/cellar/bash/4.2.45/bin 

but when do

$ /usr/local/cellar/bash/4.2.45/bin/bash 

i still in

$ bash -version gnu bash, version 3.2.51(1)-release (x86_64-apple-darwin13) copyright (c) 2007 free software foundation, inc. 08:06:45 mdurrant w89123148q1 /usr/local/cellar/bash/4.2.45/bin master 

the contents of /etc/shells are:

/usr/local/cellar/bash/4.2.45/bin/bash  # (i added this) /usr/local/bin/bash /bin/bash /bin/csh /bin/ksh /bin/sh /bin/tcsh /bin/zsh 

chsh didn't seem hoped:

$ chsh -s /usr/local/cellar/bash/4.2.45/bin/bash changing shell mdurrant. password mdurrant: chsh: /usr/local/cellar/bash/4.2.45/bin/bash: non-standard shell $ bash --version gnu bash, version 3.2.51(1)-release (x86_64-apple-darwin13) copyright (c) 2007 free software foundation, inc. 

i have file here:

$ l /usr/local/cellar/bash/4.2.45/bin/bash -r-xr-xr-x  1 mdurrant  admin  699688 apr 14 19:54 /usr/local/cellar/bash/4.2.45/bin/bash* 

i've yet see new bash version anyway try interactively invoke it.

$ echo $bash_version shows

3.2.51(1)-release 

i tried using dscl , did

> change local/default/users/mdurrant usershell /bin/bash /usr/local/cellar/bash/4.2.45/bin/bash 

but got

<main> attribute status: edsattributenotfound <dscl_cmd> ds error: -14134 (edsattributenotfound) 

and list shows

> usershell: /usr/local/cellar/bash/4.2.45/bin/bash 

bash --version (or bash -version) not report current shell's version, version of bash executable comes first in $path.

[note: osx 10.10 (yosemite) first osx version /usr/local/bin placed before system paths such /bin in $path. 10.9, system paths came first. thus, @ time op asked question, bash --version reported system's bash's version (/bin/bash), not homebrew-installed version (/usr/local/bin/bash)]

if want know current bash shell's version, use:

echo $bash_version 

in other words: shell may have been changed - test flawed.


you can use chsh change current user's shell, follows:

[update: switched using /usr/local/bin/bash rather specific, versioned path in /usr/local/cellar/bash/<version>/bin/bash, homebrew automatically keep symlink @ /usr/local/bin/bash pointed recent installed version. tip of hat @drevicko.]

 # first, add new shell list of allowed shells. sudo bash -c 'echo /usr/local/bin/bash >> /etc/shells'  # change new shell. chsh -s /usr/local/bin/bash  

note you'll prompted password.
terminal tab/window create point on use new shell.

bonus tip @bmike: if want replace current shell instance instance of new shell right away, run:

exec su - $user  # instantly replaces current shell instance of new shell 

note you'll prompted password again.


alternatively, use dscl - osx directory services cli - change current user's shell; more cumbersome, however.

to examine current user's shell, use:

dscl . -read /users/$user usershell  # e.g. (default): 'usershell: /bin/bash' 

or, more simply, echo $shell, outputs file path (e.g., /bin/bash).

to change current user's shell to, e.g., /usr/local/bin/bash, use:

sudo dscl . -change /users/$user usershell /bin/bash /usr/local/bin/bash 

note:

  • the penultimate argument must value in effect.
  • it not necessary new value contained in /etc/shells interactive use, comments in /etc/shells state ftpd not allow users connect not using 1 of these shells.
  • simply quit , restart terminal.app (or iterm.app) change take effect - verify new shell echo $bash_version - reboot not required.

explanation of errors encountered op:

  • chsh: /usr/local/cellar/bash/4.2.45/bin/bash: non-standard shell implies /usr/local/cellar/bash/4.2.45/bin/bash not - not yet, or not in exact form - listed in /etc/shells.
  • <main> attribute status: edsattributenotfound: dscl error occurs when penultimate (next-to-last) argument specified -change command not match current attribute value - - admittedly strange - requirement attribute's current value specified in order change it.

while question suggests both conditions met, suspect weren't met @ right times, due experimentation.


Comments

Popular posts from this blog

windows - Single EXE to Install Python Standalone Executable for Easy Distribution -

c# - Access objects in UserControl from MainWindow in WPF -

javascript - How to name a jQuery function to make a browser's back button work? -