emacs: rgrep does not work over tramp

Open

Details

2 participants

Simon Streit
Tomas Volf

Owner: unassigned

Submitted by: Tomas Volf

Severity: normal

Tomas Volf wrote on 31 Jan 14:08 +0100

Recipients:(address . bug-guix@gnu.org)

Message-ID:ZbpGQXNSpoOHCl5C@ws

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.

Simon Streit wrote on 10 Dec 16:05 +0100

Recipients:(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 68850@debbugs.gnu.org)

Message-ID:ygu4j3b60jo.fsf@netpanic.org

Hello Tomas,

Tomas Volf <~@wolfsden.cz> writes:

Toggle quote (8 lines)

> 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.

Toggle quote (6 lines)

> 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:

Toggle snippet (8 lines)

(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.

Cheers

Simon

Tomas Volf wrote on 10 Dec 17:12 +0100

Recipients:(name . Simon Streit)(address . simon@netpanic.org)(address . 68850@debbugs.gnu.org)

Message-ID:87bjxj7bzr.fsf@wolfsden.cz

Hello,

Simon Streit <simon@netpanic.org> writes:

Toggle quote (12 lines)> 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.

Simon Streit wrote on 10 Dec 21:02 +0100

Recipients:(name . Tomas Volf)(address . ~@wolfsden.cz)(address . 68850@debbugs.gnu.org)

Message-ID:yguseqv4884.fsf@netpanic.org

Thank you for your quick reply!

Tomas Volf <~@wolfsden.cz> writes:

Toggle quote (11 lines)> 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

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 68850@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 68850

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date