Bug report #16731
Processing/GRASS tools fail if input datasource has spaces in the name
| 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 over 6 years ago
This seems to affect other tools as well as GRASS. e.g. try GDAL rasterize.
#2
Updated by Alister Hood over 6 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 about 6 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 almost 6 years ago
- Resolution set to fixed/implemented
- Status changed from Open to Closed
Fixed in 3.2 (or at least, no longer reproducible)