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/