Thomas Walker Lynch <thomas.lynch@reasoningtechnology.com> writes:
> Hello,
Hi Thomas,
> Recently my prompt has changed on shells raised with Tramp. I use
> dirtrack, so this messes up Emacs royally.
>
...
Thanks for the report. I need more data for analysis, though.
- Which Emacs/Tramp version are you using? The Tramp version info is
needed only in case you don't use the built-in Tramp.
GNU Emacs 27.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.21, cairo version 1.16.0) of 2020-08-20
- Have you upgraded Emacs and/or Tramp recently?
This is on Fedora 32, dnf update just today.
- Since I don't use dirtrack myself, could you please give me a recipe
for analysis? Please start with "emacs -Q",
Yes it has the same behavior with emacs -Q
Here is what the erroneous prompt looks like:
Yes that is a two line prompt. Makes for reading transcripts much easer.
and describe all steps
(including activating dirtrack) you apply. What do you see, and what
do you expect instead?
Please find attached a reduced dot_emacs_test, and dot_bashrc_test files that also display the problem.
Attached is a .emacs file that exhibits the problem. There are sections for tramp and dirtrack configuration.
dirtrack is not important here, the question is about the prompt not being set.
steps:
That is a regular user. Again the prompt in the bashrc files was ignored, dirtrack is messed up and no timestamps.
This might matter .. a year or two ago I reported a sudo security bug because scripts may be injected through an inherited prompt. It is conceivable that the prompt behavior going through sudo has changed. But this does not apply here because the prompt is set in the .bashrc and thus is set by the process after it is already the other user. This is not an inherited prompt. Unless they killed the prompt setting altogether.
Thanks Michael et al. I look forward to your reply, and apologize in advance if I've done something stupid here. Though gosh, it did work. I used it often, prompt was correct from the .bashrc and dirtrack worked etc.