Re^2: Why not recommend IO::All?

Thanks for your reply but i'm not convinced...

"IO::All is certainly nice for oneliners or throw-away scripts..."

Yes, but i have some scripts > 100 lines using IO::All that work for years without any quirks.

"...horribly easy to open up security holes ... open functionality transparently opens http:// URLs just like files."

May be. But if you know about this issue there is no reason to make it so.

And as fare as i remember you need IO::All::LWP installed for this kind of transparency.

"...far too much magic for my taste to make its fancy syntax work..."

Some folks like Perl for the magic.

OK, i found one feature that didn't work as proposed: Strange IO::All constructor behavior?

But remember this German saying:

"A matter of taste" said the ape and bit into the soap.

Best regards, Karl

«The Crux of the Biscuit is the Apostrophe»

Comment on Re^2: Why not recommend IO::All?

Replies are listed 'Best First'.
Re^3: Why not recommend IO::All? by Your Mother (Archbishop) on Mar 19, 2015 at 18:24 UTC
I have run into at least one situation where the magic versus other deep monkying broke things. I tried to use IO::All at work a few years back and it caused problems (which at the time was too much work to debug so I just let go of the attempt). The code base is a huge mess hopelessly full of `BEGIN{}`s and `STDIN/STDERR` shenanigans so I understand IO::All was not exactly to blame but I still would avoid it today unless it’s for personal or throwaway stuff. Path::Tiny and other new tools fill the gaps for most of what I need.	[reply] [d/l] [select]
Re^4: Why not recommend IO::All? by karlgoethebier (Abbot) on Mar 19, 2015 at 18:54 UTC
Thank you very much for reply Your Mother. "...Path::Tiny and other new tools..." Yes, i'm aware of this. Please see Re^2: Optical drive contents listing problem. Best regards, Karl P.S.: And i added shenanigans to my flashcard. Never heard before. «The Crux of the Biscuit is the Apostrophe»	[reply]