2000-04-30

  * Investigate the relevance of the recent discussion about IPC::BashEm
    (may be renamed) on the perl5-porters list.
    [GNP]


2000-01-01

  * Unify builtin's usage_ error messages with help builtin and make
    the help messages translatable. Seriously think about avoiding
	to hold all error texts in memory all the time. [warp]


1999-12-26

  * Investigate the relationship between the Perl Power Tools project
	http://www.perl.com/pub/language/ppt/index.html, and the Perl Shell.
	They are reimplementing Unix utilities in Perl. It would be nice if
	the implementations were all modules with thin command-line hook
	programs that basically hand over control to the module. Then, we
	could leverage the modules without doing an exec by being aware of
	the namespace they use...
	[GNP]


1999-12-13

  * Make a new strategy: '? ...', that shows information about how psh
    is processing the line. For example, show it after alias expansion,
    etc. Perhaps ? ... could be short-form (just alias and var subst)
    and ?? ... could be long form.
    [GNP]

  * What is the effect of bash's ':', and should we do the same thing?
    The manpage makes it sound uninteresting, and unnecessary, and
    trying it doesn't make it appear to do anything useful. Have I
    missed the point?
    [GNP]

  * ulimit.
    [GNP]

  * On my system, nohup is a /bin/sh script. Perhaps we should make
    this a builtin so that we don't need to call out.
    [GNP]


1999-11-01

  * There is something called the XMLTerm that is like an xterm, but
    uses XML for its display. Find out if there is anything that can
    be done in psh to make interaction via XML Shell especially nice.

	XMLTerm was mentioned in MozillaZine on 1999-09-27:

		http://www.mozillazine.org/talkback.html?article=813

	More information can be found at http://xmlterm.com

	There is another XMLTerm project, related to the LunuXML project. Info
	at http://www.geocities.com/ResearchTriangle/Forum/6751/#anchor3
	[GNP]

  * Along those same lines, create a mode whereby the shell intercepts
    all command output (rather than letting it stream to its own STDOUT)
    and produces an output stream that uses a period on a separate line
    to indicate the end of a multi-line region (with appropriate escaping).
    A GUI could then use this information to to put up a nice display with
    a divider line between commands, the ability to collapse the output of
    a command, etc. Think of the Mathematica notebook interface. Here's an
    example of what it would look like:

        .in psh$ 
        echo 'foo'
        .
        .out
        foo
        .

    Of course, there are some problems with this. (i) Standard input and
    standard output would be merged into the "out" section probably. But,
    it would be nicer to actually keep them separate so that, for example,
    the error output could be formatted red. But, of course, we'd want to
    have the streams synchronized, since error and regular output might
    be interspersed. (ii) Programs like 'vi' and those that use the 'curses'
    library treat the screen as an array of cells. We might have to detect
    this and go into a different mode, where the output would be just an
    indicator that it was "visual" interaction. (iii) Interactive input to
    a program while it is running would have to flow through the shell, too.
    This way, it could be captured just like STDOUT and STDERR. This, too
    would need synchronization. Perhaps an internal representation following
    the W3C recommendations for synchronized media would be in order here?
    (iv) Handling the "visual" case mentioned above might cause some trouble
    in dealing with ReadLine-style command-line editing by the user.
    [GNP]

  * Implement an underlying module that can be used to construct shells.
    This module (named "Mantle" after the part of a mollusk that creates
    the shell) would have support for creating subprocesses, managing
    pipelines and so on. Here are some ideas:

    The code:

        $cat  = command(qw(cat foo));
        $sort = command('sort');
        $uniq = command('uniq');

        pipeline($cat, $sort, $uniq);

    Would cause the following to happen:

        @read  = (new FileHandle, new FileHandle);
        @write = (new FileHandle, new FileHandle);

        push @job, task($cat,                      STDOUT => $write[0]);
        push @job, task($sort, STDIN  => $read[0], STDOUT => $write[1]);
        push @job, task($uniq, STDIN  => $read[1])

        await @job;

    And now, the @job array has handles for all the processes involved in
    the pipeline.

    A generalization of pipeline(), called flow() could provide an easy way
    to specify connectivity other than simple pipelines. For example, the
    STDERR of a task in the flow could be sent down its own pipeline that
    did some parsing and processing before landing it in a file somewhere.

        $foo   = command('foo');
        $bar   = command('bar');
        $quux  = command('quux');
        $splee = command('splee');

        flow({foo => $foo, bar => $bar, quux => $quux, splee => $splee}, 
            'bar.stdin'   => 'foo.stdout',
            'quux.stdin'  => 'foo.stderr',
            'splee.stdin' => 'quux.stdout'
        );
    [GNP]

  * Use this underlying support module to provide background jobs and pipelines
    from within this shell. Also, create simple shells similar to other shells
    using it (for testing and demonstration purposes).
    [GNP]