Re: Inconsistent use of exit code's

[Michael Perdue]

Actually, I'm finding this in multiple areas. Then I read the CHANGES.txt and see

7 Mai 2024 -- unify exit codes; refactoring error handling

This is good, but what do the various codes mean? Is this documented somewhere? Exit codes in the readme's would be a good thing. I still read them ;) I will have a lot of updates to various scripts as in the past I have accepted that 0 was success and 1 was fail.

On Thu, May 16, 2024 at 10:54 AM Michael Perdue <michael...@gmail.com> wrote:

Hello,

I just noticed that las2las throws an exit code of 1 on some warnings. In particular, it throws an exit code of 1 when it changes the offsets due to a change in scale request.

WARNING: i changed y_offset from 0 to 3.74075e+06 to accommodate enlarged bounding box

WARNING: rescaling from 0.01 to 0.001 and reoffsetting from 3.7e+06 to 3.74075e+06 causes LAS integer overflow for min_y

WARNING: rescaling from 0.01 to 0.001 and reoffsetting from 3.7e+06 to 3.74075e+06 causes LAS integer overflow for max_y

WARNING: rescaling from 0.01 to 0.001 and reoffsetting from 500000 to 0 causes LAS integer overflow for min_x

WARNING: rescaling from 0.01 to 0.001 and reoffsetting from 500000 to 0 causes LAS integer overflow for max_x

WARNING: rescaling from 0.01 to 0.001 and reoffsetting from 500000 to 0 causes LAS integer overflow for min_x

WARNING: rescaling from 0.01 to 0.001 and reoffsetting from 500000 to 0 causes LAS integer overflow for max_x

WARNING: rescaling from 0.01 to 0.001 and reoffsetting from 500000 to 0 causes LAS integer overflow for min_x

WARNING: rescaling from 0.01 to 0.001 and reoffsetting from 500000 to 0 causes LAS integer overflow for max_x

In this case, the program changed the offsets as required, finished processing the file and then threw an exit code of 1. Is this intended behaviour? Other programs such as "laszip -check -i some_corrupt_file.laz" exit with 0 even if the file is corrupt.

When lastools exits with 1 even though it successfully competed, it makes it tough to separate a critical failure (malloc, bad options, bug) from general information that I might want to be aware of. I capture exit code's, stdout and stderr, but generally treat anything other than 0 as an indication that the workflow needs to stop for that file immediately.

Structured exit codes (0 - I'm happy and all is good, 1 - Warnings, 2 - Bad CLI Parameters, 3 - Critical Failure, 4 - No license, etc) would be useful for those of us that do heavy scripting with lastools. But in that absence, I think 0 should mean "I finished" and 1 should mean "I failed".

Cheers,

Mike

[Jochen Rapidlasso]

Hi Mike,

the documentation for the new error codes was in review, so we had undocumented features for some days.

Please see the documentation for the explanation of the redesigned error handling.

Redesign of LAStools error handling

Best regards,

Jochen @rapidlasso

[michaelperdue99]

Hi Jochen,

The new functionality is greatly appreciated. Refactoring the exit codes definitely improves flow control in scripting and simplifies life on the commandline. And I also appreciate you standardizing the messaging flags and the addition of the silent flag. Most of the time I just want a program to shush and go do it's thing in the background. Having a bunch of chatter on the CLI can really interfere with a person's ability to find the important messages like warnings and failures. This is just one example of something that wasn't so easy 2 weeks ago:

mi...@air.local@earth01 /mnt/x/Projects/2024_04_05_uofi_gm/checkme
>parallel --joblog results.log laszip -silent -check -i {} ::: *.laz
WARNING: 'corrupt chunk table'

mi...@air.local@earth01 /mnt/x/Projects/2024_04_05_uofi_gm/checkme
>cat results.log
Seq Host Starttime JobRuntime Send Receive Exitval Signal Command
1 : 1716931612.287      0.019 0 0 0 0 laszip -silent -check -i 5093_51874.laz
2 : 1716931612.290      0.235 0 0 0 0 laszip -silent -check -i 5093_51875.laz
8 : 1716931612.304      0.445 0 0 0 0 laszip -silent -check -i 5094_51869.laz
3 : 1716931612.292      0.490 0 0 0 0 laszip -silent -check -i 5093_51876.laz
4 : 1716931612.295      0.770 0 0 0 0 laszip -silent -check -i 5093_51877.laz
20 : 1716931612.333      1.054 0 0 1 0 laszip -silent -check -i 5095_51868.laz
21 : 1716931612.337      1.099 0 0 0 0 laszip -silent -check -i 5095_51869.laz
7 : 1716931612.302      1.394 0 0 0 0 laszip -silent -check -i 5093_51880.laz
6 : 1716931612.299      2.312 0 0 0 0 laszip -silent -check -i 5093_51879.laz
5 : 1716931612.297      2.488 0 0 0 0 laszip -silent -check -i 5093_51878.laz
13 : 1716931612.317      5.236 0 0 0 0 laszip -silent -check -i 5094_51874.laz
19 : 1716931612.330      5.800 0 0 0 0 laszip -silent -check -i 5094_51880.laz
9 : 1716931612.306      6.407 0 0 0 0 laszip -silent -check -i 5094_51870.laz
14 : 1716931612.319      7.828 0 0 0 0 laszip -silent -check -i 5094_51875.laz
12 : 1716931612.314      8.688 0 0 0 0 laszip -silent -check -i 5094_51873.laz
11 : 1716931612.312      8.897 0 0 0 0 laszip -silent -check -i 5094_51872.laz
10 : 1716931612.309     11.776 0 0 0 0 laszip -silent -check -i 5094_51871.laz
15 : 1716931612.321     11.813 0 0 0 0 laszip -silent -check -i 5094_51876.laz
18 : 1716931612.328     12.161 0 0 0 0 laszip -silent -check -i 5094_51879.laz
16 : 1716931612.323     13.765 0 0 0 0 laszip -silent -check -i 5094_51877.laz
17 : 1716931612.326     16.832 0 0 0 0 laszip -silent -check -i 5094_51878.laz

Running laszip in parallel checking files would flood the CLI with messages of success. With 21 files, it's not such a big deal, but when you have 30k+ tiles it becomes problematic. The terminal buffer generally isn't that long and who wants to scroll through that much output anyways? I would have to capture the output and try to interpret it from within a script, which can be fragile.

Now I can tell it to be silent and have parallel write a joblog. If there is no output then there is nothing to check. But if I see warnings or errors on the screen I can check the joblog for what failed and investigate as necessary.

Being able to capture and separate warnings from failures using exit codes is an added bonus!

Kuddo's

Mike