4

Normally, bash command-lines wrap - which I am used to and works great:

[cnd@MacBook-Pro ~]$ echo abcdefgABCDEFGhijklmnopHIJKLMNOPq
rsQRStuvTuvWXYZ

(I made my window narrow to demonstrate)

However - the default CentOS8 shell no longer does this. Instead, it truncates most of the start of your typing (once you get to within 3 characters of the end of the terminal width), replacing it with a ">", and you can no longer see what you typed.

[cnd@hpz ~]$ 
<EFGhijklmnopHIJKLMNOPqrsQRStuvTuvWXYZ

(actual copy/paste from the shell window)

What is the correct way to disable that infuriating behaviour? I need to see my whole command (I type a lot of long perl one-liners - it is important to check before running!)

I've tried assorted things, like using vt100 or xterm for the terminal, some "set" commands and other exports, but so far I can't guess it, and google doesn't seem to have any answers (polluted with irrelevant questions about output wrapping, unwanted scrolling, ansi escape prompt escaping, etc)

Improve this question

1 Answer 1

Reset to default
3

This is the behaviour of the GNU Readline line input editing library, and manifests itself in any program that uses Readline, not just the Bourne Again shell.

If the record for the terminal (denoted by the TERM environment variable) in the termcap/terminfo database does not give a terminal capability for moving the cursor upwards, Readline falls back from multiple-line mode to single-line mode with sideways scrolling (in the fashion of the Korn shell, which uses its own line editing library).

True to form, the only doco for this is a comment buried in the source code for the library.

You can also force it to fall back to single-line mode by setting Readline's horizontal-scroll-mode variable to on. You cannot force it to use multiple-line mode, however, except by providing a fully-functional termcap/terminfo record.

Ironically, terminals and terminal emulators for which this fallback was important were rare even 35 years ago. Line printers and dumb terminals weren't suitable for line input editing of this form in the first place. And pretty much every contemporary video terminal had a control sequence for moving the cursor upwards.

A more sensible approach for the 21st century would be to default to the ECMA-48 standard, that has been around since 1976 and widely supported from the middle 1980s onwards, and make dumb (effectively TTY-37 from 1968, c.f. glasstty, vanilla, and tty37) the exception rather than the default. This would recognize that nowadays one is almost never going to encounter even a real TTY-37 let alone a terminal that can do enough for input line editing but yet lacks a cursor up control sequence.

This has not been done with GNU Readline.

Further reading

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .