Front page | perl.perl5.porters |
Postings from October 2015
On 10/05/2015 01:59 PM, Ed Avis wrote:
> karl williamson <perlbug-followup <at> perl.org> writes:
>
>> my @b = glob(qq{$path/mp_[0123456789]*.dat
>> $path/md_[0123456789]*.dat});
>>
>>from https://rt.perl.org/Ticket/Display.html?id=114984 (and now in
>> ext/File-Glob/t/rt114984.t) now work fine on Linux unless it is compiled
>> with -DPERL_EXTERNAL_GLOB. In that case, a shell is run instead of F:G,
>> and the shell thinks the 2nd line is a shell command instead of part of
>> what to glob.
>
> That sounds like a bug in the PERL_EXTERNAL_GLOB case. Having your glob
> kick off a random shell command cannot be the intended behaviour. I suggest
> that PERL_EXTERNAL_GLOB should convert \n to space or otherwise sanitize
> the glob pattern slightly before invoking the shell. (It may never be
> possible to completely make the shell invocation safe while keeping
> compatibility with the current behaviour, but certainly this case can be
> fixed.)
>
>> I am not conversant in all the nuances of what bsd vs csh vs other
>> shells accept, but I believe this means that F:G is not an accurate
>> reproducer of what most shells would do with this, and I think it is
>> meant to be.
>
> Well... not in that way IMHO. It should provide the same kind of glob
> expansion as shells do. It doesn't and shouldn't try to reimplement all
> the interesting quoting bugs and code injection bugs that running an
> external shell is prone to. (To do that it would indeed need to fork a
> shell and see what happens, and then there would be no point having F::G.)
>
I have pushed a fix to the .t file that was failing; I simply joined the
two lines to make one.
It turns out that porting/maintainers.t also fails with
PERL_EXTERNAL_GLOB on Linux. I haven't looked at this.
It is my supposition that the core converting to use File::Glob was for
performance reasons. (Perhaps it was to also get more uniform handling
across platforms.) Since it's undocumented, perhaps someone could
enlighten me. One solution I thought of (that Zefram) doesn't like is
for F:G to fork a shell if and only if it finds a shell metacharacter.
That way the performance wouldn't suffer except in edge cases.
Thread Previous
|
Thread Next