Date: Wed, 12 Nov 2025 06:35:53 -0500
From: Grisha Levit <[email protected]>
Message-ID: <[email protected]>
| However, if an external command is executed between the last time an
| exported variable was modified and the local array is created, the
| existing variable remains in the environment until the next time that
| an exported variable is modified.
To me that suggests that bash is trying to optimise away the cost of
building the environment to be exported to exec'd commands - only building
it when required (and that you have found a bug in how that is done).
I tried that with the NetBSD shell several years ago now - it was a true
pain to get correct (and I'm not sure I succeeded, even with the optimisation
being fairly pessimistic - lots of things would disable it).
But more to the point here, it also wasn't worth the effort - the environment
only matters when an exec is to happen, and the costs of that (all the costs
involved, not just the part the shell is involved in directly) totally
dwarf the cost of preparing the environment to be used. That is, the
planned optimisation (when it was used) made no detectable difference at
all, but was just a bunch of extra code (to go wrong) which also added
(again, very small, but non-zero) execution costs to the shell for all kinds
of other operations. The net effect on the cpu time used by the shell in
a typical session (or for an average script) might have been a very small
win - but so small it just wasn't worth it.
That code didn't survive to ever get released.
kre
ps: it might be relevant that the design of the way vars are stored in
the NetBSD shell (from way, way, before I was involved) makes preparing
the environment a relatively cheap operation (no string copies required,
just creating the array of pointers) - if that's not true of bash, that
might be a better way to cut the cost of building the environment, rather
than trying to simply do it less often.
