in reply to Re^2: portable way to get system load average
in thread portable way to get system load average

every other script langauge has a call for this.. perl being the system tool it is, how is this even possible? i am disappointed there is no pure perl solution in the core :/

I didn't say there wasn't one (I don't have the information to accurately answer that question), but I was merely asking why you have such a restriction. If there is some technical reason, perhaps it can be mitigated another way.

If you don't have a shell, how is your program running? If you don't know what commands are available on the host, how can you assume that any program/shell/script/whatever is available? There is no cure-all for every environment or platform.

One thing that perl does that I think is a great thing, is that it doesn't re-invent the wheel all of the time. If there is a command that exists on all version of a particular platform (like ls, cp, etc), it doesn't try to create it's own version. You have to make some assumptions to expect any script to work on any particular system. (is perl installed, is it the correct version, do I have access to /bin, is my script executable, or whatever) You can check for these assumptions, but if you want a script to execute on _any_ environment regardless of what you have access to, what exists on the box, or anything, then I'd imagine it would be rather difficult and/or tedious.
  • Comment on Re^3: portable way to get system load average

Replies are listed 'Best First'.
Re^4: portable way to get system load average
by loadaverage (Novice) on Jul 07, 2010 at 11:02 UTC

    i dont find it unreasonable to write full perl programs that make no assumptions about what systems they run on whatsoever... actually, that's one of its real strengths and the reason many commercial applications and many inhouse tools were written in it. it can bridge systems flawlessly because it has its own library of functions.

    there are multiple CPAN modules for uptime/load, i had a look at some of them. there are a couple of reasons why i would prefer not to use them:

    1. they have no corresponding packages in most operating systems (only the most used/famous ones have) and would create overhead in system admininstration.
    2. they use exactly the same unportable techniques like using sysctl and /proc and so on