Pure Perl df

[James Edward Gray II]

Okay, I'm at a loss and need help. A friend of mine is working with a
Perl script. It has a system call to df in it, he would like to
replace with something a little more portable.

The script is used in a 32 server environment that I know has at least
four operating systems: HP-UX, Solaris, Linux, and Windows. I believe
df is pretty standard on all of those but Windows, though the options
vary.

So the questions: Is there a pure Perl way to handle a df-like call?
Is there an equivalent program in the Windows world? Any other tips?

I browsed the CPAN a bit, but wasn't too happy with the choices there,
aside from the fact that any module installs would pretty much defeat
the purpose here.

Thanks for any help you can provide.

James

[Luke Bakken]

> Okay, I'm at a loss and need help. A friend of mine is

> working with a
> Perl script. It has a system call to df in it, he would like to
> replace with something a little more portable.

Well, looking here at the source to df on OpenBSD:
[url]http://www.openbsd.org/cgi-bin/cvsweb/src/bin/df/df.c?rev=1.37&content-t[/url]
ype=text/x-cvsweb-markup

it looks as though it uses getmntinfo() to get information about free
space. This function call may be implemented in some perl module, or you
could be brave and use syscall() to call it. I'll work on that for kicks
and get back to the list. Your friend will have to see if this function
exists on all his unix platforms.

> The script is used in a 32 server environment that I know has
> at least
> four operating systems: HP-UX, Solaris, Linux, and Windows.
> I believe
> df is pretty standard on all of those but Windows, though the options
> vary.

On Windows, I'd use Win32::DriveInfo

> So the questions: Is there a pure Perl way to handle a
> df-like call?
> Is there an equivalent program in the Windows world? Any other tips?
>
> I browsed the CPAN a bit, but wasn't too happy with the
> choices there,
> aside from the fact that any module installs would pretty much defeat
> the purpose here.

Why is that? That is the point of modules.

Luke

[Morbus Iff]

>> I browsed the CPAN a bit, but wasn't too happy with the

>> aside from the fact that any module installs would pretty much defeat
>> the purpose here.

>
>Why is that? That is the point of modules.

Note that if the module is pure perl without a lot of dependencies, you can
ship it with your final tarbull - that's the approach I use with AmphetaDesk
([url]http://www.disobey.com/amphetadesk/[/url]), where I ship XML::Simple and
Text::Template, even for Linux distributions. Stuff that requires
compilation (like XML::Parser, Compress::Zlib, etc., etc.), I leave
up to the ever easy-to-use CPAN.


--
Morbus Iff ( i put the demon back in codemonkey )
Culture: [url]http://www.disobey.com/[/url] and [url]http://www.gamegrene.com/[/url]
Spidering Hacks: [url]http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom[/url]
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

[James Edward Gray II]

On Dec 30, 2003, at 3:56 PM, Bakken, Luke wrote:

>> I browsed the CPAN a bit, but wasn't too happy with the
>> choices there,
>> aside from the fact that any module installs would pretty much defeat
>> the purpose here.

>
> Why is that? That is the point of modules.

Well, as I said we're talking about 32 servers running at least 4
different operating systems here, and we're not comparing versions yet.
How many versions of Perl do you think that adds up to? If we're
going to install modules under those conditions why not just check the
OS version and shell out? I bet there are less combinations that way.

This a professional server environment, with real world serving
concerns like big uptime, system restores, etc. The way the sys admins
keep on top of all that is to stay as in control of those machines as
humanly possible. That means they think long and hard before adding
more software dependancies. If they add even one module, that means
they've practically doubled the work of all future Perl upgrades (one
install to two, plus testing). If they add 10 modules across 32
servers, well that's getting crazy pretty fast.

Don't get me wrong. I love the CPAN and the tons of modules it offers.
I'm sure they do too, under the right circumstance. They've got a job
to do though and sometimes that makes for hard choices.

James

[Luke Bakken]

> >> I browsed the CPAN a bit, but wasn't too happy with the

> >> choices there,
> >> aside from the fact that any module installs would pretty

> much defeat

> >> the purpose here.

> >
> > Why is that? That is the point of modules.

>
> Well, as I said we're talking about 32 servers running at least 4
> different operating systems here, and we're not comparing
> versions yet.
> How many versions of Perl do you think that adds up to? If we're
> going to install modules under those conditions why not just
> check the
> OS version and shell out? I bet there are less combinations that way.

That's your answer. Use $^O and other OS indicators and set up df's args
appropriately then.

[James Edward Gray II]

On Dec 30, 2003, at 4:07 PM, Morbus Iff wrote:

> Note that if the module is pure perl without a lot of dependencies,
> you can
> ship it with your final tarbull

I looked at three modules. Two didn't support Windows and I have no
idea about the third, which I couldn't figure out what it was up to.
If you guys are seeing a good module I'm missing please do point it
out. Heck, if it's "pure Perl", I can just see how it's managing a df
call...

James

[James Edward Gray II]

On Dec 30, 2003, at 4:30 PM, Bakken, Luke wrote:

> That's your answer. Use $^O and other OS indicators and set up df's
> args
> appropriately then.

Which gets us back to my other question: Is there a Windows equivalent?

James

[Luke Bakken]

> > That's your answer. Use $^O and other OS indicators and set up df's

> > args
> > appropriately then.

>
> Which gets us back to my other question: Is there a Windows
> equivalent?

Sure, look at the output of the 'dir' command.