On Wed, Jul 31, 2013 at 06:32:18PM -0400, Andrew Cady wrote:
> By that, I assume you mean to execute the option in the shell. So the
> existing usage:
>
> --rename-output=s/x/y/
>
> would (almost) become:
>
> --rename-output='perl -lpe "BEGIN{\$|++}" -e s/x/y/'
It COULD, sure, but why on earth would someone choose to use that
instead of 'sed s/x/y/'?
...and in more complex situations that actually DO demand perl (or
python or whatnot), it'd likely best be expressed in a source file,
rather than directly on the commandline.
> Thus I think Tim's suggestion is the best one so far: there can be a
> list of supported transformers, one of which can be perl. One of them
> could be shell, which could allow arbitrary other programs.
>
> Then the current perl filter would be:
>
> --rename-output=perl:s/x/y/
>
> But this would also work:
>
> --rename-output=sed:s/x/y/
>
> And this:
>
> --rename-output=sh:'sed s/x/y/'
<snip>
> On the other hand, maybe separate options should be used, instead of
> parsing out the colon:
>
> --name-filter=sed --rename='sed code here'
> --name-filter=perl --rename='perl code here'
> --name-filter=shell --rename='shell code here'
> --name-filter=pcre --rename='regex here'
All of the above seems like over-engineering to me, especially just
to avoid the occasional backslash... don't forget, the more complexity
you introduce, the more bugs as well (and wget already rather suffers
from such a scenario). Sh is already well-tested...
-mjc
