Hi,
I've had some success prototyping the below idea on a few utilities. See
https://github.com/OSGeo/gdal/pull/9445 for details
Even
Le 08/03/2024 à 16:40, Even Rouault via gdal-dev a écrit :
Hi,
Our command line C++ utilities use ad-hoc manual parsing, which means
that:
- the usage
Le 08/03/2024 à 18:34, Javier Jimenez Shaw a écrit :
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 was perhaps not clear. Let me clarify, but at
> 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.
>
+1
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
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
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
Some options have related environment variables, eg --debug /CPL_DEBUG.
Options are also passed through to several drivers.
I assume that the implications for these are not significant ?
This wouldn't change the general logic of GDAL and so the existing
(possibly confusing) set of various type
Hi Even.
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?
... well, how is GDAL
Le ven. 8 mars 2024, 17:42, Even Rouault a
écrit :
> Thomas,
> >
> > my number 1 requirement would be that the rewrite not cause any
> > backwards compatibility issues compared to today's argument handling.
> > I suspect many users are calling the gdal utilities through scripts
> > and it would
On Fri, 8 Mar 2024, Even Rouault via gdal-dev wrote:
Hi,
Our command line C++ utilities use ad-hoc manual parsing, which means that:
- the usage message must be manually composed,
- you must take care to check that there are enough remaining arguments for
the ones that take value to avoid
Thomas,
my number 1 requirement would be that the rewrite not cause any
backwards compatibility issues compared to today's argument handling.
I suspect many users are calling the gdal utilities through scripts
and it would be a pain to have to update those when upgrading gdal.
Yes,
Hi Even,
my number 1 requirement would be that the rewrite not cause any backwards
compatibility issues compared to today's argument handling. I suspect many
users are calling the gdal utilities through scripts and it would be a pain
to have to update those when upgrading gdal.
a nice to have
Hi,
Our command line C++ utilities use ad-hoc manual parsing, which means that:
- the usage message must be manually composed,
- you must take care to check that there are enough remaining arguments
for the ones that take value to avoid out-of-bounds accesses (tests like
argc + 1 < argn)
12 matches
Mail list logo
