On 30.03.10 06:54, Dan Price wrote:
On Mon 29 Mar 2010 at 11:14AM, Bart Smaalders wrote:
On 03/29/10 11:01, Matthew Ahrens wrote:
How do commands like ls and find handle printing of filenames with
arbitrary characters (newlines and such)?
In general, badly.
Tim,
My concern, which others have hinted at, is that there are a legion of
people who are going to want to consume this information and there is
great value in making said information be machine parseable. Automated
build systems, tripwires, fancy backup/recovery tools, et cetera.
In summary, the current output seems mostly OK if it's for humans, but
the case is ambiguous about who the expected consumer is. It would
be a tragedy if there wasn't a machine consumable way to get at this
information.
May I humbly point at dladm here, specifically at the -p option that
various show-* subcommands utilise? Here's the relevant snippet from the
man-page:
Parseable Output Format
Many dladm subcommands have an option that displays output
in a machine-parseable format. The output format is one or
more lines of colon (:) delimited fields. The fields
displayed are specific to the subcommand used and are listed
under the entry for the -o option for a given subcommand.
Output includes only those fields requested by means of the
-o option, in the order requested.
When you request multiple fields, any literal colon charac-
ters are escaped by a backslash (\) before being output.
Similarly, literal backslash characters will also be escaped
(\\). This escape format is parseable by using shell read(1)
functions with the environment variable IFS=: (see EXAMPLES,
below). Note that escaping is not done when you request only
a single field.
regards
Michael
--
michael.schus...@oracle.com
Recursion, n.: see 'Recursion'
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
