can't see existing directory on remote machine

can't see existing directory on remote machine

[ken]

My emacs has a file loaded which resides in a directory on a remote
(Linux) machine.  If from within that file's buffer window I run "C-x
C-d RETURN" (to show the files in that directory, Emacs throws an error:

Debugger entered--Lisp error: (file-missing "Setting current directory"
"No such file or directory" "/remo:~/dir/dir2/")
  call-process("/bin/bash" nil t nil "-c" "\\ls -d -CF -- ")
  #f(compiled-function (arg1 arg2 &optional arg3 arg4) #<bytecode
0x1fe9634981e3>)("/remo:~/dir/dir2/" "-CF" t nil)
  ls-lisp--insert-directory(#f(compiled-function (arg1 arg2 &optional
arg3 arg4) #<bytecode 0x1fe9634981e3>) "/remo:~/dir/dir2/" "-CF" t nil)
  apply(ls-lisp--insert-directory #f(compiled-function (arg1 arg2
&optional arg3 arg4) #<bytecode 0x1fe9634981e3>) ("/remo:~/dir/dir2/"
"-CF" t nil))
  insert-directory("/remo:~/dir/dir2/" "-CF" t nil)
  list-directory("/remo:~/dir/dir2/" nil)
  funcall-interactively(list-directory "/remo:~/dir/dir2/" nil)
  call-interactively(list-directory nil nil)
  command-execute(list-directory)

When logged into that remote machine and cd'd into that same directory,
the bash command in the second line of the debugger output yields this:

$ ls -d -CF --
./

I restarted emacs, but that changed nothing.

When I try to open a new or an existing file in that directory, emacs
prompts, offering to create the directory and its parent. 

The emacs version, the latest available in this distro, is 27.1, release
4.1.

Re: can't see existing directory on remote machine... workaround

[ken]

On 10/8/20 11:17 AM, ken wrote:
> My emacs has a file loaded which resides in a directory on a remote
> (Linux) machine.  If from within that file's buffer window I run "C-x
> C-d RETURN" (to show the files in that directory, Emacs throws an error:
>
> Debugger entered--Lisp error: (file-missing "Setting current directory"
> "No such file or directory" "/remo:~/dir/dir2/")
>   call-process("/bin/bash" nil t nil "-c" "\\ls -d -CF -- ")
>   #f(compiled-function (arg1 arg2 &optional arg3 arg4) #<bytecode
> 0x1fe9634981e3>)("/remo:~/dir/dir2/" "-CF" t nil)
>   ls-lisp--insert-directory(#f(compiled-function (arg1 arg2 &optional
> arg3 arg4) #<bytecode 0x1fe9634981e3>) "/remo:~/dir/dir2/" "-CF" t nil)
>   apply(ls-lisp--insert-directory #f(compiled-function (arg1 arg2
> &optional arg3 arg4) #<bytecode 0x1fe9634981e3>) ("/remo:~/dir/dir2/"
> "-CF" t nil))
>   insert-directory("/remo:~/dir/dir2/" "-CF" t nil)
>   list-directory("/remo:~/dir/dir2/" nil)
>   funcall-interactively(list-directory "/remo:~/dir/dir2/" nil)
>   call-interactively(list-directory nil nil)
>   command-execute(list-directory)
>
> When logged into that remote machine and cd'd into that same directory,
> the bash command in the second line of the debugger output yields this:
>
> $ ls -d -CF --
> ./
>
> I restarted emacs, but that changed nothing.
>
> When I try to open a new or an existing file in that directory, emacs
> prompts, offering to create the directory and its parent. 
>
> The emacs version, the latest available in this distro, is 27.1, release
> 4.1.
>
I found a workaround... I change the default, inserting "scp:" ... e.g.,
"/remo:~/dir/dir2/" -> "/scp:remo:~/dir/dir2/".  I doubt, however, that
this workaround will change the emacs code.

"/remo:~/dir/dir2/"

Re: can't see existing directory on remote machine... workaround

[Michael Albinus]

ken <gebser@mousecar.com> writes:

Hi Ken,

> I found a workaround... I change the default, inserting "scp:" ... e.g.,
> "/remo:~/dir/dir2/" -> "/scp:remo:~/dir/dir2/".  I doubt, however, that
> this workaround will change the emacs code.
>
> "/remo:~/dir/dir2/"

I don't know whether adding "/scp:" counts as a workaround. But for sure
"/remo:~/dir/dir2/" is not remote directory, a leading connection method
(like "scp") is mandatory.

Best regards, Michael.

Re: can't see existing directory on remote machine... workaround

[ken]

On 10/8/20 1:31 PM, Michael Albinus wrote:
> ken <gebser@mousecar.com> writes:
>
> Hi Ken,
>
>> I found a workaround... I change the default, inserting "scp:" ... e.g.,
>> "/remo:~/dir/dir2/" -> "/scp:remo:~/dir/dir2/".  I doubt, however, that
>> this workaround will change the emacs code.
>>
>> "/remo:~/dir/dir2/"
> I don't know whether adding "/scp:" counts as a workaround. But for sure
> "/remo:~/dir/dir2/" is not remote directory, a leading connection method
> (like "scp") is mandatory.
>

Well, then it should have been put in place automatically by emacs and
it wasn't.

Re: can't see existing directory on remote machine... workaround

[Michael Albinus]

ken <gebser@mousecar.com> writes:

Hi Ken,
>>
>>> I found a workaround... I change the default, inserting "scp:" ... e.g.,
>>> "/remo:~/dir/dir2/" -> "/scp:remo:~/dir/dir2/".  I doubt, however, that
>>> this workaround will change the emacs code.
>>>
>>> "/remo:~/dir/dir2/"
>> I don't know whether adding "/scp:" counts as a workaround. But for sure
>> "/remo:~/dir/dir2/" is not remote directory, a leading connection method
>> (like "scp") is mandatory.
>>
>
> Well, then it should have been put in place automatically by emacs and
> it wasn't.

"Emacs" doesn't put anything in place automatically. Which package do
you have in mind, which shall "put in place" this automatically?

IOW, could you pls give us a reproducible scenario, starting with
"emacs -Q"?

Best regards, Michael.

Re: can't see existing directory on remote machine... workaround

[ken]

On 10/10/20 5:00 AM, Michael Albinus wrote:
> ken <gebser@mousecar.com> writes:
>
> Hi Ken,
>>>> I found a workaround... I change the default, inserting "scp:" ... e.g.,
>>>> "/remo:~/dir/dir2/" -> "/scp:remo:~/dir/dir2/".  I doubt, however, that
>>>> this workaround will change the emacs code.
>>>>
>>>> "/remo:~/dir/dir2/"
>>> I don't know whether adding "/scp:" counts as a workaround. But for sure
>>> "/remo:~/dir/dir2/" is not remote directory, a leading connection method
>>> (like "scp") is mandatory.
>>>
>> Well, then it should have been put in place automatically by emacs and
>> it wasn't.
> "Emacs" doesn't put anything in place automatically. Which package do
> you have in mind, which shall "put in place" this automatically?
>
> IOW, could you pls give us a reproducible scenario, starting with
> "emacs -Q"?
>
> Best regards, Michael.
Hi, Michael,

When I said "automatically, I meant that, for instance, when I have a
remote file open and I do "C-x C-d", emacs "automatically" puts the
current directory into the minibuffer (so that it can be edited if
desired), and then I hit "Enter" to display the file listing for that
directory.  And the "current directory" here means the directory where
the file resides that was currently open.  In the same way, if I have a
remote file open and then do "C-x C-f", again emacs *automatically* puts
the current directory into the minibuffer (again, which can be edited if
desired), I type in the name of the file I want to open, hit "Enter",
and emacs opens a buffer for that file.  All this is great, fantastic,
and the way it should be.  It's so great, in fact, that I don't notice
anymore the *entire* contents of the prompt in the minibuffer, but just
the right-hand part of the minibuffer prompt relevant to the work I'm
doing at that moment.  It's worked that way for decades.  So frankly, I
don't remember, because it works so well, whether there was always the
"scp:" as part of the minibuffer prompt for remote files or not.  I
believe so, but that's going on very faint memory of when tramp was
first implemented in emacs decades ago and I wondered at and marveled
over its ability to seamlessly open and edit files on remote machines
pretty much in just the same way as if they were local files, this at a
time when with Windows you had to remember and specify whether a file
was on "A:" or "C:" or wherever, as if they were separate filesystems...
because, for MS, they were.  Not having to remember is great... but then
occasionally remembering is helpful.

As for "which package" provides this functionality, I don't know.  It
used to be a package called "tramp", which I'm sure you're quite
familiar with (being its Hauptaccoucher), but it appears all the tramp
functionality has been incorporated into emacs and so it's no longer a
separate package; "rpm -qa| grep -i tramp" returns nothing and I don't
see mention of "tramp" anymore in the dozens of emacs status messages
that go flying by when I do anything with remote files.  But I probably
missed the memo on that, so while I'd very much like to know, I can't say. 

It appears that the problem has fixed itself.  Since implementing my
workaround for that one file, emacs now automatically includes that
"scp:" in all the minibuffer prompts for remote files.  I don't know how
that could have happened, how that one small fix could propagate itself
to all subsequent instances, but my suspicion is that a recent version
update created a small corruption in my ".emacs.desktop", one which left
out that little "scp:" for one file and then all subsequent files and
directories until I put it back in, at which time it put it back in
again for all files and directories.  But that's just a blind guess
based on the chronology of the problem's occurrence.  Hopefully we won't
have to figure it out with certainty because the problem is now gone
forever.  But if it comes back, say, after a reboot or another version
update, and the workaround fails, then we take another look.

Thanks for your reply and your interest.
Regards,
ken

Re: can't see existing directory on remote machine... workaround

[Michael Albinus]

ken <gebser@mousecar.com> writes:

> Hi, Michael,

Hi Ken,

> When I said "automatically, I meant that, for instance, when I have a
> remote file open and I do "C-x C-d", emacs "automatically" puts the
> current directory into the minibuffer (so that it can be edited if
> desired), and then I hit "Enter" to display the file listing for that
> directory.  And the "current directory" here means the directory where
> the file resides that was currently open.  In the same way, if I have a
> remote file open and then do "C-x C-f", again emacs *automatically* puts
> the current directory into the minibuffer (again, which can be edited if
> desired), I type in the name of the file I want to open, hit "Enter",
> and emacs opens a buffer for that file.  All this is great, fantastic,
> and the way it should be.  It's so great, in fact, that I don't notice
> anymore the *entire* contents of the prompt in the minibuffer, but just
> the right-hand part of the minibuffer prompt relevant to the work I'm
> doing at that moment.
>
>  It's worked that way for decades.  So frankly, I
> don't remember, because it works so well, whether there was always the
> "scp:" as part of the minibuffer prompt for remote files or not.  I
> believe so, but that's going on very faint memory of when tramp was
> first implemented in emacs decades ago and I wondered at and marveled
> over its ability to seamlessly open and edit files on remote machines
> pretty much in just the same way as if they were local files, this at a
> time when with Windows you had to remember and specify whether a file
> was on "A:" or "C:" or wherever, as if they were separate filesystems...
> because, for MS, they were.  Not having to remember is great... but then
> occasionally remembering is helpful.

And this shall be still the case. There is a buffer-local variable
default-directory, which is responsible for all this behaviour. If it
isn't changed accidently, it still shall work this way.

> As for "which package" provides this functionality, I don't know.  It
> used to be a package called "tramp", which I'm sure you're quite
> familiar with (being its Hauptaccoucher), but it appears all the tramp

What I nice word :-) However, the Hauptaccouchewr is still Kai
Grossjohann. I'm just the maintainer.

> functionality has been incorporated into emacs and so it's no longer a
> separate package; "rpm -qa| grep -i tramp" returns nothing and I don't
> see mention of "tramp" anymore in the dozens of emacs status messages
> that go flying by when I do anything with remote files.  But I probably
> missed the memo on that, so while I'd very much like to know, I can't say. 

Tramp still exists outside Emacs. And you can upgrade to the recent
version via GNU ELPA.

> It appears that the problem has fixed itself.  Since implementing my
> workaround for that one file, emacs now automatically includes that
> "scp:" in all the minibuffer prompts for remote files.  I don't know how
> that could have happened, how that one small fix could propagate itself
> to all subsequent instances, but my suspicion is that a recent version
> update created a small corruption in my ".emacs.desktop", one which left
> out that little "scp:" for one file and then all subsequent files and
> directories until I put it back in, at which time it put it back in
> again for all files and directories.

Yes, and that's why I have asked whether it is reproducible. To all of
my best knowledge, Tramp does not corrupt the default-directory
variable. So I would be grateful if you could show us a recipe for this
problem.

>   But that's just a blind guess
> based on the chronology of the problem's occurrence.  Hopefully we won't
> have to figure it out with certainty because the problem is now gone
> forever.  But if it comes back, say, after a reboot or another version
> update, and the workaround fails, then we take another look.

Yes, please.

> Thanks for your reply and your interest.
> Regards,
> ken

Best regards, Michael.