I believe it is better to explicitly fail when the/an input file is missing than silently going on

So do I. Note that Thomas is on vacation and it could be a while before he sees this.

On holidays and commenting from my phone, so my ability to grasp the overall problem tackled by this PR is quite limited. But if I understand the issue reported by @jidanni, the problem is that when given meaningless +arguments, cct does not react properly: The epsg:nnnn looking like an arg to "+to", if cct was cs2cs, should be taken as the name of an input file by cct, but apparently is not?

If no input file names are given, cct, like any filter style program, should not complain, but read stdin, write stdout. And the syntax used in the issue should perhaps give unchanged output?

the problem is that when given meaningless +arguments, cct does not react properly: The epsg:nnnn looking like an arg to "+to", if cct was cs2cs, should be taken as the name of an input file by cct, but apparently is not?

cct considers the epsg:nnnn as a filename from which to take input coordinates, and without the fix in that PR, it fails to open it, but without any error message, and without returning in error, and when opt_input_loop() has consumed all input filenames, cct returns with a success error code. With that PR, it should be more obvious that invalid arguments have been provided. This won't obviously catch all potential non-sensical inputs, but I believe it is valuable to report invalid filenames.