Re: PIPI (Parsed Input Process Initiator) -- another silly proposal?

[Brian May <bam@debian.org>]

>>>>> "Pavel" == Pavel M Penev <kal_pav@sz.techno-link.com> writes:

    Pavel> Notes: Actually in PIPI the input streams are named (so for
    Pavel> a command line interface it would rather look like "Shell%
    Pavel> audio-player chan_l< left.wav chan_r< right.wav"). Another
    Pavel> note is that it could have any type of front ends (even a
    Pavel> GUI -- let's say you choose a stereo wave file from a menu
    Pavel> and then the front end pipies the left channel from the
    Pavel> file to "chan_l" and the right channel to "chan_r", never
    Pavel> mind they're in the same file.)

I think it is an interesting idea, but perhaps you could generalise
it?  (not that I understand the full concept).

THINKING MODE (needs further development).

ie, your example seems to imply that it is specific to input streams,
and I gather might have similar problems lots of programs seem to have
these days with command line processing.

If you are redesigning command line processing in such a way, I think
you should really work to get rid of all existing problems, not just
one or two.

For, an example of a typical problem programs face. Each program, when
interpreting the command line must decide "is that argument a option,
a parameter to an option, or a filename"[1]. If the program gets this
wrong[2], and mis-interprets a filename as a command line, or vice
versa, it could result in a security hole (eg if the list of files
comes from an untrusted source). Not to mention user mistakes...

If I was doing it myself, I would design some sort of XML
language[3][4], eg

<parameters>
  <listoffiles long_id="left_channel" short_id="l">
    <title>Input for left channel</title>
    <help>Give a list of files for the left channel.</help>
  </listoffiles>
  <listoffiles long_id="right_channel" short_id="r">
    <title>Input for right channel</title>
    <help>Give a list of files for the right channel.</help>
  </listoffiles>
  <boolean long_id="muted" short_id="m">
    <title>Muted sound</title>
    <help>Play the sound tracks muted.</help>
  </boolean>
  <integer long_id="volume" short_id="v">
    <range min="0" max="100"/>
    <title>Volume of sound track</title>
    <help>How loud do you want it to play?</help>
  </integer>
</command>

You could have a parser that translates this into code for your
favourite language (eg similar to glade), whether sh, perl, C, c++,
etc.  So, the above would work in standard form:

doit --left_channel *.left -r *.right -m --volume 100

or

doit --help

could give verbose help about all the options.

while this wouldn't solve any of the problems, it would allow
solutions to be developed later on without requiring any changes to
the application (other then regenerating the code from the XML file).

eg. perhaps sometime in the future, a GUI shell might have access to
the XML file (how?). It could then come up with a dialog box:

Input for left channel?  _________________ (browse files) (?help)
Input for right channel? _________________ (browse files) (?help)
Volume of sound track?   0 <-|-----------> 100 ? help
[X] Muted

Instead of the generic one:

parameters: _____________________________

and transfer this information to the program using some really safe
protocol, that is yet to be invented. So, people who want the existing
command line method can still use that, or people who want the GUI can
use that, too. At the same time, better protocols for input can be
designed and implemented (eg Pavel's suggestion).

Notes:
[1] yes, I know you can use '--' in many programs, but that doesn't
work for all applications. See [2].

[2] yes, there are lots of libraries to try an automate the task of
command line processing, but I think they fixate too much on the old
thinking: "command [options] -- list-of-files", which isn't really
appropriate to all commands. For instance, the mv and cp commands do
not fall into the category, as the last filename is treated as the
destination, not the source.

[3] pick a type better then "listoffiles". "listofstreams"?

[4] please don't use my XML sample as is, it could be improved...  eg
short titles vs long titles, optional vs required parameters, options
specific to individual files in each list, other lists, etc. I know
how I could fix these, but want to keep this E-Mail simple.

[5] I have spent to long on this E-Mail message already. I hope there
aren't any obvious mistakes that distract attention away from the main
points I am raising...
-- 
Brian May <bam@debian.org>