GNU bug report logs -
#71709
Fix recent change in tramp-sh-handle-make-process
Previous Next
Reported by: Iurie Marian <marian.iurie <at> gmail.com>
Date: Fri, 21 Jun 2024 19:13:02 UTC
Severity: normal
Fixed in version 30.1
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 71709 in the body.
You can then email your comments to 71709 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71709; Package
emacs.
(Fri, 21 Jun 2024 19:13:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Iurie Marian <marian.iurie <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 21 Jun 2024 19:13:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
tramp-sh-handle-make-process is failing when `:stderr' argument is used.
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.41, cairo version 1.18.0) of 2024-06-21 built on rrouwprlc0222
Repository revision: e7123edfe7f7abc9043429dfb3f84941f83d6565
Repository branch: master
System Description: Ubuntu 24.04 LTS
[Message part 2 (text/html, inline)]
[tramp-sh-handle-make-process.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71709; Package
emacs.
(Fri, 21 Jun 2024 19:22:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 71709 <at> debbugs.gnu.org (full text, mbox):
Iurie Marian <marian.iurie <at> gmail.com> writes:
Hi,
> tramp-sh-handle-make-process is failing when `:stderr' argument is
> used.
>
> In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.41, cairo version 1.18.0) of 2024-06-21 built on rrouwprlc0222
> Repository revision: e7123edfe7f7abc9043429dfb3f84941f83d6565
> Repository branch: master
> System Description: Ubuntu 24.04 LTS
>
> diff --git a/lisp/net/tramp-sh.el b/lisp/net/tramp-sh.el
> index bce7c323dad..68018298b68 100644
> --- a/lisp/net/tramp-sh.el
> +++ b/lisp/net/tramp-sh.el
> @@ -2969,6 +2969,7 @@ tramp-sh-handle-make-process
> (let* ((program (car command))
> (args (cdr command))
> ;; STDERR can also be a file name.
> + (stderr (plist-get args :stderr))
> (tmpstderr
> (and stderr
> (tramp-unquote-file-local-name
Why that? stderr is extracted from args in tramp-skeleton-make-process.
Do you get an error which shows the problem?
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71709; Package
emacs.
(Sat, 22 Jun 2024 07:11:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 71709 <at> debbugs.gnu.org (full text, mbox):
Hello Michael,
Yes, you are right, of course :) Okay, I didn't notice that `stderr'
is extracted earlier.
-----
After updating emacs today I got strange errors while running
consult-find in a remote container, for example:
```
/usr/bin/cat: /tmp/tramp.gBbQP1: No such file or directory
/usr/bin/cat: /tmp/tramp.SWKx2Y: No such file or directory
```
I checked the consult-find (which also points out to a "tramp bug"),
then I checked the tramp's latest changes and applied that one-line
from the patch, which fixed my issue.
(In fact that line `(stderr (plist-get args :stderr))' actually
nullifies the `stderr', so probably that's why it worked and I had a
feeling that it is a solution)
Please see below:
* consult-find: https://github.com/minad/consult/blob/main/consult.el#L4965
* consult--async-process:
https://github.com/minad/consult/blob/main/consult.el#L2287C1-L2296C69
I guess, to reproduce the issue, it's enough to invoke `make-process'
on a remote location and with a non-nil `:stderr' argument (a buffer
in `consult-find''s case).
Kind Regards,
Iurie
On Fri, 21 Jun 2024 at 21:21, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Iurie Marian <marian.iurie <at> gmail.com> writes:
>
> Hi,
>
> > tramp-sh-handle-make-process is failing when `:stderr' argument is
> > used.
> >
> > In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> > 3.24.41, cairo version 1.18.0) of 2024-06-21 built on rrouwprlc0222
> > Repository revision: e7123edfe7f7abc9043429dfb3f84941f83d6565
> > Repository branch: master
> > System Description: Ubuntu 24.04 LTS
> >
> > diff --git a/lisp/net/tramp-sh.el b/lisp/net/tramp-sh.el
> > index bce7c323dad..68018298b68 100644
> > --- a/lisp/net/tramp-sh.el
> > +++ b/lisp/net/tramp-sh.el
> > @@ -2969,6 +2969,7 @@ tramp-sh-handle-make-process
> > (let* ((program (car command))
> > (args (cdr command))
> > ;; STDERR can also be a file name.
> > + (stderr (plist-get args :stderr))
> > (tmpstderr
> > (and stderr
> > (tramp-unquote-file-local-name
>
> Why that? stderr is extracted from args in tramp-skeleton-make-process.
>
> Do you get an error which shows the problem?
>
> Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71709; Package
emacs.
(Sat, 22 Jun 2024 07:32:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 71709 <at> debbugs.gnu.org (full text, mbox):
Iurie Marian <marian.iurie <at> gmail.com> writes:
> Hello Michael,
Hi Iurie,
> After updating emacs today I got strange errors while running
> consult-find in a remote container, for example:
> ```
> /usr/bin/cat: /tmp/tramp.gBbQP1: No such file or directory
> /usr/bin/cat: /tmp/tramp.SWKx2Y: No such file or directory
> ```
>
> I checked the consult-find (which also points out to a "tramp bug"),
> then I checked the tramp's latest changes and applied that one-line
> from the patch, which fixed my issue.
> (In fact that line `(stderr (plist-get args :stderr))' actually
> nullifies the `stderr', so probably that's why it worked and I had a
> feeling that it is a solution)
>
> Please see below:
> * consult-find: https://github.com/minad/consult/blob/main/consult.el#L4965
> * consult--async-process:
> https://github.com/minad/consult/blob/main/consult.el#L2287C1-L2296C69
Sorry, I don't use consult, and I don't know its code. If we want to
hunt a Tramp bug, we should run a use case with vanilla Emacs, invoking
Tramp's remote make-process.
> I guess, to reproduce the issue, it's enough to invoke `make-process'
> on a remote location and with a non-nil `:stderr' argument (a buffer
> in `consult-find''s case).
Tramp has a very comprehensive test library, see .../test/lisp/net/tramp-tests.el
The test case tramp-test30-make-process runs extensive tests over
make-process, including a non-empty stderr. And of course, I always run
the whole testsuite before I commit serious Tramp changes.
So pls show a recipe how to reproduce the problem, starting with 'emacs
-Q'. And pls contact the consult author(s); they might report a Tramp
problem when they detect such.
> Kind Regards,
> Iurie
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71709; Package
emacs.
(Sat, 22 Jun 2024 11:14:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 71709 <at> debbugs.gnu.org (full text, mbox):
Hello Michael,
Could you please try the below snippet?
Evaluate it in a local and _remote_ buffer.
```
;; -*- lexical-binding: t; -*-
(let ((.test-buffer (get-buffer-create "*test buffer*"))
(.remote? (file-remote-p default-directory)))
(with-current-buffer .test-buffer
(goto-char (max-char))
(insert "====================\n")
(insert (if .remote? "Remote:\n" "Local :\n")))
(make-process :file-handler t
:connection-type 'pipe
:name "test proc"
:stderr .test-buffer
:noquery t
:command (list "echo" "Hello!")
:filter (lambda (proc str)
(with-current-buffer .test-buffer
(goto-char (max-char))
(insert "test proc output: " str)))))
```
I get the below output:
```
====================
Local :
Process test proc stderr finished
test proc output: Hello!
====================
Remote:
/usr/bin/cat: /tmp/tramp.J0RZDc: No such file or directory
```
I would expect "Hello!" output from _remote_ as well. Isn't it?
It seems that the process is not executed and the output
"/usr/bin/cat: /tmp/tramp.J0RZDc: No such file or directory" is from
stderr.
Kind Regards,
Iurie
On Sat, 22 Jun 2024 at 09:31, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Iurie Marian <marian.iurie <at> gmail.com> writes:
>
> > Hello Michael,
>
> Hi Iurie,
>
> > After updating emacs today I got strange errors while running
> > consult-find in a remote container, for example:
> > ```
> > /usr/bin/cat: /tmp/tramp.gBbQP1: No such file or directory
> > /usr/bin/cat: /tmp/tramp.SWKx2Y: No such file or directory
> > ```
> >
> > I checked the consult-find (which also points out to a "tramp bug"),
> > then I checked the tramp's latest changes and applied that one-line
> > from the patch, which fixed my issue.
> > (In fact that line `(stderr (plist-get args :stderr))' actually
> > nullifies the `stderr', so probably that's why it worked and I had a
> > feeling that it is a solution)
> >
> > Please see below:
> > * consult-find: https://github.com/minad/consult/blob/main/consult.el#L4965
> > * consult--async-process:
> > https://github.com/minad/consult/blob/main/consult.el#L2287C1-L2296C69
>
> Sorry, I don't use consult, and I don't know its code. If we want to
> hunt a Tramp bug, we should run a use case with vanilla Emacs, invoking
> Tramp's remote make-process.
>
> > I guess, to reproduce the issue, it's enough to invoke `make-process'
> > on a remote location and with a non-nil `:stderr' argument (a buffer
> > in `consult-find''s case).
>
> Tramp has a very comprehensive test library, see .../test/lisp/net/tramp-tests.el
> The test case tramp-test30-make-process runs extensive tests over
> make-process, including a non-empty stderr. And of course, I always run
> the whole testsuite before I commit serious Tramp changes.
>
> So pls show a recipe how to reproduce the problem, starting with 'emacs
> -Q'. And pls contact the consult author(s); they might report a Tramp
> problem when they detect such.
>
> > Kind Regards,
> > Iurie
>
> Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71709; Package
emacs.
(Sat, 22 Jun 2024 11:14:03 GMT)
Full text and
rfc822 format available.
Message #20 received at 71709 <at> debbugs.gnu.org (full text, mbox):
Might it be related to the ~:connection-type 'pipe~?
If I remove it I get the expected results.
Many thanks
Iurie
On Sat, 22 Jun 2024 at 11:10, Iurie Marian <marian.iurie <at> gmail.com> wrote:
>
> Hello Michael,
>
> Could you please try the below snippet?
> Evaluate it in a local and _remote_ buffer.
> ```
> ;; -*- lexical-binding: t; -*-
>
> (let ((.test-buffer (get-buffer-create "*test buffer*"))
> (.remote? (file-remote-p default-directory)))
> (with-current-buffer .test-buffer
> (goto-char (max-char))
> (insert "====================\n")
> (insert (if .remote? "Remote:\n" "Local :\n")))
>
> (make-process :file-handler t
> :connection-type 'pipe
> :name "test proc"
> :stderr .test-buffer
> :noquery t
> :command (list "echo" "Hello!")
> :filter (lambda (proc str)
> (with-current-buffer .test-buffer
> (goto-char (max-char))
> (insert "test proc output: " str)))))
> ```
>
> I get the below output:
> ```
> ====================
> Local :
>
> Process test proc stderr finished
> test proc output: Hello!
> ====================
> Remote:
> /usr/bin/cat: /tmp/tramp.J0RZDc: No such file or directory
> ```
>
> I would expect "Hello!" output from _remote_ as well. Isn't it?
> It seems that the process is not executed and the output
> "/usr/bin/cat: /tmp/tramp.J0RZDc: No such file or directory" is from
> stderr.
>
> Kind Regards,
> Iurie
>
>
> On Sat, 22 Jun 2024 at 09:31, Michael Albinus <michael.albinus <at> gmx.de> wrote:
> >
> > Iurie Marian <marian.iurie <at> gmail.com> writes:
> >
> > > Hello Michael,
> >
> > Hi Iurie,
> >
> > > After updating emacs today I got strange errors while running
> > > consult-find in a remote container, for example:
> > > ```
> > > /usr/bin/cat: /tmp/tramp.gBbQP1: No such file or directory
> > > /usr/bin/cat: /tmp/tramp.SWKx2Y: No such file or directory
> > > ```
> > >
> > > I checked the consult-find (which also points out to a "tramp bug"),
> > > then I checked the tramp's latest changes and applied that one-line
> > > from the patch, which fixed my issue.
> > > (In fact that line `(stderr (plist-get args :stderr))' actually
> > > nullifies the `stderr', so probably that's why it worked and I had a
> > > feeling that it is a solution)
> > >
> > > Please see below:
> > > * consult-find: https://github.com/minad/consult/blob/main/consult.el#L4965
> > > * consult--async-process:
> > > https://github.com/minad/consult/blob/main/consult.el#L2287C1-L2296C69
> >
> > Sorry, I don't use consult, and I don't know its code. If we want to
> > hunt a Tramp bug, we should run a use case with vanilla Emacs, invoking
> > Tramp's remote make-process.
> >
> > > I guess, to reproduce the issue, it's enough to invoke `make-process'
> > > on a remote location and with a non-nil `:stderr' argument (a buffer
> > > in `consult-find''s case).
> >
> > Tramp has a very comprehensive test library, see .../test/lisp/net/tramp-tests.el
> > The test case tramp-test30-make-process runs extensive tests over
> > make-process, including a non-empty stderr. And of course, I always run
> > the whole testsuite before I commit serious Tramp changes.
> >
> > So pls show a recipe how to reproduce the problem, starting with 'emacs
> > -Q'. And pls contact the consult author(s); they might report a Tramp
> > problem when they detect such.
> >
> > > Kind Regards,
> > > Iurie
> >
> > Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71709; Package
emacs.
(Sat, 22 Jun 2024 11:14:04 GMT)
Full text and
rfc822 format available.
Message #23 received at 71709 <at> debbugs.gnu.org (full text, mbox):
Sorry, it's the ~:file-handler t~, not the connection-type.
Thanks
Iurie
On Sat, 22 Jun 2024 at 11:18, Iurie Marian <marian.iurie <at> gmail.com> wrote:
>
> Might it be related to the ~:connection-type 'pipe~?
> If I remove it I get the expected results.
>
> Many thanks
> Iurie
>
> On Sat, 22 Jun 2024 at 11:10, Iurie Marian <marian.iurie <at> gmail.com> wrote:
> >
> > Hello Michael,
> >
> > Could you please try the below snippet?
> > Evaluate it in a local and _remote_ buffer.
> > ```
> > ;; -*- lexical-binding: t; -*-
> >
> > (let ((.test-buffer (get-buffer-create "*test buffer*"))
> > (.remote? (file-remote-p default-directory)))
> > (with-current-buffer .test-buffer
> > (goto-char (max-char))
> > (insert "====================\n")
> > (insert (if .remote? "Remote:\n" "Local :\n")))
> >
> > (make-process :file-handler t
> > :connection-type 'pipe
> > :name "test proc"
> > :stderr .test-buffer
> > :noquery t
> > :command (list "echo" "Hello!")
> > :filter (lambda (proc str)
> > (with-current-buffer .test-buffer
> > (goto-char (max-char))
> > (insert "test proc output: " str)))))
> > ```
> >
> > I get the below output:
> > ```
> > ====================
> > Local :
> >
> > Process test proc stderr finished
> > test proc output: Hello!
> > ====================
> > Remote:
> > /usr/bin/cat: /tmp/tramp.J0RZDc: No such file or directory
> > ```
> >
> > I would expect "Hello!" output from _remote_ as well. Isn't it?
> > It seems that the process is not executed and the output
> > "/usr/bin/cat: /tmp/tramp.J0RZDc: No such file or directory" is from
> > stderr.
> >
> > Kind Regards,
> > Iurie
> >
> >
> > On Sat, 22 Jun 2024 at 09:31, Michael Albinus <michael.albinus <at> gmx.de> wrote:
> > >
> > > Iurie Marian <marian.iurie <at> gmail.com> writes:
> > >
> > > > Hello Michael,
> > >
> > > Hi Iurie,
> > >
> > > > After updating emacs today I got strange errors while running
> > > > consult-find in a remote container, for example:
> > > > ```
> > > > /usr/bin/cat: /tmp/tramp.gBbQP1: No such file or directory
> > > > /usr/bin/cat: /tmp/tramp.SWKx2Y: No such file or directory
> > > > ```
> > > >
> > > > I checked the consult-find (which also points out to a "tramp bug"),
> > > > then I checked the tramp's latest changes and applied that one-line
> > > > from the patch, which fixed my issue.
> > > > (In fact that line `(stderr (plist-get args :stderr))' actually
> > > > nullifies the `stderr', so probably that's why it worked and I had a
> > > > feeling that it is a solution)
> > > >
> > > > Please see below:
> > > > * consult-find: https://github.com/minad/consult/blob/main/consult.el#L4965
> > > > * consult--async-process:
> > > > https://github.com/minad/consult/blob/main/consult.el#L2287C1-L2296C69
> > >
> > > Sorry, I don't use consult, and I don't know its code. If we want to
> > > hunt a Tramp bug, we should run a use case with vanilla Emacs, invoking
> > > Tramp's remote make-process.
> > >
> > > > I guess, to reproduce the issue, it's enough to invoke `make-process'
> > > > on a remote location and with a non-nil `:stderr' argument (a buffer
> > > > in `consult-find''s case).
> > >
> > > Tramp has a very comprehensive test library, see .../test/lisp/net/tramp-tests.el
> > > The test case tramp-test30-make-process runs extensive tests over
> > > make-process, including a non-empty stderr. And of course, I always run
> > > the whole testsuite before I commit serious Tramp changes.
> > >
> > > So pls show a recipe how to reproduce the problem, starting with 'emacs
> > > -Q'. And pls contact the consult author(s); they might report a Tramp
> > > problem when they detect such.
> > >
> > > > Kind Regards,
> > > > Iurie
> > >
> > > Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71709; Package
emacs.
(Sat, 22 Jun 2024 11:19:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 71709 <at> debbugs.gnu.org (full text, mbox):
Iurie Marian <marian.iurie <at> gmail.com> writes:
> Hello Michael,
Hi Iurie,
> Could you please try the below snippet?
> Evaluate it in a local and _remote_ buffer.
> ```
> ;; -*- lexical-binding: t; -*-
>
> (let ((.test-buffer (get-buffer-create "*test buffer*"))
> (.remote? (file-remote-p default-directory)))
> (with-current-buffer .test-buffer
> (goto-char (max-char))
> (insert "====================\n")
> (insert (if .remote? "Remote:\n" "Local :\n")))
>
> (make-process :file-handler t
> :connection-type 'pipe
> :name "test proc"
> :stderr .test-buffer
> :noquery t
> :command (list "echo" "Hello!")
> :filter (lambda (proc str)
> (with-current-buffer .test-buffer
> (goto-char (max-char))
> (insert "test proc output: " str)))))
> ```
>
> I get the below output:
> ```
> ====================
> Local :
>
> Process test proc stderr finished
> test proc output: Hello!
> ====================
> Remote:
> /usr/bin/cat: /tmp/tramp.J0RZDc: No such file or directory
> ```
>
> I would expect "Hello!" output from _remote_ as well. Isn't it?
> It seems that the process is not executed and the output
> "/usr/bin/cat: /tmp/tramp.J0RZDc: No such file or directory" is from
> stderr.
Thanks for the recipe. I've played with it. Most cases, it works as
expected, but sometimes I see a similar error. Looks like a race
condition. I'll debug further.
> Kind Regards,
> Iurie
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71709; Package
emacs.
(Sat, 22 Jun 2024 12:03:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 71709 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Michael Albinus <michael.albinus <at> gmx.de> writes:
Hi Iurie,
> Thanks for the recipe. I've played with it. Most cases, it works as
> expected, but sometimes I see a similar error. Looks like a race
> condition. I'll debug further.
Well, I've found something suspicious in the code. Could you, pls, apply
the appended patch to tramp.el in your Emacs Lisp directory? Since it
changes a macro, you must remove all tramp*.elc files, and run 'make'
afzerwards.
>> Kind Regards,
>> Iurie
Best regards, Michael.
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71709; Package
emacs.
(Sat, 22 Jun 2024 17:06:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 71709 <at> debbugs.gnu.org (full text, mbox):
Iurie Marian <marian.iurie <at> gmail.com> writes:
Hi Iurie,
> Unfortunately, the patch doesn't help.
> By the way, this is what I noticed:
> * the issue seems to occur more often in a docker container
> * over /ssh it is working well, or at least it never occurred
> * the temporary buffers like ~/tmp/tramp.J0RZDc~ are actually created on remote
> * after repetitive tests I noticed that it doesn't reproduce anymore
> and I added a line to print the default-directory right before
> `make-process` for stderr: ~lisp/net/tramp-sh.el:3057~
> - when it fails, the default-directory is on local host
> - when it succeeds - it's on remote (where I guess it finds that
> temporary file)
But this was exactly the change I have sent to you: preserve proper default-directory.
> * on emacs restart it starts reproducing again
> * once it starts working, it never reproduces again until emacs restart
>
> It looks like it has something to do with `stderr` process execution
> environment.
Yes. Did you apply the change as I have said? That means
- Patch tramp.el inside the emacs tree
- Remove all compiled Tramp files, like 'rm lisp/net/tramp*.elc'
- Recompile EWmacs by calling 'make'.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71709; Package
emacs.
(Sat, 22 Jun 2024 17:32:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 71709 <at> debbugs.gnu.org (full text, mbox):
Unfortunately, the patch doesn't help.
By the way, this is what I noticed:
* the issue seems to occur more often in a docker container
* over /ssh it is working well, or at least it never occurred
* the temporary buffers like ~/tmp/tramp.J0RZDc~ are actually created on remote
* after repetitive tests I noticed that it doesn't reproduce anymore
and I added a line to print the default-directory right before
`make-process` for stderr: ~lisp/net/tramp-sh.el:3057~
- when it fails, the default-directory is on local host
- when it succeeds - it's on remote (where I guess it finds that
temporary file)
* on emacs restart it starts reproducing again
* once it starts working, it never reproduces again until emacs restart
It looks like it has something to do with `stderr` process execution
environment.
On Sat, 22 Jun 2024 at 14:02, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
> Hi Iurie,
>
> > Thanks for the recipe. I've played with it. Most cases, it works as
> > expected, but sometimes I see a similar error. Looks like a race
> > condition. I'll debug further.
>
> Well, I've found something suspicious in the code. Could you, pls, apply
> the appended patch to tramp.el in your Emacs Lisp directory? Since it
> changes a macro, you must remove all tramp*.elc files, and run 'make'
> afzerwards.
>
> >> Kind Regards,
> >> Iurie
>
> Best regards, Michael.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71709; Package
emacs.
(Sat, 22 Jun 2024 17:32:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 71709 <at> debbugs.gnu.org (full text, mbox):
Alright, yes last time I've only applied the patch in *.el file and
evaluated the buffer :D
I've recompiled from scratch and it works as expected! :)
Many thanks!
Iurie
On Sat, 22 Jun 2024 at 19:05, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Iurie Marian <marian.iurie <at> gmail.com> writes:
>
> Hi Iurie,
>
> > Unfortunately, the patch doesn't help.
> > By the way, this is what I noticed:
> > * the issue seems to occur more often in a docker container
> > * over /ssh it is working well, or at least it never occurred
> > * the temporary buffers like ~/tmp/tramp.J0RZDc~ are actually created on remote
> > * after repetitive tests I noticed that it doesn't reproduce anymore
> > and I added a line to print the default-directory right before
> > `make-process` for stderr: ~lisp/net/tramp-sh.el:3057~
> > - when it fails, the default-directory is on local host
> > - when it succeeds - it's on remote (where I guess it finds that
> > temporary file)
>
> But this was exactly the change I have sent to you: preserve proper default-directory.
>
> > * on emacs restart it starts reproducing again
> > * once it starts working, it never reproduces again until emacs restart
> >
> > It looks like it has something to do with `stderr` process execution
> > environment.
>
> Yes. Did you apply the change as I have said? That means
>
> - Patch tramp.el inside the emacs tree
> - Remove all compiled Tramp files, like 'rm lisp/net/tramp*.elc'
> - Recompile EWmacs by calling 'make'.
>
> Best regards, Michael.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>:
You have taken responsibility.
(Sat, 22 Jun 2024 17:56:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Iurie Marian <marian.iurie <at> gmail.com>:
bug acknowledged by developer.
(Sat, 22 Jun 2024 17:56:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 71709-done <at> debbugs.gnu.org (full text, mbox):
Version: 30.1
Iurie Marian <marian.iurie <at> gmail.com> writes:
Hi Iurie,
> Alright, yes last time I've only applied the patch in *.el file and
> evaluated the buffer :D
>
> I've recompiled from scratch and it works as expected! :)
Thanks for the feedback, so we've got it. Thanks also for your
testing. I've pushed the patch to the repositories, closing the bug.
> Many thanks!
> Iurie
Best regards, Michael.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 21 Jul 2024 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 19 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.