Re: [PATCH v2] CodingGuidelines: document a shell that "fails" "VAR=VAL shell_func"

From: Rubén Justo <rjusto@gmail.com>
Date: Jul 23, 2024, 21:55 UTC
Message-ID: <f613ed64-fc5f-4204-a364-f671f315390d@gmail.com>
In-Reply-To: <20240723033418.GA1838963@coredump.intra.peff.net>

On Mon, Jul 22, 2024 at 11:34:18PM -0400, Jeff King wrote:

Show 18 quoted lines

> On Mon, Jul 22, 2024 at 04:10:41PM -0700, Junio C Hamano wrote:
> 
> > Over the years, we accumulated the community wisdom to avoid the
> > common "one-short export" construct for shell functions, but seem to
> > have lost on which exact platform it is known to fail.  Now during
> > an investigation on a breakage for a recent topic, we found one
> > example of failing shell.  Let's document that.
> 
> My recollection was that FreeBSD's /bin/sh was the culprit, but I
> couldn't find any mention digging in the archive. However, I just
> checked on a FreeBSD 13 VM, and it does have the same problem (that the
> one-shot variable is not exported). I don't think that changes anything
> for your patch, but just reinforces this part:
> 
> > This does *not* mean that we can freely start using the construct
> > once Ubuntu 20.04 is retired.  But it does mean that we cannot use
> > the construct until Ubuntu 20.04 is fully retired from the machines
> > that matter.

And adding more confusion, which further reinforces the need to avoid the construct and the usefulness of Eric's change [1], it sometimes appears to function differently:

   ** dash 0.5.10.2-6 **

   $ f() { echo $A; bash -c 'echo $A'; }
   $ A=2
   $ A=1 f
   1
   
   $ export A
   $ f
   2
   2
   $ A=1 f
   1
   1

 1.- https://lore.kernel.org/git/2e1c8fc6-86f0-404f-bef6-9502aa0d31d0@gmail.com/T/#m3470fc6c1df59d29312bbe3de0444f1f608f3611

Show 8 quoted lines

> 
> since now we have one other instance.
> 
> I thought it also had the issue that the variable would remain set in
> the caller after the function returned, but it does not seem to do so
> now (if it ever did).
> 
> -Peff