Tracked this down to a very inefficient DateTime::TimeZone.
https://rt.cpan.org/Ticket/Display.html?id=47671

Since you're already using autodie qw(:all), perl5i will be delegating the heavy lifting of system() to IPC::System::Simple. It also provides a capture() method that isn't exported by autodie, but which does provide a cross-platform replacement for backticks.

IPC::System::Simple goes to great lengths to smooth out cross-platform issues. In particular, it detects and corrects all sorts of wacky bugs, like windows running commands twice, or not running them at all and saying that it did, or Perl 5.10 under Linux not reporting coredumps, or older versions of Perl not doing proper taint checking.

Of course, IPC::System::Simple only provides you with a simple interface. If you want anything more than that, you'll need to use a different module.

-- Paul

What about capturing STDERR?

IPC::System::Simple tries very hard to be as close as possible in syntax and semantics to system() and backticks without sucking; that's why it's got 'simple' in the name.

Capturing STDERR is something which has come up a few times. There aren't any technical barriers to doing it, but there are interface barriers. Unless you want something that just rolls STDOUT and STDERR together, then it's easy to end up with an interface that's large and complex, which is very much against the IPC::System::Simple design goal.

Interface suggestions are very welcome. If it's simple, clean, and can be used by a developer who has the attention span of a monkey chewing on a fly-swatter, then I'm very willing to consider it.

I'm also interested if you find the holy grail of IPC modules, which works consistently everywhere, has an interface that doesn't suck, doesn't require me to look inside $?, returns full return values on Windows, doesn't use the shell when it's not supposed to, captures both stdout and stderr, performs taint checks, looks up signal names, and throws proper exception objects, then do let me know. ;)

I think I've implemented helpers for IPC::Open3 methods 3 times in 3 different ways. I'm pretty happy with my latest iteration of this if we'd like to go down an open3 route. Accepts an arrayref of command+args and returns stdout & stderr as scalars. Could also implement returning the system return value/pid etc.

The method I'm using currently is probably a reworking of some part of IPC::Run(tweaked what I needed w/out installing the module). Have not given any thought to portability with the method though.

That looks as easy as overriding system with

use Scalar::Util qw/dualvar/;

sub system {

  my $ret = CORE::system @_;
  return dualvar $ret, $ret == 0;

}

Do you want that in perl5i or as a separate module?

dualvar isn't going to cut it. The exit code won't show up in string context, like when it gets printed.

$ perl -wle 'print system "dont exist"' Can't exec "dont": No such file or directory at -e line 1.
-1

$ perl -wle 'use Scalar::Util qw/dualvar/; sub system { my $ret = CORE::system(@_); return dualvar($ret, $ret == 0) } print ::system("dont exist")' Can't exec "dont": No such file or directory at -e line 1.

Okay, it isn't fully tested (because I have to sleep at somepoint), but how about this:

http://gist.github.com/103579

Hang on, we're already using autodie qw(:all), aren't we? That means that system already throws an exception on failure, and returns the command's exit value on success.

By default, non-zero exit statuses are considered a failure (and result in an exception). You can supply a list of "successful" exit values as the first argument:

system( [0, 1], $cmd, @args); # exit value of 2+ is considered a failure.

As a special case, you can pass in a value of [ -1 ] to mean that any exit value is considered okay:

my $exit_value = system( [ -1 ], $cmd, @args);

Cheerio,

Paul

@cowens For future reference, you want to use the "fallback" parameter to overload. Then you only have to implement 0+ and Perl will figure out the rest.

@pjf INGENIOUS! Teach me not to write tests first. Hmm, doesn't look like the exit code is in the exception. Could you add a way to get at that?

The inability to get the exit status and other information is a known bug, and already on my TODO list. It involves a modest rearchitecture of the underlying IPC::System::Simple module to improve its error reporting.

I've actually got a rough design spec put together for the changes needed, and while I've discussed this with @jettero, I should publish it in a more public place to make it easier for patches to find me. ;)

This weekend has me working on autodie's hinting interface as a first priority, to make sure it's ready in time for everyone to feel comfortable about it for the 5.10.1 release. If I get the time I'd love to get the ISS fixes done at the same time, but that depends very much on my supply of round tuits.

This is done in the signatures branch, but signatures.pm has some critical bugs. Waiting for upstream to fix them.

+1 for Path::Class

I have found that the recent versions of MooseX::Declare itself adds at least 1 second to the compile time of a program. Therefore, I have made it an optional feature in my own fork of perl5i. A quick 'use perl5i moose => 1;' will enable it in the global level.

Then in your class myclass { statement you need to include 'use perl5i' again (without the moose => 1 this time) as I haven't figured out how to make that automatically get added to the class and role statements. If anyone knows, please feel free to fork and fix!

use Tie::RefHash::Nestable by default unless specified otherwise?

But fixing it in core would be better, certainly.

Putting aside for a moment the performance problems, how would one tie all hashes "by default"?

Adding some kind of hack to make all hashes Tie::RefHash::Nestable, unless and until tied to a different class, would be one ugly way to provide this behaviour. (For example a source filter that turns "my %h;" into 'my %h; tie %h, "Tie::RefHash::Nestable" or die;'

But as I mentioned I think it would be better to fix core to preserve references stored in hash keys.

Is this too UNIX centric?

Recursive rm and mkdir -p already exist in File::Path as remove_tree and mkpath respectively. Multiple file mv and copy should be easy: move and copy from File::Copy combined with a for loop.

sub mv {
    my $dir = pop;
    croak "not enough args" unless @_;
    for my $file (@_) {
        move $file, $dir
            or croak "could not move '$file' to '$dir': $!;
    }
    return 1;
}

touch is implemented by Touch

The names are Unixy, but the need for the functionality is not. make_path() and remove_tree() are better. Not sure what to do about mv and cp and touch.

hmm, move_file/copy_file isn't good enough because you can move/copy a directory. And I don't like move or copy because they are general verbs. Naming them Fred and Barney isn't any good either. Must think some more.

I would classify that as unexpected, unpleasant behaviour.

Your reasoning?

It prepends directories I didn't specify to @INC, messing with @INC behind my back is not nice. Everything else in perl5i (except strict, which is a special case) has enhanced existing things. You could ignore the enhancements if you wanted to. But with mylib I would have to worry that the directory my script is in (or its parent directory) might have a lib directory and the lib directory might have a .pm or .pmc file that matches a module I am using. Imagine helper scripts in a source directory that use the installed version of the module, suddenly they will use the new (possibly buggy) version of the module instead of the installed version (which presumably has been tested). Also, I have to take extra pains to not have it prepend stuff (e.g. shifting @INC in a BEGIN block after use perl5i).

Thanks for expanding on that.

Part of perl5i is to make Perl DTRT for 99% of the cases and only for the remaining 1% do you have to turn it off. To that end, for every scenario where you have a module in lib/ and you don't want to use it I'm pretty sure there's about 100 where you do. Since the @INC path is absolute it's not nearly as dangerous as, say, having the cwd in @INC which we already do and the sky remains fixed firmly overhead.

You're right that having to muck with @INC in a BEGIN block to turn it off is ugly. I think a "no mylib" would allow those 1% to easily turn off the behavior.

There is one scenario where its a bad idea, and that's in module testing since that wants to use blib, not lib. That's a pretty broad case. It might make sense to prepend blib/lib as well, but then I'm wondering if that's a bit too much of a good thing.

But is using ./lib the right thing? Is this something we want to encourage people to do? Or would we rather people use Module::Starter to make installable modules and have them install the modules into the right place (rather than some random place). If we are talking about delivering projects that are supposed to be self-contained, well, that is what PAR is for.

Including mylib doesn't eliminate any of that. And they're all relatively complicated things that have to be discovered and configured and learned by both the developer and the user. Shipping a program as a module is often overkill, your users have to understand the Perl module installation process just to get their program running. PAR is neat, but it creates opaque files which are difficult to debug.

As I use more and more PHP there's definite value in being able to just unpack a source archive and have it work. So to the question of whether this is the sort of thing we want to encourage people to do I say yes.

There is Perl6::Caller which provides behavior similar to what you are looking for. It would probably be fairly simple to integrate it with perl5i. I don't have any experience with github (just signed up) but I could look at implementing that change.

And, again, in my own fork I have implemented Perl6::Caller as an automatically included module.

Or just use IO::All. I'm leaning that way.

In addition to insertion, replacing a line in the middle of a file using Tie::File is something I do frequently, and is one task for which I'd like some sugar. Something like

file( 'foo.txt' )->replace_line( 'service foo-0' => 'service bar-0' );

would be great.

IO::All has Tie::File sugar.

 $io = io 'file.txt';
 $io->[42] = 'Line Forty Three';       # Change a line
 print $io->[@$io / 2];                # Print middle line
 @$io = reverse @$io;                  # Reverse the file
 $_ =~ s/this/that/ for @$io;          # s/// over the whole file

I second IO::All, it's very slick, and really does live up to it's name!

And since I liked it, I added it to my own fork. Enjoy!

Look at the PHP array functions for inspiration.
http://php.net/manual/en/function.array.php

I'll pick this one up.

trim/ltrim/rtrim: done
is_number and friends: done

still todo:
- is_regex - is_object - is_instance - is_ref

All the trims are merged in

NO SOURCE FILTERS!

I'm kind of surprised nothing has fixed that localization bug yet.

But you're right, its a problem.

Well, in my fork, I have just added Carp to the list of imported modules (as well as several other features.)
If you are interested, you can see my fork over here. Maybe it it's useful, it'll get merged with the original version.

I have forked brunoV's fork and added some extra features if anyone is interested.