[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Structured (XML-like) input/output for shell apps?



* Olaf ::

> On 6/13/05, Humberto Massa Guimarães <humberto.massa@almg.gov.br>
> wrote:
<snikt>
> > 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).

Not necessarily. Just as you have "tableout" as an external command
(built-in or not) in Monad, you can have a Perl module to print
things in a tabular manner, expanding the column sizes as needed
(based on HTML::Format::Table or somesuch)
>
> > > > 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.

Yes, and I withdraw :-) what I said about XML. But *any*
serialization / deserialization necessary for this scheme to work
would add (unnecessary) overhead. This and the fact that you would
create incompatibilities with other Unices ... Those are indications
that this won't be done.

Obviously, some Monad clone can be done with its entire toolchain
(monad-ls, monad-tableout) ...

--
HTH,
Massa



Reply to: