Follow-up Comment #3, bug #23922 (project make): This was fixed by git commit b5c06541
This change has broken my makefiles. I think it is appropriate to extra-quote commands passed to the shell, but not those in the SHELL definition itself. Whoever defines SHELL can be presumed to know what they mean by it. Surely it doesn't matter if SHELL has characters special to the shell, unless it is being invoked by the shell, in which case can we limit the escaping to the circumstance when it is actually invoked by the shell, and not by execve ? If we insist on doing this, can we have an option to disable it? Or to enforce that it be invoked by the shell instead of execve? Detail: Some make files, generated using a literate programming tool fangle (https://savannah.nongnu.org/p/fangle) have SHELL defined thus: SHELL:=bash -c 'exec $(SHELL) "$${@//\$$''' 12'''/$$''' 12'''}"' -- as you see, there are many shell-special characters there, but they are already quoted appropriately. This fix now extra quotes characters like $ preventing their proper interpretation by the shell. The SHELL contrivance above is to permit use of continuations at the end of a recipe line but preserving the n to the shell, avoiding the need of the common but painful ; construct which is not valid in many embedded commands, e.g. sed invocations with complex rules as part of the make recipe. .ONESHELL does a similar thing but without the selective control of the trailing (as well as other harm by difficult-to-control stripping of @ - in the middle of the recipe). _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?23922> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make