Michael Albinus <michael.albi...@gmx.de> writes: > > I've lost the trace. Could you pls show a recipe (starting with "emacs > -Q" how to reproduce?
emacs -Q C-x C-f /docker:alpine3173: RET M-x eshell ``` Welcome to the Emacs shell /docker:alpine3173:~ # sh sh: cd: /root/: Permission denied ///d7a490935d9ccac4bbd00c51c4cb863b#$echo $USER paretoOptimalDev ///d7a490935d9ccac4bbd00c51c4cb863b#$echo $SHELL /run/current-system/sw/bin/bash ///d7a490935d9ccac4bbd00c51c4cb863b#$ exit /docker:alpine3173:~ # whoami paertoOptimalDev ``` I guess it's expected that it's using my local user name paretoOptimalDev to connect by default? I thought this indicated sh wasn't being run in the docker container, but now not sure. Specifying the root user I have an even more interesting issue: ``` emacs -Q C-x C-f /docker:root@alpine3173: RET M-x eshell Welcome to the Emacs shell /docker:root@alpine3173:~ # whoami root /docker:root@alpine3173:~ # sh ‘echo \"`uname -sr`\"’ does not return a valid Lisp expression: ‘sh: uname: command not found "" ’ ``` That last example shows how seems consistent with my other tests where something very off seems to be happening where tramp thinks taht even uname isn't available. It is available in that docker image though: ``` $ docker exec -it alpine3173 sh -c 'ls -larth /bin/uname' lrwxrwxrwx 1 root root 12 Mar 29 14:45 /bin/uname -> /bin/busybox ``` I get the feeling this could be a permissions issue. I'm not sure if I've communicated this adequately or not, but it seems the `exec` in: ``` exec env TERM='dumb' INSIDE_EMACS='30.0.50,eat,tramp:2.7.0-pre' ENV='' HISTFILE=~/.tramp_history PROMPT_COMMAND='' PS1=///d7a490935d9ccac4bbd00c51c4cb863b\#\$ PS2='' PS3='' /bin/sh -i ``` Is taking over my eshell. My understanding is that in normal operation this is only supposed to temporarily happen while tramp executes a command and then if there are no errors that prompt gets exited and you appear to have always remained in eshell. Is that correct?
