perlrun: -e -p -p -e all the same...

[p5pRT]

Migrated from rt.perl.org#35091 (status was 'rejected')

Searchable as RT35091$

[p5pRT]

From @jidanni

$ man perlrun|grep -- -.*loop   -n causes Perl to assume the following loop around your program\,   -p causes Perl to assume the following loop around your program\, OK\, but emphasize that these all act the same​: $ seq 3|perl -we 'print 9;' -p -e print\ 4 $ seq 3|perl -we 'print 9;' -p -e print\ 4 -p $ seq 3|perl -we 'print 9;' -e print\ 4 -p $ seq 3|perl -wpe 'print 9;' -e print\ 4 -p ... etc. etc. Also note it for -n.

Patch? You write the patch. You are the pros\, I am the schmoes. Just breeze your patch by me\, and I'll comment if it's wrong.

[p5pRT]

From @petdance

On Sat\, Apr 23\, 2005 at 09​:48​:02PM -0000\, Dan Jacobson (perlbug-followup@​perl.org) wrote​:

Patch? You write the patch. You are the pros\, I am the schmoes. Just breeze your patch by me\, and I'll comment if it's wrong.

No. You write the patch. Otherwise\, this is going to get ignored.

xoa

-- Andy Lester => andy@​petdance.com => www.petdance.com => AIM​:petdance

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @iabyn

On Sat\, Apr 23\, 2005 at 05​:02​:42PM -0500\, Andy Lester wrote​:

On Sat\, Apr 23\, 2005 at 09​:48​:02PM -0000\, Dan Jacobson (perlbug-followup@​perl.org) wrote​:

Patch? You write the patch. You are the pros\, I am the schmoes. Just breeze your patch by me\, and I'll comment if it's wrong.

No. You write the patch. Otherwise\, this is going to get ignored.

and even then it may well be ignored...

-- Counsellor Troi states something other than the blindingly obvious.   -- Things That Never Happen in "Star Trek" #16

[p5pRT]

From perl5-porters@ton.iguana.be

In article \rt\-3\.0\.11\-35091\-111324\.11\.2927027568466@​perl\.org\,   Dan Jacobson (via RT) \perlbug\-followup@​perl\.org writes​:

# New Ticket Created by Dan Jacobson # Please include the string​: [perl #35091] # in the subject line of all future correspondence about this issue. # \<URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=35091 >

$ man perlrun|grep -- -.*loop -n causes Perl to assume the following loop around your program\, -p causes Perl to assume the following loop around your program\, OK\, but emphasize that these all act the same​: $ seq 3|perl -we 'print 9;' -p -e print\ 4 $ seq 3|perl -we 'print 9;' -p -e print\ 4 -p $ seq 3|perl -we 'print 9;' -e print\ 4 -p $ seq 3|perl -wpe 'print 9;' -e print\ 4 -p ... etc. etc. Also note it for -n.

Patch? You write the patch. You are the pros\, I am the schmoes. Just breeze your patch by me\, and I'll comment if it's wrong.

Actually\, I'd prefer not to document it and leave open the option to make

perl -we 'print 9;' -pe 'print 4'

become

print 9; while (\<>) {   print 4; } continue {   print; }

[p5pRT]

@rgs - Status changed from 'open' to 'rejected'

[p5pRT]

From @rgs

Ton Hospel wrote​:

Actually\, I'd prefer not to document it and leave open the option to make

perl -we 'print 9;' -pe 'print 4'

become

print 9; while (\<>) { print 4; } continue { print; }

Nice idea\, but with complex ramifications. However\, you have a point\, so I'll mark this bug as rejected.

[p5pRT]

From @ysth

On Sun\, Apr 24\, 2005 at 02​:50​:03PM +0200\, Rafael Garcia-Suarez wrote​:

Ton Hospel wrote​:

Actually\, I'd prefer not to document it and leave open the option to make

perl -we 'print 9;' -pe 'print 4'

become

print 9; while (\<>) { print 4; } continue { print; }

Nice idea\, but with complex ramifications. However\, you have a point\, so I'll mark this bug as rejected.

I think the documentation already promises otherwise. perlrun says​:

  Upon startup\, Perl looks for your program in one of the following   places​:

  1. Specified line by line via -e switches on the command line.

  2. Contained in the file specified by the first filename on the com-   mand line. (Note that systems supporting the #! notation invoke   interpreters this way. See "Location of Perl".)

  3. Passed in implicitly via standard input. This works only if there   are no filename arguments--to pass arguments to a STDIN-read pro-   gram you must explicitly specify a "-" for the program name.

which clearly (to me) defines the meaning of "your program" in​:

  -p causes Perl to assume the following loop around your program\,

I suggest the following\, though it could use some shortening​:

Inline Patch

```diff --- perl/pod/perlrun.pod.orig 2005-03-20 03:21:02.000000000 -0800 +++ perl/pod/perlrun.pod 2005-04-27 16:41:58.154526400 -0700 @@ -640,7 +640,9 @@ you follow the example under B<-0>. C and C blocks may be used to capture control before or after -the implicit program loop, just as in B. +the implicit program loop, just as in B. Placing B<-e> switches +before the B<-n> switch will not accomplish this; the loop is placed +around all B<-e>-specified code, wherever placed on the command line. =item B<-p> @@ -658,11 +660,13 @@ If a file named by an argument cannot be opened for some reason, Perl warns you about it, and moves on to the next file. Note that the lines are printed automatically. An error occurring during printing is -treated as fatal. To suppress printing use the B<-n> switch. A B<-p> -overrides a B<-n> switch. +treated as fatal. To suppress printing use the B<-n> switch instead. +A B<-p> overrides a B<-n> switch. C and C blocks may be used to capture control before or after -the implicit loop, just as in B. +the implicit loop, just as in B. Placing B<-e> switches +before the B<-p> switch will not accomplish this; the loop is placed +around all B<-e>-specified code, wherever placed on the command line. =item B<-P> End of Patch. ```

[p5pRT]

From @demerphq

Nice idea\, but with complex ramifications. However\, you have a point\, so I'll mark this bug as rejected.

I think the documentation already promises otherwise. perlrun says​:

Personally i think this feature would be a worthy 5.10'ism. Since apparently this means breaking old semantics maybe a new switch could be added that would modify the standard behaviour of -e\, -n and -p?

so assuming it was -X

perl -Xe "$x=1;" -n "print $x++\,$_"

would be the same as

$x=1; while (\<>) {   print $x++\,$_ }

It would make a lot of command line scripts a lot easier to write. Also possibe would be new switches (possibly -b and -E) for putting code at the beginning or end of the script text without using a BEGIN{} or END{} block.

And a last thing would be it would be nice if there was an easy way to cause \<> to binmode its input files as under win32 its a real pain if you dont want text mode behaviour when you are using magic IO operator...

sticking

  binmode ARGV if $ARGV ne $_ARGV; $_ARGV=$ARGV;

into one liners when you want to do this is really annoying. (If there already is an easy way to do this please let me know.)

Cheers\, Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @tux

On Thu\, 28 Apr 2005 13​:27​:09 +0200\, demerphq \demerphq@&#8203;gmail\.com wrote​:

Nice idea\, but with complex ramifications. However\, you have a point\, so I'll mark this bug as rejected.

I think the documentation already promises otherwise. perlrun says​:

Personally i think this feature would be a worthy 5.10'ism. Since apparently this means breaking old semantics maybe a new switch could be added that would modify the standard behaviour of -e\, -n and -p?

so assuming it was -X

perl -Xe "$x=1;" -n "print $x++\,$_"

  perl -Xe '$x=1' -ne 'print $x++\,$_'

(and in examples\, it /could/ be wise to use single quotes\, because most shells in a unix-ish machine will try to expand $...)

As my example shows\, if the `extension' would be accepted\, in whatever form\, I also suggest to define that each -e part gets it's own braces/scope

would be the same as

$x=1; while (\<>) { print $x++\,$_ }

{ $x = 1   } while (\<>) {   print $x++\,$_   }

It would make a lot of command line scripts a lot easier to write. Also possibe would be new switches (possibly -b and -E) for putting code at the beginning or end of the script text without using a BEGIN{} or END{} block.

/me viciously nods​: very useful!

And a last thing would be it would be nice if there was an easy way to cause \<> to binmode its input files as under win32 its a real pain if you dont want text mode behaviour when you are using magic IO operator...

-C could be extended\, and that would include the env $PERL_UNICODE

sticking

binmode ARGV if $ARGV ne $_ARGV; $_ARGV=$ARGV;

into one liners when you want to do this is really annoying. (If there already is an easy way to do this please let me know.)

-- H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/) using Perl 5.6.2\, 5.8.0\, 5.8.5\, & 5.9.2 on HP-UX 10.20\, 11.00 & 11.11\, AIX 4.3 & 5.2\, SuSE 9.2 & 9.3\, and Cygwin. http​://www.cmve.net/~merijn Smoking perl​: http​://www.test-smoke.org\, perl QA​: http​://qa.perl.org reports to​: smokers-reports@​perl.org\, perl-qa@​perl.org

[p5pRT]

From @ysth

On Thu\, Apr 28\, 2005 at 01​:27​:09PM +0200\, demerphq wrote​:

And a last thing would be it would be nice if there was an easy way to cause \<> to binmode its input files as under win32 its a real pain if you dont want text mode behaviour when you are using magic IO operator...

sticking

binmode ARGV if $ARGV ne $_ARGV; $_ARGV=$ARGV;

into one liners when you want to do this is really annoying. (If there already is an easy way to do this please let me know.)

use open IN=>"​:bytes"\, I think.

IIRC\, the code you show won't work because you have no way to place the binmode between the open of a new file and reading the first line.

[p5pRT]

From @ysth

On Thu\, Apr 28\, 2005 at 03​:43​:24PM +0200\, H.Merijn Brand wrote​:

As my example shows\, if the `extension' would be accepted\, in whatever form\, I also suggest to define that each -e part gets it's own braces/scope

Yuck! Right now\, each -e is considered a separate line\, not scope​:

$ perl -wle'my $x=42;' -e'print $x;' -e'warn $x' 42 42 at -e line 3.

I don't want to see this changed.

It would make a lot of command line scripts a lot easier to write. Also possibe would be new switches (possibly -b and -E) for putting code at the beginning or end of the script text without using a BEGIN{} or END{} block.

/me viciously nods​: very useful!

Is BEGIN/END so hard to type?

[p5pRT]

From @demerphq

On 4/29/05\, Yitzchak Scott-Thoennes \sthoenna@&#8203;efn\.org wrote​:

On Thu\, Apr 28\, 2005 at 03​:43​:24PM +0200\, H.Merijn Brand wrote​:

As my example shows\, if the `extension' would be accepted\, in whatever form\, I also suggest to define that each -e part gets it's own braces/scope

Yuck! Right now\, each -e is considered a separate line\, not scope​:

$ perl -wle'my $x=42;' -e'print $x;' -e'warn $x' 42 42 at -e line 3.

I don't want to see this changed.

I agree with this. I dont think wrapping each -e in a {} makes that much sense.

It would make a lot of command line scripts a lot easier to write. Also possibe would be new switches (possibly -b and -E) for putting code at the beginning or end of the script text without using a BEGIN{} or END{} block.

/me viciously nods​: very useful!

Is BEGIN/END so hard to type?

I think it happens often enough with -n or -p that providing an easier alternative doesnt seem too unreasonable. And to a certain extent this idea is unnecessary if the -X modifier switch were implemented as there you would just do

  -Xe "#init" -n "#process" -e "#cleanup"

But if the -X idea doesnt seem acceptable to folks then making it easier to do BEGIN{} END{} would be nice. Id much prefer to see an -X modifier added if only because it would make explaining things a little easier as you dont have to explain/learn BEGIN/END semantics _and_ the code wrapping rules\, instead just the latter.

Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @tux

On Fri\, 29 Apr 2005 00​:24​:49 -0700\, Yitzchak Scott-Thoennes \sthoenna@&#8203;efn\.org wrote​:

On Thu\, Apr 28\, 2005 at 03​:43​:24PM +0200\, H.Merijn Brand wrote​:

As my example shows\, if the `extension' would be accepted\, in whatever form\, I also suggest to define that each -e part gets it's own braces/ scope

Yuck! Right now\, each -e is considered a separate line\, not scope​:

$ perl -wle'my $x=42;' -e'print $x;' -e'warn $x' 42 42 at -e line 3.

I don't want to see this changed.

Then let me reword. I'd like it to be possible.

lt09​:/home/merijn 104 > perl -l -e 'my $x = 42' -e 'print $x' syntax error at -e line 2\, near "print" Execution of -e aborted due to compilation errors. Exit 255 lt09​:/home/merijn 105 >

That's just because I left out the semicolon in the first -e Could we then at least agree on something that each -e is guaranteed to be closed? a lone semicolon is a no-op\, so there won't be any backward compatibility issues

It would make a lot of command line scripts a lot easier to write. Also possibe would be new switches (possibly -b and -E) for putting code at the beginning or end of the script text without using a BEGIN{} or END{} block.

/me viciously nods​: very useful!

Is BEGIN/END so hard to type?

No\, but it is a lot to type in short one-liners

# perl -nle'BEGIN{$s="Something"}chomp;$_ eq $s and next;%s{$s=$_}++}END {print"$_​:$s{$_}" for keys%s"

doesn't really read easy

-- H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/) using Perl 5.6.2\, 5.8.0\, 5.8.5\, & 5.9.2 on HP-UX 10.20\, 11.00 & 11.11\, AIX 4.3 & 5.2\, SuSE 9.2 & 9.3\, and Cygwin. http​://www.cmve.net/~merijn Smoking perl​: http​://www.test-smoke.org\, perl QA​: http​://qa.perl.org reports to​: smokers-reports@​perl.org\, perl-qa@​perl.org

[p5pRT]

From @tamias

On Fri\, Apr 29\, 2005 at 10​:44​:34AM +0200\, H.Merijn Brand wrote​:

Then let me reword. I'd like it to be possible.

lt09​:/home/merijn 104 > perl -l -e 'my $x = 42' -e 'print $x' syntax error at -e line 2\, near "print" Execution of -e aborted due to compilation errors. Exit 255 lt09​:/home/merijn 105 >

That's just because I left out the semicolon in the first -e Could we then at least agree on something that each -e is guaranteed to be closed? a lone semicolon is a no-op\, so there won't be any backward compatibility issues

There won't be any backwards compatibility issues with adding a semicolon at the end of every line of a script??

% perl -l -e 'print "Hello\, "' -e '\, "world!\n"' Hello\, world! % perl -l -e 'print "Hello\, ";' -e '\, "world!\n";' syntax error at -e line 2\, near "\," Execution of -e aborted due to compilation errors.

Ronald

[p5pRT]

From @demerphq

On 4/29/05\, Ronald J Kimball \rjk\-perl\-p5p@&#8203;tamias\.net wrote​:

On Fri\, Apr 29\, 2005 at 10​:44​:34AM +0200\, H.Merijn Brand wrote​:

Then let me reword. I'd like it to be possible.

lt09​:/home/merijn 104 > perl -l -e 'my $x = 42' -e 'print $x' syntax error at -e line 2\, near "print" Execution of -e aborted due to compilation errors. Exit 255 lt09​:/home/merijn 105 >

That's just because I left out the semicolon in the first -e Could we then at least agree on something that each -e is guaranteed to be closed? a lone semicolon is a no-op\, so there won't be any backward compatibility issues

There won't be any backwards compatibility issues with adding a semicolon at the end of every line of a script??

Not if the new behaviour only occurs in presence of the hypothetical -X modifier.

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @tamias

On Fri\, Apr 29\, 2005 at 03​:37​:06PM +0200\, demerphq wrote​:

On 4/29/05\, Ronald J Kimball \rjk\-perl\-p5p@&#8203;tamias\.net wrote​:

On Fri\, Apr 29\, 2005 at 10​:44​:34AM +0200\, H.Merijn Brand wrote​:

Then let me reword. I'd like it to be possible.

lt09​:/home/merijn 104 > perl -l -e 'my $x = 42' -e 'print $x' syntax error at -e line 2\, near "print" Execution of -e aborted due to compilation errors. Exit 255 lt09​:/home/merijn 105 >

That's just because I left out the semicolon in the first -e Could we then at least agree on something that each -e is guaranteed to be closed? a lone semicolon is a no-op\, so there won't be any backward compatibility issues

There won't be any backwards compatibility issues with adding a semicolon at the end of every line of a script??

Not if the new behaviour only occurs in presence of the hypothetical -X modifier.

The -X modifier would do more than just add a semicolon to the end of every line\, right? Anyone wanting to use the -X modifier for its other benefits would have to write their command lines differently than they would without the -X modifier.

Ronald

[p5pRT]

From @demerphq

On 4/29/05\, Ronald J Kimball \rjk\-perl\-p5p@&#8203;tamias\.net wrote​:

On Fri\, Apr 29\, 2005 at 03​:37​:06PM +0200\, demerphq wrote​:

On 4/29/05\, Ronald J Kimball \rjk\-perl\-p5p@&#8203;tamias\.net wrote​:

On Fri\, Apr 29\, 2005 at 10​:44​:34AM +0200\, H.Merijn Brand wrote​:

Then let me reword. I'd like it to be possible.

lt09​:/home/merijn 104 > perl -l -e 'my $x = 42' -e 'print $x' syntax error at -e line 2\, near "print" Execution of -e aborted due to compilation errors. Exit 255 lt09​:/home/merijn 105 >

That's just because I left out the semicolon in the first -e Could we then at least agree on something that each -e is guaranteed to be closed? a lone semicolon is a no-op\, so there won't be any backward compatibility issues

There won't be any backwards compatibility issues with adding a semicolon at the end of every line of a script??

Not if the new behaviour only occurs in presence of the hypothetical -X modifier.

The -X modifier would do more than just add a semicolon to the end of every line\, right? Anyone wanting to use the -X modifier for its other benefits would have to write their command lines differently than they would without the -X modifier.

I think the -X modifier would change other aspects of the behaviour of -e anyway. If something like the following becomes

-Xe "#init" -p "#preprocess" -e "#postprocess"

#init while (\<>) {   #preprocess } continue {   print ... } #postprocess

then obviously the rules for the endings of -e have to change anyway. So automatically adding a semicolon and newline seems to me to make sense. The whole idea for me is to better huffman encode command line usage so making the semicolon optional fits in nicely. And I dont think its that different in terms of expectation\, I dont think the style you showed is that common even if it is legal.

Cheers\, yves -- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @tamias

On Sat\, Apr 30\, 2005 at 12​:40​:18PM +0200\, demerphq wrote​:

I think the -X modifier would change other aspects of the behaviour of -e anyway. If something like the following becomes

-Xe "#init" -p "#preprocess" -e "#postprocess"

#init while (\<>) { #preprocess } continue { print ... } #postprocess

then obviously the rules for the endings of -e have to change anyway. So automatically adding a semicolon and newline seems to me to make sense. The whole idea for me is to better huffman encode command line usage so making the semicolon optional fits in nicely. And I dont think its that different in terms of expectation\, I dont think the style you showed is that common even if it is legal.

Sorry\, it's not obvious to me from this example why the rules for the endings have to change. Could you clarify?

Perhaps someone would want to do this​:

-Xe "#init" -Xe "#init" -p "#preprocess" -p "#preprocess" -e "#postprocess" -e "#postprocess"

It really only requires inserting a single semicolon\, before the start of the while loop.

Being able to break up a single statement across multiple -e's has the same advantages as being able to break up a single statement in a regular script; you can keep individual lines from getting too long.

Personally\, I'm not sure why someone would do this​:

-e 'my $x = 42' -e 'print $x'

instead of

-e 'my $x = 42; print $x'

:)

Ronald

[p5pRT]

From @demerphq

On 4/30/05\, Ronald J Kimball \rjk\-perl\-p5p@&#8203;tamias\.net wrote​:

On Sat\, Apr 30\, 2005 at 12​:40​:18PM +0200\, demerphq wrote​:

I think the -X modifier would change other aspects of the behaviour of -e anyway. If something like the following becomes

-Xe "#init" -p "#preprocess" -e "#postprocess"

#init while (\<>) { #preprocess } continue { print ... } #postprocess

then obviously the rules for the endings of -e have to change anyway. So automatically adding a semicolon and newline seems to me to make sense. The whole idea for me is to better huffman encode command line usage so making the semicolon optional fits in nicely. And I dont think its that different in terms of expectation\, I dont think the style you showed is that common even if it is legal.

Sorry\, it's not obvious to me from this example why the rules for the endings have to change. Could you clarify?

Perhaps someone would want to do this​:

-Xe "#init" -Xe "#init" -p "#preprocess" -p "#preprocess" -e "#postprocess" -e "#postprocess"

It really only requires inserting a single semicolon\, before the start of the while loop.

Ok\, im not sure about your example. I was thinking that the -X would change the behaviour of any following -e\, -n or -p so having two wouldnt matter.

Regarding the example code (not the multiple p's) for the example above I think youll agree that it needs newlines or the entire code ends up being a comment. (I suppose you may be lucky enough to use a shell that allows for embedding newlines\, I dont however.)

Being able to break up a single statement across multiple -e's has the same advantages as being able to break up a single statement in a regular script; you can keep individual lines from getting too long.

Sure\, and there doesnt seem to be too much reason not to insist that that breakup occurs at statement boundaries.

I guess ones view on this will come down to how often one uses multiple -e's for the purpose you describe. Since I never have my personal position is that changing the semantics as Merijn described with adding semicolon newline to each -e is beneficial.

Having said that Id hate to see this idea ignored just because of the controversy over this issue.

Personally\, I'm not sure why someone would do this​:

-e 'my $x = 42' -e 'print $x'

instead of

-e 'my $x = 42; print $x'

:)

Heh\, I suppose not. But i can see a lot of people forgetting the semicolon in

-e "INIT()" -p"CONVERT()" -e "SHOWCOUNT"

and i think making the above DWIM is better huffman encoded than breaking expectations from the previous -e behaviour\, expectations that I think are uncommon as I doubt that many people know off heart the exact rules for how multiples -e's are joined together. I bet most folks when they see multiple -e's on a command line recheck the docs to see just what is going on.

Anyway I suppose this is the kind of thing that Larry and the Pumpkings need to decide on. Personally I plan to look into putting together an implementation sometime if someone doesnt beat me to it and then let the powers that be make the call then.

Cheers\, Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @tamias

On Sat\, Apr 30\, 2005 at 08​:08​:27PM +0200\, demerphq wrote​:

Regarding the example code (not the multiple p's) for the example above I think youll agree that it needs newlines or the entire code ends up being a comment. (I suppose you may be lucky enough to use a shell that allows for embedding newlines\, I dont however.)

But that's not new behavior; each -e is already a separate line​:

% perl -e '#comment' -e 'print "hello\n"' hello %

My concern is about adding an implicit semicolon to the end of each -e line\, which would be new behavior.

Heh\, I suppose not. But i can see a lot of people forgetting the semicolon in

-e "INIT()" -p"CONVERT()" -e "SHOWCOUNT"

Supporting that doesn't require an implicit semicolon at the end of every -e line; it just requires a single semicolon before the start of the while loop.

and i think making the above DWIM is better huffman encoded than breaking expectations from the previous -e behaviour\, expectations that I think are uncommon as I doubt that many people know off heart the exact rules for how multiples -e's are joined together. I bet most folks when they see multiple -e's on a command line recheck the docs to see just what is going on.

Each -e is a line of Perl code. It's that simple.

Anyway I suppose this is the kind of thing that Larry and the Pumpkings need to decide on. Personally I plan to look into putting together an implementation sometime if someone doesnt beat me to it and then let the powers that be make the call then.

Sounds good to me.

Ronald

[p5pRT]

From @abigail

On Fri\, Apr 29\, 2005 at 12​:24​:49AM -0700\, Yitzchak Scott-Thoennes wrote​:

Is BEGIN/END so hard to type?

It's not. But if "not hard to type" was a reason to leave something out\, we wouldn't have -p\, -n\, -a\, -F\, -M\, -l\, -s or -I.

Nor wouldn't we have a million functions that have optional arguments.

In fact\, if that was a reason\, we wouldn't have Perl. We'd still use C.

Abigail

[p5pRT]

From david@landgren.net

Ronald J Kimball wrote​: [...]

Personally\, I'm not sure why someone would do this​:

-e 'my $x = 42' -e 'print $x'

instead of

-e 'my $x = 42; print $x'

:)

This sort of thing comes up quite often when you have a programs generating programs.

Things like environment variables that contain either -e fragments or the empty strings. Just throw them all on the command line and let getopts figure it out\, rather than constructing a bespoke -e.

David

[p5pRT]

From bmb@Mail.Libs.UGA.EDU

On Sun\, 1 May 2005\, Abigail wrote​:

On Fri\, Apr 29\, 2005 at 12​:24​:49AM -0700\, Yitzchak Scott-Thoennes wrote​:

Is BEGIN/END so hard to type?

It's not. But if "not hard to type" was a reason to leave something out\, we wouldn't have -p\, -n\, -a\, -F\, -M\, -l\, -s or -I.

Nor wouldn't we have a million functions that have optional arguments.

In fact\, if that was a reason\, we wouldn't have Perl. We'd still use C.

Abigail

Can I assume that the difference in the synopses in perl and perlrun is not intentional?

% perldoc perl ... SYNOPSIS   perl [ -sTuU ] [ -hv ] [ -V[​:configvar] ]   [ -cw ] [ -d[​:debugger] ] [ -D[number/list] ]   [ -pna ] [ -Fpattern ] [ -l[octal] ] [ -0[octal] ]   [ -Idir ] [ -m[-]module ] [ -M[-]'module...' ]   [ -P ] [ -S ] [ -x[dir] ]   [ -i[extension] ]   [ -e 'command' ] [ -- ] [ programfile ] [ argument ]... ... perl v5.8.6 Last change​: 2005-01-21 9

% perldoc perlrun ... SYNOPSIS   perl [ -sTtuUWX ] [ -hv ] [ -V[​:configvar] ]   [ -cw ] [ -d[t][​:debugger] ] [ -D[number/list] ]   [ -pna ] [ -Fpattern ] [ -l[octal] ] [ -0[octal/hexadecimal] ]   [ -Idir ] [ -m[-]module ] [ -M[-]'module...' ]   [ -P ] [ -S ] [ -x[dir] ]   [ -i[extension] ]   [ -e 'command' ] [ -- ] [ programfile ] [ argument ]...   [ -C [number/list] ] ]> ... perl v5.8.6 Last change​: 2005-01-21 25

I mention this because of the suggestion to use -X\, which is apparently already in use. The following apparently are not already in use​:

b f g j k n o q r y z A B E G H J K L N O Q R Y Z 1 2 3 4 5 6 7 8 9

Of these\, none stands out to me as an obvious choice for the kinds of uses that have been suggested. Would overloading -e with a single letter be too dangerous?

-eB '...' === -e 'BEGIN{...}' -eE '...' === -e 'END{...}' -eC '...' === -e 'CHECK{...}' (?) -eI '...' === -e 'INIT{...}' (?) -eb '...' === -e '...' but before the implicit while loop -ee '...' === -e '...' but after the implicit while loop

Regards\,

Brad

[p5pRT]

From @demerphq

On 5/3/05\, Brad Baxter \bmb@&#8203;mail\.libs\.uga\.edu wrote​: \

I mention this because of the suggestion to use -X\, which is apparently already in use.

Yes\, my use of X there was not really meant to be literal but rather as a placeholder for something nicer. But as you have pointed out (in a much nicer way than i was going to\, thanks :-) there isnt a great candidate. (its too bad about that pesky previous use of -X eh?)

The following apparently are not already in use​:

b f g j k n o q r y z A B E G H J K L N O Q R Y Z 1 2 3 4 5 6 7 8 9

Of these\, none stands out to me as an obvious choice for the kinds of uses that have been suggested. Would overloading -e with a single letter be too dangerous?

-eB '...' === -e 'BEGIN{...}' -eE '...' === -e 'END{...}'

Id like these to be -B and -E personally. Especially if we decide on a modifier flag.

-eC '...' === -e 'CHECK{...}' (?) -eI '...' === -e 'INIT{...}' (?)

Given that this is for one liners im not sure that i grok why -B and -E wouldnt be sufficient for this use.

-eb '...' === -e '...' but before the implicit while loop -ee '...' === -e '...' but after the implicit while loop

but if we are going to go with double char usage this isnt a bad idea IMO.

If we do go with the "modifier" flag then maybe it should be Y? modifYer ? Umm?

:-)

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From ajs@ajs.com

On Tue\, 2005-05-03 at 11​:43\, demerphq wrote​:

-eb '...' === -e '...' but before the implicit while loop -ee '...' === -e '...' but after the implicit while loop

but if we are going to go with double char usage this isnt a bad idea IMO.

My installed Perl is 5.8.3​:

  $ perl -d -eb  
  Loading DB routines from perl5db.pl version 1.23   Editor support available.  
  Enter h or `h h' for help\, or `man perldebug' for more help.  
  main​::(-e​:1)​: b   DB\<1>

Of course\, it's unlikely that anyone uses -eb (not a terribly useful program)\, but it's worth thinking about the fact that you're going to have to accept "-ecode" and recognize that "code" happens to be a flag.

I'd be much happier with long options\, but that's just me.

-- Aaron Sherman \ajs@&#8203;ajs\.com Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying\, 'get me down!'" -Shriekback

[p5pRT]

From @abigail

On Tue\, May 03\, 2005 at 11​:14​:51AM -0400\, Brad Baxter wrote​:

Of these\, none stands out to me as an obvious choice for the kinds of uses that have been suggested. Would overloading -e with a single letter be too dangerous?

Yes. perl -eB already has a meaning. It's equivalent to 'perl -e "B"'. Without further arguments\, not very useful. But in combination with arguments\, it very well may be.

Abigail

[p5pRT]

From bmb@Mail.Libs.UGA.EDU

On Tue\, 3 May 2005\, Abigail wrote​:

On Tue\, May 03\, 2005 at 11​:14​:51AM -0400\, Brad Baxter wrote​:

Of these\, none stands out to me as an obvious choice for the kinds of uses that have been suggested. Would overloading -e with a single letter be too dangerous?

Yes. perl -eB already has a meaning. It's equivalent to 'perl -e "B"'. Without further arguments\, not very useful. But in combination with arguments\, it very well may be.

Abigail

Yes\, that was the kind of danger I was alluding to. I thought perhaps that "perl -eB '...'" might be recognizable as different from "perl -eB" by virtue of the following '...' If not\, I might suggest -E (mnemonic​: a variant of -e).

-EB '...' and/or -B '...' === -e 'BEGIN{...}' -EE '...' and/or -E '...' === -e 'END{...}' -Eb '...' === -e '...' but before while loop -Ee '...' === -e '...' but after while loop

That would invest -E and perhaps -B. I wonder if the Perl6 folks are thinking about anything similar ...

Brad

[p5pRT]

From @demerphq

On 5/3/05\, Brad Baxter \bmb@&#8203;mail\.libs\.uga\.edu wrote​:

On Tue\, 3 May 2005\, Abigail wrote​:

On Tue\, May 03\, 2005 at 11​:14​:51AM -0400\, Brad Baxter wrote​:

Of these\, none stands out to me as an obvious choice for the kinds of uses that have been suggested. Would overloading -e with a single letter be too dangerous?

Yes. perl -eB already has a meaning. It's equivalent to 'perl -e "B"'. Without further arguments\, not very useful. But in combination with arguments\, it very well may be.

Abigail

Yes\, that was the kind of danger I was alluding to. I thought perhaps that "perl -eB '...'" might be recognizable as different from "perl -eB" by virtue of the following '...' If not\, I might suggest -E (mnemonic​: a variant of -e).

-EB '...' and/or -B '...' === -e 'BEGIN{...}' -EE '...' and/or -E '...' === -e 'END{...}' -Eb '...' === -e '...' but before while loop -Ee '...' === -e '...' but after while loop

That would invest -E and perhaps -B. I wonder if the Perl6 folks are thinking about anything similar ...

Hmm\, so with this scheme would the order be relevent? And how would it interact with the normal -p\,-n\,-e?

The reason i keep saying a "modifier" is that I like the way changing the behaviour of -e\,-p\,-n resolves the ambiguity of mixing the two forms. For instance if -E simply changes the behaviour of any following -e\,-p\,-n then

-Ee "1;" -n "2;" -e "3;" -p "4;" -e "5;"

would produce

1; while (\<>) {2;} 3; while (\<>) {4;} continue {print;} 5;

If the presence of -E comes after an existing -n or -p it would be an error. If we special case -EB and -EE we get the BEGIN{} and END{} too.

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From bmb@Mail.Libs.UGA.EDU

On Tue\, 3 May 2005\, demerphq wrote​:

On 5/3/05\, Brad Baxter \bmb@&#8203;mail\.libs\.uga\.edu wrote​:

-EB '...' and/or -B '...' === -e 'BEGIN{...}' -EE '...' and/or -E '...' === -e 'END{...}' -Eb '...' === -e '...' but before while loop -Ee '...' === -e '...' but after while loop

Hmm\, so with this scheme would the order be relevent? And how would it interact with the normal -p\,-n\,-e?

The reason i keep saying a "modifier" is that I like the way changing the behaviour of -e\,-p\,-n resolves the ambiguity of mixing the two forms. For instance if -E simply changes the behaviour of any following -e\,-p\,-n then

-Ee "1;" -n "2;" -e "3;" -p "4;" -e "5;"

would produce

1; while (\<>) {2;} 3; while (\<>) {4;} continue {print;} 5;

If the presence of -E comes after an existing -n or -p it would be an error. If we special case -EB and -EE we get the BEGIN{} and END{} too.

I wonder\, though\, about the case when you want to specify multiple -e code inside a loop. If you do the following intending "3;" to be inside the loop with "2;"​:

-Ee "1;" -n "2;" -n "3;" -p "4;" -e "5;"

how would you differentiate that from the case where you want to loop 3 times\, 2 -n's and a -p?

On the other hand\, say the modifier (-E) includes -Ep and -En. (I agree you'll have to rely on the order that -Ee appears and -Eb would not be needed or wanted). Might -Ep and -En "turn on" the looping "state" (and -Ee turn in off) such that plain -e lines would be unambiguously inside or outside the loop? E.g.\,

-Ee"1" -e"1.5" -En"2" -e"2.5" -Ee"3" -e"3.5" -Ep"4" -Ee"5"

(That first E would actually be unnecessary\, -e"1" would do the same because -En hasn't "turned looping on" yet.)

would produce

1 1.5 ;while (\<>) {   2   2.5 } 3 3.5 ;(magic rewind happens here?) while (\<>) {   4 } continue {   print } 5

__ Brad

[p5pRT]

From @rgarcia

On 5/3/05\, Brad Baxter \bmb@&#8203;mail\.libs\.uga\.edu wrote​:

Can I assume that the difference in the synopses in perl and perlrun is not intentional?

You can\, and I just fixed that in bleadperl.

[p5pRT]

From @tamias

On Tue\, May 03\, 2005 at 11​:11​:46PM +0200\, demerphq wrote​:

The reason i keep saying a "modifier" is that I like the way changing the behaviour of -e\,-p\,-n resolves the ambiguity of mixing the two forms. For instance if -E simply changes the behaviour of any following -e\,-p\,-n then

-Ee "1;" -n "2;" -e "3;" -p "4;" -e "5;"

would produce

1; while (\<>) {2;} 3; while (\<>) {4;} continue {print;} 5;

Would it be up to the programmer to remember to include code in 2 to break out of the loop early\, so that the second loop actually has some input left to iterate over?

Is -E -n"1;" -n"2;" equivalent to

while (\<>) {1;} while (\<>) {2;}

or

while (\<>) {1; 2;}

?

If the former\, how do you include multiple lines inside the loop? If the latter\, how do you put one loop right after another?

If the programmer wants two separate loops over \<> in your program\, he should probably just write the code himself. Is it really worth the added complexity to support multiple -p and/or -n in the same command line? I'm curious whether people think this would actually see a lot of use.

Ronald

[p5pRT]

From bmb@Mail.Libs.UGA.EDU

On Wed\, 4 May 2005\, Ronald J Kimball wrote​: [...]

If the programmer wants two separate loops over \<> in your program\, he should probably just write the code himself. Is it really worth the added complexity to support multiple -p and/or -n in the same command line? I'm curious whether people think this would actually see a lot of use.

As for me\, I'm not wedded to the idea. I just started thinking out loud when it sounded like folks were edging toward working on a patch.

Regards\,

Brad

[p5pRT]

From @ysth

On Wed\, May 04\, 2005 at 11​:26​:24AM -0400\, Brad Baxter wrote​:

On Wed\, 4 May 2005\, Ronald J Kimball wrote​: [...]

If the programmer wants two separate loops over \<> in your program\, he should probably just write the code himself. Is it really worth the added complexity to support multiple -p and/or -n in the same command line? I'm curious whether people think this would actually see a lot of use.

As for me\, I'm not wedded to the idea. I just started thinking out loud when it sounded like folks were edging toward working on a patch.

'twould be good to consult some golfers on what they would find helpful. (No\, I'm not joking.)