[sr #110912] Backslash followed by quote treated as escape sequence on Windows.

[Marek Knápek]

URL:
  <https://savannah.gnu.org/support/?110912>

                 Summary: Backslash followed by quote treated as escape
sequence on Windows.
                   Group: GNU M4
               Submitter: marekknapek
               Submitted: Sat 29 Jul 2023 11:36:06 PM UTC
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: Microsoft Windows


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Sat 29 Jul 2023 11:36:06 PM UTC By: Marek Knápek <marekknapek>
Backslash followed by quote treated as escape sequence on Windows. Hi all,
recently I started using the m4 template processor on MS Windows OS. I found
one problem with invoking it when using the -I option to specify the include
path. Everything works fine, except when the path ends with directory
separator (backslash) and at the same time it is enclosed inside double
quotes. Please see examples below. Every example works fine, except example
number 5. I suspect the problem is that there is backslash followed by double
quote. There are multiple things happening at the same time:

 - On Windows, the directory separator is backslash, but forward slash works
also in most cases as a compatibility shim.
 - Directory names could contain space, and space is also parameter separator.
Thus it is good practice to enclose user-provided paths in double quotes, so
it could be treated as single parameter.
 - Some people and some software have habit of appending directory separator
(backslash) to the end of directory path name, so it is clear to the user that
the string specifies directory path name as opposed to file path name.

I'm using the Visual Studio / MSBuild software as my build environment, this
program uses an combination of points above, resulting in invoking the m4
template processor the way as in example number 5. I could work-around the
problem by appending dot at the end of the include path. But this is no
generic solution and similar problem might arise in different places where the
user could not work-around this like me.

On Windows, the invoked program (m4 in this case) receives the complete
command line as single long string and it is its responsibility to parse it
into argc+argv before passing it to the C main function. This is different
from Linux where it is shell's responsibility to create argc+argv, pass it
into kernel and kernel passing it to the invoked program. On Windows most
programs are using the CRT to do the parsing from command line to argc+argv.
CRT is shortcut for C run-time, basically equivalent to libc/glibc. CRT could
be linked to programs statically or dynamically, dynamic CRT are the
msvcrt.dll, msvcp140.dll and similar DLLs. I suspect the problem might be
there, but I have no idea.

It is unfortunate that m4 sometimes works fine, sometimes gets stuck. It is
based on format of the command line. Please fix this problem. Best regards,
Marek.

[1] m4 -I c:\dev\tmp\templates some_template.m4 > some_output.txt
[2] m4 -I c:\dev\tmp\templates\ some_template.m4 > some_output.txt
[3] m4 -I c:/dev/tmp/templates/ some_template.m4 > some_output.txt
[4] m4 -I "c:\dev\tmp\templates" some_template.m4 > some_output.txt
[5] m4 -I "c:\dev\tmp\templates\" some_template.m4 > some_output.txt
[6] m4 -I "c:/dev/tmp/templates/" some_template.m4 > some_output.txt








    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/support/?110912>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/