How does checking the amount of free disk space before and after execution help?

This script isn't the only process running - lots of other stuff will be using up disk space as well in an unpredictable manner. And if the partition's full at run end, that doesn't tell me if my output succeeded or not. Finally if I'm querying variable length fields out of a database, I dont know how much data I'm going to write before run time.

Checking disk space can *never* work.

>If your hard drive is full, you have more to worry about than a 
>perl script failing to die 'gracefully'

If a write fails during a run I'd better try damn hard to log the failure into a database, get an email to an administrator, then try to switch output to a different mounted drive. Yes there are sysadmin checks for disk space, but that's no excuse for a script failing to act sensibly when the worst happens.

Unfortunately, this is the kind of reply I expected - "they're only a few scripts, why does it matter if you lose some data?". Well it does matter for people doing this stuff commercially, and I wish (some) authors would start to realise this!

When I'm writing a 20 liner at home, yes i don't care too much, but these are CPAN modules, and by implication others are going to use them, and they therefore need to be robust and behave sensibly when errors occur.

Thanks for the reply - It's good to get an alternative viewpoint even if I have to politely disagree :)

Some of these scripts drive the back ends for multi-million pound companies [...]

Right, but the guy who wrote the CPAN module probably did so to help him out with a 20 liner at home; conversely, if the module had been written for a multi-million pound company in the first place, chances are it would never have been okayed for release to CPAN.

Now I don't run a multi-million pound company, but I do see it as my responsibility to audit the CPAN code I employ, more or less carefully according to the criticality of the operations I'm using it for. If I'm not happy with the code I don't use it - either I roll my own, or I adapt it for my needs.

While it would be nice if all the code offered for free on CPAN were perfect, we're unlikely to reach that happy state any time soon.

One perfectly valid option is to offer the author some money to harden their code, either direct or through the convenience of a TPF grant.

Hugo

I agree with the last half of your comment.

• You should audit the code you use.
• You should harden it, and you should resubmit the code back to the author and back to CPAN.
• Or pay the authour to harden it.

But outside of that the community as a whole has a responsibility to understand the users needs. CPAN modules are for users, what do users need is what the author should focus on. This is usually easy because the code you are working on is for your own needs, and if you need something there is a probability someone else will need it or find it useful once you are done with it.

But I think the point this post is making is with more people using CPAN modules blindly as time goes on what is the communities responsibility to the code on CPAN. With the recent meditations on security in CPAN modules and this I think this whole debate can be changed slightly to does the PERL community need to audit the offerings on CPAN occasionally. And if so should there be a mechanism of discusison for what is found in the audit process.

Now I think that is being done, just the fact that the poster posted this shows the code gets reviewed. And the possible redresses for the situation have been stated, but I think the poster is asking for something more active from the community as a whole in general.

"No matter where you go, there you are." BB

Well I don't own a multi-million pound company either - I just write scripts that are used by some, but not many - if only my pay reflected that :)

Modules specifically written for companies will generally not get released due to ownership issues, but often they're just written for specific in house tasks which are not that useful to anyone else (apart from the odd competitor!)

From my own experience, you might be surprised how much CPAN code does get used by companies. I don't want people to stop releasing modules to CPAN because there's some great stuff out there, and I don't expect them to be perfect either - mine certainly aren't!

It's just that recently when auditing potential modules for our own use, I've seen a few that don't check for write failures and that worries me a bit - I can't see any situation where that's a good idea.

I suppose I'm trying to say if an author writes a module to scratch an itch - fantastic, but please think about proper error checking before releasing it to CPAN because many other people may start to depend on it :)

Some of these scripts drive the back ends for multi-million pound companies, I DO need to worry about how they handle errors.

What scripts? The ones you write? Do you follow your own advice?

Well it does matter for people doing this stuff commercially, and I wish (some) authors would start to realise this!

What are you paying these authors?

What scripts? The ones you write? Do you follow your own advice? 

Yes and yes as much as humanly possible - forgive me if I don't see the point of this. Are you going to post some useful comments or just troll?

What are you paying these authors?

Nothing - I avoid using these modules because they *dont* check for write errors which is what I've said all along, and for some bizare reason you've chosen to ignore.

Do I generally pay the authors of modules I use or the perl developers? No, though a previous company I worked for did heavily sponsor Embperl development - I would always consider sponsoring a module author if a module showed promise and could be useful to us - as a salaried employee I'd prefer it if sponsorship came from the company rather than my own pocket though :) I've donated code to a CPAN project and a tiny bit of stuff to KDE, and am happy to donate code/advice to authors (which may or may not be useful!) - that's generally how things work in the OS world isnt it. Don't forget that a lot of bug reports are probably coming from developers using code heavily in commercial environments, and that does help the whole community in a more indirect way.

Ok seeing as I know this is going to go into a discussion on commercial companies and social responsibility etc - just because I mentioned money and companies does not mean I consider myself important or a great perl coder - I write fairly solid code but there are many developers in the perl community better than me (and probably better paid as well :). Some posters have implied that it doesn't matter if a script isn't robust - I'm respectfully saying that just isn't true - for other people such as myself, it's vitally important that scripts are 99.9% robust. Actually, unless you're just pratting around, I can't see any situation where silent data loss is desirable, but that's exactly what will happen if you use some of the modules on CPAN without a lot care.

I'm trying to emphasise the fact that if an author *chooses* to release to CPAN, and it is *their* choice, they really must think about sensible error handling before they release. Who knows what will be developed with/on top of that module, and what impact it may have later on?

If a script doesn't handle errors, at least the problem is localised to that script but, as we all know, modules are there for *reusable* code and that code might be used in thousands or millions of scripts. A module author therefore has to take some responsibility (heck, pride even!) for ensuring robustness - I'm not talking legal liability here, just a personal duty. If they can't or won't do that they should *NOT* release to CPAN - post it on their site, advertise it here, do anything else yes, but again - DONT PUT IT ON CPAN!

Code auditing is an answer, and depending on the project ranges from being to desirable to mandatory, but having to do a thorough audit on every CPAN module you use takes a lot of time and effort - as suggested by another poster, I need to look at the B:: stuff to see if that could help automate things - if I get something done (which wont be anytime soon) I'll release it here.