Skip to content

Commit

Permalink
Set $PROCESS::ARGFILES after command line processing
Browse files Browse the repository at this point in the history
  • Loading branch information
perlpilot committed Jul 5, 2012
1 parent 58d9852 commit 6ec88fa
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion src/core/Main.pm
Original file line number Diff line number Diff line change
Expand Up @@ -101,7 +101,7 @@ my sub MAIN_HELPER($retval = 0) is hidden_from_backtrace {
last;
}
}

$PROCESS::ARGFILES = IO::ArgFiles.new(:args(@args));
return @positional-arguments, %named-arguments;
}

Expand Down

4 comments on commit 6ec88fa

@pmichaud
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$*ARGFILES is already being set in terms.pm -- any reason for setting it here instead? Do we need both?

@perlpilot
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if we need both. I didn't trace when/if/how process-cmd-args was called.

The reason I added it in process-cmd-args is because if it's not there, $*ARGFILES contains the original @*ARGS with all of the command line options and IO constructs such as lines try to open files named after those options.

@pmichaud
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've decided that IO::ArgFiles should be directly manipulating @*ARGS instead of having its own copy. That's how P5 does it :-).

Beyond that, I suspect that a MAIN subroutine that wants to have the unbound arguments captured into @*ARGS should capture and set it directly via

multi sub MAIN($arg1, $arg2, *@*ARGS) { ... }

and then $*ARGFILES should be smart enough to use that.

I'm handwaving a bit here, though, because if $_ARGFILES has already been consuming
some stuff before MAIN() was called, we may need some way to "reset" it if a new
@_ARGS has been created.

Or, $_ARGFILES could keep track of the identity of the current @_ARGS object and reset
itself if/when it detects a change. That sort of magic might be on the heavy side... but then
again $*ARGFILES Is already fairly magical to begin with.

Pm

@perlpilot
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like IO::ArgFiles is insufficiently lazy. It tries to capture @_ARGS at a particular point in time, but what it really should do is completely ignore @_ARGS until the last possible moment when it's needed (like when calling slurp() or get() or when someone tries to look at $*ARGFILES) So I tend to agree with your last paragraph.

Please sign in to comment.