Subject: Re: goredo gets confused with relative paths and symlinks

From: Rafael Fourquet <[email-masked]>
Date: Thu, 23 Oct 2025 16:58:30 +0200

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!