[j-nsp] How to catch invalid value/option for a command in SLAX script?

[Phil Shafer]

Martin T writes:
>Thanks for the reply! Did I understand you correctly that "if(
>$variable == "usb0\ninvalid value" ) {" is actually "if( string(
>$variable ) == "usb0\ninvalid value" ) {" and the string() inserts a
>newline at the beginning and in the end of the string? Based on the
>debugger output it looks like so:
>
>(sdb) p string( $variable )
>[string] "
>usb0
>invalid value
>"
>(sdb) p string( $variable ) == "usb0\ninvalid value"
>[boolean] false
>(sdb) p string( $variable ) == "\nusb0\ninvalid value\n"
>[boolean] true
>(sdb)

Yes and no:  SLAX (and the XSLT and XPath standards it's built on)
use "type promotion" to turn objects of differing types into the same
to be able to compare them.  See the fifth paragraph in:

    https://www.w3.org/TR/xpath/#booleans

But the newlines are my fault.  The initial XML output for JUNOS
generated newlines after each tag open/close/data call to ease
debugging for developers, and also because I thought it would make
the XML->text renderer in the CLI easier.  By the time I realized
the latter was false, the former was shipping.  So XML output from
JUNOS looked like:

<tag>
data
</tag>

which means that leading and trailing newlines are present on some
data fields.  It's been corrected in many places, and some libraries
have options to automatically remove them.

Thanks,
 Phil