hanslub42 / rlwrap Goto Github PK

When both master and slave pty are unfit for sensing slave commands terminal settings, rlwrap should issue a warning (Readline mode will always be on (as if -a option was set)) but then not fail trying to use fd=-1

The comment above mybasename() and mydirname() in string_utils.h reads:

mybasename and mydirname: wrappers around basename and dirname,
if available, otherwise emulations of them

but it's a lie: they don't use basename and dirname even if those are available (HAVE_BASENAME)

configure has a few handwritten tests that run a script or ad-hoc program to determine capabilities of the host (mostly around the /proc filesystem)

When cross-compiling, all of this makes no sense.

Todo:

• issue a warning when cross-compiling
• offer configuration options to override (/compensate for the absence of) those tests.

If two or more filenames are similar and contain a dash (e.g. abc-123.log and abc-124.log), completion stops at the first character that differs. When "tab" is hit again, instead of the expected options, all possible filenames are presented.

If a directory contains a dash, no files in the directory are presented on subsequent tabbings.

This is all true for spaces in filenames as well, but I imagine that's a more intractable issue, given that whitespace delineates completion strings.

PS Thanks for rlwrap! I'm loving it in combination with ed.

rlwrap senses command's terminal settings whenever select() returns. However, when slave changes ISIG or VINTR (and maybe other flags...?) select() will not return, and rlwrap remains ignorant of the fact.

Most flags (like ICANON, ECHO) can be taken care of after the select() returns, but not the interrupt key: when we press that the terminal driver will issue a signal before rlwrap can investigate whether that should have happened

Case in point: node clears ISIG after startup, in order to use CTRL-C to interrupt an ongoing eval. rlwrap will not yet have noticed the fact and sends a SIGINT. Thus transparency is broken

Solution: add a --poll (-W) option to always call select() with a small timeout, and then adapt stdin's ISIG and VINTR

I got the following question

I'm using rlwrap to get command-line history for an interactive application, but there doesn't seem to be a way to start rlwrap and also pipe input to the application without the application exiting.

I want the application to stay in an interactive mode, where I can keep typing commands to it.

Is it possible to add to rlwrap a command similar to the -P (which loads pre-given input) but which reads an entire file and enters it in the interactive application?

It is possible to use cat like this:

rlwrap sh -c 'cat  input_file /dev/stdin | command'

.. but this will not work well whenever command asks for single keypresses

It would not be difficult to add an rlwrap option --read-first. (note that this is not analogous to the --pre-given option, as we don't want to edit what is read by --read-first)

Say I do this:

echo SELECT > ~/.rlwrap/sqlite3_completions
rlwrap -a -i sqlite3
select‸<TAB>
select‸
selec‸<TAB>
SELECT ‸

Is it possible to have completions for complete words as well?

I see this while configuring on HP-UX where I have cc only.

Will rlwrap find command's working directory under /proc/<commands pid>/cwd? let's see...
checking for /proc/15814/cwd/configure.ac... no
checking whether we can find command line under <opt_proc_mountpoint>/<pid>/cmdline and mirror it by overwriting our own *argv... ./configure[6683]: gcc:  not found.
kill: 17374: The specified process does not exist.
no

Since configure already checks for the compiler type maybe this could be reused here not to invoke GCC.

See this question on Stack Overflow

Ubuntu's sudo preserves the value of $HOME. After a sudo rlwrap xxx xxxs history file will be owned by root, so that a subsequent invocation of rlwrap as the original user will fail with rlwrap: cannot read and write /home/user/.xxx_history: Permission denied

My first reaction would be that this is a screw-up by Ubuntu. But how do other programs avoid the problem (if at all)?

Note: the preserving of $HOME is the default under Ubuntu (they apply a special patch to sudo) but can be specified in /etc/sudoers on any system. Hence, it is not 100% fair to call this an Ubuntu problem. But I do feel that any user that messes with env_keep in /etc/sudoers can be expected to know what she is doing, while unsuspecting Ubuntu users likely will be flummoxed by this error.

In the meantime, the problem can be avoided by adding the user name to the history file name:

    rlwrap --history-filename=$HOME/.${USER}_command_history command

The manpage is telling lies:

-o, --one-shot
       Send an EOF to command after accepting the first line of input

.... but rlwrap doesn't send an EOF at all, it just quits when, at "cooking time" (by default, 40 ms after accepting the input) exactly one line has been read. So when you manage to input two, it will run on as if no --one-shot had been specified

As a temporary stopgap, one can specify --wait-before-prompt=1 to minimize the chance that more than one line is entered, or more reliably, use

rlwrap head -n 1
rlwrap sh -c 'head -n 1 | command'

(Thanks to Tobias D. Oestreicher who reported this bug)

The GNU history library (used by rlwrap) has extensive support for bash-style history expansion. rlwrap has only a homegrown simple version of it, where !word at the beginning of an input line expands to the last command that started with word.

Should rlwrap switch to the more fancy version?

• Pro: simple to implement, much more versatile and powerful than the current expansion.
• Contra: a lot more intrusive. We certainly need an option (or environment variable) to switch it off.

bash users can set options HISTIGNORE and HISTCONTROL to specify when a command should not be put in the history list. rlwrap has options --forget-matching and --history-no-dupes that do the same thing, but in a slightly more complicated way.

For example, a bash user can specify HISTCONTROL=ignoredups:ignorespace, where rlwrap needs options --forget-matching='^ ' --history-no-dupes=1 to achieve the same.

As the machinery for ignoring duplicates and forgetting input is already there, it should not be too difficult to make rlwrap consult the environment (into which the bash options then have to be exported, of course) to mimic the desired bash behaviour.

zsh users (like myself) can just set the environment variables as in bash, even if zsh uses a different set of options

All this is minimally intrusive: those who don't want this can just refrain from exporting the options into the environment.

This is relevant with the issue #47.
I have used peco for history expansion on bash for the last years. Adding the following code in my .bashrc, my ctrl-r invokes peco:

_complete_history() {
    local l=$(HISTTIMEFORMAT= history | tac | sed -e 's/^\s*[0-9]*  //' | peco --query "$READLINE_LINE")
    if [ "${l}x" != "x" ]; then
        READLINE_LINE="$l"
        READLINE_POINT=${#l}
    fi
}
bind -x '"\C-r": _complete_history'

If the rlwrap has the feature like the bind command of bash to bind a key sequence to a macro, it augments the rlwrap's history expansion feature and gives the rlwrap more flexibility.

the code for feed_file_into_completion_list() assumes that fgets() sets errno. Most implementations actually comply with this assumption, but no standard requires fgets() to do anything with errno. The "file not found" is a stale errno, the result of a (harmless) failed syscall a bit earlier

With many C libraries the bug will not manifest itself; it has been there for a very long time (probably since version 0.23).

Remedy: use feof() and ferror() instead of inspecting errno

RlwrapFilter.pm is a great feature. However, if there is a python version, it would make us happier. I wrote a prototype and its application:-
https://github.com/hokuda/rlwrapfilter.py
https://github.com/hokuda/rljdb
I think I could prove a python version is feasible. Hope you will have a genuine RlwrapFilter in python.

on SunOS 5.10 Generic_144488-11 sun4u sparc SUNW,SPARC-Enterprise:

bash-3.00$ rlwrap perl
Warning: rlwrap cannot determine terminal mode of perl
(because: Invalid argument).

NB: rlwrap 0.37 used to sleep for 1 sec before calling tcgetattr() on the slave pty
Maybe this was a good idea after all ....?

Apparently, ee17ef2 makes rlwrap require a newer readline than it used to:

readline.c:689: error: ‘rl_executing_keyseq’ undeclared (first use in this function)

Until 6.3 (and on RedHat, even with 6.3) readline didn't export a variable rl_executing_keyseq

Is it reasonable to require readline >= 6.3? Is there an alternative that would work with multi-byte hotkeys (or are those impossible in readline<6.3 anyway)

Some programs use one or more keys to interrupt an ongoing computation or even an ongoing edit.

In many cases this is done by manipulating its special character VINTR so that this key generates a SIGINT. This is e.g. what emacs does, and rlwraps transparency takes care of that: as soon as rlwrap notices that VINTR has changed, (which may be a bit too late) it will do the same with its own VINTR, so that the same key generates the same signal, which is then passed on to the rlwrapped command.

But some programs, like Erlangs erl shell, catch the keypress directly, even while the user is editing a command line (in this case a CTRL-G to prompt for a "user switch command"), without using a signal.

If we rlwrap -a such a program, nothing will happen when we press CTRL-G .

We need a way to make rlwrap pass those keypresses directly to the rlwrapped program, without disrupting the ongoing line edit (although the program may decide that the keypress indeed interrupts the line edit (as erl does) this is not in general what we want)

Since time immemorial, rlwrap understands a single dot after -f (--file) to mean: use the current history file as source for completions

Is this a good idea? If so, mention it in the manpage. If not, remove.

Sometimes (if rarely) rlwrap needs to position the cursor someplace on the line (usually at rl_point)

Currently it uses terminfo/termcap capability cursos_hpos, and just gives up when that is unavailable (as it is under xterm).

This causes errors like:

Assertion failed: term_cursor_hpos != NULL, file term.c, line 212

when e.g. calling rlwrap-edit-history

But most terminals do have carriage_return and cursor_right, so why not use those whenever cursor_hpos is unavailable?

Long standing bug (at least back to 0.28).

Try

$ sleep 5; rlwrap -P 'I knew that!' cat

If you enter a line before the sleep is finished, that line will be accepted, not the pre-given input. This means that pressing ENTER because you already know what is coming and want to accept that will accept an empty line, which is not what you want.

Remedy (?): move the assignment of the pre-given input to the input_buffer out of the cooking logic and into the main loop.

rlwrap --no-children uses /proc/<slave_pid>/wchan to decide whether slave is waiting for one of its children.

This has always been a linux-only feature. However, newer linux kernels don't have wchan anymore (and rather use status)

gcc 4.9 (but, strangely, not 4.8, even with -pedantic) fails with

utils.c:758:6: error: argument 'command_pid' doesn't match prototype 
void mirror_args(command_pid) {
     ^

With a negative history size rlwrap opens the history file read-only. As rlwrap looks at the numeric value of the --history-size (or -s) argument, not at the presence of a minus sign,

rlwrap --history-size -0 <command>

is not a good way to say "don't use the history file, and leave it alone". On the contrary, it will do the same as rlwrap -s 0, and completely truncate the history.

It is still possible to achieve the same with rlwrap -H /dev/null. So:

• should we leave the behaviour as it is, and only put a warning in the manual?
• or shoud rlwrap test for the presence of a minus sign in, instead of the numeric value of, the -s argument

After rm ~/.rlwrap/cat_history a rlwrap -s -10 cat will fail with

 rlwrap: error: cannot read /home/hlub/.rlwrap/cat_history: No such file or directory

It tries to open the history file readonly instead of read+write, and fails. It should ignore this error, of course.

The listing filter is special in that it rlwrap -z listing should not give the help text for listing, but a listing of filters in $RLWRAP_FILTERDIR

This has stopped working somewhere between releases 0.37 and 0.41

The command bluetoothctl prints rubbish at exit, followed by cr el (carriage return - erase line)

the unbackspace routine chokes on this - maybe rlwrap should recognise el, or not cook final output (when it is aware of command death - this awareness might come too late, however)

In contrast to the way completion is done in bash, mksh, python, and other REPLs, rlwrap completion does not consider words that are already fully entered on the input line. IMHO this should be fixed to provide a similar experience to other shells and REPLs based on readline.

By way of example,

$ cat complist
a
ab
abc
abcd
$ rlwrap -f complist cat
a<Tab>
ab<Tab>
abc<Tab>
abcd 

Each press of Tab adds another character to jump to the next possible completion. Other readline-based environments would normally block on the initial a because it is a valid completion word in and of itself.

I originally reported this as Debian bug #648264.

The cooked prompt will grow into a monster like

Time left: 3000 s <CR>Time left: 2999 s<CR>....

The function copy_and_unbackspace() in string_utils.c is meant to handle this, but is currently #ifdefed into oblivion, and doesn't seem to be used anyway :-(

I got this error:

rlwrap: error: Couldn't read completions from /usr/local/Cellar/rlwrap/0.41/share/rlwrap/completions/coqtop: No such file or directory

But the file /usr/local/Cellar/rlwrap/0.41/share/rlwrap/completions/coqtop exists.

I installed rlwrap with homebrew, and both /usr/local/bin/coqtop and /Applications/CoqIdE_8.4pl4.app/Contents/Resources/bin/coqtop won't work.

RlwrapFilter.pm uses a humongous regexp to chop off the prompt from $self->{cumulative_output}
This regexp is wrong, is will chop off the last line even if there is no prompt (i.e. when the cumulative_output ends in a newline)

Eric Pruitt wrote:

I was wondering if there was a way to make rlwrap either A: stop the wrapped command from writing to stdout when the user is type or B: make rlwrap clear the prompt before allowing the subprocess to write to stdout. I am using rlwrap with an IRC client, and if someone sends a message while I'm typing, my prompt gets mangled, so I was wondering if there was an option that would help with that problem. I read the man page section "DIRECT MODE AND READLINE MODE," but unless I'm overlooking something, I don't believe that addresses this situation

At present, rlwrap considers any output that doesn't end in a newline a prompt. If such a 'prompt' arrives while you are typing it will be appended to the current prompt before the cursor, which is messy.

This is the most general solution, but for many commands a prompt can be recognised as such because it fits a certain pattern (e.g. it ends in a '>' or a '$'). Specifying e.g --only-cook '>\s?$' prevents rlwrap from cooking (e.g. colouring) anything else.

I could extend the effect of this option (or add a new option), making rlwrap reprint the original prompt (on a new line) below any output that doesn't fit the given regexp, even if this output doesn't end in a newlne.

If more output arrives, rlwrap should go back to the line above the prompt, append the new output, and reprint the prompt (except when this fits the regexp, in which case rlwrap should behave as it does now)

This (Eric's solution 'B') is a bit tricky, but probably doable.

An alternative (or additional) solution would be to extend the filter mechanism (which already can send back messages _THIS_IS_NOT_A_PROMPT_)

Solution 'A' -don't print any of the slave command's output between starting the line editor and accepting the resulting input - is less attractive to me: the user would miss out on important information, like error messages.

As soon as rlwrap uses a filter, all input, output, prompts, history, etc are packed into tagged messages (TAG_OUTPUT, 1024, "blah ...") and then passed through the filter. Most filters are interested in only one or two message types, and will send back the other message types unchanged, which is a waste of processor time.

Proposal: Introduce an in-band TAG_NOT_INTERESTED. Instead of an unchanged message, the filter can also send back (TAG_NOT_INTERESTED, 0,"")

This is undesirable in a pipeline, where a downstream filter may be interested in a message that didn't interest an upstream filter. Hence, there should be a way to fall back to the old behaviour.

An easy way to do that is to make the pipeline filter set an envirionment variable ALWAYS_INTERESTED that causes uninterested filters to always pass on the complete original message.

My console following a reading of INSTALL:

$ ./configure
-bash: ./configure: No such file or directory
$ ls
AUTHORS  ChangeLog    configure.ac  doc      INSTALL      NEWS  README  test
BUGS     completions  COPYING       filters  Makefile.am  PLEA  src     TODO
$ autoconf
configure.ac:34: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:39: error: possibly undefined macro: AM_SANITY_CHECK
$ ./configure
configure: error: cannot find install-sh, install.sh, or shtool in tools "."/tools
$

Sometimes it would come in handy to be able to purge an item from the history list, or be able to search the entire history list in an editor.

This should be an easy addition, as most of the infrastructure is already there

reproduce by

rlwrap node
... press CTRL-C

[hlub@karpaten] .../elmo/rlwrap-0.40 > src/rlwrap node
> rlwrap: read error on master pty: Input/output error

The compiler warns me about:

cc -DHAVE_CONFIG_H -I. -I..   -I/usr/local/include -DDATADIR=\"/usr/local/share\                                                                     "  -g -c -o completion.o completion.c
"completion.rb", line 25: warning #2161-D: unrecognized #pragma
  #pragma GCC diagnostic ignored "-Wunused-but-set-variable"
          ^

"completion.rb", line 26: warning #2161-D: unrecognized #pragma
  #pragma GCC diagnostic ignored "-Wunused-function"
          ^

"completion.rb", line 104: warning #2177-D: function "print_list" was declared
          but never referenced
  print_list()
  ^

"completion.rb", line 115: warning #2177-D: function "rbtree_to_string" was
          declared but never referenced
  static char *rbtree_to_string(const struct rbtree *rb, int max_items) {
               ^

source='term.c' object='term.o' libtool=no \
DEPDIR=.deps depmode=hp2 /bin/sh ../tools/depcomp \
cc -DHAVE_CONFIG_H -I. -I..   -I/usr/local/include -DDATADIR=\"/usr/local/share\                                                                     "  -g -c -o term.o term.c
source='ptytty.c' object='ptytty.o' libtool=no \
DEPDIR=.deps depmode=hp2 /bin/sh ../tools/depcomp \
cc -DHAVE_CONFIG_H -I. -I..   -I/usr/local/include -DDATADIR=\"/usr/local/share\                                                                     "  -g -c -o ptytty.o ptytty.c
source='utils.c' object='utils.o' libtool=no \
DEPDIR=.deps depmode=hp2 /bin/sh ../tools/depcomp \
cc -DHAVE_CONFIG_H -I. -I..   -I/usr/local/include -DDATADIR=\"/usr/local/share\                                                                     "  -g -c -o utils.o utils.c
"utils.c", line 513: warning #2047-D: incompatible redefinition of macro
          "isset" (declared at line 411 of "/usr/include/sys/param.h")
  #define isset(flag) ((flag) ? "set" : "unset")
          ^

"utils.c", line 758: warning #3051-D: standard requires that parameter
          "command_pid" be given a type by a subsequent declaration ("int"
          assumed)
  void mirror_args(command_pid) {
                   ^

"utils.c", line 598: warning #2177-D: function "print_debug_flag" was declared
          but never referenced
  print_debug_flag(int flag, char *explanation) {
  ^

Compilations completes though. I am on:

$ uname -a
HP-UX <hostname> B.11.31 U ia64 HP-UX

rlwrap is a typical old-fashioned Unix program that (without RLWRAP_HOME set) peppers the users home directory with dotfiles like .a.out_history. It expects completion word lists in either $HOME or /usr/local/share/rlwrap/completions.

TODO:

• add a configuration-option --use-xdg-basedir and, if this is specified, use e.g. $XDG_DATA_HOME to store history files if RLWRAP_HOME is unset

Hello!

I'd like rlwrap to have an option --retain to retain the last typed command. It should work like prompt, except it should be editable by the user.

Inputting a command and then pressing enter again n times would cause the same command to be sent n+1 times in total.

Ideally, starting typing would erase whatever's in the previous input buf without needing any backspacing / ctrl-u.

Tested with rlwrap 0.37 and gnuplot 4.6 patchlevel 4 on Ubuntu 14.04.3.

Seems like there needs to be at least two files with a common prefix and a hyphen in a directory for this to occur.

To reproduce the problem first set up some test files:

$ mkdir test
$ cd test
$ touch test-a.txt test-b.txt

Now try file completion with rlwrap:

$ rlwrap -a -c gnuplot
gnuplot> t[TAB]
gnuplot> test-[TAB]
gnuplot> test-test-[TAB]
gnuplot> test-test-test-[TAB]

Let's rewind and try:

gnuplot> test-a[TAB]

Nothing happens.

But it all works fine with gnuplot's built-in readline support:

gnuplot> t[TAB]
gnuplot> test-[TAB]
test-a.txt test-b.txt
gnuplot> test-a[TAB]
gnuplot> test-a.txt 

If there are other files, something else happens, so add one:

$ touch not-a-test.txt

This is what happens with rlwrap:

gnuplot> t[TAB]
gnuplot> test-[TAB]
not-a-test.txt  test-a.txt      test-b.txt      
gnuplot> test-a[TAB]

Then nothing happens after pressing [TAB], no matter how many more characters of the filename I type myself.

Again, this is how it should look like and how it works in gnuplot:

gnuplot> t[TAB]
gnuplot> test-[TAB]
test-a.txt test-b.txt
gnuplot> test-a[TAB]
gnuplot> test-a.txt 

Some commands (like Sybase isql) change their argument list after startup, e.g. to hide a password that was given on the command line.

When running such a program under rlwrap, the original arguments will be plainly visible for all users.

rlwrap should inspect the slave command's argument list periodically and adapt its argv[] if necessary or at least warn about this issue in the manpage

Okay am I high or something or is the .configure script completely missing from this repository? Cloned it and proceeded to install when I realized it was absent.

Regards

$ rlwrap -z test_environment cat

where test_environment is

#!/usr/bin/env perl
die "$ENV{RLWRAP_COMMAND_LINE}\n";

will print rlwrap where one would expect cat

This may be a regression, as it should have been fixed as per #19

eshell runs commands under a terminal (pty) with winsize.ws_col (width) == 0
At present, rlwrap bails out in such a case. Shouldn't it get out of the way and just exec the slave command ?

Hi,

I'm trying to make rlwrap work with matlab on MacOS, here is the command I type :

$ rlwrap -c -m " \ " -H "$MATLAB/history.m" matlab -nodesktop -nosplash

Alt+left, Alt+right, Esc+Backspace,Ctrl+D and Ctrl+R keyboard shortcuts don't work, can you help me ?

Hello:
I have a command (kdb+ q, close sourced )that is not able to handle SIGWINCH, is it possible for rlwrap to send a string to it when caught SIGWINCH?

Thanks in advance.

This was first reported as Bug #799943 on debian-bugs

To reproduce:

$ rlwrap cat

then issue CTRL+X, ( to start recording a macro. Enter
two or more lines of text and stop recording with CTRL+X, ).

When attempting to play back the macro with CTRL+X, e,
rlwrap crashes with a SIGSEGV

Shorter macros (one line or less) work OK.