bug#68850: emacs: rgrep does not work over tramp

bug#68850: emacs: rgrep does not work over tramp

[Tomas Volf]

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

Hello,

when I try to execute rgrep over a tramp connection, I get the following error:

/bin/sh: /gnu/store/sk8rxsrj3drr4arypicnhy899vgn3prr-findutils-4.9.0/bin/find: not found

That is somewhat expected, since the remote machine is not a Guix one, but even
if it were, it would require to have the find in exact same store path.

I understand the advantages of baking in the path to find into the
configuration, but I wonder whether the trade-off is worth if for this
particular case.  Setting it to just `find' seems to work fine, both locally and
remotely (at the cost of a minuscule hit to reproducibility).

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#68850: emacs: rgrep does not work over tramp

[Simon Streit]

Hello Tomas,

Tomas Volf <~@wolfsden.cz> writes:

> when I try to execute rgrep over a tramp connection, I get the following error:
>
> /bin/sh: /gnu/store/sk8rxsrj3drr4arypicnhy899vgn3prr-findutils-4.9.0/bin/find: not found
>
> That is somewhat expected, since the remote machine is not a Guix one,
> but even if it were, it would require to have the find in exact same
> store path.

I am running into the same issue as well.  This is on a foreign system
using Emacs and Tramp trying to call find on remote hosts that are not
Guix.

> I understand the advantages of baking in the path to find into the
> configuration, but I wonder whether the trade-off is worth if for this
> particular case.  Setting it to just `find' seems to work fine, both
> locally and remotely (at the cost of a minuscule hit to
> reproducibility).

Is there maybe an easy way around this?  I tried:

--8<---------------cut here---------------start------------->8---
(connection-local-set-profile-variables
 'remote-system
 '((tramp-remote-path . ("/bin" "/usr/bin" "/sbin" "/usr/sbin" "/usr/local/bin" "/usr/local/sbin" "/local/bin"))))
(connection-local-set-profiles
 '(:application tramp :machine "host.example.com")
 'remote-system)
--8<---------------cut here---------------end--------------->8---

The connection will set the remote-path.  But rgrep will still invoke
find from a path in /gnu/store.


Cheers

-- 
Simon

bug#68850: emacs: rgrep does not work over tramp

[Tomas Volf]

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


Hello,

Simon Streit <simon@netpanic.org> writes:

> Is there maybe an easy way around this?  I tried:
>
> (connection-local-set-profile-variables
>  'remote-system
>  '((tramp-remote-path . ("/bin" "/usr/bin" "/sbin" "/usr/sbin" "/usr/local/bin" "/usr/local/sbin" "/local/bin"))))
> (connection-local-set-profiles
>  '(:application tramp :machine "host.example.com")
>  'remote-system)
>
> The connection will set the remote-path.  But rgrep will still invoke
> find from a path in /gnu/store.

Customizing `find-program' to just "find" and restarting Emacs does the
trick.  So just sticking

    (setopt find-program "find")

into `init.el' should work.

I played with it around for a bit but did not figure out how to
customize it in already running Emacs.  I am sure it is possible, but I
hit the self-imposed time limit before figuring it out.

Have a nice day,
Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

bug#68850: emacs: rgrep does not work over tramp

[Simon Streit]

Thank you for your quick reply!

Tomas Volf <~@wolfsden.cz> writes:

> Customizing `find-program' to just "find" and restarting Emacs does the
> trick.  So just sticking
>
>     (setopt find-program "find")
>
> into `init.el' should work.
>
> I played with it around for a bit but did not figure out how to
> customize it in already running Emacs.  I am sure it is possible, but I
> hit the self-imposed time limit before figuring it out.

Setting this variable fixes it and happily applied it locally.

I also get your point now too.  The path has been hard-coded at build
time.  Looking into the package declaration, it is not the only one
being modified.  This modification may seem reasonable when working
within an environment of Guix.  But it can become a disadvantage
when working on hosts that are sans Guix.

Also, how can this path to an application within the store work on a
remote system – that may also have a Guix store – when it does not
exist?  My guess here is, that tramp will call the application on remote
host it is working on.  Then it should also expect that path on the
remote store to exist too.

I can't deny that my Guix systems are not that much different to each
other.  They usually tend to have similar states of stores.  I can test
a scenario with an empty near clean store.


Kind regards

-- 
Simon