Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
proj_create: +geogrids breaks Windows pathnames with embedded spaces #1152
This worked in version 4, but not version 5. I stepped through the source code even before submitting the original bug. The function pj_trim_argc() in line 266 of pj_internal.c blindly breaks the string by replacing all spaces with null characters. Your suggestion of surrounding the argument with quotes does not work. I think it is a bug.…
On Mon, Oct 15, 2018 at 1:26 AM Kristian Evers ***@***.***> wrote: Closed #1152 <#1152>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1152 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AqD1-Ew5xrXoOtwsQzLjNsLMM4fRXEM5ks5ulEadgaJpZM4XaR1n> .
Indeed it is. Thanks for getting back on this, it was definitely closed prematurely.
Originally, this really isn't a bug, but a deliberate decision: Since PROJ by convention uses the apostrophe to indicate minutes-of-arc, and the quotation mark to indicate seconds-of-arc, including quoted whitespace was (mostly) impossible anyway: It would interfere with the
Allowing quoted whitespace would require us to disallow this syntax - perhaps switching to the (IMHO more readable)
Alternatively, we could adopt repeated quotes as a way to indicate quoted whitespace.
Both alternatives will, however, be quite involved: The former breaking backward compatibility, the latter being a minor nightmare of housekeeping and probably introducing hard-to-debug de facto syntax differences between Unix/Linux and Windows, due to differing conventions for the shell’s handling of quotes.
Under all circumstances, we will have to discuss syntax and breaking backwards compatibility to repair this, since formally, the bug is not the one reported, but a matter of incompatible legacy syntax.
Whatever we do, retrofitting support for quoted whitespace is a bit involved, including changes in all of:
Since I wrote this code, and have done a fair bit of working-around the original design of
It will, however, take some discussion and deliberation to figure out how exactly to do it: No matter how, we will break some backward compatibility.
Personally, I'm mostly in favour of disallowing the
@busstoptaktik I'm not really seing the backward compatibility issue (but I admit to have ignored that part of the code). Why not treating the pattern
But indeed, I had missed the stuff going on in
Also, I think your suggestion of special-casing the
I once tried to do something similar with LEX - but PROJ syntax is compLEX...