Abul,
gdal_ls.py is a non officially promoted script that isn't installed with
GDAL. Your best luck is just to fetch it from
https://github.com/OSGeo/gdal/blob/master/swig/python/gdal-utils/osgeo_utils/samples/gdal_ls.py
, ship it with your program, and directly points at it. It obviously
requires users to have the GDAL Python bindings installed.
Your other alternative could be to "port" it to Go using Go bindings,
but I don't know much about the distribution story of go bindings, so
don't ask me more about that part. I see that lukeroth/gdal has
VSIReadDirRecursive() which is essentially what you need:
https://github.com/search?q=repo%3Alukeroth%2Fgdal%20VSIReadDir&type=code
Even
Le 12/12/2024 à 21:23, Abdul Raheem Siddiqui via gdal-dev a écrit :
Hello,
I am developing a compiled program in Golang that calls GDAL through
subprocess calls. In one of the program's features that I am
developing, I want to call *gdal_ls*. However, I see that gdal_ls is
not available in PATH by default and hence can't be called directly in
a terminal without specifying the full path or moving `gdal_ls.py`
script to the path.
My program will be shipped as a binary, and GDAL is expected to be
available on the machine where the binary is executed. This has worked
well so far but now that I want to call *gdal_ls *in the new feature,
the new feature will not work out of the box.
Is there a way to install GDAL with gdal_ls available in Path (so that
I can ask my users to do this) or is there a better solution for my
problem?
Thanks,
Abdul Siddiqui
ERT Corp.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is
just about bytes.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
