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 <[email protected]> wrote: > Thomas Walker Lynch <[email protected]> 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:[email protected]:/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 > follows: > > (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]$ " > fi > --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 > untouched. > > Best regards, Michael. >
