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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp