[bug #62200] Make tries to execute directories name as commands instead of using shell PATH resulting failure with permission denied

Follow-up Comment #5, bug #62200 (project make): > typed the recipe command line into your shell prompt I see the point but I'm not sure I'd put it *quite* that way. Didn't bash win the Shell Wars? martind@sirius:~/tmp/make-62200$ PATH=$(pwd):$PATH /bin/sh -c asdf /bin/sh: 1: asdf: Permission

[bug #62200] Make tries to execute directories name as commands instead of using shell PATH resulting failure with permission denied

Follow-up Comment #4, bug #62200 (project make): Thanks for the explanation this made things very clearer to me, I fixed my issue with building gcc that had a 'cp' directory by building the latest version of make from git, when is the next release scheduled because since January 2020 there has

[bug #62200] Make tries to execute directories name as commands instead of using shell PATH resulting failure with permission denied

Update of bug #62200 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #3: It's important to

[bug #62200] Make tries to execute directories name as commands instead of using shell PATH resulting failure with permission denied

Follow-up Comment #2, bug #62200 (project make): So what should be done to fix this problem for a build such as gcc ? This bug is stated as fixed : https://savannah.gnu.org/bugs/index.php?57962 So why am I encountering it again ? What should be done to mitigate the bug, also I don't have in my

[bug #62200] Make tries to execute directories name as commands instead of using shell PATH resulting failure with permission denied

Follow-up Comment #1, bug #62200 (project make): Oh no, not error 127 again. The error message here is the strerror form of EACCES, which currently seems to come (on my build on reasonably modern Linux, with findprog-in and posix_spawn) from this change:

Re: Bug report made anonymously should be assigned to my username on Savannah for receiving updates on it

On Fri, 2022-03-18 at 21:12 +, Lahfa Samy wrote: > I've reported this bug anonymously : > https://savannah.gnu.org/bugs/index.php?62200 and would like to > receive updates/comments on it by mail on my Savannah account, I > don't know if the bug report could be assigned to me or the "posted >

Bug report made anonymously should be assigned to my username on Savannah for receiving updates on it

Hi, I've reported this bug anonymously : https://savannah.gnu.org/bugs/index.php?62200 and would like to receive updates/comments on it by mail on my Savannah account, I don't know if the bug report could be assigned to me or the "posted by" field could be updated to my username on Savannah

[bug #62200] Make tries to execute directories name as commands instead of using shell PATH resulting failure with permission denied

URL: Summary: Make tries to execute directories name as commands instead of using shell PATH resulting failure with permission denied Project: make Submitted by: None Submitted on: ven. 18 mars 2022

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

> On Mar 18, 2022, at 2:03 PM, Paul Smith wrote: > > On Fri, 2022-03-18 at 17:48 +, Martin Dorey wrote: >> Maybe putting it in the form of a patch on the latest git source will >> help it over the finish line: > > I'm OK with adding some short text about this into the man page. As >

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

Paul Smith wrote: I'm OK with adding some short text about this into the man page. As David mentions it may be important enough to do that since command being run by make even when the user gives "-n" could give unexpected or even unpleasant consequences. The most unpleasant consequences of

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

On Fri, 2022-03-18 at 17:48 +, Martin Dorey wrote: > Maybe putting it in the form of a patch on the latest git source will > help it over the finish line: I'm OK with adding some short text about this into the man page. As David mentions it may be important enough to do that since command

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

Maybe putting it in the form of a patch on the latest git source will help it over the finish line: diff --git a/doc/make.1 b/doc/make.1 index ec6f8a3b..4c258d68 100644 --- a/doc/make.1 +++ b/doc/make.1 @@ -222,8 +222,12 @@ With no argument, removes a previous load limit. Use the latest mtime

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

> On Mar 18, 2022, at 3:19 AM, Ambrus Sumegi wrote: > > Thanks a lot for your suggestions, Martin and Paul. I understand the > reasoning behind why Make cannot improve this behavior, and the conditional > execution of tee that you both proposed looks like a concise and elegant > solution

RE: GNU Make bug report: broken dry-run functionality with sub-make invocations

Thanks a lot for your suggestions, Martin and Paul. I understand the reasoning behind why Make cannot improve this behavior, and the conditional execution of tee that you both proposed looks like a concise and elegant solution to my problem. My only remaining concern is about the man page,