I "redesigned" my shell prompt yesterday.

I now have the current date/time, host name and working directory
(possibly shortened) in a scroll-protected status line at the bottom of
the terminal.

The prompt is just a dollar sign (PS1='\$ ') which is very refreshing.

Here is the code. I have this in a ~/.bash_functions file that gets
sourced.

Using the PROMPT_COMMAND hook mechanism, before every command, we
update the status area and scroll-protect it. Before that, we check whether the
LINES or COLUMNS has changed, in which case we call prepare_terminal
to reserve the bottom row for ourselves, and make sure the cursor is
off thatline. This happens on the first call to update_status_line
also, since old_lines and old_cols are zero.

Whenever a command has a termination status other than successful, we
print the line !<n>! where <n> is the status before the prompt.
Logic in update_status_line ensures that repetitions of this are suppressed
if the user hits enter on an empty line.

prepare_terminal()
{ stty rows $((LINES - 1))
printf "\n\033[1A"
old_lines=$LINES
old_cols=$COLUMNS
}

old_cmdno=0
old_lines=0
old_cols=0

update_status_line()
{ local exit=$?
local getcmdno='\#'
local cmdno=${getcmdno@P}
local esc=$(printf "\033")
local pwd=$PWD
local dots=

[ $LINES -eq $old_lines -a $COLUMNS -eq $old_cols ] || prepare_terminal

while true; do
[ "${pwd#/*/}" == "$pwd" ] && break
local status="$esc[7m$(date +%m-%d/%H:%M)$esc[m $HOSTNAME $dots$pwd"
local status_nohl="$(date +%m-%d/%H:%M) $HOSTNAME $dots$pwd"
[ ${#status_nohl} -le $COLUMNS ] && break
pwd=${pwd#/}
pwd=/${pwd#*/}
dots='...'
done

[ ${#status_nohl} -gt $COLUMNS ] && return

printf "${esc}7$esc[%s;1H$esc[K%s$esc[1;%sr${esc}8" $((LINES + 1)) "$status" $
LINES
if [ $exit -ne 0 -a $cmdno -ne $old_cmdno ] ; then
printf "!%s!\n" $exit
fi
old_cmdno=$cmdno
}

PROMPT_COMMAND='update_status_line'

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 03.08.2023 20:31, Kaz Kylheku wrote:
> I "redesigned" my shell prompt yesterday.
>
> [...]

Hi Kaz, I wanted to try out your script and have two questions...

My bash doesn't seem to support the @P in cmdno=${getcmdno@P}
what does it do?

At certain places you use in printf contexts \033 or define a
variable esc to carry that value. In Kornshell I use \E or \e
for ANSI escapes, and my bash also supports that. Is there in
bash with PROMPT_COMMAND some technical necessity to use $esc ?

Janis

>
> prepare_terminal()
> {
> stty rows $((LINES - 1))
> printf "\n\033[1A"
> old_lines=$LINES
> old_cols=$COLUMNS
> }
>
> old_cmdno=0
> old_lines=0
> old_cols=0
>
> update_status_line()
> {
> local exit=$?
> local getcmdno='\#'
> local cmdno=${getcmdno@P}
> local esc=$(printf "\033")
> local pwd=$PWD
> local dots=
>
> [ $LINES -eq $old_lines -a $COLUMNS -eq $old_cols ] || prepare_terminal
>
> while true; do
> [ "${pwd#/*/}" == "$pwd" ] && break
> local status="$esc[7m$(date +%m-%d/%H:%M)$esc[m $HOSTNAME $dots$pwd"
> local status_nohl="$(date +%m-%d/%H:%M) $HOSTNAME $dots$pwd"
> [ ${#status_nohl} -le $COLUMNS ] && break
> pwd=${pwd#/}
> pwd=/${pwd#*/}
> dots='...'
> done
>
> [ ${#status_nohl} -gt $COLUMNS ] && return
>
> printf "${esc}7$esc[%s;1H$esc[K%s$esc[1;%sr${esc}8" $((LINES + 1)) "$status" $
> LINES
> if [ $exit -ne 0 -a $cmdno -ne $old_cmdno ] ; then
> printf "!%s!\n" $exit
> fi
> old_cmdno=$cmdno
> }
>
> PROMPT_COMMAND='update_status_line'
>
>

On 2023-08-04, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 03.08.2023 20:31, Kaz Kylheku wrote:
>> I "redesigned" my shell prompt yesterday.
>>
>> [...]
>
> Hi Kaz, I wanted to try out your script and have two questions...

Hi Janis,

Thanks for trying it; if you get it working 100%, you will like it,
I'm sure. The idea is to set the prompt to just PS=1'\$ ' which
is clean and refreshing, and feels like old Unix. All the junk
like showing the date, time, host name and current directory, goes into
a scroll-protected status line at the bottom.

> My bash doesn't seem to support the @P in cmdno=${getcmdno@P}
> what does it do?

This is a newer feature (Bash 4.4+)? It specifies prompt-like
expansion.

The variable getcmdno contains a code that is normally used
in the PS1 prompt. @{getcmdno@P} handles that variable as if it
were PS1, expanding that code.

The only reason I used this was to gain access to the current prompt
line number. I don't think there is any other way to get to it. The line
number lets us distinguish whether the user is just hitting Enter on an
empty line:

$
$
$ _

or actually issuing new commands.

When the user issues an empty line, the value of $? observed by the
PROMPT_COMMAND hook remains the same. I wanted the failed status like
!1! to be printed only once, like this:

$ false
!1!
$
$
$ _

and not:

$ false
!1!
$
!1!
$
!1!
$ _

which is achieved by observing no change in the prompt number.

So it is all for aesthetics.

Someone who doesn't mind that, or doesn't want the termination
status, or does something else with it can remove all that
code.

> At certain places you use in printf contexts \033 or define a
> variable esc to carry that value. In Kornshell I use \E or \e
> for ANSI escapes, and my bash also supports that. Is there in
> bash with PROMPT_COMMAND some technical necessity to use $esc ?

I initially had a hard-coded escape.

By defining it as a named term, we can do this:

esc=ESC # for debugging

The performance hit of the extra substitutions is not an issue.

Also, the reason the following variables are defined the way they are is
to support reloading of the code.

old_cmdno=${old_cmdno-0}
old_lines=${old_lines-0}
old_cols=${old_cols-0}

If the variables already exist, their values are left alone, so that
update_statusS_line will not call prepare_terminal, which will steal
another line of display, which is an annoying behavior.

In Common Lisp, (defvar variable value) will not evaluate the value
expression or assign the variable if the variable already exists. This
supports reloading of modules without disturbing their global variables.
(You use defparameter, which always assigns, if you want that.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-03, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> while true; do
> [ "${pwd#/*/}" == "$pwd" ] && break
> local status="$esc[7m$(date +%m-%d/%H:%M)$esc[m $HOSTNAME $dots$pwd"
> local status_nohl="$(date +%m-%d/%H:%M) $HOSTNAME $dots$pwd"
> [ ${#status_nohl} -le $COLUMNS ] && break
> pwd=${pwd#/}
> pwd=/${pwd#*/}
> dots='...'
> done

Erratum: the break test at the top of the loop body should be moved to the
bottom:

while true; do
local status="$esc[7m$(date +%m-%d/%H:%M)$esc[m $HOSTNAME $dots$pwd"
local status_len=$((${#status} - ${#status_esc}))
[ $status_len -le $COLUMNS ] && break
pwd=${pwd#/}
pwd=/${pwd#*/}
dots='...'
[ "${pwd#/*/}" == "$pwd" ] && break
done

This causes an issue reported by a user on Mastodon, that
when you change to a directory like / or /home, the status
line disappears. We need the loop body executed unconditionally
at least to calculate a status line, and then to stop iterating
if the path cannot be reduced further after that.

There is one more check after the loop for a status line that cannot fit
the current $COLUMNS with, in which case it is turned off.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
> Hi Kaz, I wanted to try out your script and have two questions...
>
> My bash doesn't seem to support the @P in cmdno=${getcmdno@P}
> what does it do?

What version of bash are you using? This feature was introduced in bash
4.4, released in 2016.

From "bash info param":

'${PARAMETER@OPERATOR}'
The expansion is either a transformation of the value of PARAMETER
or information about PARAMETER itself, depending on the value of
OPERATOR. Each OPERATOR is a single letter:
[...]
'P'
The expansion is a string that is the result of expanding the
value of PARAMETER as if it were a prompt string (*note
Controlling the Prompt::).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 04/08/2023 18:36, Kaz Kylheku wrote:
> On 2023-08-03, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> while true; do
>> [ "${pwd#/*/}" == "$pwd" ] && break
>> local status="$esc[7m$(date +%m-%d/%H:%M)$esc[m $HOSTNAME $dots$pwd"
>> local status_nohl="$(date +%m-%d/%H:%M) $HOSTNAME $dots$pwd"
>> [ ${#status_nohl} -le $COLUMNS ] && break
>> pwd=${pwd#/}
>> pwd=/${pwd#*/}
>> dots='...'
>> done
>
> Erratum: the break test at the top of the loop body should be moved to the
> bottom:
>
> while true; do
> local status="$esc[7m$(date +%m-%d/%H:%M)$esc[m $HOSTNAME $dots$pwd"
> local status_len=$((${#status} - ${#status_esc}))
> [ $status_len -le $COLUMNS ] && break
> pwd=${pwd#/}
> pwd=/${pwd#*/}
> dots='...'
> [ "${pwd#/*/}" == "$pwd" ] && break
> done
>
> This causes an issue reported by a user on Mastodon, that
> when you change to a directory like / or /home, the status
> line disappears. We need the loop body executed unconditionally
> at least to calculate a status line, and then to stop iterating
> if the path cannot be reduced further after that.
>
> There is one more check after the loop for a status line that cannot fit
> the current $COLUMNS with, in which case it is turned off.
>

Yes, nice, but you lose a line on the terminal (but who cares?). If you
use Esc]2; you can update the terminal title. However, no highlights.

Should PROMPT_COMMAND= be PROMPT_COMMAND[0]= for modernity?

As it happens, mine looks like this:
PROMPT_COMMAND=(
[0]="echo -ne \"\\033]11;#204A87\\007\""
[1]="echo -ne \"\\033]2;\${USER}@\${HOSTNAME} (\${IP}) : (\${KERNEL},
\${BASHVR}) : \$(pwd) : \${LAST_COMMAND}\\007\""
)

Cheers

--

Chris Elvidge, England
I AM NOT THE NEW DALAI LAMA

On 2023-08-04, Chris Elvidge <chris@mshome.net> wrote:
> Yes, nice, but you lose a line on the terminal (but who cares?). If you
> use Esc]2; you can update the terminal title. However, no highlights.

Yes; putting stuff into the title is an old trick.

That stuff is far away from where my attention is, usually close
to the prompt.

Secondly, it's sometimes occupied. Right now I'm in screen session; when
you swap screens, screen updates the title.
(Though, that doesn't mean we can't clobber it, too.)

> Should PROMPT_COMMAND= be PROMPT_COMMAND[0]= for modernity?

I guess so; if there is a stack/list of them now, we want to
just be one entry. But probably [0] is already occupied?
We want to add to the array, not clobber an arbitrary index.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-03, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> I "redesigned" my shell prompt yesterday.

I have discovered an issue. When I run the "top" utility from procps-ng,
and then exit, stupidly puts the cursor into the scroll-protected area,
for whatever reason.

I implemented a countermeasure. As the last interaction with the
terminal, after we print the status line, and restore the cursor
position, we ask the terminal the X, Y position. If it is beyond the
last line, then we move the cursor to the first colum of the last line.

To read the X, Y position, we issue ESC[6h, and then parse the response
which is like ESC[<y>;<x>]R. Bash's read function lets us do this
nicely: read -s -d R <var>. Read until the delimiter R, silently
without echoing.

I will probably optimize things. Now that we are getting the ecurrent
position, we don't have to use the ESC 7 and ESC 8 trick for saving
and restoring position. We can just get the position once,
do the status line and then before restoring the position, check
for a valid line number.

For now it's like this:

old_cmdno=${old_cmdno-0}
old_lines=${old_lines-0}
old_cols=${old_cols-0}

prepare_terminal()
{ stty rows $((LINES - 1))
printf "\n\033[1A"
old_lines=$LINES
old_cols=$COLUMNS
}

get_current_line()
{ local esc=$(printf "\033")
local response
printf "$esc[6n" > /dev/tty
read -s -d R response < /dev/tty
local IFS="[;"
set -- $response
printf "%s\n" "$2"
}

update_status_line()
{ local exit=$?
local getcmdno='\#'
local cmdno=${getcmdno@P}
local esc=$(printf "\033")
local pwd=$PWD
local dots=

[ $LINES -eq $old_lines -a $COLUMNS -eq $old_cols ] || prepare_terminal

local status_esc="$esc[7m$esc[m"

while true; do
local status="$esc[7m$(date +%m-%d/%H:%M)$esc[m $HOSTNAME $dots$pwd"
local status_len=$((${#status} - ${#status_esc}))
[ $status_len -le $COLUMNS ] && break
pwd=${pwd#/}
pwd=/${pwd#*/}
dots='...'
[ "${pwd#/*/}" == "$pwd" ] && break
done

status_len=$((${#status} - ${#status_esc}))

[ $status_len -gt $COLUMNS ] && status=

printf "${esc}7$esc[%s;1H$esc[K%s$esc[1;%sr${esc}8" $((LINES + 1)) "$status" $LINES
if [ $exit -ne 0 -a $cmdno -ne $old_cmdno ] ; then
printf "!%s!\n" $exit
fi

local curln=$(get_current_line)

if [ $curln > $LINES ]; then
printf "$esc[%s;1H" $LINES
fi

old_cmdno=$cmdno
}

PROMPT_COMMAND='update_status_line'

On 2023-08-05, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-08-03, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> I "redesigned" my shell prompt yesterday.
>
> I have discovered an issue. When I run the "top" utility from procps-ng,
> and then exit, stupidly puts the cursor into the scroll-protected area,
> for whatever reason.

The fix has the unexpected tiny benefit that when you quit top, the top
output left on the screen no longer scrolls up by one line The cursor is
placed over the last line of the top output, and you can still see the
first line of the display.

Normally, top occupies the entire screen. When you quit, it puts the
cursor on the next line after that, so the display scrolls by one line.

Now it's putting the cursor into the status line which we adjust to the
previous line, and so no scrolling takes place.

On 2023-08-05, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> if [ $curln > $LINES ]; then

You want to make this $curln -gt $LINES, if you don't want to keep
creating a file called 52 (or however many lines you have).

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-03, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> I "redesigned" my shell prompt yesterday.

This now lives here:

https://www.kylheku.com/cgit/kabapro/tree/bash-prompt.sh

On 2023-08-03, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> I "redesigned" my shell prompt yesterday.

LOL, I got the clock in the status line to update spontaneously.

$ trap update_status_line ALRM
$ while true; do kill -ALRM $$ ; sleep 15 ; done &
[1] 19410

Background process sends SIGALRM every 15 seconds; status
line updates.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 05.08.2023 10:10, Kaz Kylheku wrote:
> On 2023-08-03, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> I "redesigned" my shell prompt yesterday.
>
> LOL, I got the clock in the status line to update spontaneously.
>
> $ trap update_status_line ALRM
> $ while true; do kill -ALRM $$ ; sleep 15 ; done &
> [1] 19410
>
> Background process sends SIGALRM every 15 seconds; status
> line updates.

I think this extension introduced a bug; I started a bash shell,
sourced the script, exited the bash instance, and on a new start
and sourcing I get every 15s (even after leaving bash completely)
./bash-prompt-V0: line 73: kill: (4118) - No such process
I got rid by the timer background process only after a 'pkill bash'
(couldn't identify the actual PID under my own or init's UID).

I suppose it needs at least a process cleanup before termination?

Janis

PS: Does bash support (as known from ksh) process bound timers?

On 03.08.2023 20:31, Kaz Kylheku wrote:
> I "redesigned" my shell prompt yesterday.
> [...]

Yet another question...

> printf "${esc}7$esc[%s;1H$esc[K%s$esc[1;%sr${esc}8" $((LINES + 1)) "$status" $LINES

What does $esc[1;%sr (with $LINES expanded for %s) do?
Say, \033[1;24r
(It seems I cannot find the ANSI control character 'r'.)

Janis

On 04.08.2023 19:26, Kaz Kylheku wrote:
>
> Thanks for trying it; if you get it working 100%, you will like it,
> I'm sure. The idea is to set the prompt to just PS=1'\$ ' which
> is clean and refreshing, and feels like old Unix. All the junk
> like showing the date, time, host name and current directory, goes into
> a scroll-protected status line at the bottom.

I can already say that I like the idea! Formerly we already had "all
the junk" in a separate line by adding a \n before the $ prompt. The
fixed (and protected) status line is certainly a step forward. When
(or if) I write my ksh variant - bash is not my standard shell -, I
want to make further changes; the attributes I like to be displayed
are of course different, but I also prefer to change the cursor
position for the command input to be constantly at the bottom of the
screen. - The short time special case that the first commands are
entered at the top of the screen and only if the screen gets filled
it moves downwards until it permanently reaches the bottom of the
screen is somewhat strange if you think about it; after the first
or second command entered my screen is anyway full and the cursor
at the bottom, so why not keep it static where it usually is. For
my taste that would be another little step forwards.

I want to strive to this layout...

+-----
|
| Scroll area (Input and Output)
|
:
:
|
| Prompt (Input)
| Status (scroll protected)
+-----

(That faintly reminds me the old mainframe times.)

Janis

On 05.08.2023 15:21, Janis Papanagnou wrote:
> On 03.08.2023 20:31, Kaz Kylheku wrote:
>> I "redesigned" my shell prompt yesterday.
>> [...]
>
> Yet another question...
>
>> printf "${esc}7$esc[%s;1H$esc[K%s$esc[1;%sr${esc}8" $((LINES + 1)) "$status" $LINES
>
> What does $esc[1;%sr (with $LINES expanded for %s) do?
> Say, \033[1;24r
> (It seems I cannot find the ANSI control character 'r'.)

I suppose I found the answer...

| The basics are: configure your device's shell to set scroll
| region once the command is accepted from user (equivalent of
| printf "\033[1,24r") -- and reset it once it completes --
| printf "\033[r".
[Stackexchange]

....presuming the differences (';' vs. ',') are not changing semantics.

>
> Janis
>

On 2023-08-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 05.08.2023 10:10, Kaz Kylheku wrote:
>> On 2023-08-03, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>> I "redesigned" my shell prompt yesterday.
>>
>> LOL, I got the clock in the status line to update spontaneously.
>>
>> $ trap update_status_line ALRM
>> $ while true; do kill -ALRM $$ ; sleep 15 ; done &
>> [1] 19410
>>
>> Background process sends SIGALRM every 15 seconds; status
>> line updates.
>
> I think this extension introduced a bug; I started a bash shell,
> sourced the script, exited the bash instance, and on a new start
> and sourcing I get every 15s (even after leaving bash completely)
> ./bash-prompt-V0: line 73: kill: (4118) - No such process

I looked for this problem proactively but didn't see it! Looks
like it has to be handled. A simple hack would be to terminate if
the kill fails. The ugly error should go to /dev/null.

I noticed another problem. In a fresh login shell, if I do a reverse
search with Ctrl-R for something, and cancel the search with Ctrl-C,
the background process dies. Orphaning the process so that it becomes
the child of PID 1 might fix it. It needs to be removed from the
TTY session so that it doesn't get signals.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 05.08.2023 15:21, Janis Papanagnou wrote:
>> On 03.08.2023 20:31, Kaz Kylheku wrote:
>>> I "redesigned" my shell prompt yesterday.
>>> [...]
>>
>> Yet another question...
>>
>>> printf "${esc}7$esc[%s;1H$esc[K%s$esc[1;%sr${esc}8" $((LINES + 1)) "$status" $LINES
>>
>> What does $esc[1;%sr (with $LINES expanded for %s) do?
>> Say, \033[1;24r
>> (It seems I cannot find the ANSI control character 'r'.)
>
> I suppose I found the answer...
>
>| The basics are: configure your device's shell to set scroll
>| region once the command is accepted from user (equivalent of
>| printf "\033[1,24r") -- and reset it once it completes --
>| printf "\033[r".
> [Stackexchange]
>
> ...presuming the differences (';' vs. ',') are not changing semantics.

The documented syntax requires a semicolon. If it works with the
comma, it's some exstension; it doesn't on the terminal I'm using.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 04.08.2023 19:26, Kaz Kylheku wrote:
>>
>> Thanks for trying it; if you get it working 100%, you will like it,
>> I'm sure. The idea is to set the prompt to just PS=1'\$ ' which
>> is clean and refreshing, and feels like old Unix. All the junk
>> like showing the date, time, host name and current directory, goes into
>> a scroll-protected status line at the bottom.
>
> I can already say that I like the idea! Formerly we already had "all
> the junk" in a separate line by adding a \n before the $ prompt. The
> fixed (and protected) status line is certainly a step forward.

I like being able to cut and paste commands in examples without
the chore of editing out the long prompts down to '$'.

> (or if) I write my ksh variant - bash is not my standard shell -, I
> want to make further changes; the attributes I like to be displayed
> are of course different, but I also prefer to change the cursor
> position for the command input to be constantly at the bottom of the
> screen.

The logic is already there; it's executed when the cursor intrudes
into the status line.

We just have to execute that logic whenever the prior cursor position is
not exactly one line before the status line.

Maybe just executing the move unconditionally would also work,
in which case saving the previous position can be dropped.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 05.08.2023 17:40, Kaz Kylheku wrote:
> On 2023-08-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 05.08.2023 15:21, Janis Papanagnou wrote:
>> [ANSI escape codes, Stackexchange quote]
>>
>> ...presuming the differences (';' vs. ',') are not changing semantics.
>
> The documented syntax requires a semicolon. If it works with the
> comma, it's some exstension; it doesn't on the terminal I'm using.

If it doesn't work it was probably just a typo of that poster.

Janis

On 2023-08-05, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-08-03, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> I "redesigned" my shell prompt yesterday.
>
> This now lives here:
>
> https://www.kylheku.com/cgit/kabapro/tree/bash-prompt.sh

Renamed. It's not a prompt but a status line.
So it's called Basta! (BAsh STAtus).

https://www.kylheku.com/cgit/basta/tree/

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 05.08.2023 17:45, Kaz Kylheku wrote:
> On 2023-08-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> [...]
>> (or if) I write my ksh variant - bash is not my standard shell -, I
>> want to make further changes; the attributes I like to be displayed
>> are of course different, but I also prefer to change the cursor
>> position for the command input to be constantly at the bottom of the
>> screen.
>
> The logic is already there; it's executed when the cursor intrudes
> into the status line.
>
> We just have to execute that logic whenever the prior cursor position is
> not exactly one line before the status line.
>
> Maybe just executing the move unconditionally would also work,
> in which case saving the previous position can be dropped.

I've written some experimental code using some Kornshell mechanisms,
so it differs from yours. (I've adopted/adapted your name though; I
like "basta" and named mine accordingly "kosta", kornshell status :-)
One thing I used (that I think doesn't exist in bash) are discipline
functions; I use them to update changes in rows/columns, and trigger
prompt PS1 access. And I have a few own details. Yet I've a lot to
add to that basic frame (path shortening, coloring, maybe composing
status lines, ...), it certainly can be shortened, and needs testing.
But I'm anyway just playing around with your status line idea...

Janis

function LINES.set { .kosta.rows=${.sh.value} ; .kosta.update ;}
function COLUMNS.set { .kosta.cols=${.sh.value} ;}
function PS1.get { .kosta.compose ;}

namespace kosta
{ typeset -i rows=${LINES} cols=${COLUMNS}
typeset -i prompt_line=$((rows-1))
typeset -i status_line=$((rows))

function update
{
prompt_line=$((rows-1))
status_line=$((rows))
}

function compose
{
prev_rc=$?
PS1='(!)$ '
status="${USER}@${HOSTNAME}:${PWD/${HOME}\//\~/} ${SHLVL_P}"

printf '\E[%d;1H\E[K' status_line # goto(row,column);
clear-to-eol;
if (( prev_rc > 255 )) # signal
then printf 'SIG %d (%s)! ' prev_rc-256 $( kill -l $((prev_rc)) )
elif (( prev_rc > 0 )) # error
then printf 'ERR %d! ' prev_rc
fi
printf '%s' "${status}"
printf '\E[1;%dr' prompt_line # scroll-region(from,to);
printf '\E[%d;1H' prompt_line # goto(row,column);
}

} # namespace kosta

On 2023-08-08, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 05.08.2023 17:45, Kaz Kylheku wrote:
>> On 2023-08-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> [...]
>>> (or if) I write my ksh variant - bash is not my standard shell -, I
>>> want to make further changes; the attributes I like to be displayed
>>> are of course different, but I also prefer to change the cursor
>>> position for the command input to be constantly at the bottom of the
>>> screen.
>>
>> The logic is already there; it's executed when the cursor intrudes
>> into the status line.
>>
>> We just have to execute that logic whenever the prior cursor position is
>> not exactly one line before the status line.
>>
>> Maybe just executing the move unconditionally would also work,
>> in which case saving the previous position can be dropped.
>
> I've written some experimental code using some Kornshell mechanisms,
> so it differs from yours. (I've adopted/adapted your name though; I
> like "basta" and named mine accordingly "kosta", kornshell status :-)

Great!

See, you can still innovate in the area of 1970's ECMA/ANSI terminal
control combined with 1980's Unix shells.

On 2023-08-06, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-08-05, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> On 2023-08-03, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>> I "redesigned" my shell prompt yesterday.
>>
>> This now lives here:
>>
>> https://www.kylheku.com/cgit/kabapro/tree/bash-prompt.sh
>
> Renamed. It's not a prompt but a status line.
> So it's called Basta! (BAsh STAtus).
>
> https://www.kylheku.com/cgit/basta/tree/

I'm seeing a weird glitch with Gnome terminal.

I have multiple terminal tabs open, each running a Bash with a Basta
status line.

When I switch from one tab to another, I see a spontaneous cursor
movement and scrolling a few seconds later.

What is happening is that the value of $LINES has spontaneously changed.
The basta.update_status function notices this and handles it like a
resize.

No resize has taken place; I'm just switching tabs.

This is some Gnome Terminal B.S. Probably, whenever a tab is selected to
be current, it is sending a SIGWINCH to the TTY session.

I'm guessing, they are doing it just in case the application window had
changed since the last time that tab was shown, whether it actually
changed or not.

Anyway, resize will just have to be handled more smoothly, so there
is no glitch.

Another, unrelated issue is that the background signal for updating the
screen can occur in the middle of an command line editing action. The
escape sequences get bungled.

I suspect my latest public changes already have the effect of mostly
mitigating it. I refactored the update function into two smaller ones,
and the trap handler only calls one of the two. That one no longer
interrogates the current position of the cursor, and so it isn't
processing input from the TTY that could be fooled by user input. I'm
keeping an eye on this issue to see how much of a problem it still is,
if any.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-09, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> Anyway, resize will just have to be handled more smoothly, so there
> is no glitch.

.... and I fixed it. Part the fix is to catch the window change
signal: "trap basta.update_status WINCH"!

This way, after a resize, we immediately restore the status line
and the scroll-protected region; the user has no chance to run
a command with the scroll-protection off where their output
then runs into the status line, which then scrolls up.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca