Re: Multiline editing breaks if the previous output doesn't end in newline
On Mon, Oct 31, 2022 at 2:47 AM Greg Wooledge wrote: > > There's no 100% portable way to determine where the cursor is. On Mon, Oct 31, 2022 at 4:45 PM Chet Ramey wrote: > > There is no portable way to determine this. If only computers were general purpose programmable devices... :) Koichi's PROMPT_COMMAND hack works well enough, so I will stick with that for now.
Re: Multiline editing breaks if the previous output doesn't end in newline
where the cursor is ? some tput ansi code returns it .. but i guess u mean bigger compatibility problems does, readline, export its cursor assumptations ? like for dev'ing On Mon, Oct 31, 2022, 16:46 Chet Ramey wrote: > On 10/30/22 9:40 PM, Oğuz wrote: > > > Yeah, or add a new prompt sequence (e.g. \N) that prints a newline only > if > > the cursor is not at column 0. > > There is no portable way to determine this. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > > >
Re: Multiline editing breaks if the previous output doesn't end in newline
On 10/30/22 9:40 PM, Oğuz wrote: Yeah, or add a new prompt sequence (e.g. \N) that prints a newline only if the cursor is not at column 0. There is no portable way to determine this. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Multiline editing breaks if the previous output doesn't end in newline
On 10/28/22 8:21 AM, Albert Vaca Cintora wrote: Machine: All archs OS: All OSes Bash Version: All versions since I have memory Description: When there's leftover output before the prompt (ie: when the previous command output doesn't end in a new line), editing a multi-line command from history doesn't correctly display what you edit. As I'm sure you'll hear again, readline assumes that it knows where the physical cursor is on the line, and to assure this assumes it starts with the cursor in column 0. The redisplay code assumes this. There is no portable way for readline to determine the physical cursor location, so it has to make assumptions. There are various imperfect workarounds, but the easiest one is to hit return. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Multiline editing breaks if the previous output doesn't end in newline
31 Ekim 2022 Pazartesi tarihinde Greg Wooledge yazdı: > > There's no 100% portable way to determine where the cursor is. Pity > Shells like zsh that show a special symbol in these cases use a hack > to do so. There's a good explanation in this answer: > > https://unix.stackexchange.com/questions/167582/why-zsh- > ends-a-line-with-a-highlighted-percent-symbol#answer-302710 > Thanks for the link. The hack is clever but the result is ugly. I'd much prefer the current behavior of bash. -- Oğuz
Re: Multiline editing breaks if the previous output doesn't end in newline
On Mon, Oct 31, 2022 at 03:40:34AM +0200, Oğuz wrote: > > Option B: Fix the line editor to take into account when the > > prompt doesn't start at column 0. > > > > > Yeah, or add a new prompt sequence (e.g. \N) that prints a newline only if > the cursor is not at column 0. There's no 100% portable way to determine where the cursor is. Shells like zsh that show a special symbol in these cases use a hack to do so. There's a good explanation in this answer: https://unix.stackexchange.com/questions/167582/why-zsh-ends-a-line-with-a-highlighted-percent-symbol#answer-302710
Re: Multiline editing breaks if the previous output doesn't end in newline
28 Ekim 2022 Cuma tarihinde Albert Vaca Cintora yazdı: > > Option A: If the previous command doesn't end in a newline, > add a newline manually. This is what most shells do. This sounds wrong. How are you going to know if the previous command ends in a newline or not then? > Option B: Fix the line editor to take into account when the > prompt doesn't start at column 0. > > Yeah, or add a new prompt sequence (e.g. \N) that prints a newline only if the cursor is not at column 0. -- Oğuz
Re: Multiline editing breaks if the previous output doesn't end in newline
On Sun, Oct 30, 2022, 23:01 Dennis Williamson wrote: > > > On Sun, Oct 30, 2022 at 4:41 PM Alex fxmbsw7 Ratchev > wrote: > >> >> >> i coded a files tree to bash code via gawk reading and printing bash code >> i did noeol no newline at end >> logically , cause , who wants var='from file\n' >> >> > >> > > Because command substitution strips trailing newlines? > no , sir i did simple files-in-dirs to bash-code i cant ( i did ) generate bash via bash , but it was too slow the current uses gawk to generate project bash code in one run with find \0 as input for , to file , or eval , source .. my point with the newlines i came across when processing the files 1:1 , i think it began with mapfile usage but gawk does as well there is to me , not knowing end newline(s) count , only a ( too ) fatal disability it also makes data processing , a pain to me the ansi or whatever newline ending rule is , as i try to say , nothing profitable what i mean in my example is when normally writing a file in vim , it ends with the big time ignored newline say one has vars/foo with content 'bar' my code would produce , along var stacking , foo='bar ' to me , as data cruncher , one to one data preservance is must so i changed vim settings to skip this ending newline there is also another case if use for exactness that is data stacking in sequencial files sometimes \n sometimes not hopes for good , /peace $ echo -e 'foo\n\n\n' > foo > > > > $ s=$(echo -e 'foo\n\n\n') > $ declare -p s > declare -- s="foo" > > No gyrations needed. > -- > Visit serverfault.com to get your system administration questions > answered. >
Re: Multiline editing breaks if the previous output doesn't end in newline
On Sun, Oct 30, 2022 at 4:41 PM Alex fxmbsw7 Ratchev wrote: > > > i coded a files tree to bash code via gawk reading and printing bash code > i did noeol no newline at end > logically , cause , who wants var='from file\n' > > > > Because command substitution strips trailing newlines? $ echo -e 'foo\n\n\n' foo $ s=$(echo -e 'foo\n\n\n') $ declare -p s declare -- s="foo" No gyrations needed. -- Visit serverfault.com to get your system administration questions answered.
Re: Multiline editing breaks if the previous output doesn't end in newline
On Sun, Oct 30, 2022, 21:21 Albert Vaca Cintora wrote: > On Sun, Oct 30, 2022 at 7:54 AM Martin D Kealey > wrote: > > > > 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. > > > > There are many reasons why one could end up with text in a terminal > that doesn't end in a newline. A couple of them are: > - An app is killed in the middle of writing its output (eg: because of > a sigterm/sigkill). > - A file that isn't a POSIX text file is printed to the terminal. > > So I think this should still be handled by bash. > i coded a files tree to bash code via gawk reading and printing bash code i did noeol no newline at end logically , cause , who wants var='from file\n' >
Re: Multiline editing breaks if the previous output doesn't end in newline
On Sun, Oct 30, 2022 at 7:54 AM Martin D Kealey wrote: > > 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. > There are many reasons why one could end up with text in a terminal that doesn't end in a newline. A couple of them are: - An app is killed in the middle of writing its output (eg: because of a sigterm/sigkill). - A file that isn't a POSIX text file is printed to the terminal. So I think this should still be handled by bash.
Re: Multiline editing breaks if the previous output doesn't end in newline
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
> $ printf '%*s\rY' "$COLUMNS" X > | ... X| > |Y | P.S. Here I used `|' to represent the left and right boundaries of the terminal display area.
Re: Multiline editing breaks if the previous output doesn't end in newline
2022年10月29日(土) 15:44 Albert Vaca Cintora :
> On Sat, Oct 29, 2022 at 7:28 AM Koichi Murase wrote:
> > shopt -s checkwinsize
> > { ! type -t tput || tput xenl || tput xn; } &>/dev/null;
> > _prompt_xenl_offset=$?
> > _prompt_newline() { (:); printf '\e[m%-*s\r\e[K'
> > "$((COLUMNS-_prompt_xenl_offset))" '[EOF]'; }
> > PROMPT_COMMAND+=(_prompt_newline)
>
> It would be great if this got fixed in bash itself, but in the
> meantime this workaround will help, thanks :)
>
> I've noted that it creates some artifacts when you resize the terminal
> after a command that ends without a newline, though.
Isn't that the same for zsh and fish?
> Would you mind explaining the code a bit? Eg: why is "(:);" in there,
To make Bash update COLUMNS. The manual (see below) says `external
command', but a subshell () works as well.
>From Bash Reference Manual
:
> checkwinsize
>
> If set, Bash checks the window size after each external (non-builtin)
> command and, if necessary, updates the values of LINES and COLUMNS.
> This option is enabled by default.
> or why do we need $_prompt_xenl_offset ?
Because the behavior depends on the terminal capability
"eat_newline_glitch" ("xenl" in terminfo name / "xn" in termcap name).
In a terminal without "eat_newline_glitch", when there are as many
characters in the line as the columns, the cursor automatically moves
to the next line:
$ printf '%*s\rY' "$COLUMNS" X
| ... X|
|Y |
But in a terminal with "eat_newline_glitch", the cursor stays at the
last column with an intermediate state:
$ printf '%*s\rY' "$COLUMNS" X
|Y ... X|
VT and XTerm behave in the latter way, and the recent terminals
emulate VT/XTerm, but some terminals/consoles behave in the former
way. To support both types of terminals, one needs to adjust the
number of characters in the line. If you only use the VT terminal
emulators, you can just drop the processing related to
"_prompt_xenl_offset" and just write it like
PROMPT_COMMAND+=('(:); printf "\e[m%-${COLUMNS}s\r\e[K" "[EOF]"')
Re: Multiline editing breaks if the previous output doesn't end in newline
On Sat, Oct 29, 2022 at 7:28 AM Koichi Murase wrote:
>
> 2022年10月28日(金) 21:24 Albert Vaca Cintora :
> > Description:
> > When there's leftover output before the prompt (ie: when the
> > previous command output doesn't end in a new line), editing a
> > multi-line command from history doesn't correctly display what you
> > edit.
> >
> > [...]
> > Option A: If the previous command doesn't end in a newline,
> > add a newline manually. This is what most shells do.
>
> This can be configured by yourself. E.g.,
>
> shopt -s checkwinsize
> { ! type -t tput || tput xenl || tput xn; } &>/dev/null;
> _prompt_xenl_offset=$?
> _prompt_newline() { (:); printf '\e[m%-*s\r\e[K'
> "$((COLUMNS-_prompt_xenl_offset))" '[EOF]'; }
> PROMPT_COMMAND+=(_prompt_newline)
It would be great if this got fixed in bash itself, but in the
meantime this workaround will help, thanks :)
I've noted that it creates some artifacts when you resize the terminal
after a command that ends without a newline, though.
Would you mind explaining the code a bit? Eg: why is "(:);" in there,
or why do we need $_prompt_xenl_offset ?
Re: Multiline editing breaks if the previous output doesn't end in newline
2022年10月28日(金) 21:24 Albert Vaca Cintora :
> Description:
> When there's leftover output before the prompt (ie: when the
> previous command output doesn't end in a new line), editing a
> multi-line command from history doesn't correctly display what you
> edit.
>
> [...]
> Option A: If the previous command doesn't end in a newline,
> add a newline manually. This is what most shells do.
This can be configured by yourself. E.g.,
shopt -s checkwinsize
{ ! type -t tput || tput xenl || tput xn; } &>/dev/null; _prompt_xenl_offset=$?
_prompt_newline() { (:); printf '\e[m%-*s\r\e[K'
"$((COLUMNS-_prompt_xenl_offset))" '[EOF]'; }
PROMPT_COMMAND+=(_prompt_newline)
Multiline editing breaks if the previous output doesn't end in newline
Machine: All archs OS: All OSes Bash Version: All versions since I have memory Description: When there's leftover output before the prompt (ie: when the previous command output doesn't end in a new line), editing a multi-line command from history doesn't correctly display what you edit. Repeat-By: - Run a long command, one that wraps across more than one line (can be anything). - Run a command whose output doesn't end in a newline, eg: echo -n "ASD". - Press up twice to go back in history to the long command and try to edit part of it. - The text you are editing doesn't display properly, and it's impossible to edit correctly. I think bash assumes the line to edit begins at column 0 + prompt_length, but in this case it begins after previous_output_length + prompt_lengt$ Fix: Option A: If the previous command doesn't end in a newline, add a newline manually. This is what most shells do. Option B: Fix the line editor to take into account when the prompt doesn't start at column 0.
