* can't see existing directory on remote machine @ 2020-10-08 15:17 ken 2020-10-08 15:43 ` can't see existing directory on remote machine... workaround ken 0 siblings, 1 reply; 7+ messages in thread From: ken @ 2020-10-08 15:17 UTC (permalink / raw) To: GNU Emacs List 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: can't see existing directory on remote machine... workaround 2020-10-08 15:17 can't see existing directory on remote machine ken @ 2020-10-08 15:43 ` ken 2020-10-08 17:31 ` Michael Albinus 0 siblings, 1 reply; 7+ messages in thread From: ken @ 2020-10-08 15:43 UTC (permalink / raw) To: help-gnu-emacs 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/" ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: can't see existing directory on remote machine... workaround 2020-10-08 15:43 ` can't see existing directory on remote machine... workaround ken @ 2020-10-08 17:31 ` Michael Albinus 2020-10-09 18:19 ` ken 0 siblings, 1 reply; 7+ messages in thread From: Michael Albinus @ 2020-10-08 17:31 UTC (permalink / raw) To: ken; +Cc: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: can't see existing directory on remote machine... workaround 2020-10-08 17:31 ` Michael Albinus @ 2020-10-09 18:19 ` ken 2020-10-10 9:00 ` Michael Albinus 0 siblings, 1 reply; 7+ messages in thread From: ken @ 2020-10-09 18:19 UTC (permalink / raw) To: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: can't see existing directory on remote machine... workaround 2020-10-09 18:19 ` ken @ 2020-10-10 9:00 ` Michael Albinus 2020-10-11 12:17 ` ken 0 siblings, 1 reply; 7+ messages in thread From: Michael Albinus @ 2020-10-10 9:00 UTC (permalink / raw) To: ken; +Cc: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: can't see existing directory on remote machine... workaround 2020-10-10 9:00 ` Michael Albinus @ 2020-10-11 12:17 ` ken 2020-10-11 14:00 ` Michael Albinus 0 siblings, 1 reply; 7+ messages in thread From: ken @ 2020-10-11 12:17 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: can't see existing directory on remote machine... workaround 2020-10-11 12:17 ` ken @ 2020-10-11 14:00 ` Michael Albinus 0 siblings, 0 replies; 7+ messages in thread From: Michael Albinus @ 2020-10-11 14:00 UTC (permalink / raw) To: ken; +Cc: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-10-11 14:00 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-10-08 15:17 can't see existing directory on remote machine ken 2020-10-08 15:43 ` can't see existing directory on remote machine... workaround ken 2020-10-08 17:31 ` Michael Albinus 2020-10-09 18:19 ` ken 2020-10-10 9:00 ` Michael Albinus 2020-10-11 12:17 ` ken 2020-10-11 14:00 ` Michael Albinus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).