public inbox for goredo-devel@lists.stargrave.org
Atom feed
From: Rafael Fourquet <fourquet.rafael@gmail•com>
To: goredo-devel@lists.cypherpunks.su
Subject: Re: goredo gets confused with relative paths and symlinks
Date: Thu, 23 Oct 2025 16:58:30 +0200 [thread overview]
Message-ID: <CAJoaZ9JF5ZdkAfo+NfWEeBeWx_XHPLybqrZJzPhFxsUg=cSa9w@mail.gmail.com> (raw)
In-Reply-To: <915985b5-d75b-4743-a16f-e3ce581ff139@spacefrogg.net>
Yes, I read more today about this topic in the list and in the doc.
I'd like to make two points however:
1) the "bug" I reported happens even when there is no symlink within
the "redo project" itself.
In my example, "a", "a/b" and "b" (symlink to a/b) could be located
anywhere else to trigger the bug.
My use case is that sometimes I will want to rebuild a target when I'm
in another unrelated project, which I might have accessed through a
symlink (e.g. I did `cd ~/projects; redo /tmp/goredo-test/test1`,
where `~/projects` is a symlink to `/mnt/whatever/projects`.
2) if 1) if not a sufficient motivation to recognize the behavior as a
bug, at the very least, I don't think goredo should then try to call
`/bin/sh test1.do`.
IOW, I think it's definitely a bug for goredo to interpret the failure
of ` unix.Access(doFile.rel, unix.X_OK)` to mean that the file isn't
executable, when in fact it just means that the file is non-existent
(and then to proceed blindingly with `/bin/sh` on another file
(`doFile.a`) which is actually executable and relies on another
interpreter). This leads to this impenetrable error I got initially
(`a-b-c': not a valid identifier).
Cheers!
next prev parent reply other threads:[~2025-10-23 15:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 13:54 goredo gets confused with relative paths and symlinks Rafael Fourquet
2025-10-23 14:10 ` goredo
2025-10-23 14:58 ` Rafael Fourquet [this message]
2025-10-24 12:12 ` Sergey Matveev
2025-10-24 13:45 ` Rafael Fourquet
2025-10-24 13:59 ` Sergey Matveev
2025-10-24 12:03 ` Sergey Matveev
2025-10-26 14:34 ` Sergey Matveev