OK, looks like it god broken again with d21c653, which fixes handling of \s and " in file names.

Interestingly enough, apparently the escaping required for -file-exec-and-symbols, the command used to load the file, is not really the same than the one needed for i.e. -break-insert. So with the current status, it's no possible to load an executable that contains non-ASCII in its path, but it's possible to debug an executable whose source files contain non-ASCII in their paths.

-file-exec-and-symbols seems to only accept escapes \\ and ", and seem happy about everything else -- but newlines \n, which I couldn't find how to escape.

-break-insert accepts more complex escapes, like \ooo octal sequences the above-mentioned patch introduced.

Seems like I only tested with non-ASCII in the source files, not the executable. I'll fix that, yet I'm not sure if I should lower the escaping everywhere or only when it's actually required -- that might affect setups where the file system locale is not the system one, or more generally non-UTF-8 systems (which I don't have at hand, so can't test).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub