I work in linux a lot… not bsd. So the OSX (bsd style) implementation of sed really throws me for a loop when I go text-file-spelunking, whats worse is that my scripts using sed aren’t portable between the two OSs.
A quick googling this morning landed me here: http://wiki.octave.org/wiki.pl?OctaveForMac which gives perfectly good instructions on installing sed. except it didnt work. I grabbed the latest version of sed (4.1.5) and got the error
sed: 1: "install_sh=/Users/apoka ...": command i expects \ followed by text sed: 1: "install_sh=/Users/apoka ...": command i expects \ followed by text
Ironic, huh? Well taking a guess that at some point sed hadcome to depend on its own functionality to configure itself I jumped back a version… Figuring i replace BSD sed with an out of date GNU sed, and then use the old GNU sed to build the new GNU sed. Which worked great. I Installed first sed-3.0.2, and then 4.1.5 in this manner:
./configure --prefix=/usr/ --with-included-regex --with-included-gettext && make && sudo make install
I’m happy with my -r again…
# date | sed -r s/'[0-9]'/'?'/g Thu Apr ?? ??:??:?? PDT ????
For BSD sed you can use -E, which does the same thing as -r in GNU sed.
You absolutely can, and up till now i have. still doesn't help when you spend a lot of time in both, and like to be able to copy and paste one-liners between the two… doesn't feel right to have to sed your sed scripts… ya know?
Thanks brother for the tip.
David
Thanks! I found this while trying to do the same thing for the same reasons.
Wouldn't have thought to install an old version of sed.
I also got that error. I was trying to install sed so I could develop a script to be used on an ancient Sun server with an ancient version of sed that doesn't even know about extended regex, as far as I can tell. It doesn't have a manpage or even an option to display the version. At least if you give it an option it doesn't understand it spits out the minimal "usage" message.
So anyway, thanks for the suggestion about installing an older version of sed to build the latest version. I don't think that ever would have occurred to me. I'm surprised that the sed developers didn't realize there were different versions of sed with different options and write the configure script to recognize the rather predictable errors and respond to them by trying other options.
Also, I was going to go ahead and install sed in /usr/local/bin and keep it out of the default command path, assuming that there are probably cron tasks and other system utilities that depend on sed -E. Have you run into any issues there?
I dont forsee any problems with that except for portability. if you specify /usr/local/bin/sed and move the script to another box you have to remember to move sed. I guess in this case you could have your script put /usr/local/bin at a higher precedence in your $PATH (or QV) and then test (or not) the version at runtime. by using "sed' and not "/path/to/sed" this would allow a more graceful failover on a new system (with a new sed)
Austin, Try /usr/sfw/bin/gsed – it's bundled with various Solaris releases.