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

stevieb has asked for the wisdom of the Perl Monks concerning the following question:

Hey there my fellow esteemed Monks!

I've been having a long-running problem that I'm finally fed up enough with to ask for help.

In my test suite for berrybrew, I perform a path substitution in a configuration file before the tests load. The specific command which is run out of a batch script looks like this:

call perl -i.bak -ne "s/berrybrew(?!\\+test)/berrybrew\\test/; print" +test/data/config.json

Essentially, that's supposed to change the path C:\berrybrew to C:\berrybrew\test.

On some of my Windows 10 systems, it works just fine, and everything goes on its merry way. On other Win10 systems, the change results in a tab character being inserted, so the path looks like this: C:\berrybrew[TAB]est. If I insert four backslashes in the replacement (ie. berrybrew\\\\test, it works. However, after a git push then a git pull on the other systems that work with just the two backslashes, it breaks.

What can I do to provide myself some consistency across systems? Is there some unicode trick or something I can use? I've tried replacing the forward slashes in the substitution to single-quotes (eg: s///; to s''';) to no avail.

I'd really like to get this resolved so that the substitution works reliably across all systems.

Cheers,

-stevieb

Replies are listed 'Best First'.
Re: Windows and backslashes and replacements oh my!
by The Perlman (Scribe) on Jun 18, 2021 at 15:07 UTC
    My guess is something in your call is doing some escape code interpretation which translates \t to tab.

    Which is weird for Windows. ..

    One workaround is to replace every \\ with ${bs} in your Perl code and to initialize it with $bs= chr (92), like this a literal backslash wouldn't show up.


    Update: or something is collapsing \\t to \t such that Perl sees a tab.

    Anyway the problem is not in Perl but the surrounding shell .

    - Ron

      Changing the line to the following has resolved the issue:

      call perl -i.bak -ne "my $bs=chr(92); s/berrybrew(?!\\+test)/berrybrew +${bs}${bs}test/; print" test/data/config.json

      Thanks!

        ${bs}${bs} means using two consecutive backslashes, which is still weird.

        Looks like somewhere a Unix tool like bash or another Perl is processing the file.

        (Update: Obviously Perl needs to escape the backslash inside a regex)

        FWIW: using $b2=chr(92)x2 might save you some typing

        - Ron

      Which is weird for Windows. ..

      it's not even a little bit weird. Variable expansion is basic job of shells.

      turn it off in your batch files

      SETLOCAL DISABLEDELAYEDEXPANSION

      help setlocal

        > it's not even a little bit weird. Variable expansion is basic job of shells.

        The discussion was about "escape sequences" with \ not "variable expansion".

        The escape meta in bat is ^ not \

        And \ is - unfortunately - used as path separator in win, which rules out any use as escape character.°

        Anything else would be indeed "weird", because it would make using paths impossible!

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

        °) see Escape_character#Windows_Command_Prompt

Re: Windows and backslashes and replacements oh my!
by LanX (Saint) on Jun 18, 2021 at 18:36 UTC
    These different win10 boxes run the same perl, same environment?

    Are you preloading something like Win32::Autoglob ?

    Is PERL5OPT empty?

    Did you try to test if Perl really gets the same code to see on different boxes?

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

Re: Windows and backslashes and replacements oh my! ( use perl not batch files)
by Anonymous Monk on Jun 18, 2021 at 19:30 UTC
    use perl not batch files; that is the lesson of batch files.
    perl berryshells11.pl ...

      Almost the entire unit test suite infrastructure for berrybrew was written by a friendly volunteer contributor, and I haven't the time to rewrite it, nor do I have any interest in doing so as it works very well.

      Thanks for the seemingly obvious suggestion though...