GNU bug report logs - #79036
[PATCH] Fix pdb tracking for remote filenames

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Liu Hui <liuhui1610 <at> gmail.com>
Cc: 79036 <at> debbugs.gnu.org, kobarity <at> gmail.com, michael.albinus <at> gmx.de
Subject: bug#79036: [PATCH] Fix pdb tracking for remote filenames
Date: Fri, 18 Jul 2025 21:25:47 +0300

> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Fri, 18 Jul 2025 23:31:50 +0800
> Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> 
> On Fri, Jul 18, 2025 at 10:52 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Liu Hui <liuhui1610 <at> gmail.com>
> > > Date: Fri, 18 Jul 2025 22:06:56 +0800
> > > Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> > >
> > > On Fri, Jul 18, 2025 at 8:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > >
> > > > > file-exists-p: For a local file name in a remote python shell, we
> > > > > cannot simply distinguish whether it is a file on the remote system or
> > > > > a local file (i.e. sending code from local host), although the former
> > > > > is more likely. So we need file-exists-p for verification.
> > > >
> > > > Sorry, I don't understand the problem and its solution.  What do you
> > > > mean by "local file name in a remote python shell"?
> > >
> > > For example, below is the pdb output in a remote python shell, and the
> > > file-name "/tmp/test.py" is local. Because of the "from ... import
> > > ...", we can know the file is on the remote system.
> > >
> > >     >>> from test import f; f()
> > >     > /tmp/test.py(3)f()
> > >     -> return 1
> > >     (Pdb)
> > >
> > > However, with the following pdb output in a remote python shell
> > >
> > >     >>> f()
> > >     > /tmp/test.py(3)f()
> > >     -> return 1
> > >     (Pdb)
> > >
> > > The local filename "/tmp/test.py" may be on the remote system like the
> > > above case, or may be on the local host if we press C-c C-c to send
> > > its code to the remote process.
> > >
> > > Which file should python shell track? The simplest solution is to
> > > check which file exists.
> >
> > Doesn't the value of default-directory tells us whether it's a local
> > or a remote file?  If not, why not?
> 
> In the example:
> 
>     >>> f()
>     > /tmp/test.py(3)f()
>     -> return 1
>     (Pdb)
> 
> The current buffer is the Python shell buffer, default-directory is
> remote only means
>  python process is remote. "/tmp/test.py" may be on the local host because users
> may send code in local file "/tmp/test.py" to the remote process.

This cannot work reliably, and I don't think we should support it.
Please ignore this case in the following discussions.

> > > > > Moreover, if file doesn't exist (e.g. the original file may be
> > > > > deleted), it makes no sense to create an empty buffer/file, because we
> > > > > don't want to edit it, but to debug the code in it.
> > > >
> > > > This can be handled by other means.  But again, I don't understand why
> > > > is this important, so please elaborate.
> > >
> > > I was explaining why file-exists-p is needed. It is another possible
> > > case.
> >
> > If a file doesn't exist, debugging it will not work.  The fact that we
> > leave behind an empty buffer is not important.
> 
> Since an empty buffer is useless, why not just not show it in the
> first place? I find it disturbing.

Because it complicates the code for no good reason.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.