[Bug 276250] Backspace issue related to PS1 special variable containing \n formatting sequence

2024-01-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276250

Mark Johnston  changed:

   What|Removed |Added

 CC||ma...@freebsd.org
 Status|New |Open

--- Comment #1 from Mark Johnston  ---
I can reproduce this on main, but only with /bin/sh.  Is this a regression from
an earlier release?

For others, just setting PS1="\[\n\]\h:\w \[\n\]\$ " in /bin/sh, entering a few
characters and pressing backspace is enough to trigger the problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 276250] Backspace issue related to PS1 special variable containing \n formatting sequence

2024-01-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276250

Bug ID: 276250
   Summary: Backspace issue related to PS1 special variable
containing \n formatting sequence
   Product: Base System
   Version: 14.0-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: white-p...@pm.me

The non-printing character \n in a formatting sequence for PS1 only works as
expected at the beginning of a formatting sequence. If placed anywhere else,
then the backspace key behaves erratically.

For instance:

1) The following sequence works as expected with no backspace issues:
export PS1="\[\n\]\h:\w \$ "

2) The following one reveals an issue with the backspace behavior:
export PS1="\[\n\]\h:\w \[\n\]\$ "

This has been observed at the console level.
No X-Windows is running, thus no graphical terminals are involved.

$ echo $TERM​
xterm-256color​
​
$ stty​
speed 9600 baud;​
lflags: echoe echoke echoctl​
iflags: -iutf8
oflags: tab0​
cflags: cs8 -parenb​

-- 
You are receiving this mail because:
You are the assignee for the bug.