Running "gdalcompare --help" shows binary name as "gdalcompare.py" in output

[pjonsson]

What is the bug?

Running gdalcompare --help at the prompt adds a .py extension to the "binary" name in the help:

$ gdalcompare --help
Usage: gdalcompare.py [--help] [--help-general]
                      [-dumpdiffs] [-skip_binary] [-skip_overviews]
                      [-skip_geolocation] [-skip_geotransform]
                      [-skip_metadata] [-skip_rpc] [-skip_srs]
                      [-sds] <golden_file> <new_file>

My system contains a gdalcompare.py as well (and that is a different file from gdalcompare) whose last two lines are:

deprecation_warn("gdalcompare")
sys.exit(main(sys.argv))

so I'm guessing one of them is deprecated. I tried gdalcompare --help --debug on and gdalcompare.py --help --debug on and I don't see any deprecation warnings in my terminal.

Steps to reproduce the issue

Run gdalcompare --help or ogr_layer_algebra --help inside the Ubuntu docker container.

Versions and provenance

Using local Docker image built from ubuntu-small-3.9.3.

Additional context

No response

[jratike80]

I think that gdalcompare is really a Python script and the binary thing is some convenience method that allows users to run gdalcompare instead of python gdalcompare.py. The launcher scripts came with https://github.com/OSGeo/gdal/issues/8811.

My latest experience was that python gdalcompare.py works always but the launcher scripts sometimes fail. I don't know if they are always reliable now.

[rouault]

@pjonsson If you want to tackle this, feel free to submit a PR stripping the .py extension in the usage message.

[pjonsson]

I guess that's one way to solve it. In the middle of upgrading to GDAL 3.9.3 now, but I'll make a PR later this week.

[jratike80]

Right, if user has reached the point when they see the message they know already how to run the utility. Seeing .py makes just confusion. Better to make the message and the documentation https://gdal.org/en/latest/programs/gdalcompare.html to match.