Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

iEdd

macrumors 68000
Original poster
Aug 8, 2005
1,956
4
Is it possible to update the version of bash used by Terminal.app?

Currently, I get:
Code:
$ bash -version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)

However, some of the built-in commands are old. For example, trying to run cut with --output-delimiter fails, as I have an outdated version of cut.

Is there some simple way to update everything (bash+builtins) to the latest GNU release? I haven't found anything promising from Googling, or from searching, so usual apologies if it's been covered before.

Thanks.
 

jiminaus

macrumors 65816
Dec 16, 2010
1,449
1
Sydney
To answer the core of your question, you can download, compile and install the latest version of bash if you wish.

But cut is not a builtin. It's an executable that lives in /usr/bin. Updating bash will do nothing to get to closer to solving your issue. Your issue is actually that you're trying to use a GNU extension to the standard cut command line args, but you're not using a GNU version of cut at all.

If you install the coreutils port from macports, you'll get the core GNU utilities. To avoid conflict they have a "g" prefixed to their name. So it's gcut instead of cut. While you're at it, you could also install the bash port to a later version of bash. The latest version of bash via macports is 4.2.8.
 
Last edited:

iEdd

macrumors 68000
Original poster
Aug 8, 2005
1,956
4
Sorry, yes, I meant built-ins and all the standard externals in usr/bin.

How can I get the latest versions of these programs, or their extensions? Say I want to update vim; where would I find it, and would putting it into the bin folder mean that my manual page is then outdated? I'm a bit new to all this... Edit2: vim is a bad example... I can easily find that with Google. I can't find cut though. Even then, it seems dodgy to poke around replacing things with sudo.

Edit: Ignore below, as you edited your post.
Also, for example compare the output of man cut to what's found here:
http://linux.die.net/man/1/cut

-d and --output-delimiter are different things.
 

jiminaus

macrumors 65816
Dec 16, 2010
1,449
1
Sydney
Sorry for this discontinuity. I'd actually edited my post twice. First is realised my mistake with -d verses --output-delimiter. Then I suggested macports.

These wont install into /usr/bin, for good reason. Instead they install into /usr/local/bin. You just need to add that to the front of your PATH environment variable for them to "override" the Mac OS X default utilities.

Man is normally intelligent in find manual pages relative to the executables in your PATH. Macports will install updated manual pages into /usr/local/share/man, so you should get the updated manual pages as well. If you don't, setup the MANPATH environment variable in the same as you do PATH.
 

iEdd

macrumors 68000
Original poster
Aug 8, 2005
1,956
4
Thanks a lot. For a second there I thought this thread might be really concise if we just reply in edits. :p

Installing into local sounds good. That at least alleviates my concerns of botching everything.
 

subsonix

macrumors 68040
Feb 2, 2008
3,551
79
is --output-delimiter just a linuxism or is it real unix? Might be good to look up. It might have less to do with version and more to do with Linux not respecting the standard.
 

subsonix

macrumors 68040
Feb 2, 2008
3,551
79
It's not in the POSIX.2 standard.

I suspected that, so by installing the GNU cut you are breaking comparability with POSIX. Meaning, scripts using it will not be compatible with the default OS X installation and creating a dependency on GNU cut. In my opinion it's better to use the default POSIX compliant cut, and use AWK for anything more involved than cut was originally intended for.


Edit: for a multi character delimiter using awk

Code:
awk -F"delimiter" '{ print $1 }' /path/to/file

Here $1 will print the first field, ($0 prints the entire line)
 
Last edited:

iEdd

macrumors 68000
Original poster
Aug 8, 2005
1,956
4
Okay, this all makes a lot of sense now. I'm actually doing this to get a bunch of scripts I was given to work properly. Anything I write myself would be done such that it worked on a stock Mac (ie. POSIX standard).
 

chown33

Moderator
Staff member
Aug 9, 2009
10,765
8,466
A sea of green
Okay, this all makes a lot of sense now. I'm actually doing this to get a bunch of scripts I was given to work properly. Anything I write myself would be done such that it worked on a stock Mac (ie. POSIX standard).

In that case, I recommend installing the Linux tools, but only as needed, and NOT in /usr/local. Maybe a /usr/linux/ directory tree, with a bin subdir.

Then you simply prepend /usr/linux/bin to your PATH when you want the Linux versions of commands, and you remove it when you want Posix versions of commands. In other words, you change the command-line environment by changing the where-to-find-commands environment variable.

You may need several Linux-specific commands, or you may only need 'cut'. In any case, install only the minimum number of specific commands, and only in a specific location, where they can be used only when needed.
 

iEdd

macrumors 68000
Original poster
Aug 8, 2005
1,956
4
Thanks. I went with the default coreutils install from MacPorts, which has placed it all in opt/local/bin, so it's well separated from usr/bin, plus all the GNU versions are used by preceding the command with 'g'. It works well so far and it leaves all the standard executables alone. :)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.