PS1 bug in TC16

[adb014]

In the file /etc/profile you'll see the code

Code: [Select]

if [ "`id -u`" -eq 0 ]; then
        # Light green and blue colored prompt.
        #PS1='\e[1;31m\u@\h\e[0m:\e[1;34m\w\e[0m\# '
        PS1='\u@\h:\w\# '
else
        # Light green and blue colored prompt.
        PS1='\e[1;32m\u@\h\e[0m:\e[1;34m\w\e[0m\$ '
        #PS1='\u@\h:\w\$ '
fi

Unfortunately the shell sees the characters like "\e[1;32m" as taking 8 characters and "\e[0m" as taking 5 rather than 0 characters which messes up the prompt and the history commands. This is probably why the root prompt doesn't use color. You can tell the shell that certain sequences of characters take zero space by enclosing them in "\[" and "\]" so this code block updated should read

Code: [Select]

if [ "`id -u`" -eq 0 ]; then
        # Red and blue colored prompt.
        PS1='\[\e[1;31m\]\u@\h\[\e[0m\]:\[\e[1;34\m\]\w\[\e[0m\]# '
else
        # Light green and blue colored prompt.
        PS1='\[\e[1;32m\]\u@\h\[\e[0m\]:\[\e[1;34\m\]\w\[\e[0m\]$ '
fi

and then the stty size will be respected and 26 characters won't be lost/misaligned when trying to edit long lines of the history

[nick65go]

wow! I fought in the past (with myself in a chroot) to have colors for shell prompter (RED for root, GREEN for user). The script is so old and simple, that I wonder why nobody complaint until now?

This shows that not many stop login at root phase, they just blindly / automatically go further and login as TC user + maybe Xvesa/ Xfbdev etc.

PS: my cmd line in history were short and almost never edited them, just re-type it.
Could be maybe a bug in the latest ash, because I hit some busybox bugs myself regarding wget options, etc.
I have not this problem with a static compiled busybox 1.37 from Alpinelinux in a chroot.

FYI: if I am not wrong (I do not remember the TC version) then I think there are color problems (I saw escape chars instead of colors) with filetools (the back-up appl) in FLTK GUI mode (the CLI mode was OK).

[adb014]

Yet I'd set my own prompt in /home/tc/.profile and "sudo sh" doesn't reread /etc/profile. I only saw the problem when I removed the setting of PS1 in /home/tc/.profile

[nick65go]

hm, it is a difference if the shell (ash or sh) is interactive (like sudo sh) or a login shell (ash -l); maybe only the login shell read the /etc/profile* and then the ".profile" from user (tc or root) home.

[nick65go]

Here a demo. with two fictive users (John and Smith), each with different shell prompter

Code: [Select]

❯ ls -l home/
drwxr-xr-x - abc  5 Sep 19:52  John
drwxr-xr-x - abc  5 Sep 19:53  Smith

❯ cat home/John/.profile
PS1='\u@GREEN:\w\$ '
export PS1

❯ cat home/Smith/.profile
PS1='\u@RED:\w\$ '
export PS1If you use a LOGIN SHELL, sh -l, or login, you get the user specific prompter.
But if you just SU/SUDO (switch user) , the shell prompter stays as former user:

Code: [Select]

~/Desktop/TinyCore/demo
❯ sudo chroot . /bin/login -f John
John@GREEN:~$ cd /
John@GREEN:/$ su Smith
Smith@GREEN:/$                        <==same GREEN prompter as for John, former user

Smith@GREEN:/$ sudo login -f Smith
Smith@RED:~$ exit                      <==now the new user prompter RED
Smith@GREEN:/$ ^CThe way to change the shell prompter even for a non-login shell is to have, BEFORE summon the su or sudo, the ENV (environment variable) set to a personal script somewhere, as ENV=full-path-to-that-executable-script-to-change-PS1. So every time you change user, the new sh shell will SOURCE that script.