> On Wed, Jun 11, 2008 at 11:26:05PM -0400, Peter > Memishian wrote: > > > > > Please explain why using a whitespace character > such as tab as the > > > delimiter is unworkable. > > > > Because most shells will consolidate multiple > consecutive whitespace > > fields into a single field. Blank fields become > unworkable. > > > > > My definition of parsable input means I can > write a script like > > > this in sh: > > > > > > dladm -o state,over | while read a b; do > > > echo "a=$a,b=$b" > > > done > > > > That works, just set IFS=| > > And would dladm quote '|' chars in ESSIDs?
That's actually just part of the problem, I think; from what I've read, an SSID is simply 1-32 arbitrary octets, with all possible values allowed for any given octet. Is there even a convention for how to represent an SSID that may contain non-printable characters, using only printable characters, and distinguishable from a representation of an SSID that merely happened to contain only the equivalent of printable characters? If there is such a convention, then it might be best to be able to represent (and accept) the SSID either way, depending on (for example) whether all the octets satisfied isprint() in the C locale. In other words, to guarantee that you can represent them all textually requires some kind of escape sequence protecting more than just the field delimiter character. As for the IFS trick, just as a warning, it doesn't work in /usr/bin/sh. In /usr/bin/sh, I get $ IFS='|' read a b c 1||3 $ echo $a 1 $ echo $b 3 $ echo $c $ but in /usr/bin/ksh or /usr/xpg4/bin/sh, the results are $ echo $a 1 $ echo $b $ echo $c 3 This message posted from opensolaris.org
