How can we use "validate" in scripts?

[rpgoldman]

I was planning to invoke validate in a script, and check to see if my plan validated using the customary check against exit status. But I was disappointed to find that even when validate emitted `Bad plan description!" its exit code was still zero.

Digging further, since the plan argument is optional, and it's possible to check multiple plans in a single run of validate, I can see why the exit code wasn't set. And, indeed, AFAICT if validate fails to parse a plan file, it gets a zero back from getPlan, which means it's just like the plan not being there.

But if validate doesn't set an exit code, how can one use it in a script?

[DerekLong101]

Hi Rob Thanks for the comments. Good question - perhaps it would be useful to set a command line switch to cause a fail-with-exit-code on a bad plan entry? Cheers Derek

…

________________________________ From: rpgoldman <notifications@github.com> Sent: 12 September 2017 23:09:45 To: KCL-Planning/VAL Cc: Subscribed Subject: [KCL-Planning/VAL] How can we use "validate" in scripts? (#20) I was planning to invoke validate in a script, and check to see if my plan validated using the customary check against exit status. But I was disappointed to find that even when validate emitted `Bad plan description!" its exit code was still zero. Digging further, since the plan argument is optional, and it's possible to check multiple plans in a single run of validate, I can see why the exit code wasn't set. And, indeed, AFAICT if validate fails to parse a plan file, it gets a zero back from getPlan, which means it's just like the plan not being there. But if validate doesn't set an exit code, how can one use it in a script? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKCL-Planning%2FVAL%2Fissues%2F20&data=01%7C01%7Cderek.long%40kcl.ac.uk%7C088cb331b5e449b5239908d4fa2afadb%7C8370cf1416f34c16b83c724071654356%7C0&sdata=syCcQp12zfP9m9wJEIsvXqzk6oZzs3oG8xZkm%2Bv9Yhk%3D&reserved=0>, or mute the thread<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAHSnVE75cRWGipOmzvkSDqOUq9AcWj27ks5shwEhgaJpZM4PVUqG&data=01%7C01%7Cderek.long%40kcl.ac.uk%7C088cb331b5e449b5239908d4fa2afadb%7C8370cf1416f34c16b83c724071654356%7C0&sdata=yRj1Drsh%2BJXhKcTX9mAZJhP1F3IoUn3GgVEJG0VDBeU%3D&reserved=0>.

[rpgoldman]

Yes, I think that would be quite helpful. The alternative would be forcing scripts to parse output strings, which isn't very appealing.

[maltehelmert]

For our work, we have to parse the output anyway because we are also interested in what VAL says about the quality of the validated plans. I don't know if it's helpful for you, but we use the "downward-lab" package by Jendrik Seipp for this, which is available online. I don't know how difficult it would be to adapt Jendrik's code for other planning systems than Fast Downward.

[rpgoldman]

See #66 where I started to implement @DerekLong101 's suggestion.

But it's not at all clear that's right. In fact, it looks like Validate succeeding (exit status == 0) might simply be a typo bug.

The original main() deletes the_plan and then sets it to 0, presumably to avoid use after free.

But then it unconditionally returns the_plan, which means on failure it returns 0.

Everywhere else in main seems to call exit(-1) when something goes wrong. So I'm starting to wonder if it wasn't just a mistake that failure to validate the plan sets exit status to zero.

If it was just a mistake, then main should just set the exit status to a non-zero value here, and we don't need a -x special flag or any special handling.

It's possible we should modify the code so that an error condition (failure to find a file named on the command line, e.g.) has a value distinct from successful processing but input not validated.

[rpgoldman]

P.S. Since IANACPPP (I Am Not A C Plus Plus Programmer), what are those -1s for in the exit statements? Why not just use something like exit(1)? Was this deliberate?

and re

It's possible we should modify the code so that an error condition (failure to find a file named on the command line, e.g.) has a value distinct from successful processing but input not validated.

Maybe error conditions should be exit code 2 and failures to validate without error should be 1, or some such convention?