<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on Simple filters in Perl, Ruby, and Bourne shell ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-339517/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-06-18T13:58:28-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[I think you missed some important details.]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3402691]]></link>
        <description><![CDATA[0. Your response was in reply to a comment Justin James made, which was entirely about Perl and not at all about bash.  I'll go by the assumption you're complaining about the article instead.1. Nobody said succinctness was equivalent to power.  The specific statement about power in relation to the shell merely said that the input filter loop idiom used with the Bourne shell was less powerful than the equivalent for Ruby and Perl.2. The Bourne shell (sh) is not the Bourne again shell (bash), so the article didn't even say anything about bash.3. You said:&gt;  second of all, a shell script can take arguments, so for example:while read xxx ; do ; echo $xxx; done   $1eliminates the need for a redirect on the command line. You have an extraneous semicolon after your  do .  Your code example, even after having that semicolon fixed, will not take a stream through a pipe, either -- which means it falls short of the capabilities of the version in the article in terms of functionality and flexibility.  Yes, you eliminated the redirect at the command line, but only by breaking the script for its most common use case.4. I'm not sure what a Java-based build system has to do with writing filters.  While bash can certainly be used for a lot of scripting, though, that doesn't mean it's the best tool for the job -- and, in most of the cases I've seen of scripts that people actually considered worth sharing, it has  not   So bash has its place, i don't think people who use command line interfaces would want to have to type perl.Well, sure -- use bash as your interactive shell if you want to.  I prefer tcsh as my interactive shell, but bash can work for you too.  Go for it.That's not the same thing as writing software, by a long shot, though.  I have yet to see bash used to write code where sh or a &quot;real&quot; programming languages would not be a better fit, and the same goes for tcsh.  Try writing your admin scripts in the Bourne shell (sh, not bash); if you find yourself missing some bash capabilities, consider whether a language like Perl, Python, or Ruby might be a better fit.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3402691]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Mon, 27 Dec 2010 07:37:07 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[bash not powerful?]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3402015]]></link>
        <description><![CDATA[first of all, succinct is not equivalent to powerful.second of all, a shell script can take arguments, so for example:while read xxx ; do ; echo $xxx; done  $1eliminates the need for a redirect on the command line.thirdly, while a language like perl makes some tasks easier, in my experience almost all my needs of scripting things i do for development (as opposed to the data manipulation you may need to do for a product) are met by bash and now-a-days by ant.So bash has its place, i don't think people who use command line interfaces would want to have to type perl.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3402015]]></guid>
        <dc:creator><![CDATA[jg@...]]></dc:creator>
        <pubDate>Thu, 23 Dec 2010 13:35:03 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Message has been deleted.]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3401308]]></link>
        <description><![CDATA[]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3401308]]></guid>
        <dc:creator><![CDATA[priya008]]></dc:creator>
        <pubDate>Tue, 21 Dec 2010 22:17:32 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Message has been deleted.]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3401307]]></link>
        <description><![CDATA[]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3401307]]></guid>
        <dc:creator><![CDATA[priya008]]></dc:creator>
        <pubDate>Tue, 21 Dec 2010 22:14:40 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[ugh, bash]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3400771]]></link>
        <description><![CDATA[My take on it is that by the time you need more than the features that the Bourne shell provides, you should be using something like Perl, Ruby, or Tcl instead of a shell language -- which means that bash is basically in that no-man's-land of languages that frankly don't need to exist.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3400771]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Mon, 20 Dec 2010 17:18:11 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[nice.. and very timely]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3400628]]></link>
        <description><![CDATA[I was just doing a bit of Bash on the weekend though it is coming time to look at Perl or Ruby rather than Bash and awk/sed/greps.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3400628]]></guid>
        <dc:creator><![CDATA[Neon Samurai]]></dc:creator>
        <pubDate>Mon, 20 Dec 2010 10:48:50 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[readability]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3400183]]></link>
        <description><![CDATA[My opinion is that when you're dealing with  $_  (the implicit scalar), there are basically two &quot;right&quot; ways to do it, in general: while (&amp;lt;&amp;gt;) {  print;} The first leaves the implicit scalar  implicit .  This, to me, is preferable when dealing with extremely simple code where implicit usage comes naturally. while (&amp;lt;&amp;gt;) {  my $line = $_;  if ($line eq $foo) {    print $line;  }}That's a case where a little more is going on, where you could benefit from more explicit variable names that serve as implicit documentation for yourself and others who may come along and look at the source later.  Note the technically superfluous assignment of the value of the implicit scalar to an explicit scalar variable that has a name somewhat evocative of its use.Actually cluttering up the source with a bunch of extra lines of code, such as working with an explicit filehandle, is wholly unnecessary in my second example.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3400183]]></guid>
        <dc:creator><![CDATA[apotheon]]></dc:creator>
        <pubDate>Sat, 18 Dec 2010 14:43:58 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Unreadable Perl]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3400152]]></link>
        <description><![CDATA[In my experience, it's the usage of the implicit variable (especially when you don't even write it out, since it is assumed when you omit arguments) that causes most of the Perl readability issues. That, and the regexes (which are a problem to read in any language, but especially prevalent in Perl).I've found that you can write:while ( )printor you can write:while ()print $_for more readabilityand you can go all the way on readability by explicitly using chomp:line = chomp FILE;while (line) {print line;line = chomp FILE;}Also, the Perl interpreter somethings does some VERY bad things in terms of performance when you omit lines. I've seen it, for example, suck an entire file into memory and perform split on it to transform it into an array, instead of reading it line by line. While the end result looks the same to the user, the performance does not...So, my advice, when working in Perl, is to be explicit as possible. While the interpreter can save you a few seconds of typing, you'll quite possibly lose a lot more time down the road when you maintain the code or just in performance.J.Ja]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-339517-3400152]]></guid>
        <dc:creator><![CDATA[Justin James]]></dc:creator>
        <pubDate>Sat, 18 Dec 2010 11:51:36 -0800</pubDate>
    </item>
    </channel>
</rss>

