bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[alexis purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 5582 bytes --]

As the the title says, whenever I try to do project-find-* on a project that uses the podman TRAMP method, it spits out an error and otherwise does nothing. Here's the backtrace:

```
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  split-string(nil "\0" t)
  project--vc-list-files("/podman:development:~/Development/embryo-engine/" Git nil)
  #f(compiled-function (dir) #<bytecode -0x443eb4e00f15eb4>)("/podman:development:~/Development/embryo-engine/")
  mapcan(#f(compiled-function (dir) #<bytecode -0x443eb4e00f15eb4>) ("/podman:development:~/Development/embryo-engine/"))
  #f(compiled-function (project &optional dirs) #<bytecode 0xe73db4877a27b8>)((vc Git "/podman:development:~/Development/embryo-engine/") ("/podman:development:~/Development/embryo-engine/"))
  apply(#f(compiled-function (project &optional dirs) #<bytecode 0xe73db4877a27b8>) (vc Git "/podman:development:~/Development/embryo-engine/") ("/podman:development:~/Development/embryo-engine/"))
  project-files((vc Git "/podman:development:~/Development/embryo-engine/") ("/podman:development:~/Development/embryo-engine/"))
  project-find-file-in(nil ("/podman:development:~/Development/embryo-engine/") (vc Git "/podman:development:~/Development/embryo-engine/") nil)
  project-find-file()
  #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_62>("/podman:development:~/Development/embryo-engine/")
  funcall(#<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_62> "/podman:development:~/Development/embryo-engine/")
  (lambda (&rest _) (funcall (dashboard-projects-backend-switch-function) (dashboard-expand-path-alist "0|/podman:development:~/Development/embryo-engine/" dashboard-projects-alist)))((item :tag #(" /podman:development:~/Development/embryo-engine/" 0 1 (rear-nonsticky t display (raise 0.01) font-lock-face (:family "Symbols Nerd Font Mono" :height 1.0) face (:family "Symbols Nerd Font Mono" :height 1.0))) :action (lambda (&rest _) (funcall (dashboard-projects-backend-switch-function) (dashboard-expand-path-alist "0|/podman:development:~/Development/embryo-engine/" dashboard-projects-alist))) :button-face dashboard-items-face :mouse-face highlight :button-prefix "" :button-suffix "" :format "%[%t%]" :button-overlay #<overlay from 706 to 756 in *dashboard*> :from #<marker (moves after insertion) at 706 in *dashboard*> :to #<marker at 756 in *dashboard*>) nil)
  widget-apply-action((item :tag #(" /podman:development:~/Development/embryo-engine/" 0 1 (rear-nonsticky t display (raise 0.01) font-lock-face (:family "Symbols Nerd Font Mono" :height 1.0) face (:family "Symbols Nerd Font Mono" :height 1.0))) :action (lambda (&rest _) (funcall (dashboard-projects-backend-switch-function) (dashboard-expand-path-alist "0|/podman:development:~/Development/embryo-engine/" dashboard-projects-alist))) :button-face dashboard-items-face :mouse-face highlight :button-prefix "" :button-suffix "" :format "%[%t%]" :button-overlay #<overlay from 706 to 756 in *dashboard*> :from #<marker (moves after insertion) at 706 in *dashboard*> :to #<marker at 756 in *dashboard*>) nil)
  widget-button-press(706)
  evil-ret-gen(nil nil)
  evil-ret(nil)
  funcall-interactively(evil-ret nil)
  command-execute(evil-ret)
```

I have a weird little snippet of code to fix it, and a sort-of analysis of what I think is wrong, here: https://gist.github.com/alexispurslane/890ea9971787c979f8c59c8decf132c4. However, this fix is half-baked currently.

Here's my emacs info:

```
Basic Info: 

GNU Emacs 29.3 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
3.24.41, cairo version 1.18.0) of 2024-04-25

Build Flags:
"--build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-cairo --with-dbus --with-gif --with-gpm=no --with-harfbuzz --with-jpeg --with-json --with-modules --with-native-compilation=aot --with-pgtk --with-png --with-rsvg --with-sqlite3 --with-tiff --with-tree-sitter --with-webp --with-xpm --with-xwidgets build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer ' LDFLAGS=-Wl,-z,relro PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig CXX=g++ 'CXXFLAGS=-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '"
```

This seems like it is probably a bug, and not just user error, so I hope this helps.

Don't hesitate to let me know if you need more info.

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

alexis purslane via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

Hi Alexis,

> I have a weird little snippet of code to fix it, and a sort-of
> analysis of what I think is wrong, here:
> https://gist.github.com/alexispurslane/890ea9971787c979f8c59c8decf132c4. However,
> this fix is half-baked currently.

I cannot contribute to a solution in project.el. But your workaround
would be much simpler if you use `file-local-name', instead of parsing
the remote file name yourself.

Please let me know if you believe there's something wrong in Tramp which
must be fixed.

Best regards, Michael.

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[alexis purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 1034 bytes --]

Thank you! Apologies for the mislabel, I was quite tired at the time. I'll continue to iterate on my monkey-patch until maybe hopefully it just turns into a generally applicable solution I can contribute.

-------- Original Message --------
On 5/26/24 4:11 AM, Michael Albinus <michael.albinus@gmx.de> wrote:

>  alexis purslane via "Bug reports for GNU Emacs, the Swiss army knife of
>  text editors" <bug-gnu-emacs@gnu.org> writes:
>  
>  Hi Alexis,
>  
>  > I have a weird little snippet of code to fix it, and a sort-of
>  > analysis of what I think is wrong, here:
>  > https://gist.github.com/alexispurslane/890ea9971787c979f8c59c8decf132c4. However,
>  > this fix is half-baked currently.
>  
>  I cannot contribute to a solution in project.el. But your workaround
>  would be much simpler if you use `file-local-name', instead of parsing
>  the remote file name yourself.
>  
>  Please let me know if you believe there's something wrong in Tramp which
>  must be fixed.
>  
>  Best regards, Michael.
>  

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 701 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Dmitry Gutov]

Hi Michael,

On 26/05/2024 11:11, Michael Albinus via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> I cannot contribute to a solution in project.el. But your workaround
> would be much simpler if you use `file-local-name', instead of parsing
> the remote file name yourself.
> 
> Please let me know if you believe there's something wrong in Tramp which
> must be fixed.

 From what I understand this scenario only fails when using the 'podman' 
transport, but not 'ssh' transport - I'm using project-find-file and 
related commands over Tramp with no problem.

That makes it a Tramp bug, doesn't it? Somewhere in podman support code.

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Hi Michael,

Hi Dmitry,

> From what I understand this scenario only fails when using the
> 'podman' transport, but not 'ssh' transport - I'm using
> project-find-file and related commands over Tramp with no problem.
>
> That makes it a Tramp bug, doesn't it? Somewhere in podman support code.

In this case, I need a step-by-step recipe, starting with "emacs -Q".

Best regards, Michael.

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[alexis purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 643 bytes --]

I'll get to this as soon as I can :)

-------- Original Message --------
On 5/26/24 11:33 AM, Michael Albinus <michael.albinus@gmx.de> wrote:

>  Dmitry Gutov <dmitry@gutov.dev> writes:
>  
>  > Hi Michael,
>  
>  Hi Dmitry,
>  
>  > From what I understand this scenario only fails when using the
>  > 'podman' transport, but not 'ssh' transport - I'm using
>  > project-find-file and related commands over Tramp with no problem.
>  >
>  > That makes it a Tramp bug, doesn't it? Somewhere in podman support code.
>  
>  In this case, I need a step-by-step recipe, starting with "emacs -Q".
>  
>  Best regards, Michael.
>  

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 701 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[alexis purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 1276 bytes --]

As it happens (and I can hardly believe this, this is the second bug
I've reported that has ended like this) without /any/ changes of my own
whatsoever to my config, just deleting my ~/.emacs.d/ completely and
then recloning my config from git (minus the code snipped I posted
above to fix the issue I was having), the problem has... utterly
disappeared, as far as I can tell. Many apologies for the, seemingly,
false alarm, and I'll follow up with replication steps if I'm ever able
to replicate this.

On Sunday, May 26th, 2024 at 3:35 PM, alexis purslane <alexispurslane@pm.me> wrote:

> I'll get to this as soon as I can :)
> 

> -------- Original Message --------
> On 5/26/24 11:33 AM, Michael Albinus michael.albinus@gmx.de wrote:
> 

> > Dmitry Gutov dmitry@gutov.dev writes:
> > 

> > > Hi Michael,
> > 

> > Hi Dmitry,
> > 

> > > From what I understand this scenario only fails when using the
> > > 'podman' transport, but not 'ssh' transport - I'm using
> > > project-find-file and related commands over Tramp with no problem.
> > > 

> > > That makes it a Tramp bug, doesn't it? Somewhere in podman support code.
> > 

> > In this case, I need a step-by-step recipe, starting with "emacs -Q".
> > 

> > Best regards, Michael.

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[alexis purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 1920 bytes --]

Scratch that, it's back. Steps:

1. run emacs -Q
2. Do {C-x p p}
3. Enter `...` to add a new project
4. Enter a podman container location such as: /podman:texlive-latest:Documents/Awesome-CV/
5. Hit {ENT}, then {f}
6. Error happens.

For comparison, you can do:

7. {M-x eshell}
8. `cd /podman:texlive-latest:Documents/Awesome-CV/`
9. Do ls, find-file, whatever you like, watch it work perfectly
10. Do `podman exec -it  texlive-latest bash`
11. See that work perfectly.



On Sunday, May 26th, 2024 at 5:07 PM, alexis purslane <alexispurslane@pm.me> wrote:

> As it happens (and I can hardly believe this, this is the second bug
> I've reported that has ended like this) without /any/ changes of my own
> whatsoever to my config, just deleting my ~/.emacs.d/ completely and
> then recloning my config from git (minus the code snipped I posted
> above to fix the issue I was having), the problem has... utterly
> disappeared, as far as I can tell. Many apologies for the, seemingly,
> false alarm, and I'll follow up with replication steps if I'm ever able
> to replicate this.
> 

> On Sunday, May 26th, 2024 at 3:35 PM, alexis purslane alexispurslane@pm.me wrote:
> 

> > I'll get to this as soon as I can :)
> > 

> > -------- Original Message --------
> > On 5/26/24 11:33 AM, Michael Albinus michael.albinus@gmx.de wrote:
> > 

> > > Dmitry Gutov dmitry@gutov.dev writes:
> > > 

> > > > Hi Michael,
> > > 

> > > Hi Dmitry,
> > > 

> > > > From what I understand this scenario only fails when using the
> > > > 'podman' transport, but not 'ssh' transport - I'm using
> > > > project-find-file and related commands over Tramp with no problem.
> > > > 

> > > > That makes it a Tramp bug, doesn't it? Somewhere in podman support code.
> > > 

> > > In this case, I need a step-by-step recipe, starting with "emacs -Q".
> > > 

> > > Best regards, Michael.

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[alexis purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 2324 bytes --]

So on one of my containers project.el works (thats why I thought the problem went away), but on the other two it doesn't. Just figured out what it was: the other two don't have git installed at all.

On Sunday, May 26th, 2024 at 5:14 PM, alexis purslane <alexispurslane@pm.me> wrote:

> Scratch that, it's back. Steps:
> 

> 1. run emacs -Q
> 2. Do {C-x p p}
> 3. Enter `...` to add a new project
> 4. Enter a podman container location such as: /podman:texlive-latest:Documents/Awesome-CV/
> 5. Hit {ENT}, then {f}
> 6. Error happens.
> 

> For comparison, you can do:
> 

> 7. {M-x eshell}
> 8. `cd /podman:texlive-latest:Documents/Awesome-CV/`
> 9. Do ls, find-file, whatever you like, watch it work perfectly
> 10. Do `podman exec -it texlive-latest bash`
> 11. See that work perfectly.
> 

> 

> 

> On Sunday, May 26th, 2024 at 5:07 PM, alexis purslane alexispurslane@pm.me wrote:
> 

> > As it happens (and I can hardly believe this, this is the second bug
> > I've reported that has ended like this) without /any/ changes of my own
> > whatsoever to my config, just deleting my ~/.emacs.d/ completely and
> > then recloning my config from git (minus the code snipped I posted
> > above to fix the issue I was having), the problem has... utterly
> > disappeared, as far as I can tell. Many apologies for the, seemingly,
> > false alarm, and I'll follow up with replication steps if I'm ever able
> > to replicate this.
> > 

> > On Sunday, May 26th, 2024 at 3:35 PM, alexis purslane alexispurslane@pm.me wrote:
> > 

> > > I'll get to this as soon as I can :)
> > > 

> > > -------- Original Message --------
> > > On 5/26/24 11:33 AM, Michael Albinus michael.albinus@gmx.de wrote:
> > > 

> > > > Dmitry Gutov dmitry@gutov.dev writes:
> > > > 

> > > > > Hi Michael,
> > > > 

> > > > Hi Dmitry,
> > > > 

> > > > > From what I understand this scenario only fails when using the
> > > > > 'podman' transport, but not 'ssh' transport - I'm using
> > > > > project-find-file and related commands over Tramp with no problem.
> > > > > 

> > > > > That makes it a Tramp bug, doesn't it? Somewhere in podman support code.
> > > > 

> > > > In this case, I need a step-by-step recipe, starting with "emacs -Q".
> > > > 

> > > > Best regards, Michael.

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[alexis purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 2897 bytes --]

Actually, no, installing git does not help resolve the problem whatsoever. One works, the other two don't, but I can't tell why. The one that works is my general purpose development container, and the other two are more specialized, so that may be the origin of the problem, but it doesn't explain what in particular is missing. What does project.el rely on the host having installed?

On Sunday, May 26th, 2024 at 5:19 PM, alexis purslane <alexispurslane@pm.me> wrote:

> So on one of my containers project.el works (thats why I thought the problem went away), but on the other two it doesn't. Just figured out what it was: the other two don't have git installed at all.
> 

> On Sunday, May 26th, 2024 at 5:14 PM, alexis purslane alexispurslane@pm.me wrote:
> 

> > Scratch that, it's back. Steps:
> > 

> > 1. run emacs -Q
> > 2. Do {C-x p p}
> > 3. Enter `...` to add a new project
> > 4. Enter a podman container location such as: /podman:texlive-latest:Documents/Awesome-CV/
> > 5. Hit {ENT}, then {f}
> > 6. Error happens.
> > 

> > For comparison, you can do:
> > 

> > 7. {M-x eshell}
> > 8. `cd /podman:texlive-latest:Documents/Awesome-CV/`
> > 9. Do ls, find-file, whatever you like, watch it work perfectly
> > 10. Do `podman exec -it texlive-latest bash`
> > 11. See that work perfectly.
> > 

> > On Sunday, May 26th, 2024 at 5:07 PM, alexis purslane alexispurslane@pm.me wrote:
> > 

> > > As it happens (and I can hardly believe this, this is the second bug
> > > I've reported that has ended like this) without /any/ changes of my own
> > > whatsoever to my config, just deleting my ~/.emacs.d/ completely and
> > > then recloning my config from git (minus the code snipped I posted
> > > above to fix the issue I was having), the problem has... utterly
> > > disappeared, as far as I can tell. Many apologies for the, seemingly,
> > > false alarm, and I'll follow up with replication steps if I'm ever able
> > > to replicate this.
> > > 

> > > On Sunday, May 26th, 2024 at 3:35 PM, alexis purslane alexispurslane@pm.me wrote:
> > > 

> > > > I'll get to this as soon as I can :)
> > > > 

> > > > -------- Original Message --------
> > > > On 5/26/24 11:33 AM, Michael Albinus michael.albinus@gmx.de wrote:
> > > > 

> > > > > Dmitry Gutov dmitry@gutov.dev writes:
> > > > > 

> > > > > > Hi Michael,
> > > > > 

> > > > > Hi Dmitry,
> > > > > 

> > > > > > From what I understand this scenario only fails when using the
> > > > > > 'podman' transport, but not 'ssh' transport - I'm using
> > > > > > project-find-file and related commands over Tramp with no problem.
> > > > > > 

> > > > > > That makes it a Tramp bug, doesn't it? Somewhere in podman support code.
> > > > > 

> > > > > In this case, I need a step-by-step recipe, starting with "emacs -Q".
> > > > > 

> > > > > Best regards, Michael.

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Dmitry Gutov]

On 26/05/2024 20:21, alexis purslane wrote:
> Actually, no, installing git does not help resolve the problem
> whatsoever. One works, the other two don't, but I can't tell why. The
> one that works is my general purpose development container, and the
> other two are more specialized, so that may be the origin of the
> problem, but it doesn't explain what in particular is missing. What does
>   project.el rely on the host having installed?

project-find-file just uses 'git ls-files' if it's in a repository, or 
'find' otherwise.

If your file name string juggling made things work correctly, it seems 
unlikely that the problem is in some missing software on the remote host.

Does the ssh transport work with the "more specialized" containers?

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[alexis purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 1397 bytes --]

> Does the ssh transport work with the "more specialized" containers?

It took me a bit to get that set up, but no, it doesn't. Did essentially this:

https://linuxhandbook.com/ssh-into-container/

Created a directory with some files in it in the homedir of the container,
and then added the project with the location as `/ssh:root@localhost#7655:Folder`.
It found the folder just fine (eg showed up in completion), but when I added 

it and did project-find-files, I got the same error as usual.

On Sunday, May 26th, 2024 at 5:26 PM, Dmitry Gutov <dmitry@gutov.dev> wrote:

> On 26/05/2024 20:21, alexis purslane wrote:
> 

> > Actually, no, installing git does not help resolve the problem
> > whatsoever. One works, the other two don't, but I can't tell why. The
> > one that works is my general purpose development container, and the
> > other two are more specialized, so that may be the origin of the
> > problem, but it doesn't explain what in particular is missing. What does
> > project.el rely on the host having installed?
> 

> 

> project-find-file just uses 'git ls-files' if it's in a repository, or
> 'find' otherwise.
> 

> If your file name string juggling made things work correctly, it seems
> unlikely that the problem is in some missing software on the remote host.
> 

> Does the ssh transport work with the "more specialized" containers?

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[alexis purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 2439 bytes --]

Follow up:

I have these containers installed:

1. devcontainers/rust:latest
2. devcontainers/typescript-node:latest
3. devcontainers/cpp:latest
4. texlive/texlive:latest
5. tensorflow/tensorflow:latest-gpu

Only one of them wor--

....

Oh.

Git keeps "detecting dubious ownership" over each project's
.git/
for some reason, which prevents `git ls-files` from running,
hence the
problem. So this isn't really a bug per-se, it's more like a lack
of
clear enough errors.

I could also really use some help with getting the ownership and
gpg & ssh
keychain stuff (commits always fail because Magit over TRAMP can't
access my GPG or SSH private keys) figured out over TRAMP but I can get that help
elsewhere.

Anyway, when git ls-files fails, maybe the stderr output it
produced should be
printed instead of just trying to parse its empty stdin and
crashing.

On Sunday, May 26th, 2024 at 5:46 PM, alexis purslane <alexispurslane@pm.me> wrote:

> > Does the ssh transport work with the "more specialized" containers?
> 

> 

> It took me a bit to get that set up, but no, it doesn't. Did essentially this:
> 

> https://linuxhandbook.com/ssh-into-container/
> 

> Created a directory with some files in it in the homedir of the container,
> and then added the project with the location as `/ssh:root@localhost#7655:Folder`.
> It found the folder just fine (eg showed up in completion), but when I added
> it and did project-find-files, I got the same error as usual.
> 

> On Sunday, May 26th, 2024 at 5:26 PM, Dmitry Gutov dmitry@gutov.dev wrote:
> 

> > On 26/05/2024 20:21, alexis purslane wrote:
> > 

> > > Actually, no, installing git does not help resolve the problem
> > > whatsoever. One works, the other two don't, but I can't tell why. The
> > > one that works is my general purpose development container, and the
> > > other two are more specialized, so that may be the origin of the
> > > problem, but it doesn't explain what in particular is missing. What does
> > > project.el rely on the host having installed?
> > 

> > project-find-file just uses 'git ls-files' if it's in a repository, or
> > 'find' otherwise.
> > 

> > If your file name string juggling made things work correctly, it seems
> > unlikely that the problem is in some missing software on the remote host.
> > 

> > Does the ssh transport work with the "more specialized" containers?

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Dmitry Gutov]

On 27/05/2024 00:43, alexis purslane wrote:
> Follow up:
> 
> I have these containers installed:
> 
> 1. devcontainers/rust:latest
> 2. devcontainers/typescript-node:latest
> 3. devcontainers/cpp:latest
> 4. texlive/texlive:latest
> 5. tensorflow/tensorflow:latest-gpu
> 
> Only one of them wor--
> 
> ....
> 
> Oh.
> 
> Git keeps "detecting dubious ownership" over each project's
> .git/
> for some reason, which prevents `git ls-files` from running,

That's possible.

> hence the
> problem. So this isn't really a bug per-se, it's more like a lack
> of
> clear enough errors.

Yep. Poor error reporting came up not too long ago, and it's improved on 
master: 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8d3e4e823f21d5a

I have now bumped the version headers for xref.el and project.el.

Try installing project 0.11.0 (it will be out on ELPA sometime in the 
next 24 hours), the errors should be easier to understand now.

> I could also really use some help with getting the ownership and
> gpg & ssh
> keychain stuff (commits always fail because Magit over TRAMP can't
> access my GPG or SSH private keys) figured out over TRAMP but I can get that help
> elsewhere.

Looking around the internet, it seems the error "detecting dubious 
ownership" comes down to file ownership - here's one of the possible 
solutions (https://askubuntu.com/a/1445820), but there are several 
different approaches being recommended in different SO and SE answers.

To make a commit, you just need to have git config for user.name and 
user.email on the working machine - ssh keys are usually not required 
unless you're trying to sign commits as well.

It's pushing commits to a remote (or pulling, or cloning) that usually 
becomes a problem. Over ssh, one usually solves that by enabling 
"authentication agent forwarding" - logging in with "ssh -A'.

I'm not sure what is the preferred solution when using podman, but 
here's an article that describes sharing your .ssh directory with the 
container: 
https://devcodef1.com/news/1088795/ssh-agent-forwarding-in-podman-container 
(step number 3).

Of course that's only safe if you're the only one with access to it.

> Anyway, when git ls-files fails, maybe the stderr output it
> produced should be
> printed instead of just trying to parse its empty stdin and
> crashing.

Let me know how how it works for you.

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[alexis purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 3224 bytes --]

Thanks for the detailed response! Re: ssh keys and committing, I knew that, sorry for my unclear phrasing --- lack of sharing ssh keys was making pushing fail, and lack of sharing gpg keys was making committing fail (I sign my commits with my private key). I'm working on ssh forwarding right now, although trying to sort of skip out on the whole thing by creating a tramp-method for distrobox and letting distrobox do it for me. I'll update to the new project.el soonish and let you know if the errors work better!

On Sunday, May 26th, 2024 at 10:44 PM, Dmitry Gutov <dmitry@gutov.dev> wrote:

> On 27/05/2024 00:43, alexis purslane wrote:
> 

> > Follow up:
> > 

> > I have these containers installed:
> > 

> > 1. devcontainers/rust:latest
> > 2. devcontainers/typescript-node:latest
> > 3. devcontainers/cpp:latest
> > 4. texlive/texlive:latest
> > 5. tensorflow/tensorflow:latest-gpu
> > 

> > Only one of them wor--
> > 

> > ....
> > 

> > Oh.
> > 

> > Git keeps "detecting dubious ownership" over each project's
> > .git/
> > for some reason, which prevents `git ls-files` from running,
> 

> 

> That's possible.
> 

> > hence the
> > problem. So this isn't really a bug per-se, it's more like a lack
> > of
> > clear enough errors.
> 

> 

> Yep. Poor error reporting came up not too long ago, and it's improved on
> master:
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8d3e4e823f21d5a
> 

> I have now bumped the version headers for xref.el and project.el.
> 

> Try installing project 0.11.0 (it will be out on ELPA sometime in the
> next 24 hours), the errors should be easier to understand now.
> 

> > I could also really use some help with getting the ownership and
> > gpg & ssh
> > keychain stuff (commits always fail because Magit over TRAMP can't
> > access my GPG or SSH private keys) figured out over TRAMP but I can get that help
> > elsewhere.
> 

> 

> Looking around the internet, it seems the error "detecting dubious
> ownership" comes down to file ownership - here's one of the possible
> solutions (https://askubuntu.com/a/1445820), but there are several
> different approaches being recommended in different SO and SE answers.
> 

> To make a commit, you just need to have git config for user.name and
> user.email on the working machine - ssh keys are usually not required
> unless you're trying to sign commits as well.
> 

> It's pushing commits to a remote (or pulling, or cloning) that usually
> becomes a problem. Over ssh, one usually solves that by enabling
> "authentication agent forwarding" - logging in with "ssh -A'.
> 

> I'm not sure what is the preferred solution when using podman, but
> here's an article that describes sharing your .ssh directory with the
> container:
> https://devcodef1.com/news/1088795/ssh-agent-forwarding-in-podman-container
> (step number 3).
> 

> Of course that's only safe if you're the only one with access to it.
> 

> > Anyway, when git ls-files fails, maybe the stderr output it
> > produced should be
> > printed instead of just trying to parse its empty stdin and
> > crashing.
> 

> 

> Let me know how how it works for you.

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[alexis purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 4446 bytes --]

Another piece of code that may be helpful:

```
(advice-add 'project-remember-project
;; If we're about to save a project
                :before (lambda (pr &optional something)
;; If we're using git, and git detects it as "dubious" (git ls-files = 128),
                            (when (and (eq 'Git (cadr pr))
                                       (let ((default-directory (caddr pr)))
                                           (= (shell-command "git ls-files") 128)))
;; Prompt the user if they want to automatically treat it as safe!
                                (when (y-or-n-p "Dubious ownership of repository detected. Treat as safe? ")
                                    (shell-command
                                     (concat "git config --global --add safe.directory "
                                             (eshell-escape-arg (directory-file-name (file-local-name (caddr pr))))))))))
```

It basically emulates VSCode's reaction to untrusted repositories.

On Sunday, May 26th, 2024 at 10:48 PM, alexis purslane <alexispurslane@pm.me> wrote:

> Thanks for the detailed response! Re: ssh keys and committing, I knew that, sorry for my unclear phrasing --- lack of sharing ssh keys was making pushing fail, and lack of sharing gpg keys was making committing fail (I sign my commits with my private key). I'm working on ssh forwarding right now, although trying to sort of skip out on the whole thing by creating a tramp-method for distrobox and letting distrobox do it for me. I'll update to the new project.el soonish and let you know if the errors work better!
> 

> On Sunday, May 26th, 2024 at 10:44 PM, Dmitry Gutov dmitry@gutov.dev wrote:
> 

> > On 27/05/2024 00:43, alexis purslane wrote:
> > 

> > > Follow up:
> > > 

> > > I have these containers installed:
> > > 

> > > 1. devcontainers/rust:latest
> > > 2. devcontainers/typescript-node:latest
> > > 3. devcontainers/cpp:latest
> > > 4. texlive/texlive:latest
> > > 5. tensorflow/tensorflow:latest-gpu
> > > 

> > > Only one of them wor--
> > > 

> > > ....
> > > 

> > > Oh.
> > > 

> > > Git keeps "detecting dubious ownership" over each project's
> > > .git/
> > > for some reason, which prevents `git ls-files` from running,
> > 

> > That's possible.
> > 

> > > hence the
> > > problem. So this isn't really a bug per-se, it's more like a lack
> > > of
> > > clear enough errors.
> > 

> > Yep. Poor error reporting came up not too long ago, and it's improved on
> > master:
> > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8d3e4e823f21d5a
> > 

> > I have now bumped the version headers for xref.el and project.el.
> > 

> > Try installing project 0.11.0 (it will be out on ELPA sometime in the
> > next 24 hours), the errors should be easier to understand now.
> > 

> > > I could also really use some help with getting the ownership and
> > > gpg & ssh
> > > keychain stuff (commits always fail because Magit over TRAMP can't
> > > access my GPG or SSH private keys) figured out over TRAMP but I can get that help
> > > elsewhere.
> > 

> > Looking around the internet, it seems the error "detecting dubious
> > ownership" comes down to file ownership - here's one of the possible
> > solutions (https://askubuntu.com/a/1445820), but there are several
> > different approaches being recommended in different SO and SE answers.
> > 

> > To make a commit, you just need to have git config for user.name and
> > user.email on the working machine - ssh keys are usually not required
> > unless you're trying to sign commits as well.
> > 

> > It's pushing commits to a remote (or pulling, or cloning) that usually
> > becomes a problem. Over ssh, one usually solves that by enabling
> > "authentication agent forwarding" - logging in with "ssh -A'.
> > 

> > I'm not sure what is the preferred solution when using podman, but
> > here's an article that describes sharing your .ssh directory with the
> > container:
> > https://devcodef1.com/news/1088795/ssh-agent-forwarding-in-podman-container
> > (step number 3).
> > 

> > Of course that's only safe if you're the only one with access to it.
> > 

> > > Anyway, when git ls-files fails, maybe the stderr output it
> > > produced should be
> > > printed instead of just trying to parse its empty stdin and
> > > crashing.
> > 

> > Let me know how how it works for you.

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Dmitry Gutov]

On 27/05/2024 05:06, alexis purslane wrote:
> Another piece of code that may be helpful:
> 
> ```
> (advice-add 'project-remember-project
> ;; If we're about to save a project
>                  :before (lambda (pr &optional something)
> ;; If we're using git, and git detects it as "dubious" (git ls-files = 128),
>                              (when (and (eq 'Git (cadr pr))
>                                         (let ((default-directory (caddr pr)))
>                                             (= (shell-command "git ls-files") 128)))
> ;; Prompt the user if they want to automatically treat it as safe!
>                                  (when (y-or-n-p "Dubious ownership of repository detected. Treat as safe? ")
>                                      (shell-command
>                                       (concat "git config --global --add safe.directory "
>                                               (eshell-escape-arg (directory-file-name (file-local-name (caddr pr))))))))))
> ```
> 
> It basically emulates VSCode's reaction to untrusted repositories.

Sounds useful.

But if you wanted Emacs to include such functionality automatically, I'm 
not quite sure what would be the best place for it. OT1H if VS Code has 
this, it's probably not the worst idea, but OT2H it seems quite specific 
to use with containers (because in other cases you either wouldn't have 
this problem, or would solve it differently).

BTW project 0.11.0 is out, if you wanted to try it.

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

alexis purslane <alexispurslane@pm.me> writes:

Hi Alexis,

> ... trying to sort of skip out on the whole thing by creating a
> tramp-method for distrobox and letting distrobox do it for me.

Tramp 2.7 / Emacs 30 offers more container-based methods, for example
toolbox or apptainer. Would this help?

I also thought about adding distrobox, but haven't done yet. Would it
help you, if we add this together to Tramp?

Best regards, Michael.

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

alexis purslane <alexispurslane@pm.me> writes:

Hi Alexis,

> One thing: it seems like you forgot to attach the patch? My email
> program isn't seeing any attachments, nor am I seeing a patch pasted
> at the end of your message, unless I'm misunderstanding something?

Strange. Unfortunately, you have removed the Cc: during conversation, so
I cannot point to the archives :-(

I append the patch again, as attachment. And I've reintroduced the Cc,
in case you don't see the attachment, you can check the archives. Pls
keep it.

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 3632 bytes --]

diff --git a/lisp/tramp-container.el b/lisp/tramp-container.el
index 2886e25d..450ef653 100644
--- a/lisp/tramp-container.el
+++ b/lisp/tramp-container.el
@@ -76,6 +76,17 @@
 ;;
 ;;
 ;;
+;; Open a file on an existing Distrobox container:
+;;
+;;     C-x C-f /distrobox:CONTAINER:/path/to/file
+;;
+;; Where:
+;;     CONTAINER     is the container to connect to (optional).
+;;
+;; If the container is not running, it is started.
+;;
+;;
+;;
 ;; Open a file on a running Flatpak sandbox:
 ;;
 ;;     C-x C-f /flatpak:SANDBOX:/path/to/file
@@ -153,6 +164,14 @@ If it is nil, the default context will be used."
   :type '(choice (const "toolbox")
                  (string)))

+;;;###tramp-autoload
+(defcustom tramp-distrobox-program "distrobox"
+  "Name of the Distrobxx client program."
+  :group 'tramp
+  :version "30.1"
+  :type '(choice (const "distrobox")
+                 (string)))
+
 ;;;###tramp-autoload
 (defcustom tramp-flatpak-program "flatpak"
   "Name of the Flatpak client program."
@@ -202,6 +221,10 @@ This is for out-of-band connections.")
 (defconst tramp-toolbox-method "toolbox"
   "Tramp method name to use to connect to Toolbox containers.")

+;;;###tramp-autoload
+(defconst tramp-distrobox-method "distrobox"
+  "Tramp method name to use to connect to Distrobox containers.")
+
 ;;;###tramp-autoload
 (defconst tramp-flatpak-method "flatpak"
   "Tramp method name to use to connect to Flatpak sandboxes.")
@@ -391,6 +414,27 @@ see its function help for a description of the format."
                        lines)))
       (mapcar (lambda (name) (list nil name)) names))))

+;;;###tramp-autoload
+(defun tramp-distrobox--completion-function (method)
+  "List Distrobox containers available for connection.
+
+This function is used by `tramp-set-completion-function', please
+see its function help for a description of the format."
+  (tramp-skeleton-completion-function method
+    (when-let ((raw-list (shell-command-to-string (concat program " list")))
+	       ;; Ignore header line.
+               (lines (cdr (split-string raw-list "\n" 'omit)))
+               (names (tramp-compat-seq-keep
+		       (lambda (line)
+			 (when (string-match
+				(rx bol (1+ (not space))
+				    (1+ space) "|" (1+ space)
+				    (group (1+ (not space))) space)
+				line)
+			   (match-string 1 line)))
+                       lines)))
+      (mapcar (lambda (name) (list nil name)) names))))
+
 ;;;###tramp-autoload
 (defun tramp-flatpak--completion-function (method)
   "List Flatpak sandboxes available for connection.
@@ -595,6 +639,26 @@ see its function help for a description of the format."
    tramp-toolbox-method
    `((tramp-toolbox--completion-function ,tramp-toolbox-method))))

+;;;###tramp-autoload
+(defun tramp-enable-distrobox-method ()
+  "Enable connection to Distrobox containers."
+  (add-to-list 'tramp-methods
+	       `(,tramp-distrobox-method
+		 (tramp-login-program ,tramp-distrobox-program)
+		 (tramp-login-args (("enter")
+				    ("-n" "%h")
+				    ("--" "%l")))
+		 ;(tramp-direct-async (,tramp-default-remote-shell "-c"))
+		 (tramp-remote-shell ,tramp-default-remote-shell)
+		 (tramp-remote-shell-login ("-l"))
+		 (tramp-remote-shell-args ("-c"))))
+
+  (add-to-list 'tramp-completion-multi-hop-methods tramp-distrobox-method)
+
+  (tramp-set-completion-function
+   tramp-distrobox-method
+   `((tramp-distrobox--completion-function ,tramp-distrobox-method))))
+
 ;;;###tramp-autoload
 (defun tramp-enable-flatpak-method ()
   "Enable connection to Flatpak sandboxes."

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Alexis Purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 146 bytes --]

I'm so sorry I keep removing CC I'm not used to communicating over email
    like at all (post-2000s-baby problems). Thanks for being so patient!

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 701 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Alexis Purslane <alexispurslane@pm.me> writes:

Hi Alexis,

> I'm so sorry I keep removing CC I'm not used to communicating over email
>     like at all (post-2000s-baby problems). Thanks for being so patient!

Don't worry. I'm ca 45 years older, and I'm sure I do *lot* of things
today's people don't understand :-)

For example, strictly bound to email communication. No whatsapp or other
devils.

Best regards, Michael.

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[alexis purslane via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 844 bytes --]

Alright, git-cloned, patched, compiled, and loaded tramp-container.el 

and it works perfectly!! Thank you so much! :D This will be great for me
and a couple other Emacs users I know experimenting with the distrobox
workflow. 


Sent with Proton Mail secure email.

On Wednesday, May 29th, 2024 at 2:06 PM, Michael Albinus <michael.albinus@gmx.de> wrote:

> Alexis Purslane alexispurslane@pm.me writes:
> 

> 

> Hi Alexis,
> 

> > I'm so sorry I keep removing CC I'm not used to communicating over email
> > like at all (post-2000s-baby problems). Thanks for being so patient!
> 

> 

> Don't worry. I'm ca 45 years older, and I'm sure I do lot of things
> today's people don't understand :-)
> 

> For example, strictly bound to email communication. No whatsapp or other
> devils.
> 

> Best regards, Michael.

[-- Attachment #1.2: publickey - alexispurslane@pm.me - 0x41E61568.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

alexis purslane <alexispurslane@pm.me> writes:

Hi Alexis,

> Alright, git-cloned, patched, compiled, and loaded tramp-container.el
>
> and it works perfectly!! Thank you so much! :D This will be great for me

Thanks for the feedback. I've pushed this to the repositories, Tramp and Emacs.

> and a couple other Emacs users I know experimenting with the distrobox
> workflow.

Roughly planned, Tramp 2.7.1 will appear on GNU ELPA end of June. So
this will be available to the public then.

Is there anything left to do? Otherwise, I would close the bug.

Best regards, Michael.

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Version: 30.1

alexis purslane <alexispurslane@pm.me> writes:

Hi Alexis,

[you've removed the Cc again :-( ]

> I really apologize for not checking this earlier, but it didn't occur
> to me to test this, it came up naturally: if you try to enter a
> distrobox that doesn't exist, Emacs will hang and peg one CPU until
> you hit C-g. But yes I think this bug can be closed for sure

Well, I don't believe it is up to Tramp to check it. For all
container-based methods it is requested that the respective container
is running. In case of toolbox and distrobox, it is sufficient that the
container is created. If not running, it is started then.

Like the other Tramp methods, distrobox offers host name
completion. Typing "C-x C-f /distrobox: TAB" will show you existing
containers.

And yes, closing the bug. Feel free to report further problems. But
likely they won't fit to the scope of this bug report; a new bug report
would be better I believe.

Best regards, Michael.

bug#71200: TRAMP: Trying to do a project-find-file or (find-directory) using the podman method causes a (wrong-type-argument stringp nil) error

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Hi Michael,

Hi Dmitry,

> Replying in private, just in case.

No, this can be discussed publicly :-)

>>> I really apologize for not checking this earlier, but it didn't occur
>>> to me to test this, it came up naturally: if you try to enter a
>>> distrobox that doesn't exist, Emacs will hang and peg one CPU until
>>> you hit C-g. But yes I think this bug can be closed for sure
>> Well, I don't believe it is up to Tramp to check it. For all
>> container-based methods it is requested that the respective container
>> is running. In case of toolbox and distrobox, it is sufficient that the
>> container is created. If not running, it is started then.
>
> Sorry to butt in, but it seems the 'docker' transport does some
> checking. At least if I enter /docker:asdfg:RET RET (the second one to
> confirm), it shows me the error rather quickly:
>
>   Error response from daemon: No such container: asdf
>
> I guess it might be considered an implementation detail, though.

Yes, it always depends on the used client program. I'm on Fedora, so I
use the podman case as example.

--8<---------------cut here---------------start------------->8---
# podman exec -it asdf /bin/sh  -i
Error: no container with name or ID "asdf" found: no such container
--8<---------------cut here---------------end--------------->8---

podman returns immediately, and Tramp sees the failed process. But it
doesn't check anything for the error message.

--8<---------------cut here---------------start------------->8---
# distrobox enter -n asdf -- /bin/sh  -i
Error: no such container asdf
Create it now, out of image registry.fedoraproject.org/fedora-toolbox:39? [Y/n]:
--8<---------------cut here---------------end--------------->8---

distrobox fails as well, but then it asks interactively how to
continue. That's why Emacs is in an infinite loop. Again, such an error
isn't checked from Tramp yet.

Well, I have added a check to Tramp, this is detected now. Pushed to the
repositories.

Best regards, Michael.