Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the '10.4: Update to a newer bash shell' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.4: Update to a newer bash shell
Authored by: wgscott on Sep 06, '06 01:22:09PM

You don't have to make any symbolic links.

Just issue the command


chsh -s /sw/bin/bash




[ Reply to This | # ]
10.4: Update to a newer bash shell
Authored by: sjk on Sep 06, '06 01:45:25PM
Just issue the command chsh -s /sw/bin/bash
With that method any references to /bin/bash will still use the original version.

[ Reply to This | # ]
10.4: Update to a newer bash shell
Authored by: wgscott on Sep 06, '06 02:49:23PM

Exactly.

System scripts that use bash (and sh, which is bash), might be dependent upon the older versions.

But exactly the same objection can be made if you put the symlink in to /usr/bin/bash. Those scripts will still run the copy in /bin.



[ Reply to This | # ]
10.4: Update to a newer bash shell
Authored by: chleuasme on Sep 06, '06 05:06:34PM
anyway, I'm not sure the shell really changed with the symlink method below ; bash --version give the answer of the first bash found int the PATH, not the running shell
that's why the autor should prefer ^-x ^-v for his tests, or echo $SHELL

I tried your command but I can't get any result (I cleaned my /etc/shells before of my /opt/local/bin/bash addition, and reset Netinfo to /bin/bash)
I suppose it's the same that what I proposed before

[ Reply to This | # ]

10.4: Update to a newer bash shell
Authored by: sjk on Sep 06, '06 07:07:26PM
System scripts that use bash (and sh, which is bash), might be dependent upon the older versions.
Yep. My point was that if you want scripts (or whatever) to access a newer version then the /bin originals need to be replaced (with copies and/or links). [btw, any clue why bash and sh aren't hard linked in /bin?]

But exactly the same objection can be made if you put the symlink in to /usr/bin/bash. Those scripts will still run the copy in /bin.
True. For minimal intrusion in reserved system directories I'd rather install a new version of any shell in /usr/local/bin, /opt/local/bin, or /sw/bin instead of /usr/bin. Then optionally replace /bin originals (after preserving backups) with symlinks, knowing there's some risk of them being overwritten by Software Update. And likely not need to fuss with NetInfo or chsh, unless switching to a different shell.

[ Reply to This | # ]
10.4: Update to a newer bash shell
Authored by: wgscott on Sep 06, '06 09:46:57PM
The reason they are copies and not hard links has to do with the HFS+ file system. Hard links exhibit some pathological behaviors. This is explained in a cheerfully snarkish dialog

[ Reply to This | # ]
10.4: Update to a newer bash shell
Authored by: JadeNB on Sep 07, '06 09:08:22AM

Thanks so much for posting this link. I was wondering about this strange behaviour, but thought I (being relatively new to Unix) must just be doing something wrong.



[ Reply to This | # ]
10.4: Update to a newer bash shell
Authored by: wgscott on Sep 06, '06 10:08:08PM
10.4: Update to a newer bash shell
Authored by: wgscott on Sep 06, '06 10:10:18PM

Another bizarre thing I noticed once about links and shells. Back before ksh was included on os x, if I needed ksh in a script, I found a hard link to zsh worked but a symbolic link caused errors in the script. The zsh manual says a soft link should be fine, but it wasn't.



[ Reply to This | # ]
Awesome, fixed double-slash problem
Authored by: lullabud on Sep 06, '06 05:48:31PM

Awesome, I was looking for a way to change my shell on a remote Mac. Now I can cd into crazy path names without ending up with double-slashed special characters!



[ Reply to This | # ]