Opened 14 years ago

Closed 13 years ago

#1198 closed defect (duplicate)

Error while parsing file paths in WinGRASS with Scripts

Reported by: luislisboa1975 Owned by: grass-dev@…
Priority: major Milestone: 6.4.1
Component: wxGUI Version: svn-releasebranch64
Keywords: wingrass Cc:
CPU: Unspecified Platform: MSWindows XP

Description

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

Change History (8)

comment:1 by hellik, 14 years ago

Keywords: wingrass added

comment:2 by hamish, 13 years ago

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

comment:3 by benducke, 13 years ago

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.

comment:4 by hamish, 13 years ago

Summary: Error while parsing file paths in WiNGRASS with Python ScriptError while parsing file paths in WinGRASS with Scripts

see also #1280

in reply to:  3 ; comment:5 by glynn, 13 years ago

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.

in reply to:  5 comment:6 by mmetz, 13 years ago

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

comment:7 by hamish, 13 years ago

continued in #1447 ...

closing this one.

Hamish

comment:8 by hamish, 13 years ago

Resolution: duplicate
Status: newclosed
Note: See TracTickets for help on using tickets.