Re: Structured (XML-like) input/output for shell apps?
* Gabor ::
> Hi,
>
> On Sat, Jun 11, 2005 at 07:40:10PM +0200, Olaf van der Spek wrote:
>
> > Many shell apps/scripts output data in tables, for example ls
> > -l, ps aux, top, netstat, etc. At the moment, most of these
> > apps use fixed-width columns with a variable-width last-column.
> > This results in (unnecessary) truncation, for example: Debian-
> > 11918 0.0 0.1 4428 1464 ? Ss Jun05 0:00
> > /usr/sbin/exim4 -bd -q30m tcp 0 0 TC218-187-80-45.2:35589
> > bananensaft.inline.:www ESTABLISHEDproxy 153239
> >
> > Also, because the output isn't structured (in way easily
> > readable by machines), using the data in a script isn't (very)
> > easy and is likely to break due to strict dependency on the
> > syntax.
> >
> > Are there already any plans to solve these issues?
>
> Yes. The commands you mention were designed for _human_
> consumption. Do not use them in scripts without good reasons.
> There are a lot of commands to get well-formatted output without
> truncation. For example, ls has a "-n" option for exactly this
> reason; stat(1) can be used instead of "ls -l" to avoid clipping;
> ps has a _lot_ of formatting options itself and all the data can
> be found under /proc in an easily parseable format etc. You just
> have to select the right tool for the job (that also includes
> using more powerful scripting languages if the task is
> complicated).
>
> > I was thinking, using structured output (and maybe input) in an
> > XML-like way would solve these and allow neat post-processing.
>
> XML is just _terrible_ for human input/output.
What Olaf *really* seems to want is a resource like the new (vapor?)
Monad shell from MS. Which can be a good thing, if done right, but
is generally a waste of CPU and memory, if you ask me. As you said,
there is not a lot of difference between
ls *.ab | fields name, size | table
in Monad and
printf "%-50.50s %d\n", $_, -s $_ for <*.ab>
in Perl. The domain is necessary anyway, ie, you have to know Monad
to understand the first, you have to know perl to grok the second.
* Olaf ::
> > XML is just _terrible_ for human input/output.
>
> It's not meant for human IO, it's meant for IO to the next chain.
> The final chain would then process it to normal text output.
Even so; imagine a long (6 links) chain of things. Each of them
would have to unserialize the input and serialize the output (XML no
less! big overhead!), besides trying to know if its input is xml or
not, if its output should be xml or not. In the Monad case, it
*seems* that what is passed around are (DCOM?) objects, lowering the
overhead a litlle bit, but there is a lot of overhead nonetheless.
And it's still easier to use a tool (like Perl, Python or Ruby for
instance) that can do the job you want (look my example above)
IOW, I don't think Monad is such a hot idea.
--
HTH,
Massa
Reply to: