http://www.perlmonks.org?node_id=1213322


in reply to pp concatenate path

This looks remarkably similar to a problem I fixed in legacy code at work in the last week or two.

The issue occurs somewhere in the code behind DBI->connect($dsn, ... (which I didn't delve into to any great depth). The problem relates to the backslashes in the MSWin path which, somewhere in the DBI code, get interpreted as escapes.

In your first script, you use a literal for the path; in your second script, you don't. Consider:

$ cat > fred $x = 'one_dir\two_dir'; $y = "one_dir\two_dir"; $ perl -MO=Deparse fred $x = 'one_dir\\two_dir'; $y = "one_dir\two_dir"; fred syntax OK

$x has the "\t" part escaped (i.e. "...\\t..."); but $y does not and is actually "one_dir<TAB>wo_dir".

The fix I implemented used quotemeta. I notice throughout this thread that you tried different versions of the DSN string; I suspect something like this might suffice for your needs:

my $dsn = "dbi:SQLite:\Q$path";

— Ken

Replies are listed 'Best First'.
Re^2: pp concatenate path
by Anonymous Monk on Apr 27, 2018 at 02:58 UTC

    The fix I implemented used quotemeta. I suspect something like this might suffice for your needs: my $dsn = "dbi:SQLite:\Q$path";

    Did you try it? Because it makes no difference, it simply can't

    The problem relates to the backslashes in the MSWin path which, somewhere in the DBI code, get interpreted as escapes.

    No. DBI project doesn't have that problem. It would be extremely serious case of stupid.

    DBI::Shell on the other hand does use eval stupidly, but it hasn't been touched in 10 years, has https://rt.cpan.org/Public/Dist/Display.html?Name=DBI-Shell}19 open tickets... and is not part of DBI project.

    I didn't delve into to any great depth

    Does that make you a troll?