[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: prompt has changed with an update

From: Thomas Walker Lynch
Subject: Re: prompt has changed with an update
Date: Thu, 24 Sep 2020 16:20:11 +0200

Thanks Michael.  Looks like I should have gone to the Tramp manual, but I was confused.  It truly was working before.  It is tied into my dirtrack  and elsewhere so there is no way I could have confused that.  I also modify the prompt when entering projects by adding the project name.  I developed a lot of code using remote access through Tramp.  I also set an inside emacs environment variable in scripts.  RTFM time ... why every time I ask a question ...

On Thu, Sep 24, 2020 at 2:42 PM Michael Albinus <> wrote:
Thomas Walker Lynch <> writes:

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

Thanks. The other message you've confirmed, that you are using the
builtin Tramp.

> Here is what the erroneous prompt looks like:
>     /sudo:root@localhost.localdomain:/root/ #$

This is what Tramp sets, indeed. I have been irritated by saying
"Recently my prompt has changed ...". This prompt is what Tramp does for
years. I've just checked, also in Emacs 26.3 this happens. I don't know
why this happens to you "recently" only.

> This is what the prompt should look like:
>     2020-09-23T15:53:09Z root@localhost§/home/morpheus§
>     #

Well, the Tramp manual tells you about. See (info "(tramp) Remote shell setup")

--8<---------------cut here---------------start------------->8---
Interactive shell prompt

     TRAMP redefines the remote shell prompt internally for robust
     parsing.  This redefinition affects the looks of a prompt in an
     interactive remote shell through commands, such as ‘M-x shell
     <RET>’.  Such prompts, however, can be reset to something more
     readable and recognizable using these environment variables.

     TRAMP sets the ‘INSIDE_EMACS’ environment variable in the startup
     script file ‘~/.emacs_SHELLNAME’.

     ‘SHELLNAME’ is ‘bash’ or equivalent shell names.  Change it by
     setting the environment variable ‘ESHELL’ in the ‘.emacs’ as

          (setenv "ESHELL" "bash")

     Then re-set the prompt string in ‘~/.emacs_SHELLNAME’ as follows:

          # Reset the prompt for remote TRAMP shells.
          if [ "${INSIDE_EMACS/*tramp*/tramp}" == "tramp" ] ; then
             PS1="[\u@\h \w]$ "
--8<---------------cut here---------------end--------------->8---

Honestly, I haven't tested these instructions for years. At least the
sentence "TRAMP sets the ‘INSIDE_EMACS’ ..." is nonsense; this variable
is changed somewhere else. But it sounds like a recipe you might go to
get your prompt. I will be happy for a response, whether it works as
documented for you (otherwise we need to adapt it).

> After step 4 the prompt will appear erroneously as noted above when
> emacs -Q was used.  Dirtrack will not be able to find it (and my
> transcript records will be messed up due to not having the UTC time
> stamps LOL)
> Note, this exact same thing happens when using tramp to open a remote
> shell.  Here is the erroneous prompt I get on my server when opening a
> remote shell:
>     /ssh:thomas_lynch@server:/home/thomas_lynch #$

This is not erroneously, but the expected prompt from Tramp pov.

> 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.

This is what makes me wonder. What has changed in your config, that the
prompt you're used to see has disappeared? Maybe there *are* other
differences between Emacs 26.3 and 27.1 in this area, which I don't
remember ...

Anyway, what I have quoted above is the recommended way to fix
it. There's no Tramp guarantee, that your .bashrc settings keep

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]