r.kappa: output file saving error on Windows

[neteler]

winGRASS users report that they are unable to save the error matrix and kappa to a file.

Feb 28, 2013 Rebecca wrote:
I have tried both with the GUI and in python script.

I am running it using NX client and so my file paths have '\' symbols to represent directories. When I use the 'browse' icon to locate the correct directory/file, grass automatically uses '\'. However I am receiving the error msg:

Illegal filename. Character </> not allowed.

For a similar report, see also:

​http://fromgistors.blogspot.it/2013/07/classification-error-QGIS.html (at page bottom)

Random ideas:

There must be something lacking in the ask() function: ​http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/gis/ask.c#L345

Perhaps a Windows specific directory separator is needed, similar to

​http://trac.osgeo.org/grass/changeset/55135/grass/branches/releasebranch_6_4/lib/g3d

?

[glynn]

Replying to neteler:

Illegal filename. Character </> not allowed.

This was fixed in 7.0 with r32820. I suggest back-porting.

[mmetz]

Replying to glynn:

Replying to neteler:

Illegal filename. Character </> not allowed.

This was fixed in 7.0 with r32820. I suggest back-porting.

Done in r57045,6.

[neteler]

Replying to mmetz:

Replying to glynn:

Replying to neteler:

Illegal filename. Character </> not allowed.

This was fixed in 7.0 with r32820. I suggest back-porting.

Done in r57045,6.

I have made a patch of r32820, diff against relbranch64 attached (recent r.kappa fixes already excluded from r32820 backport).

Please verify the attached diff. It compiles on my (Linux) machine.

[neteler]

Replying to neteler:

I have made a patch of r32820, diff against relbranch64 attached (recent r.kappa fixes already excluded from r32820 backport).

It additionally requires:

svn rm raster/r.surf.fractal/interface.c

[mmetz]

Replying to neteler:

Replying to mmetz:

Replying to glynn:

Replying to neteler:

Illegal filename. Character </> not allowed.

This was fixed in 7.0 with r32820. I suggest back-porting.

Done in r57045,6.

I have made a patch of r32820, diff against relbranch64 attached (recent r.kappa fixes already excluded from r32820 backport).

G_legal_filename() is meant for GRASS data file names (anything in $GISDASE/$LOCATION_NAME/$MAPSET/<element>/, therefore your patch does not make sense.

[neteler]

Replying to mmetz:

G_legal_filename() is meant for GRASS data file names (anything in $GISDASE/$LOCATION_NAME/$MAPSET/<element>/, therefore your patch does not make sense.

So you mean that the original r32820 doesn't make sense? I just prepared a backport patch...

[mmetz]

Replying to neteler:

Replying to mmetz:

G_legal_filename() is meant for GRASS data file names (anything in $GISDASE/$LOCATION_NAME/$MAPSET/<element>/, therefore your patch does not make sense.

So you mean that the original r32820 doesn't make sense? I just prepared a backport patch...

The original r32820 makes sense because in this case the output is a file anywhere on the file system.

G_legal_filename() is meant for GRASS data file names (anything in GISDASE/$LOCATION_NAME/$MAPSET/<element>/, not for output files located in a user-defined folder.

[neteler]

OK no problem, proposed backport of r32820 deleted.

The original ticket is solved anyway, closing.

[glynn]

Replying to mmetz:

G_legal_filename() is meant for GRASS data file names (anything in GISDASE/$LOCATION_NAME/$MAPSET/<element>/, not for output files located in a user-defined folder.

It's meant for anything which will be a single component of a pathname: either an unqualified map name, or a mapset name, or a location name.

Any characters which have "meaning" to GRASS or to the OS are not "legal" in this sense, so it rejects names which contain e.g. "@" (mapset separator) or "/" (directory separator).

[neteler]

G_legal_filename() cleanup patch (backport from G7) for GRASS 6 moved to ticket #2031