bug#10586: 23.3; cd in remote shell reset working directory to local home

bug#10586: 23.3; cd in remote shell reset working directory to local home

[Alberto]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your report will be posted to the bug-gnu-emacs@gnu.org mailing list
and the gnu.emacs.bug news group, and at http://debbugs.gnu.org.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

Open a remote folder, e.g.
    C-x C-f /onan:bin
Open a remote shell there
    M-x shell
Check with pwd that working directory is remote
    M-x pwd
Execute in the shell cd
    > cd
Check with pwd that working directory is now _local_ home
    M-x pwd

After this happens the only way I found to fix the working directory is to kill
the shell buffer and open it again.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/home/alin/Software/install/emacs-23.3/share/emacs/23.3/etc/DEBUG.


In GNU Emacs 23.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.6)
 of 2011-12-12 on alin-ubuntu
Windowing system distributor `The X.Org Foundation', version 11.0.11004000
configured using `configure  '--prefix'
'/home/alin/Software/install/emacs-23.3' '--with-x-toolkit=gtk'
'--with-crt-dir=/usr/lib/x86_64-linux-gnu''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Shell

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x C-f <backspace> <backspace> / o n a n : b i n <return>
M-x s h e <tab> <return> p w d <return> M-x p w d <return>
c d <return> M-x p w d <return> M-x <down-mouse-2>
<mouse-2> <return>

Recent messages:
Tramp: Opening connection for onan using scpc...
Tramp: Sending command `exec ssh -q   -o
ControlPath=/tmp/tramp.16372VjS.%r@%h:%p -o ControlMaster=yes -e none
onan'

Tramp: Waiting for prompts from remote shell
Tramp: Sending command `exec ssh -q   -o
ControlPath=/tmp/tramp.16372VjS.%r@%h:%p -o ControlMaster=yes -e none
onan'
Tramp: Found remote shell prompt on `onan'
Tramp: Opening connection for onan using scpc...done
Directory /scpc:onan:/home/alin/bin/
~
Directory /home/alin/

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message sendmail ecomplete rfc822 mml easymenu
mml-sec mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047
rfc2045 qp ietf-drums mailabbrev nnheader gmm-utils wid-edit mailheader
canlock sha1 hex-util hashcash mail-utils emacsbug ansi-color dired
tramp-imap assoc tramp-gw tramp-gvfs zeroconf url-util url-parse
url-vars mm-util mail-prsvr dbus xml tramp-fish tramp-smb tramp-cache
tramp-ftp tramp-cmds tramp regexp-opt auth-source gnus-util netrc
time-date advice help-fns advice-preload shell comint ring
password-cache format-spec tramp-compat trampver tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer
select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces
cus-face files text-properties overlay md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote
make-network-process dbusbind font-render-setting gtk x-toolkit x
multi-tty emacs)

bug#10586: 23.3; cd in remote shell reset working directory to local home

[Glenn Morris]

Alberto wrote:

> Open a remote folder, e.g.
>     C-x C-f /onan:bin
> Open a remote shell there
>     M-x shell
> Check with pwd that working directory is remote
>     M-x pwd
> Execute in the shell cd
>     > cd
> Check with pwd that working directory is now _local_ home
>     M-x pwd

I can't reproduce this using Tramp's scpc method and don't see how such
a thing could even be possible. Is your local home directory even
visible on the remote machine? What tramp connection method are you
using? Does it happen with `emacs -Q'?

> After this happens the only way I found to fix the working directory
> is to kill the shell buffer and open it again.

Depending on the shell you use, does not 'cd -' take you back to the
previous directory?

bug#10586: 23.3; cd in remote shell reset working directory to local home

[Alberto]

On 24 January 2012 19:19, Glenn Morris <rgm@gnu.org> wrote:
> Alberto wrote:
>
>> Open a remote folder, e.g.
>>     C-x C-f /onan:bin
>> Open a remote shell there
>>     M-x shell
>> Check with pwd that working directory is remote
>>     M-x pwd
>> Execute in the shell cd
>>     > cd
>> Check with pwd that working directory is now _local_ home
>>     M-x pwd
>
> I can't reproduce this using Tramp's scpc method and don't see how such
> a thing could even be possible. Is your local home directory even
> visible on the remote machine?

I think there is a misunderstanding. Is not the bash shell that believes to
be in the local home.
But Emacs.
What happens is that the shell buffer lose synchronization  between the
current dir of the shell and the variable that emacs to keep track of it
(e.g. the one that is used to auto complete path in the shell).
So if you want, typing pwd in the _shell_ gives the correct result,
the remote home.
M-x pwd instead returns the wrong result (the local home instead of
something like
/onan:~)

> What tramp connection method are you
> using?
scpc
This is my default so in that particular connection is not shown explicitly.

Does it happen with `emacs -Q'?
Yes. It does. I run a separate test on a friend machine, the result is the same.
However I did a test with current emacs trunk (24.something).
On that one the problem cannot be reproduced.

>> After this happens the only way I found to fix the working directory
>> is to kill the shell buffer and open it again.
>
> Depending on the shell you use, does not 'cd -' take you back to the
> previous directory?
That was a good guess in fact, "cd -" gets emacs to go back to the remote home.
I've tried again using explicitly scpc. If it can help, emacs prints
the new folder as a message after every cd.
When I do the procedure above
 - for cd it is printed ~
 - for cd - it is printed /scpc:onan:bin

Hope it helps.
Regards

-- 
Alberto Ingenito

bug#10586: 23.3; cd in remote shell reset working directory to local home

[Glenn Morris]

(Please keep 10586@debbugs included in replies.)

Alberto wrote:

> I think there is a misunderstanding. Is not the bash shell that believes to
> be in the local home.
> But Emacs.
> What happens is that the shell buffer lose synchronization  between the
> current dir of the shell and the variable that emacs to keep track of it
> (e.g. the one that is used to auto complete path in the shell).
> So if you want, typing pwd in the _shell_ gives the correct result,
> the remote home.
> M-x pwd instead returns the wrong result (the local home instead of
> something like
> /onan:~)

Oh yes, I overlooked that you said `M-x pwd' rather than just `pwd'.

>> What tramp connection method are you
>> using?
> scpc
> This is my default so in that particular connection is not shown explicitly.
>
> Does it happen with `emacs -Q'?
> Yes. It does. I run a separate test on a friend machine, the result is
> the same.
> However I did a test with current emacs trunk (24.something).
> On that one the problem cannot be reproduced.

I also can reproduce it in Emacs 23.3, but not in the current trunk, so
it looks like this has been fixed. It's not the kind of thing suitable
for backporting to the emacs-23 branch at this stage, so the fix will
appear in the 24.1 release.