Unix commands

Discussion in 'Perl Misc' started by Kim Gardiner CS2003, Jan 12, 2007.

  1. Can you issue UNIX commands using Perl?

    Thanks.
    Kim Gardiner CS2003, Jan 12, 2007
    #1
    1. Advertising

  2. Kim Gardiner CS2003

    tfe Guest

    Kim Gardiner CS2003 ha escrito:

    > Can you issue UNIX commands using Perl?
    >
    > Thanks.


    Hello,

    Sure and "there is more than one way to do it" ...
    qx! command with args!;
    system("Command","arg1","arg2",...);
    `command with args`
    open(PIPE, "command |");

    --

    tfe
    http://tfeserver.be
    tfe, Jan 12, 2007
    #2
    1. Advertising

  3. Kim Gardiner CS2003 wrote:
    > Can you issue UNIX commands using Perl?


    Sure you can, provided your operating system supports them.

    jue
    Jürgen Exner, Jan 12, 2007
    #3
  4. Kim Gardiner CS2003

    Craig Guest

    Kim Gardiner CS2003 wrote:
    > Can you issue UNIX commands using Perl?


    The previous respondents gave you good advice. You can get more
    detailed information on the system and exec commands in perlfunc. If
    you use system, remember to check the return code from the OS.

    system($cmd)==0 or die("Cannot $cmd ", $?);
    Craig, Jan 12, 2007
    #4
  5. Kim Gardiner CS2003

    Guest

    Kim Gardiner CS2003 <> wrote:
    > Can you issue UNIX commands using Perl?


    That depends. Are you running Perl on UNIX? If not, can you ssh or rsh
    into UNIX from whereever you are running Perl?

    if (so) {
    system "echo yes";
    else {
    system "echo no";
    };

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
    , Jan 12, 2007
    #5
  6. Kim Gardiner CS2003

    Guest

    Kim Gardiner CS2003 wrote:
    > Can you issue UNIX commands using Perl?


    You can, but it's often a bad idea.

    Some folks treat Perl like a glorified korn shell, and do ghastly
    things like this:
    my @data = `cat somefile.txt`;

    or
    my @files = `ls /some/directory`;

    Perl has built-in functions for a lot of stuff you might be tempted to
    use shell commands for. It's generally preferable to use Perl when you
    write Perl programs.


    --
    The best way to get a good answer is to ask a good question.
    David Filmer (http://DavidFilmer.com)
    , Jan 12, 2007
    #6
  7. Kim Gardiner CS2003

    John Bokma Guest

    wrote:

    > Kim Gardiner CS2003 wrote:
    >> Can you issue UNIX commands using Perl?

    >
    > You can, but it's often a bad idea.


    Huh!? Why?

    > Some folks treat Perl like a glorified korn shell, and do ghastly
    > things like this:
    > my @data = `cat somefile.txt`;
    >
    > or
    > my @files = `ls /some/directory`;
    >
    > Perl has built-in functions for a lot of stuff you might be tempted to
    > use shell commands for. It's generally preferable to use Perl when you
    > write Perl programs.


    Depends on what you're doing of course. Why would I copy a program that
    does already its work perfectly and reinvent the wheel? Increase
    development time, and make many mistakes while doing so?

    --
    John Experienced Perl programmer: http://castleamber.com/

    Perl help, tutorials, and examples: http://johnbokma.com/perl/
    John Bokma, Jan 12, 2007
    #7
  8. tfe <> wrote:
    > Kim Gardiner CS2003 ha escrito:
    >
    >> Can you issue UNIX commands using Perl?


    > Sure and "there is more than one way to do it" ...
    > qx! command with args!;
    > system("Command","arg1","arg2",...);
    > `command with args`
    > open(PIPE, "command |");



    The 1st one and the 3rd one are the same one.


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Jan 12, 2007
    #8
  9. Warren Block wrote:
    > Jürgen Exner <> wrote:
    >> Kim Gardiner CS2003 wrote:
    >>> Can you issue UNIX commands using Perl?

    >>
    >> Sure you can, provided your operating system supports them.

    >
    > Even if it doesn't, you can still issue them.


    Well, guess that's true ;-)

    jue
    Jürgen Exner, Jan 13, 2007
    #9
  10. John Bokma wrote:
    >> Some folks treat Perl like a glorified korn shell, and do ghastly
    >> things like this:
    >> my @data = `cat somefile.txt`;
    >>
    >> or
    >> my @files = `ls /some/directory`;
    >>
    >> Perl has built-in functions for a lot of stuff you might be tempted
    >> to use shell commands for. It's generally preferable to use Perl when
    >> you write Perl programs.

    > Depends on what you're doing of course. Why would I copy a program
    > that does already its work perfectly and reinvent the wheel? Increase
    > development time, and make many mistakes while doing so?

    Because 1) it's inefficient in that you are forking and exec'ing a
    process to do it and 2) portability - there's no guarantee that the next
    platform you port this to has the same commands. For example, you use
    "ls" above. But there is no "ls" under Windows. If instead you use a
    more Perl like way your Perl script will immediately port without and issue.

    --

    Andrew DeFaria <http://defaria.com>
    Why do the Alphabet song and Twinkle, Twinkle Little Star have the same
    tune?
    Andrew DeFaria, Jan 13, 2007
    #10
  11. Kim Gardiner CS2003

    John Bokma Guest

    Andrew DeFaria <> wrote:

    > John Bokma wrote:
    >>> Some folks treat Perl like a glorified korn shell, and do ghastly
    >>> things like this:
    >>> my @data = `cat somefile.txt`;
    >>>
    >>> or
    >>> my @files = `ls /some/directory`;
    >>>
    >>> Perl has built-in functions for a lot of stuff you might be tempted
    >>> to use shell commands for. It's generally preferable to use Perl
    >>> when you write Perl programs.

    >> Depends on what you're doing of course. Why would I copy a program
    >> that does already its work perfectly and reinvent the wheel? Increase
    >> development time, and make many mistakes while doing so?

    > Because 1) it's inefficient in that you are forking and exec'ing a
    > process to do it


    Depends a lot on what the task is doing of course. Or do you base this
    all on the example David (don't remove attribution lines if you quote)
    gave?

    > and 2) portability


    As always, instead of using a dumb set of fixed rules (never use shell
    commands because: fork overhead and non portable) one has to consider
    everything. For most of the stuff I write fork overhead is a non-issue
    as is portability.

    > - there's no guarantee that the
    > next platform you port this to has the same commands.


    There is no guarantee that what I write is going to be ported at all.


    > For example, you
    > use "ls" above.


    I didn't. Moreover, it's just an example.


    > But there is no "ls" under Windows.


    Yup, like there is no perl under Windows.

    C:\Documents and Settings\John\My Documents\Amber\Sites\johnbokma.com
    \site\web>ls -al *.png
    -rw-rw-rw- 1 user group 13112 Nov 13 2005 bokma-gnu.png
    -rw-rw-rw- 1 user group 108 Nov 13 2005 dash.png


    See: http://johnbokma.com/mexit/2006/07/01/


    > If instead you use
    > a more Perl like way your Perl script will immediately port without
    > and issue.


    Not all Perl scripts are used on different platforms. Most I write
    aren't. But like I said, it's a non-issue if the external program is
    ported to the target platform(s) as well.

    For example I now and then use wget via Perl. The fork issue is a non
    issue IMSHO. And if my customer wants to run it on Windows he gets
    instructions on how to install wget (see previous link).

    I rather do that then waste his/her valuable time and money on making a
    wget clone if wget does /exactly/ what is required.


    --
    John Experienced Perl programmer: http://castleamber.com/

    Perl help, tutorials, and examples: http://johnbokma.com/perl/
    John Bokma, Jan 13, 2007
    #11
  12. Abigail wrote:
    > If I'm willing to pay the price of running anything in Perl, do you
    > really thing I can be bothered about the overhead of forking? If the
    > time constraints where that critical, the error would have been
    > writing the program in Perl, not the forking. Then it should have been
    > written in C instead.

    As is comment it depends. When you automate your build system with say
    Perl and things are fine but as new requirements come in and more and
    more is being built the automatic build system is getting slow, and you
    look at it and see that you're spending a lot of time forking and
    execing small programs where there are better, more efficient ways to do
    that then removing these calls to system is indeed worth while.

    When you realize that those 10,000 calls to system 'ls' are really
    slowing you down, porting this to C and still forking and execing ls
    10,000 times will not be any faster!
    > __ process to do it and 2) portability - there's no guarantee that the
    > next
    > __ platform you port this to has the same commands. For example, you use
    >
    > I've been programming Perl for over 12 years. I've yet to write a
    > program that had to be ported to Windows.

    You have yet to write a program that could be ported to Windows would be
    my suspicion...

    So let me get this straight - you've never been asked to have a useful
    Perl program that you've written on a Unix system ported over to work on
    Windows? Maybe they just don't like you or perhaps your programs are as
    useful as you think. I've been asked all the time and I've done it all
    the time.
    > I did once had to port a long shell/awk/SQL script (over 1000 lines)
    > from Solaris to Windows. After installing a Unix toolkit the script
    > only required a single change: the location of the temp directory.
    > I've found more porting issues between different versions of Perl (not
    > to mention different versions of CPAN modules) than between different
    > UNIX toolkits (just keep yourself away from all the fancy GNU/Linux
    > features if you have the need to run it on a real UNIX). After all,
    > there's POSIX while there isn't a Perl standard.

    Sounds to me like you are just inexperienced in the area. I do it all
    the time and as such I'm speaking from experience you obviously and have
    stated that you lack.
    > __ "ls" above. But there is no "ls" under Windows. If instead you use a
    > __ more Perl like way your Perl script will immediately port without
    > and issue.
    >
    > Really? Last time I looked Windows didn't come with perl either.

    So you've never seen a Perl script run on Windows have you? My god your
    a noobie aren't you!

    --

    Andrew DeFaria <http://defaria.com>
    You never really learn to swear until you learn to drive.
    Andrew DeFaria, Jan 13, 2007
    #12
  13. Kim Gardiner CS2003

    John Bokma Guest

    Andrew DeFaria <> wrote:

    > Taking the poor grammar out of the picture


    As soon as people talk about grammer usage (or abuse) in a Usenet post
    they have little to say about the issue at hand, which doesn't amaze me
    in your case.

    > Similarly I think it's better to write script in anticipation that
    > they may be asked to run on systems I've never thought that they
    > would.


    If its not in the requirements and not likely, why bother? I try to find
    the best possible solution for my customers instead of making up a set
    of silly rigid rules.

    [ Cygwin ]
    > server, grep, awk, diff and quite literally thousands of others, I
    > cannot guarantee that the client will go for it. Indeed many do not.


    So they have no problem with you installing Perl, but they do have a
    problem when you install (from your example) ls.

    I guess you write all your modules yourself as well then? I mean, they
    might have a problem or two with installing some CPAN modules as well.

    >> Not all Perl scripts are used on different platforms.

    > Yes and many of them can't because they use things like those
    > described above.


    And for most that's a non-issue. Rigid development rules are for
    programmers with little skills. Skilled programmers are able to see the
    pros and cons of several possible solutions and select one.

    > My Perl scripts can and are used on various platforms.


    So can and are mine, most out of the box. On the other hand I have no
    problem at all with using external tools. It all depends on the
    requirements of my customers.

    >> Most I write aren't. But like I said, it's a non-issue if the
    >> external program is ported to the target platform(s) as well.

    > And if the client will allow you to install such tools (and upkeep,
    > patch, update, etc.). This is not always the case in the real world.


    Then their problem already starts with using Perl on Windows (for
    example). And you using CPAN in general.


    > Additionally it adds to the requirements and prerequisites for the
    > usage of your tool - not a good thing.


    But you reinvent the tool. Now if there is anything silly in software
    development it's refusing to use a library / external tool because of a
    "you never should" rule.

    Programming is about flexibility.

    > Finally often the external tool
    > does a lot more stuff than what you need. They call this wasteful.


    Most external tools have switches that enable / disable features. Code
    that doesn't get executed doesn't matter. And if there is a slight
    overhead because the tool does something extra, this overhead might be
    insignificant compared to rolling out your own code in Perl.

    It all depends on circumstances, not on some silly rule you prefer to
    live by.

    > Again this is good to know. I always like knowing who I would *not*
    > recommend for a job. Welcome to the list.


    I am glad to be on it, especially based on your other drivel I am
    sharing the honor with Abigail and probably a lot of other programmers
    in this group.

    >> I rather do that then waste his/her valuable time and money on making
    >> a wget clone if wget does /exactly/ what is required.

    > Exactly is a debatable term here.


    A debat which you avoid by making up a brain dead rule.

    > Think about how hard perl -MCPAN


    What!? Installing external libraries on Perl? That *is* allowed and a
    single executable not?

    --
    John Experienced Perl programmer: http://castleamber.com/

    Perl help, tutorials, and examples: http://johnbokma.com/perl/
    John Bokma, Jan 13, 2007
    #13
  14. Abigail wrote:
    > Bleh. If you do 10,000 calls to 'ls' and it's slow, then it's the disk
    > access that's the bottleneck, not the forks.

    My point is, if 10,000 accesses are required, strapping them with
    additional inefficiencies of 10,000 fork/execs is silly. Now you are
    free to be silly if you want....
    > And even ten, saying "if you do it 10,000 times, it's slow, so you
    > should never use it" is sillyness.

    Probably is - however I didn't say that. So if you wish to argue your
    own made up things I guess I can't stop you. But the only thing silly
    here is your strawman.
    > If your program does 10,000 regex matches and it's slow because of
    > that, do you draw the conclusion you should
    > never use a regex because doing 10,000 of them might form a bottleneck
    > in some program?

    No my argument is that you shouldn't do 10,000 fork/execs to grep to do
    these regex matches - you should do them internally as that's more
    efficient. Are you really that dense that you cannot see that?
    > No. I don't do Windows and I've never done Windows. And I don't apply
    > for jobs that involve doing anything on Windows.

    And as I can see you are extremely open minded! Bravo!
    > Good for you. I typically work in environments where if the
    > environment would need to be ported, it would take a lot of people
    > several years to do it

    Could that be because they all have their heads as far up their asses as
    you do? Just an opinion.
    > (and the only time I worked for a company where the company decided to
    > port their product to Windows they abandoned their effort after 18
    > months, as they found out their customers weren't interested). If it
    > were to be done, any program would have to be modified anyway.

    Listen sonny, I've probably worked at far more companies than you, many
    who use various platforms. I was talking about writing tools that are
    used in house and not necessarily products sold to end users, though
    there is wisdom in writing portable code nevertheless. I really have a
    hard time understanding your viewpoint. You are actually arguing that
    writing non-portable code that is inefficient is a good thing! I'm sure
    you'll go far with that attitude.
    > Yes, and? Just because you have to port your programs to Windows,

    Actually many times I've ported my programs and tools to Unix too!
    > doesn't mean I have to restrict myself and not to use the excellent
    > tools any Unix system gives me.

    You just go ahead and stick your little head back into that ground and
    ignore the fact that Unix isn't the only operating system in town. Now
    don't get me wrong, I use Unix all the time and prefer it. However at
    least I don't live in a cave.
    > I've seen Perl scripts on Windows. And I've seen 'ls' on Windows as
    > well. And 'cat'. And 'echo'. And every other common Unix tool. Unix
    > tools have been ported to Windows. More than once even.

    Granted! Hey I'm a firm advocate on usage of Cygwin. In fact I'd jump
    for joy if MS required it on every installation of Windows!

    However in the real world you don't always have that. You see aside from
    you sitting in your dark Unix dungeons and dragons cave I've been out in
    the real world and while ls, cat, echo, etc. can be installed on a
    Windows box often it isn't. To code assuming it's there, all the while
    incurring additional fork/exec overhead when there are many much more
    efficient and much more Perl like ways of doing it (in your Perl script,
    we were talking about Perl, remember?) seems to me to be stupid, short
    sighted, lazy, etc.
    > I'm just saying that if you want to use the argument that certain
    > tools aren't standard on Windows, you should consider that perl isn't
    > standard either.

    If I'm asked to write a Perl script by the client then assuming there'll
    be a Perl interpreter is not a silly assumption.
    --
    Andrew DeFaria <http://defaria.com>
    Does your train of thought have a caboose?
    Andrew DeFaria, Jan 13, 2007
    #14
  15. >>>>> "ADF" == Andrew DeFaria <> writes:

    ADF> Listen sonny, I've probably worked at far more companies than
    ADF> you, many who use various platforms. I was talking about
    ADF> writing tools that are used in house and not necessarily
    ADF> products sold to end users, though there is wisdom in writing
    ADF> portable code nevertheless. I really have a hard time
    ADF> understanding your viewpoint. You are actually arguing that
    ADF> writing non-portable code that is inefficient is a good
    ADF> thing! I'm sure you'll go far with that attitude.

    You *really* ought to do enough research to find out who you're
    lecturing. I don't think you intend this tirade to come across as
    comedy.

    Charlton


    --
    Charlton Wilbur
    Charlton Wilbur, Jan 13, 2007
    #15
  16. Kim Gardiner CS2003

    John Bokma Guest

    Andrew DeFaria <> wrote:

    > Abigail wrote:


    [..]

    >> And even ten, saying "if you do it 10,000 times, it's slow, so you
    >> should never use it" is sillyness.

    > Probably is - however I didn't say that. So if you wish to argue your
    > own made up things I guess I can't stop you. But the only thing silly
    > here is your strawman.


    >> = John Bokma wrote:

    > = Andrew DeFaria


    >> Depends on what you're doing of course. Why would I copy a program
    >> that does already its work perfectly and reinvent the wheel? Increase
    >> development time, and make many mistakes while doing so?

    >Because 1) it's inefficient in that you are forking and exec'ing a
    >process to do it and 2) portability - there's no guarantee that the >
    >next platform you port this to has the same commands. For example, you
    > use "ls" above. But there is no "ls" under Windows. If instead you use
    > a more Perl like way your Perl script will immediately port without
    > and issue.


    Maybe my grammar is bad, but you either missed "Depends on what you're
    doing of course", in which case your 1) and 2) are just more or less
    repeating what I stated and is a bit of pointless or you just falled of
    your horse...

    > No my argument is that you shouldn't do 10,000 fork/execs to grep to
    > do these regex matches - you should do them internally as that's more
    > efficient.


    Again, depends on what you're doing and trying to achieve.

    >> No. I don't do Windows and I've never done Windows. And I don't apply
    >> for jobs that involve doing anything on Windows.

    > And as I can see you are extremely open minded! Bravo!


    Nothing wrong with specialism. Abigail probably has also never
    programmed in C#, and will never do so, nor will apply for jobs. That's
    a choice and has nothing to do with being open minded or not.

    > Listen sonny, I've probably worked at far more companies than you,


    Hurray, the "my dick is bigger then yours so I have pleased more
    females" argument.

    > the real world and while ls, cat, echo, etc. can be installed on a
    > Windows box often it isn't.


    OMG!!!11111eleven you mean like, eh, perl.exe for example?

    > we were talking about Perl, remember?) seems to me to be stupid, short
    > sighted, lazy, etc.


    "A truly great computer programmer is lazy, impatient and full of
    hubris, says Larry Wall." <http://www.paulagordon.com/shows/wall/>

    > If I'm asked to write a Perl script by the client then assuming
    > there'll be a Perl interpreter is not a silly assumption.


    Two very important questions are: which version of Perl, and what
    modules are installed. Even your script and modules have to be
    installed.

    How is that different from installing an additional tool?

    --
    John Experienced Perl programmer: http://castleamber.com/

    Perl help, tutorials, and examples: http://johnbokma.com/perl/
    John Bokma, Jan 13, 2007
    #16
  17. Charlton Wilbur wrote:
    > You *really* ought to do enough research to find out who you're
    > lecturing. I don't think you intend this tirade to come across as comedy.

    What an argument to authority?!? Apparently you are also in the "let's
    write non-portable and inefficient code" camp.

    --

    Andrew DeFaria <http://defaria.com>
    I hit the CTRL key but I'm still not in control!
    Andrew DeFaria, Jan 13, 2007
    #17
  18. Kim Gardiner CS2003

    Dan Mercer Guest

    "Andrew DeFaria" <> wrote in message
    news:...
    John Bokma wrote:

    Some folks treat Perl like a glorified korn shell, and do
    ghastly things like this:


    my @data = `cat somefile.txt`;

    or
    my @files = `ls /some/directory`;

    Perl has built-in functions for a lot of stuff you
    might be tempted to use shell commands for. It's
    generally preferable to use Perl when you write Perl programs.


    Depends on what you're doing of course. Why would I copy
    a program that does already its work perfectly and reinvent
    the wheel? Increase development time, and make many mistakes
    while doing so?

    Well, for one thing, "my @files = `ls /some/directory`" can give you
    bad data that could lead your program into executing a path you never
    anticipated (think, filename with embedded newline). Also, when
    your code is peer reviewed, your peers will think you are a fargin' idiot.

    Dan Mercer


    Because 1) it's inefficient in that you are forking and exec'ing a process to do it and 2) portability - there's no guarantee that
    the next platform you port this to has the same commands. For example, you use "ls" above. But there is no "ls" under Windows. If
    instead you use a more Perl like way your Perl script will immediately port without and issue.

    --
    Andrew DeFaria
    Why do the Alphabet song and Twinkle, Twinkle Little Star have the same tune?
    Dan Mercer, Jan 13, 2007
    #18
  19. Kim Gardiner CS2003

    Dan Mercer Guest

    "John Bokma" <> wrote in message news:Xns98B777C654642castleamber@130.133.1.4...
    : Andrew DeFaria <> wrote:
    :
    : > Taking the poor grammar out of the picture
    :
    : As soon as people talk about grammer usage (or abuse) in a Usenet post
    : they have little to say about the issue at hand, which doesn't amaze me
    : in your case.
    :
    : > Similarly I think it's better to write script in anticipation that
    : > they may be asked to run on systems I've never thought that they
    : > would.
    :
    : If its not in the requirements and not likely, why bother? I try to find
    : the best possible solution for my customers instead of making up a set
    : of silly rigid rules.
    :
    : [ Cygwin ]
    : > server, grep, awk, diff and quite literally thousands of others, I
    : > cannot guarantee that the client will go for it. Indeed many do not.
    :
    : So they have no problem with you installing Perl, but they do have a
    : problem when you install (from your example) ls.

    Where I work, Perl is on the allowed list of utiliies and they foolishly
    forgot to limit it by platform. So, while I don't have Cygwin or UWIN or
    MKS, I do have grep and ls and many other Unix utilities - rolled in
    Perl.

    Dan Mercer
    :
    : I guess you write all your modules yourself as well then? I mean, they
    : might have a problem or two with installing some CPAN modules as well.
    :
    : >> Not all Perl scripts are used on different platforms.
    : > Yes and many of them can't because they use things like those
    : > described above.
    :
    : And for most that's a non-issue. Rigid development rules are for
    : programmers with little skills. Skilled programmers are able to see the
    : pros and cons of several possible solutions and select one.
    :
    : > My Perl scripts can and are used on various platforms.
    :
    : So can and are mine, most out of the box. On the other hand I have no
    : problem at all with using external tools. It all depends on the
    : requirements of my customers.
    :
    : >> Most I write aren't. But like I said, it's a non-issue if the
    : >> external program is ported to the target platform(s) as well.
    : > And if the client will allow you to install such tools (and upkeep,
    : > patch, update, etc.). This is not always the case in the real world.
    :
    : Then their problem already starts with using Perl on Windows (for
    : example). And you using CPAN in general.
    :
    :
    : > Additionally it adds to the requirements and prerequisites for the
    : > usage of your tool - not a good thing.
    :
    : But you reinvent the tool. Now if there is anything silly in software
    : development it's refusing to use a library / external tool because of a
    : "you never should" rule.
    :
    : Programming is about flexibility.
    :
    : > Finally often the external tool
    : > does a lot more stuff than what you need. They call this wasteful.
    :
    : Most external tools have switches that enable / disable features. Code
    : that doesn't get executed doesn't matter. And if there is a slight
    : overhead because the tool does something extra, this overhead might be
    : insignificant compared to rolling out your own code in Perl.
    :
    : It all depends on circumstances, not on some silly rule you prefer to
    : live by.
    :
    : > Again this is good to know. I always like knowing who I would *not*
    : > recommend for a job. Welcome to the list.
    :
    : I am glad to be on it, especially based on your other drivel I am
    : sharing the honor with Abigail and probably a lot of other programmers
    : in this group.
    :
    : >> I rather do that then waste his/her valuable time and money on making
    : >> a wget clone if wget does /exactly/ what is required.
    : > Exactly is a debatable term here.
    :
    : A debat which you avoid by making up a brain dead rule.
    :
    : > Think about how hard perl -MCPAN
    :
    : What!? Installing external libraries on Perl? That *is* allowed and a
    : single executable not?
    :
    : --
    : John Experienced Perl programmer: http://castleamber.com/
    :
    : Perl help, tutorials, and examples: http://johnbokma.com/perl/
    Dan Mercer, Jan 13, 2007
    #19
  20. Kim Gardiner CS2003

    John Bokma Guest

    Andrew DeFaria <> wrote:

    > Which rigid rule are you referring to since I made no such claim. I
    > gave reasons why I thought it was better to do X than Y not that one
    > had to do X instead of Y. Can you understand that logical difference?


    Maybe reread "<>" were I
    clearly wrote: "Depends on what you're doing of course."

    Now who has a problem with interpretoring [1] things?


    [1] <>

    --
    John Experienced Perl programmer: http://castleamber.com/

    Perl help, tutorials, and examples: http://johnbokma.com/perl/
    John Bokma, Jan 13, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Yadagiri Rao KP

    Run unix commands from Java

    Yadagiri Rao KP, Aug 5, 2003, in forum: Java
    Replies:
    2
    Views:
    7,831
    Dave Miller
    Aug 5, 2003
  2. Yadagiri Rao KP

    Get all commands from unix

    Yadagiri Rao KP, Aug 7, 2003, in forum: Java
    Replies:
    4
    Views:
    427
    William Dowling
    Aug 7, 2003
  3. Spendius
    Replies:
    2
    Views:
    2,958
    Rogan Dawes
    Dec 13, 2004
  4. Ben Pfaff

    Re: man pages for C commands (GCC commands)

    Ben Pfaff, Jun 24, 2003, in forum: C Programming
    Replies:
    4
    Views:
    3,966
    Thomas Stegen
    Jun 28, 2003
  5. Tim Stanka
    Replies:
    1
    Views:
    790
    Jeff Epler
    Aug 2, 2004
Loading...

Share This Page