Bug report #16731

Processing/GRASS tools fail if input datasource has spaces in the name

Added by Giovanni Manghi about 3 years ago. Updated over 2 years ago.

Status:Closed
Priority:Normal
Assignee:Victor Olaya
Category:Processing/GRASS
Affected QGIS version:2.18.9 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:24630

Description

For example try v.buffer

History

#1 Updated by Alister Hood about 3 years ago

This seems to affect other tools as well as GRASS. e.g. try GDAL rasterize.

#2 Updated by Alister Hood over 2 years ago

Alister Hood wrote:

This seems to affect other tools as well as GRASS. e.g. try GDAL rasterize.

Note that not all GRASS tools are affected.
e.g. v.to.rast.attribute works. v.to.3d does not work in QGIS 2.x, but works in master - the only problem is that it allows you to select an output file type (e.g. dxf), even though it always writes a shapefile. This is probably a widespread problem that should be reported separately...

#3 Updated by Alister Hood over 2 years ago

Alister Hood wrote:

This seems to affect other tools as well as GRASS. e.g. try GDAL rasterize.

Another example (but in master - I haven't check 2.18.x) is "clip vector by mask layer". I imagine there are plenty of others, as processing users probably either give up or realise very early that it is best to keep paths free of spaces!

If there are tests run on processing modules it could be worth changing all tests to use both input and output files with spaces in the name... or would it be somehow possible for the input and output file paths to be abstracted out so the algorithms themselves don't need to worry about them?

#4 Updated by Nyall Dawson over 2 years ago

  • Resolution set to fixed/implemented
  • Status changed from Open to Closed

Fixed in 3.2 (or at least, no longer reproducible)

Also available in: Atom PDF