in reply to Why not recommend IO::All?

IO::All is certainly nice for oneliners or throw-away scripts, but it makes it horribly easy to open up security holes like PHPs Remote File Inclusion because its open functionality transparently opens http:// URLs just like files.

Also, it contains far too much magic for my taste to make its fancy syntax work

Replies are listed 'Best First'.
Re^2: Why not recommend IO::All?
by karlgoethebier (Abbot) on Mar 18, 2015 at 19:46 UTC

    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»

      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.