Re: "Semantic" shell? (for lack of better name)
Hello Bryan,
I've thought about similar efforts, much were centered about having a
generic "command line syntax definition language".
Not every application can be squeezed into the input, output scheme. The
situation with multiple inputs, single output is common.
Neither can every application convert every input to every output,
sometimes just particular combinations might be possible (in particular,
input format might have to be the same as the output format).
Then there are "meta formats", especially compression.
For example gzip will convert any file type to the same file type but
gzip-compressed (or the other way round using gunzip).
So a tool trying to "magically" build chains would need to understand
that while gzip can process the "*/*" mime type, it won't convert the
file type, whereas 'convert' can convert next to any image file type to
next to any other image file type.
But for example to convert text/plain to image/gif with convert, you
should also specify a font...
The debtags efforts do a very minimal approach here: they use 'looser'
file types than MIME and they do not differentiate between input, output
or whatever-put. There are some benefits from that, including
- less information needs to be collected and updated
- the information is more likely to be accurate
obviously at the cost of the information being less useful. At some
point you need to make a cut.
At some point I was considering to actually use RDF-like triplets such
as "app1 reads image/gif" "app1 writes image/jpeg" etc. but we ended up
to going a tuplet-only approach for complexity reasons.
Of course things have made progress since. For example, the .desktop
files usually include useful information about which MIME types an
application supports (unfortunately, many non-GUI-application still do
not ship with .desktop files), but the information there also has some
kind of "vagueness".
So it might well be time to do the next step and collect such meta
information on a "reads" "writes" "displays" "prints" and whatever
basis. However collecting all this data sounds like a huge task to me.
I mentioned before that I was also thinking about a "command line syntax
definition language". The reason is that command line programs vary a
lot in how parameters are passed. There are certain common standards
such as GNU getopt command line syntax (i.e. single letter options with
a single dash, long options with a double dash, single letter options
can be joined ...), but there are also tons of exceptions
(e.g. "java -version" is different from "java -v -e -r -s -i -o -n" and
would have been "java --version" in getopt style).
A specification of the available options in some meta format ideally
would also give an indication of valid file types for file name
parameters. But also note about mutually exclusive options. And it is
obvious that not all command line can be described this way completely
(e.g. to fully validate "perl -e 'perl expression'" you'd need to be
able to validate perl syntax ... and "only perl can parse perl". So
you'll never know what MIME types that statement accepts ...)
A solution covering 90% might still be very nice to have.
I believe that a "semantic shell" might need to be based around the
command line interface of the applications.
best regards,
Erich Schubert
--
erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
Reality continues to ruin my life --- Calvin //\
Der Anfang aller Erkenntnis ist das Staunen. --- Aristoteles V_/_
Reply to: