[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
Re: Multiline editing breaks if the previous output doesn't end in newline, Oğuz, 2022/10/30
Re: Multiline editing breaks if the previous output doesn't end in newline, Chet Ramey, 2022/10/31