Error while parsing file paths in WinGRASS with Scripts

[luislisboa1975]

In a Python Script, in WinGRASS6.4.1(svn) all "\" in file paths are eliminated. It only runs if users use "/"

This topic is related with: ​http://lists.osgeo.org/pipermail/grass-user/2010-October/058320.html ​http://lists.osgeo.org/pipermail/grass-user/2010-October/058322.html ​http://lists.osgeo.org/pipermail/grass-dev/2010-October/052396.html

[hamish]

is this from within a specific grass module, from the wxGUI command entry box, or from a self-written script?

the \ is used to quote the character which follows it verbatim.

so C:\Program Files\GRASS\scripts reduces to C:Program FilesGRASSscripts.

one solution as pointed out is to use / instead. Another way is to use two of them, so that the second one gets quoted verbatim: \\.

ISTR that some OS-specific magic was added to the wxGUI command parser, but I suspect the solution to this will ultimately be education: gratuitous tooltips and inset Caution-boxes in the wxGUI help pages.

Hamish

[benducke]

Actually, the problem goes deeper than the wxGUI. I have experienced it (Windows only) with shell scripts. Basically, g.parser seems to remove all occurrences of "\" from a file type input or output option. I think this should be fixed in g.parser, not by forcing Windows users to adopt a notation that is strange on their system. In addition, the option value may come from a Windows file browser, which will certainly produce the "\" Windows notation.

[hamish]

see also #1280

[glynn]

Replying to benducke:

Actually, the problem goes deeper than the wxGUI. I have experienced it (Windows only) with shell scripts. Basically, g.parser seems to remove all occurrences of "\" from a file type input or output option. I think this should be fixed in g.parser, not by forcing Windows users to adopt a notation that is strange on their system. In addition, the option value may come from a Windows file browser, which will certainly produce the "\" Windows notation.

It isn't g.parser doing this. It's either wxGUI (e.g. shlex.split) or the shell.

In any case, this ticket contains insufficient information to attempt reproduction. At a minimum, we require the exact command entered, the means by which it was entered (cmd.exe, bash, wxGUI, etc), the GRASS version, and the result.

[mmetz]

Replying to glynn:

Replying to benducke:

Actually, the problem goes deeper than the wxGUI. I have experienced it (Windows only) with shell scripts. Basically, g.parser seems to remove all occurrences of "\" from a file type input or output option. I think this should be fixed in g.parser, not by forcing Windows users to adopt a notation that is strange on their system. In addition, the option value may come from a Windows file browser, which will certainly produce the "\" Windows notation.

It isn't g.parser doing this. It's either wxGUI (e.g. shlex.split) or the shell.

In any case, this ticket contains insufficient information to attempt reproduction. At a minimum, we require the exact command entered, the means by which it was entered (cmd.exe, bash, wxGUI, etc), the GRASS version, and the result.

I think #1447 is related, and complete with an example and a detailed description.

Markus M

[hamish]

continued in #1447 ...

closing this one.

Hamish