Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
News

Unix in Perl 154

Posted by CmdrTaco from the for-the-geek-in-you dept.
An anonymous reader writes "Or at least a pretty comprehensive suite of the classic utilities. Tom Christiansen (well-known in Perl circles) has decided that it is easier to write the utilities in Perl and make them available on all platforms than to constantly rewrite Perl scripts that use backticks. Full details are available right here. "
This discussion has been archived. No new comments can be posted.

Unix in Perl More

Unix in Perl

Comments Filter:
  • why stop at just basic tools? why not write a whole kernel in perl! with a builtin interpeter
  • Heh, that's all that we'd need to avoid the long startup times. Otherwise, seems like a cute idea.
  • Posted by Matt Perry:

    Geez, how old is Tom? Twelve? He acts like an immature brat, especially to send such a heated and off topic response to what I would consider to be good questions that should be discussed.
  • Posted by Deus_X:

    But, yes find a real reason or admit your your uninformed bias. (two posts up that is)

    Can't you guys smell trolls yet? Hehehe... Laugh. It's funny.

  • Posted by silverharloe:

    point 1:
    if you don't like the idea of the tools, don't
    download them, don't use them.

    point 2:
    if you think it's a big waste of time to write
    the tools, don't contribute your time to them.

    point 3:
    this project is unrelated to the perl5 distribution, and so nothing is being "taken" from
    anything.

    point 4:
    I think I like a lot of the features and options in many GNU binutils, and so I'll probably stick with those. but that's just me, that's just my time, and I don't see why that should affect Tom's fun.
  • If what you are saying is that your perl scripts are just as fast as your C programs, then I must ask you:

    what the hell are you talking about?

    Write this in Perl for me, or write it in shell, and tell me which is fastest. I bet it's C.

    #include <stdlib.h>
    #include <stdio.h>
    int main(int argc, char * argv[]) {
    int l, h, s, i;
    if (argc>=2) {
    l = atoi(argv[1]);
    h = atoi(argv[2]);
    if (l>h) { s = l; l = h; h = s; }
    s = 1;
    if (argc>=3)
    s = atoi(argv[3]);
    for (i=l;i=h;i+=s) printf("%d ",i);
    }
    return 0;
    }
  • As I often start every one of my posts:

    What the hell is wrong with you people?

    Lighten the fuck up. Must everything have a clear
    and explicit purpose to be allowed to exist?
    I laughed out loud when I read that. Then I
    checked out the page and realized they were
    serious. It stopped being funny and I started
    fingering the possibilities.

    Sure, Perl is butt slow, but so what? So is Java.
    Do we really have nothing better to do than
    complain that an application takes 8 seconds to
    load as opposed to 3 seconds? (Netscape vs. IE?)

    I scoffed at Perl for awhile until I picked up
    the O'Reilly "Camel" book a few weeks ago and
    found that I loved it after I read the second
    chapter. Perl is an attempt to change the
    environment. To make things better. Something
    the inventor of Java has said once. :)

    As a C programmer, I spend way too much time
    wondering what type a variable should be and how
    to save memory and gain precious nanoseconds of
    time. "Bah, don't use unsigned long, unsigned
    short is enough". Do I really need to waste
    precious seconds of my life to save two whole
    bytes of memory? Which cost what? $0.000012?
    That's an inefficient use of my life, since I
    usually throw pennies away rather than let them
    collect in my pocket. Not to mention that my
    processor is 98% idle most of the time.

    Computers are fast enough. Let's work on something
    else. At this point I'll gladly trade in speed
    for decent functionality. If I can write what I
    do in C in Perl in 10% the time for a 1000% speed
    hit. I don't care.

    I only wish I was good enough at Perl (only a week
    or two old here) to help this project out.

    To reiterate, lighten the fuck up.
  • The point is not to have a set of Unix utils in /bin that are written in Perl. The point is to give someone some code to paste into his or her Perl program to avoid having to do things like `date` and `wc -l /foo/bar`. I for one support this effort, as my Perl programs suffer mainly from the overhead involved in using backticks.
    --
  • If you were running this under NT, it sounds like a problem with either your port of Perl or NT itself. I have dozens of Perl scripts (many running fill-time) running under Linux here without so much as a hiccup. Memory, load and CPU usage are negligible and when the scripts are actively doing something, the system isn't taxed any more than if traditional programs were being used instead.

    Before you diss the language, try looking to see if maybe your system or implementation of the language might be at fault.

    All of my perl scripts are just as responsive and any load-time delays are unnoticable as any other C utility.

    Though I do agree that often times Perl is touted as a fix-all language suitable for most any task. I use Perl for just about every little scripting task I need, simply because it's so much easier to use than most any other language I've dealt with, and it's actually *fun* to write under.

    Let them do what they like. I might actually be contributing to this myself.
  • The scripting language itself is just that -- A scripting language. It's some *developers* who choose to try and use it for tasks that it's not well-suited for.

    There are legitimate reasons why you'd want to fetch data from the Web and process it by a Perl script. There are hundreds of Perl modules that let Perl scripts interface with and use data from tons of different data sources and formats. These things are useful.
  • I don't understand..

    I run Perl under NT as well and I understand where the original poster was coming from...

    I don't understand your post.
  • About 5+ years ago, I used to use a .signature that said:

    UNIX: Any of a collection of similar operating systems that you can run the programming language 'perl' on.

    Yesterday, while looking at dejanews.com, I found out that someone is still using it as a .signature. Somehow, I find this project to be most amusing.

  • Heh. I dunno what he meant... but I'm gonna be charitable and assume that when he said "malloc by hand" he really meant "keep track of pointers and free() by hand".

    Sure, experienced C programmers instinctively write well structured algorithms where pointers don't get lost, and everything malloc()d is free()d when it's done with, but to the mortal among us, that's hard work, and having our garbage collected for us is a blessing.

  • Ugh (Score:1)

    by Daniel ( 1678 )
    This is just...disturbing. I suppose they'll work but...Perl? (shudders)

    Daniel

    # Parse options here

    import sys
    import os
    import re

    if os.exists(sys.argv[-1]):
    if not isdir(sys.argv[-1]):
    throw "%s is not a directory!"%sys.argv[-1];
    for i in sys.argv[:-1]:
    infile=open(i)
    outfile=open(sys.argv[-1]+os.path.split(i)[1],"w")
    stuff=infile.read(16384)
    while len(stuff)>0:
    outfile.write(stuff)
    stuff=infile.read(16384)
    else:
    if sys.len(argv)>2:
    throw "Need two arguments!"
    destname=argv[1]
    if(os.isdir(destname)):
    destname=destname+os.path.basename(filename)
    infile=open(argv[0])
    outfile=open(argv[1],"w")
    stuff=infile.read(16384)
    while len(stuff)>0:
    outfile.write(stuff)
    stuff=infile.read(16384)
  • Well, there's a simple solution for that. Rewrite the Perl interpreter in Perl. :-)

    Daniel
  • Python is different. It doesn't try to be C. Or sed. Or awk. Or bash. (Perl, by comparison, looks like some unholy mutant offspring of the above) It has unusual things. But I stopped using Perl when I tried to add one to an integer and instead incremented a character in its string representation.

    Daniel
  • I'm aware that it's a documented feature. If I remember correctly, I was taking input from the user or a file, converting it to an integer, and incrementing it. Using $foo++ caused character incrementation but $foo=$foo+1 caused numerical incrementation. Certainly it's a language 'feature', but so is Python's use of whitespace (which I personally found quite useful after using it for a day or two). Both can lead to unexpected results. At least Python is internally consistent. ;) (If Larry Wall likes 500 different ways to do everything, that's fine..I'm happy with ten to fifty, though.)

    Daniel
  • Actually, I rather like Lisp/Scheme syntax. :-)

    Daniel
  • I don't think so -- many compilers are written in themselves.

    For interpreters, most Forths are written in themselves -- but then Forth isn't really interpreted (it's wordcoded). The Forthers call it metacompilation.

    -Billy
  • Anyhow, the GNU utilities have been ported very widely. Maybe perl has been ported more widely, maybe not. Odds are that if a platform has perl, it's got gawk, gnu ls, gnu tr, gnu sed, and the rest of the gang.

    True, but not all individual systems have the GNU tools installed. And for those that do, it's not likely that they are installed as the standard tools.

    The intention is that, in a perl script, instead of calling the external program in backticks (which, if you don't know perl, has the same effect as doing it in the shell) you would load in the equivalent script. So instead of calling whatever ls is installed on the system--not really knowing for sure what the command-line syntax or output format is on this particular machine--you just make sure and call the perl version.

  • Yes, Tom is big on Perl. But he did not provide argument on why Perl is the right tool for the job. He did not show proof why Perl is better than Python, or Java, or Tcl, for the job.

    Tom, please provide the proof.

  • Yuk (Score:1)

    by nelsonrn ( 2165 )
    It had no whitespace. If you think Python is ugly without whitespace, try Perl.
    -russ
  • His point still remains: This has nothing to do with the web. Perl has very little to do with it in all reality. It's just a powerful tool used in CGI a lot.

    And you did prove, just now, you are exactly what he (or she I guess... Doubtful though) said you are.
  • Now that guy really should have gone a little farther, and mentioned that if everything written in perl is more robust than anything written in c, why then perl itself -- having been written in c -- must suck, and so therefore anything using it (e.g., a perl script) must suck too! Around and around and around and around . .


    Too bad you can't rewrite perl in perl.

    The world's first recursive programming language.
  • A good number of the (very few) times I've had to hit the reset button, perl was the cause. Resource Pig from Hell, even doing very simple things.

    Great, undoubtedly, but the perl religion is really overdone. Sure, it's the only way to get anything done on NT, but that's no excuse.

    Just a little DogBarf tossed at the faithful...

  • Haven't you ever recompiled gcc with gcc? Granted, C isn't interpreted. However I've been forced to run Scheme interpreters that were written in Scheme. Scheme types adore the notion of recursion, thus they found this beautiful. Drop the word "performance" and they go through the roof, though...

    BTW- I like PERL
    --Lenny
  • As someone who worked with tom in the early perl days, let me say, and this is strictly MY opinion, I believe that Tom is persuing this, in no large part, because both his coffers and ego are feeling a drain from perl being in the shadows of Linux and OSS.

    just my 2 cents.

  • What operating system was this under? Any operating system with a decent scheduler should let you get a shell to kill the Perl processes(es) with. Or at least reboot cleanly. Unless you were doing something wacky like running Perl with a real-time priority.

    Anyway, there's a simple reason why those of us who love Perl love Perl. It works. Having said that, reimplimenting UNIX utilities in Perl is really silly. Perl has a module system for a reason.

  • Wouldn't it make more sense to use something like Java?

    Have you ever used Java? You know the way Netscape starts grinding the disk and doubling its RAM consumption when it runs into an applet? You want your system doing that every time you run "ls"?

    So, okay, it's a pretty silly idea to have "ls" in Perl too. But last time I checked, Perl ran on more systems than Java, and though it's developing a bit of a gut these days, it's still the Laurel to Java's Hardy.

  • # Wouldn't it make more sense to use something like
    # Java? It's more widely supported, faster, and can
    # be compiled to native code for even more speed.
    # Not to mention the porting process would probably
    # be easier, since you could cut and paste parts of
    # the code.

    ROTFL! Java more widely supported than Perl? You're kidding, right? And porting easier? You must not know Java well. Its similarity to C is about the same as Perl's. And speed? Hehehehe. You really crack me up.


  • While we're on the subject, an idea I've been playing with for quite some time is implementing perl as an OS kernel. Perhaps using the ext2fs and large portions of the Linux kernel as a base for hardware access and multitasking, but everything even remotely user-land using entirely Perl as the base.


    Yes, its going a bit overboard on the Perl language. Still, such an OS would be enormously fun to play with. At least, I think so.

  • If you want to start a language war at least get your facts straight. Perl, in it's 10 years of life, has been ported to basically every platform, including Atari ST or mainframes. Java is still struggling to be on Linux. Second, Perl is several times faster than any Java app. native code compilation is in the works. BTW, the number of modules (classes) available for Perl today will be a target for Java for a long time.
  • ... A good number of the (very few) times I've had to hit the reset button, perl was the cause.

    then:

    ... it's the only way to get anything done on NT ...

    Then your NT kernel is coded in perl, or what? If your machine drops, the kernel is guilty (or you did some nasty lowlevel stuff). If NT is uncapable of running perl without crashing then I'm very sorry for it.

    If you talk about "resource hog/pig" in conjunction with "NT" and "perl", guess to which this is attributed (grammar?)...

    Nils
  • Perl 5.005 is supposed to have some backends to other languages and binary. However, I don't know how good that works.
  • Isn't the whole point of writing these utilities in perl so that a perl coder can expect to have working, standard utilities on every platform? Or did I somehow misread the article. Seems like everyone is coming down on the idea as a stupid let's-redo-everything-in-perl idea, rather than what it really is.

    logan

  • A perfect example of how Python combines the power of MS-DOS batch file programming with the intuitiveness of INTERCAL.
  • It's not all that hypothetical.... If you're willing to brave an alpha version, have a look at Perlmacs [perl.com]. I expect to have a new version out RSN. It's getting stable enough to call beta.
  • i suppose this is amusing, but as quick-easy-and-portable as perl is, i just can't see any advantage over the GNU utils.
  • Tools written in perl will become available on brain-damaged systems that don't have those tools available, and you can take the SAME file to a different platform to get those tools ported. Think of it as a cast while the broken underlying OS sets. Or a crutch if it never does. Not perfect, but available.

    The other aim of the project is to reduce the usage of backtick subs in perl scripts. These are what makes perl slow -- I have a driver and display architecture for some LED display boards written entirely in perl. It speed up by a factor of three when I removed the numerous calls to system utilities in favor of a "native" solution.
  • The problem with using the GNU utils is that they don't help much if the bonehead sysadmins whose machine you are using either
    (a) don't install them,
    (b) don't install them completely and/or correctly.
    The GNU utils work just fine on systems that have them. However, shell scripts tend to require some hacking at when their moved from one system to another ( even one *NIX system to another ... ) ( esp if you wrote the script in bash2 / ksh / zsh ... ) OTOH, perl makes this easy . Of course, for short scripts ( say 100 lines ) , shell scripts are nice. But I cringe at the thought of writing >500 line proggies in shell script ( I've tried, and it worked, but it was unportable, not to mention darned ugly ... )
    --Elflord
    --
    Donovan Rebbechi
  • no freaking kidding!! this is the #1 reason why I haven't learned Python. #2 being that it forces you to be OO all the time. It may be a nice language in a lot of ways, but it's no match for perl in flexibility
  • well, I can see one: these things will be *much* easier to make than the GNU ones ever were, and far easier to debug. the counterpart is, of course, that they will be a little slower and use more memory. then again, no-one is suggesting to replace all of /bin and /usr/bin with perl scripts. *that* would be quite silly. OTOH, I wouldn't mind a system that used perl as its main userland language, with /bin and /usr/bin in perl with a global cache of bytecode-compiled scripts somewhere.
  • go read the site, dork. the point is not to run a Unix box with the GNU utilities replaced by the perl ones (unless you're doing it for the hack value, of course). it's to get instant-portable utilities on every single thing perl runs on. and it's *not* limited to Unix/Linux and win32.
  • the difference is that it takes about twice as long in C, even with the regexp library, thanks to having to malloc everything by hand. Python or maybe Java maybe could compare in development speed, certainly not C.
  • there's a perl interface to nvi. disclaimer: I haven't used it.
  • why put it on the *kernel*? hte kernel is supposed to be fast and low-level and every cache miss counts. everything on userland using perl as the base language, that's something I could agree to :-)
  • let's give perl a commandline switch so it will compile 2 file. then wehnever it is invoked it will test to see if the code has been modified more recently than the binary (it would then recompile). This would be really handy.

    xm@GeekMafia.dynip.com [http://GeekMafia.dynip.com/]
  • No one-liners.


    Sure, you can! Just use semicolons to separate statements and lambda. Then you end up with something as unreadable as the average Perl script ;-)
  • remove_one_or_more_newlines_at_end_of_the_char_str ing()


    How about:


    theString.removeNewlines()


    or


    theString removeNewlines.


    There's more than one way to skin a fish in a barrel.
  • The gnu tools definitely need to be redesigned and rewritten, but in C not perl!!! less bloat not more! :)

  • And then back again! Write Awk in perl, then perl in that awk, then awk again in your new perl . . . Ultimately, you could waste literally DECADES of time that could -- in a less ideal world -- have actually been spent doing something useful, interesting, or productive.

    Way to go, guys!

    I like the idea of implementing all this stuff in a portable language, but why must it be such a horribly UGLY one?! Why, why . . . Yeah, sure, it does regular expressions -- but GNU has a perfectly good C library for that, right? What's the damn difference between writing in C with GNU's library, or writing in perl which probably uses the same damn GNU library anyway?!

    Anyhow, as has been said above, all this guy's complaints (buffer length etc.) were addressed years ago -- in the GNU tools that they're using as examples. Uh, duh.


    -j

  • I seriously doubt that perl's regexp code is derived from GNU. After all, with perl you have your choice of licenses -- GNU or Artistic. If you choose Artistic, you can keep things as proprietary as you wish.

    Really? Well, yeah, then I guess they're not using much GNU code there. Odd. Hey, what the hell, it's their own code. More power to 'em.


    -j

  • Ugh (Score:1)

    by mjd ( 12596 )
    Your program didn't work for me.
    I wonder why not?

    Oh, it's because in Python, whitespace is
    significant.

    And now that it's gone, it's awfully hard to put it back because there's no other syntax indicating the block structure.

    Too bad about that, huh?
  • Why draw the line at sed, awk, lex, yacc. What about an implementation of perl - written in perl?

    On second thoughts, this all sounds completely pointless...
  • > Wouldn't it make more sense to use something
    > like Java?

    No.

    > It's more widely supported,

    Wrong.

    > faster,

    By what metric?

    > and can be compiled to native code for even more
    > speed ...

    So? That's not the point of these tools (at least, as I can see.) They basically are a set of perl utilities that make the life of a perl programmer working in a brain-dead environment easier.

    Finally,

    > Not to mention the porting process would
    > probably be easier, since you could cut and
    > paste parts of the code.

    I'm unsure exactly what this means, but the point of all this is that Jane Perl can carry a CD with all of these scripts on it to /any/ system and expect them to work: no porting involved.

    Java is Java and perl is perl and they solve different problems and represent different approaches. Personally, I prefer Smalltalk, but that's neither here nor there.

    Regards,
    JFB
  • Perl Emacs? Wash your mouth out with soap!
  • I don't expect we'll ever see a federal judge hollering at a Microsoft witness to shut up already when testifying about how they messed with Perl (as happened indirectly when ActiveState started forking Perl a while back; saner heads including Larry prevailed, fortunately). That unique scene is reserved for Microsoft's testimony on Java, which closed the trial this past week.

    As for Perl on Microsoft platforms, I've been using it daily since 1991 and it has made my professional life worth living, I can tell you. That and 4DOS/4NT, the command shell Microsoft should have done in 1983. (How they bought and butchered an already cut-down version of 4DOS from Norton/Symantec in the early 1990s is a story in itself.)

    --------
  • I'd have to say that Perl is every bit as overhyped as Java is. :-)
  • There it is. Right there. I don't rent Winnie-the-Pooh movies, I'm a grown man, I don't need this cutesey-wootsey crapola.
    --

    First off, if you can't have a sense of humor about what you do, it probably isn't worth doing. `chomp' is one of the most memorable commands in Perl 5, for that very reason. At least I seem to remember it well.

    But you would rather have something like:

    s/(.*)\n$/$1/;

    That's much easier to remember. If only all Perl syntax was that clear.

    Which brings me to one reason that I like Perl a great deal: "There's more than one way to do it."

    -B
  • I love Perl. I love Java. They are different,
    use them differently. Blanket statements like,
    "I would venture to guess then a good perl
    programmer could out produce a good jave [sic]
    programmer by 2 to 1," are incredibly ignorant.

    There are, believe it or not, things that can
    be easily done in Java and not done AT ALL in Perl. Likewise, there are things that can be done
    in Perl (regex/text stuff) that is much more
    difficult to do in Java (but probably not impossible).

    That's why we have >1 language available.

    So let's not be bandying about such crazy notions.

  • Perl has how many years on Java? Apples and
    oranges are no fun to compare. You would probably
    be lying to yourself if you claimed that Java does
    not have amazing distribution and maturity for
    such a young language.

    If you MUST compare languages (a trivial and useless exercise usually), let's at least compare Perl when it was 4 years old with Java now.

    That'd be a fairer comparison, say, like apples and pears.

  • AC is correct to point out that programmer time is more valuable than processor time.

    However, that doesn't mean that it's either smart or useful to reimplement the Unix command toolset in Perl. On a busy server, Perl's resource footprint will still trip you up. We have had to reimplement a number of small Perl tools in sh, awk or C by virtue of the fact that even with a half-gig of RAM, we cannot afford to spawn fifty Perl processes every second.

    Perl is still a great tool for a lot of our applications. Just not all of them. It might be fun to rewrite zork in Perl, but we're still going to be using good old-fashioned egregious GNU tools for getting real work done.

  • I think perl and java are going to be something to think about, there is alot you can do with it. I run a web hosting provider, we charge $50.00 setup and then no monthly charges, People love it, And they get all the neato things like cgi-bin, etc.. click here [anvdesign.net] for more info, But anyways, i think perl is a way to get things done on the web, Our FiP, "Free Internet Project" is going to use alot of perl and database kinda stuff. But i think alot of providers are not gonna like us, Just because we are doing something, no one has ever done.

Slashdot Top Deals

If a 6600 used paper tape instead of core memory, it would use up tape at about 30 miles/second. -- Grishman, Assembly Language Programming

Close