Re: [PATCH] pgbench tap tests fail if the path contains a perl special character

On 1/21/19 4:50 AM, Fabien COELHO wrote:
>
> Hello Tom,
>
>> Hm, so bowerbird (a Windows machine) has been failing the pgbench tests
>> since this went in, cf
>>
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2019-01-20%2004%3A57%3A01
>>
>>
>> I'm just guessing, but I suspect that bowerbird is using a path spec
>> that
>> includes a backslash directory separator and that's somehow bollixing
>> things.
>
> This point is unclear from the log, where plain slashes are used in
> the log prefix path, and furthermore no strange characters appear in
> the log prefix path:
>
>  # Running: pgbench -n -S -t 50 -c 2 --log
> --log-prefix=G:/prog/bf/root/HEAD/pgsql.build/src/bin/pgbench/tmp_check/t_001_pgbench_with_server_main_data/001_pgbench_log_2
> --sampling-rate=0.5
>  ok 345 - pgbench logs status (got 0 vs expected 0)
>  ok 346 - pgbench logs stdout /(?^:select only)/
>  ok 347 - pgbench logs stdout /(?^:processed: 100/100)/
>  ok 348 - pgbench logs stderr /(?^:^$)/
>  not ok 349 - number of log files
>
>> If so, we might be able to fix it by converting backslashes to
>> forward slashes before applying quotemeta().
>>
>> It's also possible that on Windows, "glob" handles backslashes
>> differently than it does elsewhere, which would be harder to fix
>> --- that would bring back my original fear that the appropriate
>> quoting rules are different for "glob" than for regexes.
>
> I'm afraid it could indeed be due to platform-specific behavior, so
> testing on the target machine to understand the actual behavior would
> help.
>
> I just tested the current version on my laptop within a directory
> containing spaces and other misc chars: Pgbench TAP tests are
> currently broken in this context on master, and this may be used to a
> collection of issues, not just one, eg pgbench function splits
> parameters on spaces which breaks if there are spaces in bdir.
>
> I'm going to investigate, possibly over next week-end, so please be
> patient.
>
> About windows-specific issues, from File::Glob man page:
>
> """ On DOSISH systems, backslash is a valid directory separator
> character. In this case, use of backslash as a quoting character (via
> GLOB_QUOTE) interferes with the use of backslash as a directory
> separator. ... """
>
> It seems to suggest that quotemeta backslash-on-nearly-everything
> approach is not appropriate.
>

File globbing is not the same thing as regex matching. For example, '.'
is a literal character in a glob pattern but a metacharacter in a regex,
while ' ' is a literal character in a regex but a globbing metacharacter
(but see below), and '*' is a metacharacter in both but has different
meanings. quotemeta is intended for regexes but being used here on an
expression used for globbing.

Perhaps it would be OK we changed back the glob line to use $prefix
instead of $qprefix, but kept the use of $qprefix in the later regex.

To deal with the issue of spaces in file names (not an issue eher ob
bowerbird), we should consider adding this:

    use File::Glob ':bsd_glob';

This removes the globbing metcharacter nature of the space character,
although it might have other effects that cause pain. See `perldoc
File::Glob`

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services