-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
oneliner helper does not allow variables #355
Comments
What are you talking about? That looks like a oneliner correctly escaped to be used in a Makefile. |
proof in image
|
Given this Makefile all:
perl -e '$$a = 42; use Devel::Peek; Dump $$a' Try running |
Another way to show the problem is to add a simple
|
another example is to try one liner using a simple hash |
As @Leont said this is not generating Perl code, it is generating Perl code escaped for use in a Makefile. |
Thanks for the clarification, once used in a Makefile, there is no issue. Unfortunately the unit test view https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/blob/master/t/oneliner.t#L33 |
@atoomic You are asserting as fact that |
The |
Fix Perl-Toolchain-Gang#355 Double escaping '$' for Makefile usage is fine, but we should not use such a syntax while testing and trying to run the oneliner output. This change is 'unescaping' the '$$' to '$' so we can perform some extra checks while using oneliner. Otherwise as shown in this example a simple 'my $foo' test will fail.
My main concern is the way we perform the test Please view and consider #356 |
a simple test like which will lead to this error
|
Fix Perl-Toolchain-Gang#355 Double escaping '$' for Makefile usage is fine, but we should not use such a syntax while testing and trying to run the oneliner output. This change is 'unescaping' the '$$' to '$' so we can perform some extra checks while using oneliner. Otherwise as shown in this example a simple 'my $foo' test will fail.
Fix Perl-Toolchain-Gang#355 Double escaping '$' for Makefile usage is fine, but we should not use such a syntax while testing and trying to run the oneliner output. This change is 'unescaping' the '$$' to '$' so we can perform some extra checks while using oneliner. Otherwise as shown in this example a simple 'my $foo' test will fail. Note we also have to unescape braces '{{' and '}}' used in dmake... A better solution would be to produce a Makefile and run it directly.
Fix Perl-Toolchain-Gang#355 Double escaping '$' for Makefile usage is fine, but we should not use such a syntax while testing and trying to run the oneliner output. We could consider unescpaing '$$', '{{', '}}'... (for dmake) but a cleaner solution is to test the oneliner in a Makefile itself.
Fix Perl-Toolchain-Gang#355 Double escaping '$' for Makefile usage is fine, but we should not use such a syntax while testing and trying to run the oneliner output. We could consider unescpaing '$$', '{{', '}}'... (for dmake) but a cleaner solution is to test the oneliner in a Makefile itself.
Fix Perl-Toolchain-Gang#355 Double escaping '$' for Makefile usage is fine, but we should not use such a syntax while testing and trying to run the oneliner output. We could consider unescpaing '$$', '{{', '}}'... (for dmake) but a cleaner solution is to test the oneliner in a Makefile itself.
Fix Perl-Toolchain-Gang#355 Double escaping '$' for Makefile usage is fine, but we should not use such a syntax while testing and trying to run the oneliner output. We could consider unescpaing '$$', '{{', '}}'... (for dmake) but a cleaner solution is to test the oneliner in a Makefile itself.
When reading the unit test for the
sub oneliner
fromt/oneliner.t
You have the feeling that oneliner authorizes the usage of variables, all the most the test is passing.
But in truth it's using references:
I wonder if we should teach
sub oneliner
toallow_variables
when callingquote_literal
, or detect incorrect usage of variable...For example you can use
%h
but then it's going to fail when using$h
later to access a value...Detail:
my %h = (1..4);
is a valid onelinerbut
my %h = (1..4); print $h[1]
is invalidThe text was updated successfully, but these errors were encountered: