[bug #63690] temp_stdin and output_sync failure on macos

2023-01-23 Thread Paul D. Smith
Follow-up Comment #3, bug #63690 (project make):

Thanks Dmitry; I already have a fix for this.  I thought I had pushed it
already but maybe not.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




[bug #52209] Support for ifeq function

2023-01-23 Thread Sam Kendall
Follow-up Comment #5, bug #52209 (project make):

I strongly agree with the need but suggest a different syntax:

$(eq lhs,rhs)
$(neq lhs,rhs)

Each function expands lhs and rhs. If the results are identical or
nonidentical, respectively, the function expands to T. Otherwise, it expands
to empty.

The rationale is that this syntax is more readable than the proposed $(ifeq
lhs,rhs,1). For me, readability trumps the slight burden of committing to a
particular "true" string. (I've suggested T, following the GMSL, but it
doesn't matter much; I'm okay with 1.)

Function-heavy code is sometimes necessary, but I find it difficult to read.
String equality primitives will help, but let's make them as concise and
readable as possible.

One more issue: should string equality functions be bug-for-bug compatible
with bug #59584? I would say no; they should be consistent with what functions
normally do, which I think is to trim whitespace to the left of each argument
before expansion.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/




[bug #63693] allow a way of asserting that $(SHELL) is POSIX/Bourne compatible

2023-01-23 Thread David Boyce
URL:
  

 Summary: allow a way of asserting that $(SHELL) is
POSIX/Bourne compatible
 Project: make
   Submitter: boyski
   Submitted: Mon 23 Jan 2023 09:20:06 PM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Mon 23 Jan 2023 09:20:06 PM UTC By: David Boyce 
Currently, make decides whether the current shell is sufficiently
POSIX-shell-like by looking at a hard-coded list of names:

/* determines whether path looks to be a Bourne-like shell. */
int
is_bourne_compatible_shell (const char *path)
{
  /* List of known POSIX (or POSIX-ish) shells.  */
  static const char *unix_shells[] = {
"sh",
"bash",
"dash",
"ksh",
"rksh",
"zsh",
"ash",
NULL
  };

This is unfortunate for a couple of reasons. First, it probably leaves out
some compatible shells and would make it harder to adapt to a new POSIX shell
someone might invent. Second, it damages shell wrapper capabilities which is
my specific problem.

I have a little open-source tool called "mdsh"
(https://github.com/boyski/mdsh) which wraps over the real shell and provides
diagnostic data for debugging complex make issues. But since name "mdsh" is
not on the list above it's not recognized as a POSIX shell though it simply
re-execs /bin/sh so of course it is. This causes problems when used with
.ONESHELL, for instance, since leading @ characters in interior lines are only
stripped for POSIX shells which means setting SHELL=mdsh results in mysterious
breakages.

I've had to resort to invoking mdsh via a symlink to a name that is on the
list, e.g. "rksh -> mdsh", which works but is not exactly elegant. I suggest
it would be better to have a way of adding to the list dynamically, or simply
to assert that the current shell is POSIX-compatible.







___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/