[gdal-dev] Using a "standard" argument parser for command line utilities?

[Javier Jimenez Shaw]

I don't like that the behaviour of a command line depends on the
configuration of the user (that is usually not aware of). So a command that
works for me doesn't work for you. That is bad.
I don't know in GDAL, but in proj there is the option --bbox, that has
comma separated coordinates. That can be -10.5,5.1,-9.5,6.3

On Fri, 8 Mar 2024 at 18:27, Even Rouault <even.rouault at spatialys.com>
wrote:

>
> >
> > In principle the idea sounds good.
> >
> > How is it parsing the numbers? is it locale agnostic? I think it is
> > not, because it is using "strtod". That means that if I have my locale
> > in Spanish, French, German, ... it will expect "," as the decimal
> > separator, right?
> if running under a non-C locale, and without modification, yes
> > ... well, how is GDAL expecting floating values?
>
> Only if the utilities enables setlocale(LC_ALL, ""), which they don't by
> default. That said as the command line utility parsing is also used for
> the utility-as-C-function, we may run under a non-C locale (that is a
> Spanish/French/whatever locale) in some contexts.
>
> > Is GDAL locale agnostic?
> Grep'ping I see that we use both CPLAtof() which is locale-agnostic and
> assume dot as decimal separator or CPLAtofM() which accept dot or comma
> as decimal separator. I don't think there is a particular reason in
> using any of them. Inconsistency likely due to doing the work manually
> and depending on the mood of the developer. Not totally sure of the
> behavior we want: should we always require dot as the decimal separator,
> or be lenient and accept both dot and comma (wondering if there wouldn't
> be situations where we would take a "a,b,c" string, with a, b, c being
> floating point numbers, in which case obviously we would have to require
> dot. But I'm not sure if that can happen)
> >
> > Do you want to add it as a dependency, or just copy-paste the header
> > file into gdal repo?
>
> yes, copy-paste and potentially with a few changes for our needs, like
> using CPLAtof or CPLAtofM.
>
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240308/a57a0fed/attachment.htm>