Re: Structured (XML-like) input/output for shell apps?
On 6/13/05, Humberto Massa Guimarães <humberto.massa@almg.gov.br> wrote:
> 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.
Except that in Perl you have hard-coded the size of the name field and
hard-coded sizes are almost never optimal (either too large or too
small in most of the cases).
> > > 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
Note that I said structured (XML-like) IO. I didn't say XML. I'm sure
an implementation without big overhead is possible.
> 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)
Reply to: