"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes:
> I don't think this is the right approach. Every version of ksh
> _except_ AT&T ksh works just fine here. ... AT&T ksh is
> considering adding local in a newer version for this reason.
Thanks. That is nice to know, though unfortunately I didn't see
signs of them making much progress.
Let's not make or change any policy but just document what we found
to help the next person.
------ >8 ----------- >8 ----------- >8 ------
Subject: [PATCH] doc: note that AT&T ksh does not work with our test suite
The scripted Porcelain commands do not allow use of "local" because
it is not universally supported, but we use it liberally in our test
scripts, which means some POSIX compliant shells (like "ksh93") can
not be used to run our tests.
Document the status quo, to help the next person who gets perplexed
seeing our tests fail.
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
---
Documentation/CodingGuidelines | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 1d92b2da03..94ca5cf7c0 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -185,8 +185,8 @@ For shell scripts specifically (not exhaustive):
- Even though "local" is not part of POSIX, we make heavy use of it
in our test suite. We do not use it in scripted Porcelains, and
- hopefully nobody starts using "local" before they are reimplemented
- in C ;-)
+ hopefully nobody starts using "local" before all shells that matter
+ support it (notably, ksh from AT&T Research does not support it yet).
- Some versions of shell do not understand "export variable=value",
so we write "variable=value" and then "export variable" on two
--
2.46.0-rc0-140-g824782812f
