GeezerVison is showing github.com — Fix the bash compatibility mode · Issue #9 · ksh93/ksh
Fix the bash compatibility mode #9DescriptionDoes anyone care about ksh's bash compatibility mode?
It's not compiled in my default. The RELEASE file says it's incomplete and experimental.
bash is pretty ubiquitous. I think if people want to run bash scripts, they'll run bash.
Would anyone object to getting rid? Activityposguy99 commented on Jun 14, 2020 Are distributions enabling it?
I mean, if *I* wanted bash, I'd run bash, but I also use macOS, so I'd be building bash anyway.
…
--
Marc Wilson
On Jun 13, 2020, at 5:48 PM, Martijn Dekker ***@***.***> wrote:
Does anyone care about ksh's bash compatibility mode?
It's not compiled in my default. The RELEASE file says it's incomplete and experimental.
bash is pretty ubiquitous. I think if people want to run bash scripts, they'll run bash.
Would anyone object to getting rid?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
McDutchie commented on Jun 14, 2020
Are distributions enabling it?
It would surprise me if there are any that do. It's easy to check: ksh sets a $BASH_VERSION variable if it's enabled and adds a shopt builtin.
…Oh. Now it would surprise me even more, because I just found out it doesn't even compile:
$ bin/package make CCFLAGS='-Os -DSHOPT_BASH=1'
[...]
/usr/local/src/ksh93/ksh/src/cmd/ksh93/sh/init.c:1397:14: warning: comparison of distinct pointer types ('Shell_t *' (aka 'struct Shell_s *') and 'Shinit_f' (aka 'void (*)(struct Shell_s *, int)')) [-Wcompare-distinct-pointer-types]
shp>userinit = userinit = bash_init;
~~~^~~~~~~~~
/usr/local/src/ksh93/ksh/src/cmd/ksh93/sh/init.c:1397:24: error: expression is not assignable
shp>userinit = userinit = bash_init;
~~~~~~~~~~~~ ^
1 warning and 1 error generated.
…that's a straight-up typo: that should be shp->userinit. It's clear the Bell Labs folks didn't bother to give this the most rudimentary testing before releasing ksh 93u+.
After fixing the typo, compiling ksh succeeds but linking it fails:
[...]
+ cc -O -L. -L/usr/local/src/ksh93/ksh/arch/darwin.i386-64/lib -o ksh pmain.o libshell.a /usr/local/src/ksh93/ksh/arch/darwin.i386-64/lib/libdll.a /usr/local/src/ksh93/ksh/arch/darwin.i386-64/lib/libast.a -liconv -liconv /usr/local/src/ksh93/ksh/arch/darwin.i386-64/lib/libast.a -liconv -liconv /usr/local/src/ksh93/ksh/arch/darwin.i386-64/lib/libcoshell.a /usr/local/src/ksh93/ksh/arch/darwin.i386-64/lib/libast.a -liconv -liconv /usr/local/src/ksh93/ksh/arch/darwin.i386-64/lib/libast.a -liconv -liconv /usr/local/src/ksh93/ksh/arch/darwin.i386-64/lib/libcmd.a -lutil /usr/local/src/ksh93/ksh/arch/darwin.i386-64/lib/libast.a -liconv -liconv -lutil /usr/local/src/ksh93/ksh/arch/darwin.i386-64/lib/libast.a -liconv -liconv /usr/local/src/ksh93/ksh/arch/darwin.i386-64/lib/libast.a -liconv -liconv /usr/local/src/ksh93/ksh/arch/darwin.i386-64/lib/libast.a -liconv
Undefined symbols for architecture x86_64:
"_e_bash_rc", referenced from:
_sh_main in libshell.a(main.o)
"_sh_bash1", referenced from:
_infof in libshell.a(args.o)
"_sh_bash2", referenced from:
_infof in libshell.a(args.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
mamake [cmd/ksh93]: *** exit code 1 making ksh
mamake: *** exit code 1 making cmd/ksh93
mamake: *** exit code 1 making all
DavidMorano commented on Jun 14, 2020
Does anyone care about ksh's bash compatibility mode?
I am (possibly one of the people) continuing the development of ksh2020 and I have not bothered to even attempt to turn on the BASH compatibility mode, nor do I have any desire to do so. But I am interested in any other responses that people might make here. McDutchie commented on Jun 14, 2020 Author show commentMore actions DavidMorano commented on Jun 14, 2020 McDutchie commented on Jun 16, 2020 Author show commentMore actions DavidMorano commented on Jun 16, 2020 changed the title [-]RFD: bash compatibility mode[/-] [+]Fix the bash compatibility mode[/+] on Jun 16, 2020McDutchie commented on Jun 16, 2020 There has been an objection on the korn-shell list against removing the broken bash compatibility mode. Here is my reply.
In short: It falls to the people interested in using this to fix it, or have it fixed. Either someone fixes this before we release, or it gets removed shortly before release.
So, this is now a TODO item. JohnoKing commented on Jun 16, 2020 Well, FWIW it is probably worth the effort to fix the local builtin present in the Bash compatibility mode. This is quoted from @bk2204's comment in att#220:
I'll point out a few things about the local keyword:
-
There's a request to the Austin Group (the POSIX folks) about standardizing it as
part of POSIX which has garnered a lot of comments in favor. ksh has typically
been capable of running POSIX commands, so it may be worthwhile to implement
for that reason.
-
Debian requires all shells that can be used as /bin/sh to implement local (and
they don't build with SHOPT_BASH). Consequently, it isn't possible to use ksh
as /bin/sh on a Debian or Ubuntu system.
-
Git requires a shell providing local in order to run the testsuite and shell
commands. Consequently, it isn't possible to use ksh as the shell for Git.
-
All other open source POSIX-compliant shells that I'm aware of implement
local: bash, dash, mksh, pdksh (and derivatives, like OpenBSD's ksh),
and zsh.
The first point seems to be referencing this request on the Austin Group Defect Tracker. The other points are all perfectly valid reasons to have a local builtin, although this project does have a 'bug fixes only' policy, as in the ksh93u+m README:
- No new features; bug fixes only (but see items 3 and 4). Feature development is for a future separate branch.
The feature development branch hasn't been created yet, so improvements to the local builtin will have to be placed behind the SHOPT_BASH ifdef with the rest of the Bash compatibility code, as the local builtin isn't enabled by default. Reacted by Kamil Dudka and Martijn Dekker McDutchie commented on Jun 16, 2020 Well, I am not a policy absolutist. I think policies should be broken if there are solid reasons why following them is worse than not following them.
Adding a local builtin just might be such a case, precisely because POSIX is likely to mandate one, one of these years. POSIX compliance was one of Korn's stated core objectives, and is one of ours.
However, to be anything like compatible with other shells, local should implement dynamic scoping, not static scoping like typeset. See Part III, Q28 in this FAQ, to know the difference.
In standard ksh mode, local should then only work in POSIX functions (defined like this() { ...; }), and it should implement dynamic scoping. The behaviour of typeset would be unchanged.
In bash compatibility mode (if it gets fixed), local should simply be a synonym of typeset without options, and both should implement dynamic scoping, even in ksh functions defined with the function keyword – because that is how typeset a.k.a. declare behaves in bash, mksh, yash, and zsh. Which means ksh static scoping would not be available if ksh is compiled in bash compatibility mode, but that is the price. You can't have both in one typeset. (edit: unless we add a new shell option for that instead…) Reacted by Johnothan King
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|