Provided by: rlwrap_0.37-2_amd64 bug


       RlwrapFilter - Perl class for rlwrap filters


         use lib $ENV{RLWRAP_FILTERDIR};
         use RlwrapFilter;

         $filter = new RlwrapFilter;

         $filter -> output_handler(sub {s/apple/orange/; $_}); # re-write output
         $filter -> prompt_handler(\&pimp_the_prompt); # change prompt
         $filter -> history_handler(sub {s/with password \w+/with password ****/; $_}); # keep passwords out of history

         $filter -> run;


       rlwrap (1) (<>) is a tiny utility that sits
       between the user and any console command, in order to bestow readline capabilities (line
       editing, history recall) to commands that don't have them.

       Since version 0.32, rlwrap can use filters to script almost every aspect of rlwrap's
       interaction with the user: changing the history, re-writing output and input, calling a
       pager or computing completion word lists from the current input.

       RlwrapFilter makes it very simple to write rlwrap filters in perl. A filter only needs to
       instantiate a RlwrapFilter object, change a few of its default handlers and then call its
       'run' method.


       $f = new RlwrapFilter
       $f = RlwrapFilter -> new(prompt_handler => sub {"Hi! > "}, minimal_rlwrap_version =>
       "0.35", ...)
           Return a new RlwrapFilter object.

       Handlers are user-defined callbacks that get called from the 'run' method with a message
       (i.e. the un-filtered input, output, prompt) as their first argument. For convenience, $_
       is set to the same value. They should return the re-written message text. They get called
       in a fixed cyclic order: prompt, completion, history, input, echo, output, prompt, ... etc
       ad infinitum. Rlwrap may always skip a handler when in direct mode, on the other hand,
       completion and output handlers may get called more than once in succession. If a handler
       is left undefined, the result is as if the message text were returned unaltered.

       It is important to note that the filter, and hence all its handlers, are bypassed when
       command is in direct mode, i.e. when it asks for single keystrokes (and also, for security
       reasons, when it doesn't echo, e.g. when asking for a password). If you don't want this to
       happen, use rlwrap -a to force rlwrap to remain in readline mode and to apply the filter
       to all of command's in- and output. This will make editors and pagers (which respond to
       single keystrokes) unusable, unless you use rlwrap's -N option (linux only)

       The getters/setters for the respective handlers are listed below:

       $handler = $f -> prompt_handler, $f -> prompt_handler(\&handler)
           The prompt handler re-writes prompts and gets called when rlwrap decides it is time to
           "cook" the prompt, by default some 40 ms after the last output has arrived. Of course,
           rlwrap cannot read the mind of command, so what looks like a prompt to rlwrap may
           actually be the beginning of an output line that took command a little longer to
           formulate. If this is a problem, specify a longer "cooking" time with rlwrap's -w
           option, use the prompts_are_never_empty method or "reject" the prompt (cf. the
           prompt_rejected method)

       $handler = $f -> completion_handler, $f -> completion_handler(\&handler)
           The completion handler gets called with the the entire input line, the prefix (partial
           word to complete), and rlwrap's own completion list as arguments. It should return a
           (possibly revised) list of completions.  As an example, suppose the user has typed
           "She played for A<TAB>". The handler will be called like this:

                myhandler("She played for A", "A", "Arsenal", "Arendal", "Anderlecht")

           it could then return a list of stronger clubs: ("Ajax", "AZ67",  "Arnhem")

       $handler = $f -> history_handler, $f -> history_handler(\&handler)
           Every input line is submitted to this handler, the return value is put in rlwrap's
           history. Returning an empty or undefined value will keep the input line out of the

       $handler = $f -> input_handler, $f -> input_handler(\&handler)
           Every input line is submitted to this handler, The handler's return value is written
           to command's pty (pseudo-terminal).

       $handler = $f -> echo_handler, $f -> echo_handler(\&handler)
           The first line of output that is read back from command's pty is the echo'ed input
           line. If your input handler alters the input line, it is the altered input that will
           be echo'ed back. If you don't want to confuse the user, use an echo handler that
           returns your original input.

           If you use rlwrap in --multi-line mode, additional echo lines will have to be handled
           by the output handler

       $handler = $f -> output_handler, $f -> output_handler(\&handler)
           All command output after the echo line is submitted to the output handler (including
           newlines). This handler may get called many times in succession, dependent on the size
           of command's write() calls, and the whims of your system's scheduler. Therefore your
           handler should be prepared to rewrite your output in "chunks", where you even don't
           have the guarantee that the chunks contain entire unbroken lines.

           If you want to handle command's entire output in one go, you can specify an output
           handler that returns an empty string, and then use $filter -> cumulative_output in
           your prompt handler to send the re-written output "out-of-band" just before the

               $filter -> output_handler(sub {""});

               $filter -> prompt_handler(
                             sub{ $filter -> send_output_oob(mysub($filter -> cumulative_output));
                                  "Hi there > "

           Note that when rlwrap is run in --multi-line mode the echo handler will still only
           handle the first echo line.  The remainder will generally be echoed back preceded by a
           continuation prompt; it is up to the output handler what to do with it.

       $handler = $f -> message_handler, $f -> message_handler(\&handler)
           This handler gets called (as handler($message, $tag)) for every incoming message, and
           every tag (including out-of-band tags), before all other handlers. Its return value is
           ignored, but it may be useful for logging and debugging purposes. The $tag is an
           integer that can be converted to a tag name by the 'tag2name' method

       $f -> help_text("Usage...")
           Set the help text for this filter. It will be displayed by rlwrap -z <filter>. The
           second line of the help text is used by "rlwrap -z listing"; it should be a short
           description of what the filter does.

       $f -> minimal_rlwrap_version("x.yy")
           Die unless rlwrap is version x.yy or newer

       $dir = $f -> cwd
           return the name of command's current working directory. This uses the /proc
           filesystem, and may only work on newer linux systems (on older linux and on Solaris,
           it will return something like "/proc/12345/cwd", useful to find the contents of
           command's working directory, but not its name)

       $text = $f -> cumulative_output
           return the current cumulative output. All (untreated) output gets appended to the
           cumulative output after the output_handler has been called. The cumulative output
           starts with a fresh slate with every OUTPUT message that directly follows an INPUT
           message (ignoring out-of-band messages and rejected prompts)

           When necessary (i.e. when rlwrap is in "impatient mode") the prompt is removed from
           $filter->cumulative_output by the time the prompt handler is called.

       $tag = $f -> previous_tag
           The tag of the last preceding in-band message. A tag is an integer between 0 and 255,
           its name can be found with the following method:

       $name = $f -> tag2name($tag)
           Convert the tag (an integer) to its name (e.g. "TAG_PROMPT")

       $name = $f -> name2tag($tag)
           Convert a valid tag name like "TAG_PROMPT" to a tag (an integer)

       $f -> send_output_oob($text)
           Make rlwrap display $text. $text is sent "out-of-band": rlwrap will not see it until
           just  after it has sent the next message to the filter

       $f -> send_ignore_oob($text)
           Send an out-of-band TAG_IGNORE message to rlwrap. rlwrap will silently discard it, but
           it can be useful when debugging filters

       $f -> add_to_completion_list(@words)
       $f -> remove_from_completion_list(@words)
           Permanently add or remove the words in @words to/from rlwrap's completion list.

       $f -> cloak_and_dagger($question, $prompt, $timeout);
           Send $question to command's input and read back everything that comes back until
           $prompt is seen at "end-of-chunk", or no new chunks arrive for $timeout seconds,
           whichever comes first.  Return the response (without the final $prompt).  rlwrap
           remains completely unaware of this conversation.

       $f -> cloak_and_dagger_verbose($verbosity)
           If $verbosity evaluates to a true value, make rlwrap print all questions sent to
           command by the "cloak_and_dagger" method, and command's responses. By default,
           $verbosity = 0; setting it to 1 will mess up the screen but greatly facilitate the
           (otherwise rather tricky) use of "cloak_and_dagger"

       $self -> prompt_rejected
           A special text ("_THIS_CANNOT_BE_A_PROMPT_") to be returned by a prompt handler to
           "reject" the prompt. This will make rlwrap skip cooking the prompt.
           $self->previous_tag and $self->cumulative_output will not be touched.

       $text = $f -> prompts_are_never_empty($val)
           If $val evaluates to a true value, automatically reject empty prompts.

       $f -> command_line
           In scalar context: the rlwrapped command and its arguments as a string ("command -v
           blah") in list context: the same as a list ("command", "-v", "blah")

       $f -> running_under_rlwrap
           Whether the filter is run by rlwrap, or directly from the command line

       $f -> run
           Start an event loop that reads rlwrap's messages from the input pipe, calls the
           appropriate handlers and writes the result to the output pipe.  This method never


       rlwrap communicates with a filter through messages consisting of a tag byte (TAG_OUTPUT,
       TAG_PROMPT etc. - to inform the filter of what is being sent), an unsigned 32-bit integer
       containing the length of the message, the message text and an extra newline. For every
       message sent, rlwrap expects, and waits for an answer message with the same tag. Sending
       back a different (in-band) tag is an error and instantly kills rlwrap, though filters may
       precede their answer message with "out-of-band" messages to output text
       (TAG_OUTPUT_OUT_OF_BAND), report errors (TAG_ERROR), and to manipulate the completion word
       are not serviced by rlwrap until right after it has sent the next in-band message - the
       communication with the filter is synchronous and driven by rlwrap.

       Messages are received and sent via two pipes. STDIN, STDOUT and STDERR are still connected
       to the user's terminal, and you can read and write them directly, though this may mess up
       the screen and confuse the user unless you are careful. A filter can even communicate with
       the rlwrapped command behind rlwrap's back (cf the cloak_and_dagger() method)

       The protocol uses the following tags (tags > 128 are out-of-band)

        TAG_INPUT       0
        TAG_OUTPUT      1
        TAG_HISTORY     2
        TAG_PROMPT      4

        TAG_IGNORE                      251
        TAG_OUTPUT_OUT_OF_BAND          254
        TAG_ERROR                       255

       To see how this works, you can eavesdrop on the protocol using the 'logger' filter.

       The constants TAG_INPUT, ... are exported by the module.


       As STDIN is still connected to the users teminal, one might expect the filter to receive
       SIGINT, SIGTERM, SIGTSTP directly from the terminal driver if the user presses CTRL-C,
       CTRL-Z etc Normally, we don't want this - it would confuse rlwrap, and the user (who
       thinks she is talking straight to the rlwapped command) probably meant those signals to be
       sent to the command itself. For this reason the filter starts with all signals blocked.

       Filters that interact with the users terminal (e.g. to run a pager) should unblock signals
       like SIGTERM, SIGWINCH.


       The filter is started by rlwrap after command, and stays alive as long as rlwrap runs.
       Filter methods are immediately usable. When command exits, the filter stays around for a
       little longer in order to process command's last words. As calling the cwd and
       cloak_and_dagger methods at that time will make the filter die with an error, it may be
       advisable to wrap those calls in eval{}

       If a filter calls die() it will send an (out-of-band) TAG_ERROR message to rlwrap before
       exiting. rlwrap will then report the message and exit (just after its next in-band message
       - out-of-band messages are not always processed immediately)

       die() within an eval() sets $@ as usual.


       Before calling a filter, rlwrap sets the following environment variables:

           RLWRAP_FILTERDIR      directory where and most filters live (set by B<rlwrap>, can be
                                 overridden by the user before calling rlwrap)

           PATH                  rlwrap automatically adds $RLWRAP_FILTERDIR to the front of filter's PATH

           RLWRAP_VERSION        rlwrap version (e.g. "0.35")

           RLWRAP_COMMAND_PID    process ID of the rlwrapped command

           RLWRAP_COMMAND_LINE   command line of the rlwrapped command

           RLWRAP_IMPATIENT      whether rlwrap is in "impatient mode" (cf B<rlwrap (1)>). In impatient mode,
                                 the candidate prompt is filtered through the output handler (and displayed before
                                 being overwritten by the cooked prompt).

           RLWRAP_INPUT_PIPE_FD  File descriptor of input pipe. For internal use only

           RLWRAP_OUTPUT_PIPE_FD File descriptor of output pipe. For internal use only

           RLWRAP_MASTER_PTY_FD File descriptor of I<command>'s pty.


       While makes it easy to write simple filters, debugging them can be a
       problem. A couple of useful tricks:

       When running a filter, the in- and outgoing messages can be logged by the logger filter,
       using a pipeline:

         rlwrap -z 'pipeline logger incoming : my_filter : logger outgoing' command

       When called by rlwrap, filters get their input from $RLWRAP_INPUT_PIPE_FD and write their
       output to $RLWRAP_OUTPUT_PIPE_FD, and expect and write messages consisting of a tag byte,
       a 32-bit length and the message proper. This is not terribly useful when running a filter
       directly from the command line (outside rlwrap), even if we set the RLWRAP_*_FD ourselves.

       Therfore, when run directly from the command line, a filter expects input messages on its
       standard input of the form

       TAG_PROMPT >

       (i.a. a tag name, one space and a message) and it will respond in the same way on its
       standard output


       rlwrap (1), readline (3)