Add $_ and $. to list of variables you can use with --output

[hoelzro]

We should probably note that $_ is unchomped, or change the behavior so that $_ is passed to --output as a chomped string.

[petdance]

Ultimately, I think we should whitelist the $ vars that we allow to be used in --output. I see no reason to allow $] or similar in output.

[hoelzro]

I'm not opposed to that, but how do we go about doing that?

[petdance]

I think that we want to not do eval on --output, and instead do the substitutions ourselves.

[hoelzro]

That really limits what you can do with --output, though; for issue beyondgrep/ack2#345 I devised a hack that did something like --output="@{chomp; [length() > 250 ? 'too long' : $_]", and I think being able to run some code in there is really handy.

[petdance]

Shoot, I'd forgotten about those. Mark Fowler has a bunch of --output magic here, too: http://www.perladvent.org/2014/2014-12-21.html

ack --output='$&: @{[ eval "use LWP::Simple; 1" && length LWP::Simple::get($&) ]} bytes' \
    'https?://\S+' list.txt
http://google.com/: 19529 bytes
http://metacpan.org/: 7560 bytes
http://www.perladvent.org/: 5562 bytes

[petdance]

But is that capability overdoing ack's capabilities? That could just have easily been done like so:

ack 'https?://\S+' --output='$&' | perl -MLWP::Simple -e'......'

[hoelzro]

That's a good point; maybe we shouldn't make ack super powerful and rely on other shell scripts to deliver that power. My biggest concern is backwards compatability.

[petdance]

I'm OK with breaking backward compatability in the name of locking down the overly-wide-open door of eval.

[petdance]

This has already been done.