bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multiline editing breaks if the previous output doesn't end in newli


From: Martin D Kealey
Subject: Re: Multiline editing breaks if the previous output doesn't end in newline
Date: Sun, 30 Oct 2022 16:53:50 +1000

This sounds like a bug in whatever is producing the output. POSIX text
files have a newline terminating every line; that description includes
streams going through pipes and tty devices if they purport to be text.

It's fairly simple to fix this by adding this to the end of your .bashrc
(or the system /etc/bashrc):

 PS1='\[\e[1;7;31m\e[K<<<<<<\e[$((COLUMNS-8))C<<\r\e[m\e[2K\]'"$PS1"

or you might prefer this version:

 _MissingEOL='<<< missing EOL ' # your choice of text here
 for (( t = COLUMNS<250 ? 1000 : COLUMNS*4; ${#_MissingEOL} < t ;)) do
_MissingEOL=$_MissingEOL$_MissingEOL ; done
 PS1='\[\e[1;7;31m${_MissingEOL:0:COLUMNS}\r\e[m\e[2K\]'"$PS1"

These will mark an incomplete line with a red chevron to highlight the
erroneous output, and move the cursor to the correct position on the next
line. If this makes copying and pasting just slightly awkward, that would
prompt me to fix the broken program, or to remember to add «; echo» when
running it.

(You might want to make this contingent on TERM being a known
ANSI-compatible terminal type, or verifying the output of tput.)

Sadly, there is an increasing number of common new utilities that don't
honour the POSIX requirements for a text stream, such as 'jq' in its
"brief" mode; if you come across these, please file bug reports on them. If
the maintainers push back, please point them at the POSIX standard.

-Martin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]