On Sat, Jan 3, 2009 at 7:16 PM, Erich Schubert wrote: > I've thought about similar efforts, much were centered about having a > generic "command line syntax definition language".
I don't know if formal grammars (BNF, etc.) would apply there. > Not every application can be squeezed into the input, output scheme. The Right. Fundamentally all steps in a program take some input and generate some output. The GNU approach of just splitting everything into smaller and smaller programs is one way to do this, but I'd prefer to not have to rewrite everything ever. Part of what I want to do here is "substitutions", just like you can find so many substitutions for your favorite text editor (insert flamewar here). But in a way not dependent on requiring people to know every text editor ever. > 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). Yes, so there's always going to be exceptions to the rule of thumb of program structure, but in those exceptional cases is it something that would qualify for inclusion in this system anyway? > But for example to convert text/plain to image/gif with convert, you > should also specify a font... Right, but there's also a known command for spitting out a list of valid fonts, so that could be a note attached to that defined parameter to the 'convert' program. > 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. we? who? Any working code that I could go poke? > 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". Another response to my email included a link over to 'open-with-install', a program to query the apt repositories to find a program to open a certain file with, which is a good step in that direction. But yes, there is a vagueness involved in .desktop too. > 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. Yikes, there are so many of those verbs though - you'd basically be doing Cyc or WordNet all over again. Each program technically qualifies as a new verb too, so the usefulness seems to deteriorate. > 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 This is why I first thought that this might require a new type of shell standard, or doing these edits to the system somewhere else other than on a debian-level. Environmental variables for passing commands (like in CGI) might not be enough metadata being passed around (or something). I'm very uncertain about all this. > 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 What about logic languages for expressing valid and invalid uses of the parameter pool? I.e., define the valid breadth-first set of parameters, and then some logic conditionals that describe validity. > 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 ...) "perl -e" accepts a string of text data (I don't think binary data works). Whether or not the string is valid in terms of perl syntax (etc.) is another issue entirely, isn't it? > 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. Another area that I'm applying this to is the interconnection of manufacturing processes, but I'll digress for the moment. - Bryan http://heybryan.org/ 1 512 203 0507 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
