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.schuster at oracle.com
Recursion, n.: see 'Recursion'
