[GRASS-dev] [bug #5220] (grass) wingrass: v.in.ogr (tcltk
version) creates wrong directory path
michael.barton at asu.edu
Thu Oct 19 15:30:35 EDT 2006
This is a good way to parse these. However, if we will have to reassemble
the pieces in a 'nonstandard', it may still require a string function
somewhere (e.g., file join will create a 'proper' path for the platform in
question). What I'm not sure of and hope someone can check is whether you
need to use this format for both reading and writing, in all modules, and
how you specify a server (does \\server\share\path\to\file.txt work?) in
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Thu, 19 Oct 2006 19:21:54 +0100
> To: Request Tracker <grass-bugs at intevation.de>
> Cc: <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] [bug #5220] (grass) wingrass: v.in.ogr (tcltk
> version) creates wrong directory path
> Request Tracker wrote:
>> this bug's URL: http://intevation.de/rt/webrt?serial_num=5220
>> Subject: wingrass: v.in.ogr (tcltk version) creates wrong directory path
>> Platform: WindowsNT/2000/XP
>> grass obtained from: Other (CDROM etc)
>> grass binary for platform: Downloaded precompiled Binaries
>> GRASS Version: huidae's wingrass version sept. 17c
>> Directory paths created by the tcktk dialogs (navigate to find file
>> buttons) do not work in wingrass. They are created in the form
>> c:/moritz, but in order for them to be recognized, they should be in
>> the form /c/moritz.
> That depends upon the Tcl/Tk implementation. For a native Windows
> Tcl/Tk implementation, you would have to use c:\moritz. The /c/moritz
> syntax is part of MinGW/Cygwin; it isn't valid within Windows itself.
> Michael Barton wrote:
>> The tcltk file browser is a prebuilt widget. The Windows version apparently
>> returns files in proper Windows format. If all file parsing for windows
>> platforms should switch from c:/ to /c/, this could be parsed in an if
>> clause to test for windows platform. Is this kind of reparsing needed
>> universally for windows or just in some places? It would take some effort to
>> track down and change in the appropriate places (most importantly in
>> gui.tcl), but it is doable.
> Probably the safest solution is to use Tcl's "file" command to manage
> filenames, rather than trying to do it manually using string
> operations. The following sub-commands appear relevant.
> file dirname name
> file extension name
> file join name ?name ...?
> file nativename name
> file normalize name
> file pathtype name
> file rootname name
> file separator ?name?
> file split name
> file tail name
> file volumes
> 1. While most Windows API calls accept both '\' and '/', most
> console-mode commands only accept '\', as '/' is used for switches
> (which needn't be preceded by a space; "dir foo/w" is equivalent to
> "dir foo /w" or "dir /w foo"). You probably need to use
> "file nativename" for any filenames passed to Tcl's "exec" command.
> 2. Don't forget about UNC paths: \\server\share\path\to\file.txt
> 3. There is some additional information in the filename(n) manpage.
> Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev