Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

9term: pasted buffer does not show when reading stdin #55

Closed
camoles opened this issue Apr 4, 2016 · 9 comments
Closed

9term: pasted buffer does not show when reading stdin #55

camoles opened this issue Apr 4, 2016 · 9 comments

Comments

@camoles
Copy link

camoles commented Apr 4, 2016

If you paste something on a 9term while a program is reading STDIN, the value will be pasted but won't be shown on the terminal. The bug does not happen if something was previously typed manually before pasting.

How to reproduce:

  • open 9term
  • type the cat command and ENTER
  • copy any text to the clipboard
  • paste to 9term

The text won't show on the terminal. But it is there, and if you press ENTER cat will echo it. Also, if you type anything after you started the program reading STDIN but before pasting, then the pasted text will show normally.

Tested on openbsd 5.9, under both fvwm, rio and dwm window managers. Using ksh shell.

@eekee
Copy link

eekee commented Apr 4, 2016

not seen on linux 3.2.29, x.org 1.12.3, twm.

@i4ki
Copy link

i4ki commented Apr 4, 2016

Reproducible here using 9term, bash and rio. I don't know if the same happens with rc.

Linux 4.3.3 (x86_64)

@camoles
Copy link
Author

camoles commented Apr 4, 2016

On openbsd, the bug does not happen if using the rc shell

@eekee
Copy link

eekee commented Apr 4, 2016

ah. :) yes i have seen this before. bash, ksh, and i imagine most other shells put the terminal into raw mode. you'll want to select 'cook' from the mb2 menu to get them to play nice. or, the shells themselves may have some option, or there may be some suitable setting for $TERM.

edit: i posted without thinking. i'm not sure why you all have problems. if i start 9term ksh -l then it works for me and so does cat; no hidden typing. ditto for 9term bash -l. then again i am running quite old versions of everything. my ksh is 'Version JM 93t+ 2010-06-21' from 2010, bash is 4.2.37 from 2011, p9p from april. my isp is restricting http at present, otherwise i'd upgrade p9p & try again.

@camoles
Copy link
Author

camoles commented Apr 5, 2016

Indeed, if I select the "cook" mode the problem goes away. Also, $TERM is set to 'dumb' by default under 9term. If I set it to say, vt100, the problem also goes away. But I am pretty sure having the apps believe they are running under vt100 when we are under 9term is not the best idea.

Any suggestion about some suitable $TERM value so that I don't have to select "cook" every time?

@camoles
Copy link
Author

camoles commented Apr 5, 2016

hmm, interestingly there is the "9term" option under the possible $TERM values. But still, it does not make the bug here related go away. Although it seem to fix some things. For example, if I open "top" under 9term with $TERM set to "dumb", the terminal just closes. Whereas if I set $TERM to "9term", it presents an correct output.

@camoles
Copy link
Author

camoles commented Apr 5, 2016

It looks like this behaviour is documented on 9term man page:

      9term changes behavior according to the terminal settings of
      the running programs.  Most programs run with echo enabled.
      In this mode, 9term displays and allows editing of the
      input.  Some programs, typically those reading passwords,
      run with echo disabled.  In this mode, 9term passes keys-
      trokes through directly, without echoing them or buffering
      until a newline character.  These heuristics work well in
      many cases, but there are a few common ones where they fall
      short.  First, programs using the GNU readline library typi-
      cally disable terminal echo and perform echoing themselves.
      The most common example is the shell bash(1). Disabling the
      use of readline with ``set +o emacs'' [sic] usually restores
      the desired behavior.  Second, remote terminal programs such
      as ssh(1) typically run with echo disabled, relying on the
      remote system to echo characters as desired.  Plan 9's ssh
      has a -C flag to disable this, leaving the terminal in
      ``cooked'' mode.  For similar situations on Unix, 9term's
      button 2 menu has an entry to toggle the forced use of
      cooked mode, despite the terminal settings.  In such cases,
      it is useful to run ``stty -echo'' on the remote system to
      avoid seeing your input twice.

set +o emacs #fixed the problem here

@camoles camoles closed this as completed Apr 5, 2016
@camoles
Copy link
Author

camoles commented Apr 5, 2016

Since I didn't find a way to automate "set +o emacs" (putting it on my .profile wasn't enough), I ended up setting SHELL=rc on my .profile so that 9term uses the rc shell instead of ksh.

@eekee
Copy link

eekee commented Apr 5, 2016

i always use it with rc. i set $SHELL in my 9 script, and i always start 9term with 9.

i'm generally happy with chording cut/paste rather than using history, and i prefer rc's syntax for lots of things. i make functions for oft-repeated commands. you may however wish to ln -s .profile .bashrc, or find some other hack to always source .profile or to initialize non-login shells.

rsc added a commit that referenced this issue May 8, 2020
C11 is apparently too new for these systems.

Fixes #55.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants