On Jul 27, 2011 5:17 AM, "Ivan Shmakov" <ivan@gray.siamics.net> wrote:
>
> >>>>> shawn wilson <ag4ve.us@gmail.com> writes:
> >>>>> On Jul 27, 2011 4:28 AM, "Ivan Shmakov" <ivan@gray.siamics.net> wrote:
> >>>>> shawn wilson <ag4ve.us@gmail.com> writes:
>
> >>> However, I'd look at some of the bio perl modules if this was the
> >>> type of data I was looking at. Either way, learning dozens of
> >>> tools to manipulate lots of data is quite time consuming, prone to
> >>> failure, and quite frankly senseless.
>
> >> How it's different to learning dozens of functions documented in
> >> perlfunc(3)? Or even more, should CPAN modules be taken into
> >> account? How could it be that the Shell commands do not form a
> >> library, or a set of, of a sort?
>
> > Different commands use different switches
>
> How it's different to different functions using different
> arguments' order?
>
This is a point we can debate :)
I think the point here is that most high level languages have the same functions and same *general* data types (yes, everything in js is an object, everything in tcl is a string, but..) and if you use a language you have more reusable code to build off of than shell scripting.
> > and do the same thing (sed vs awk vs grep for tons of uses),
>
> However, it's Perl that has “There's more than one way to do it”
> as its motto.
>
Yes but there's the perl way and the wrong way :)
Ok, seriously, I just don't like all of these commands that have their own mini scripting environments. If you're going to do this, use something like lua that was meant to be scripting inside a program. I understand these commands are older than me but still...
> > bash is slower.
>
> There're, indeed, are the cases when it's observable. There,
> however, are the cases when it's not. I would also argue that
> the Shell commands implemented in a compiled language (say, C)
> are somewhat more common than the Perl functions implemented
> that way.
>
Umm, no.
Oh and per speed and prototyping, check out caml.
> > And I find it easier for bad / different data to break a shell script
> > (well I can technically stop most languages from earring with try /
> > catch which is a plus but not the point) and verifying data in bash
> > is a pita.
>
> It depends more on a programmer's competence, than on the
> language.
>
I'm curious, how do you verify your data in bash?
> > Also, idk of any debug option in bash (perl -d, gdb, etc).
>
> There's the -x (xtrace) Bash option, though it isn't comparable
> to, say, GDB.
>
Huh, I'll have to check that out.
> And I don't remember myself ever using Perl's debugger.
>
I have :)
Along with Data::Dumper, Carp::* and print, that's my favorite general purpose debugging method.
Though, I've also found a place in my heart for gdb (and I haven't started playing with the perl modules for gdb - shame). So that probably tells more about my sanity than anything else.
> > However, this is not answering the op's question. So, while I
> > started this, I'll start a new thread if we wish to continue this
> > (preferably with code examples :) ). And I do hope you wish to
> > continue this as I find the debate fun but way OT (per op question)
> > at this point.
>
> Actually, I don't feel that I'm in position to advocate the use
> of Shell. Also, this discussion is OT not only per the OP's
> question, but also to this very mailing list.
>
> I've already mentioned that news:comp.unix.shell has a few folks
> that could provide much more insight on the questions above than
> I possible could. Therefore, I'd prefer continuing the thread
> there.
>
Apparently, you're right (I don't think he's gotten a solid answer here). I'll also add irc as a good place to look for answers. Either way, if you're only using one source for answers YDIW.