<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: building sed for osx</title>
	<atom:link href="http://blog.apokalyptik.com/2008/04/24/building-sed-for-osx/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.apokalyptik.com/2008/04/24/building-sed-for-osx/</link>
	<description>The random things that spew forth from my brain...</description>
	<lastBuildDate>Mon, 06 Sep 2010 01:58:58 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1-alpha</generator>
	<item>
		<title>By: apokalyptik</title>
		<link>http://blog.apokalyptik.com/2008/04/24/building-sed-for-osx/comment-page-1/#comment-8375</link>
		<dc:creator>apokalyptik</dc:creator>
		<pubDate>Fri, 20 Mar 2009 16:38:41 +0000</pubDate>
		<guid isPermaLink="false">http://blog.apokalyptik.com/?p=282#comment-8375</guid>
		<description>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 &quot;sed&#039; and not &quot;/path/to/sed&quot;  this would allow a more graceful failover on a new system (with a new sed)</description>
		<content:encoded><![CDATA[<p>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 &#8220;sed&#8217; and not &#8220;/path/to/sed&#8221;  this would allow a more graceful failover on a new system (with a new sed)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Austin Tashis</title>
		<link>http://blog.apokalyptik.com/2008/04/24/building-sed-for-osx/comment-page-1/#comment-8373</link>
		<dc:creator>Austin Tashis</dc:creator>
		<pubDate>Fri, 20 Mar 2009 10:35:56 +0000</pubDate>
		<guid isPermaLink="false">http://blog.apokalyptik.com/?p=282#comment-8373</guid>
		<description>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&#039;t even know about extended regex, as far as I can tell. It doesn&#039;t have a manpage or even an option to display the version. At least if you give it an option it doesn&#039;t understand it spits out the minimal &quot;usage&quot; message.

So anyway, thanks for the suggestion about installing an older version of sed to build the latest version. I don&#039;t think that ever would have occurred to me. I&#039;m surprised that the sed developers didn&#039;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?</description>
		<content:encoded><![CDATA[<p>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&#8217;t even know about extended regex, as far as I can tell. It doesn&#8217;t have a manpage or even an option to display the version. At least if you give it an option it doesn&#8217;t understand it spits out the minimal &#8220;usage&#8221; message.</p>
<p>So anyway, thanks for the suggestion about installing an older version of sed to build the latest version. I don&#8217;t think that ever would have occurred to me. I&#8217;m surprised that the sed developers didn&#8217;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.</p>
<p>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?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: TjL</title>
		<link>http://blog.apokalyptik.com/2008/04/24/building-sed-for-osx/comment-page-1/#comment-8234</link>
		<dc:creator>TjL</dc:creator>
		<pubDate>Thu, 15 Jan 2009 18:48:48 +0000</pubDate>
		<guid isPermaLink="false">http://blog.apokalyptik.com/?p=282#comment-8234</guid>
		<description>Thanks! I found this while trying to do the same thing for the same reasons.

Wouldn&#039;t have thought to install an old version of sed.</description>
		<content:encoded><![CDATA[<p>Thanks! I found this while trying to do the same thing for the same reasons.</p>
<p>Wouldn&#8217;t have thought to install an old version of sed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Cancel</title>
		<link>http://blog.apokalyptik.com/2008/04/24/building-sed-for-osx/comment-page-1/#comment-8047</link>
		<dc:creator>David Cancel</dc:creator>
		<pubDate>Wed, 17 Dec 2008 22:50:54 +0000</pubDate>
		<guid isPermaLink="false">http://blog.apokalyptik.com/?p=282#comment-8047</guid>
		<description>Thanks brother for the tip.

David</description>
		<content:encoded><![CDATA[<p>Thanks brother for the tip.</p>
<p>David</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: apokalyptik</title>
		<link>http://blog.apokalyptik.com/2008/04/24/building-sed-for-osx/comment-page-1/#comment-7784</link>
		<dc:creator>apokalyptik</dc:creator>
		<pubDate>Sat, 26 Apr 2008 20:29:18 +0000</pubDate>
		<guid isPermaLink="false">http://blog.apokalyptik.com/?p=282#comment-7784</guid>
		<description>You absolutely can, and up till now i have. still doesn&#039;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&#039;t feel right to have to sed your sed scripts... ya know?</description>
		<content:encoded><![CDATA[<p>You absolutely can, and up till now i have. still doesn&#8217;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&#8230; doesn&#8217;t feel right to have to sed your sed scripts&#8230; ya know?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joseph Scott</title>
		<link>http://blog.apokalyptik.com/2008/04/24/building-sed-for-osx/comment-page-1/#comment-7783</link>
		<dc:creator>Joseph Scott</dc:creator>
		<pubDate>Sat, 26 Apr 2008 20:26:29 +0000</pubDate>
		<guid isPermaLink="false">http://blog.apokalyptik.com/?p=282#comment-7783</guid>
		<description>For BSD sed you can use -E, which does the same thing as -r in GNU sed.</description>
		<content:encoded><![CDATA[<p>For BSD sed you can use -E, which does the same thing as -r in GNU sed.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
