Re^2: Executing a program from within a Perl Module in a non-standard path

Ahh, this is pretty cool. I like the idea that System::Sub represents, but alas, it requires that I know where the executable (or script!) will be at compile time (at least, relative to the cwd).

As an aside, I can't understand how import doesn't get itself in an infinite loop! Where's the exit?!

But thanks; I'll definitely keep this class in mind for later projects

Comment on Re^2: Executing a program from within a Perl Module in a non-standard path Download Code

Replies are listed 'Best First'.
Re^3: Executing a program from within a Perl Module in a non-standard path by tobyink (Canon) on Mar 20, 2013 at 15:30 UTC
"As an aside, I can't understand how import doesn't get itself in an infinite loop!" System::Sub::Env::import is going to System::Sub::import. Different package; different sub. The reason for the `goto` is to hide System::Sub::Env::import from the call stack - System::Sub's import method looks at `caller`. `package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name`	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Executing a program from within a Perl Module in a non-standard path
by tobyink (Canon) on Mar 20, 2013 at 15:30 UTC

"As an aside, I can't understand how import doesn't get itself in an infinite loop!"

System::Sub::Env::import is going to System::Sub::import. Different package; different sub.

The reason for the goto is to hide System::Sub::Env::import from the call stack - System::Sub's import method looks at caller.

package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name

[reply]
[d/l]
[select]