ksh 93u+m/1.0.0 release

[McDutchie]

So, it's out, finally. :)

See here for the announcement and the download links: https://github.com/ksh93/ksh/releases/tag/v1.0.0

Feel free to comment and report your experiences below.

[johnsonjh]

Besides still trying to overcome pushback from some package maintainers who switched to 2020 without any fanfare but now, for various reasons, aren't enthusiastic about switching to ksh93u+m even though ksh2020 is no longer extant, well... this is awesome.

Thanks so much!

I was in fact only vaguely aware of this repository and project until nearly going insane due to ksh2020 being shipped to me as ksh93 by another project, so I'm very glad to see this here. I usually just "trust" that Red Hat and IBM will ship me a non-bum shell, without looking more into "how the sausage is made".

Having used ksh for 30+ years, if my ksh is broken, I'm broken. I can't do any work. *sigh*

While I can actually get along just fine with zsh and often prefer it interactively, I don't think I'll ever default to writing scripts in anything but ksh. One of the biggest reasons is the extensive math libraries, so I was worried when I heard that the ksh2020 project had been removing math functions that were broken, rather than fixing them.

My primary ksh shell usage these days is on AIX, and AIX is shipping a 93u+ 2012-08-01 as their shell (but actually last updated on 11/1/2021) and it does seem to include quite a number of the fixes that have made it into this project (or maybe its the other way around). Are the IBM guys here? They used to ship a patched up version of 93t. I've never extensively poked it, but I've never had it surprise me, so there's been no need. Perhaps I can instead poke the right parties at IBM and at least make them aware of this project...

[siteshwar]

ksh2020 diehards will come around eventually I suppose. This project is alive and I'm not planning to go anywhere, ksh2020 is very much dead and I've got Siteshwar's blessing as its successor.

I don't know if "ksh2020 diehards" actually exist. And when it comes to RHEL/Fedora, it's mostly about @kdudka and @vmihalko making decisions. You don't need my blessings. I only helped you at the beginning as I saw potential in your work to achieve my original goal.

[johnsonjh]

I've read all the threads - really, you (were) in a tough spot I don't envy you. That said, ksh2020 nearly made me throw my computer out the window multiple times lately. No joke :) I can get into it but it's all water under the bridge now.

And when I say "not give me a bum shell", that's actually a compliment. I get ksh93u+m now when I install ksh on RHEL, and it's fine by me. We're all indebted to your work on ksh, even if the end result is something I can't use. No offense here intended to anyone but I feel like it was just shipped way before it was ready, and those impressions and frustrations did ruin the experience for me, absolutely.

(Oh well, I'll complain. Sorry in advance! See, on MacOS, ksh2020 always ends up going haywire with the history and then starts leaking file descriptors- of which Apple feels 256 ought to be enough for anyone. So multiple times per day I can't do anything, everything starts failing with "too many files open" and "resource exhausted" messages, and I've had to kill SSH sessions, lost work, etc. It's an order of magnitude beyond frustrating - to say the least - that just regular use of the shell totally kills my machine and/or sessions.)

Edit: I only have/had a problem with ksh2020 when it was shipped to me as ksh93! If that makes sense. :)

[johnsonjh]

I also feel like Red Hat shipped 2020 for a very short period, and it wasn't an issue for me at the time .. I missed the ksh2020 drama essentially completely due to upgrade cycle timing in fact.

[johnsonjh]

I'm not sure if I should be proud or embarrassed to admit it, but I wrote an independent "second implementation" of a blockchain-based settlement system - including all the math and crypto - completely in ksh93, which was used as a "safety check" against bugs in the production implementation. It was easily 10X slower than the primary implementation, but never crashed and ran for months. I wouldn't recommend writing stuff like that in ksh, but it's what I reach for instead of Python or Ruby.

[McDutchie]

@siteshwar wrote:

I don't work on ksh anymore, neither upstream nor downstream. I have passed the rights to maintain downstream packaging (RHEL/Fedora) to @vmihalko. There is already a pull request to rebase ksh in Fedora to ksh93u+m-1.0.0. And I believe other distros will follow.

Great news, thank you! And yes, we're already in Slackware and Debian as well, and I believe the Solaris people have taken an interest.

If a package maintainer refuses to rebase, I would like to go into the details of reasons behind it. One of the reasons was ksh is very hard to build. This is something future versions of ksh93u+m would have to solve. Package maintainers sometimes still prefer ksh2020 despite of it's shortcomings, as it's very easy to build.

It may not be immediately obvious but 93u+m is already easy to build now, certainly on Linux, *BSD, macOS, Solaris, illumos, QNX, and Cygwin. A simple bin/package make should do the trick. We jettisoned nmake because (as you've noticed) it was brittle and overcomplicated. What's left is mamake, which is very simple, and iffe, which is actually quite nice. Their problems were fixable.

The current build system is not shiny like meson, but it has no dependencies at all, save for a shell and compiler -- which is a great portability advantage. Although it looks like I still have a bit of work to do to make it build properly on AIX...

I usually just "trust" that Red Hat and IBM will ship me a non-bum shell, without looking more into "how the sausage is made".

I have spent couple of years trying to improve the quality of code and making it easier to maintain. ksh2020 failed because it was breaking user experience. Partially because we based our work on ksh93v-, and partially due to changes we made. I believe ksh93u+m is harder to maintain than ksh2020, but has better backward compatibility. So, it has better chances to succeed.

We backported a bunch of ksh2020 fixes as well. I'm grateful for all your work and Kurtis's. Thank you for stopping by!

[HansH111]

I only have access to a customer AIX 7.1 server with gcc 6.3.0 on it.. the only problem I goti when compiling: /usr/include/sys/time.h:126:3: error: conflicting types for 'sigset_t' } sigset_t; Seems the AIX time.h contains also a typedef sigset_t I adapted the gcc sys/types.h adding a #define _SIGSET_T after the definition of the typedef. After that it compiled without problems.

ls -l arch/ibm.risc-64/bin/ksh

-rwxr-xr-x 1 user usgrp 1447640 Aug 03 13:59 ksh-master/arch/ibm.risc-64/bin/ksh arch/ibm.risc-64/bin/ksh --version version sh (AT&T Research) 93u+m/1.1.0-alpha 2022-07-31 The bin/shtests -p however shows some problems... (see underneath) Hope someone from IBM steps in and compiles it correctly or give you some access to an AIX server. Hans #### Regression-testing ..../arch/ibm.risc-64/bin/ksh #### test alias begins at 2022-08-03+13:42:02 test alias passed at 2022-08-03+13:42:02 [ 45 tests 0 errors ] test append begins at 2022-08-03+13:42:02 test append passed at 2022-08-03+13:42:02 [ 17 tests 0 errors ] test arith begins at 2022-08-03+13:42:02 test arith passed at 2022-08-03+13:42:02 [ 252 tests 0 errors ] test arrays begins at 2022-08-03+13:42:02 ..../src/cmd/ksh93/tests/arrays.sh: line 239: panic: out of memory (needed 1 bytes) test arrays failed at 2022-08-03+13:42:02 with exit code 75 [ 170 tests 75 errors ] test arrays2 begins at 2022-08-03+13:42:02 test arrays2 passed at 2022-08-03+13:42:03 [ 57 tests 0 errors ] test attributes begins at 2022-08-03+13:42:03 ..../src/cmd/ksh93/tests/attributes.sh: line 269: panic: out of memory (needed 1 bytes) test attributes failed at 2022-08-03+13:42:03 with exit code 75 [ 167 tests 75 errors ] test basic begins at 2022-08-03+13:42:03 test basic passed at 2022-08-03+13:42:12 [ 147 tests 0 errors ] test bracket begins at 2022-08-03+13:42:12 test bracket passed at 2022-08-03+13:42:14 [ 158 tests 0 errors ] test builtins begins at 2022-08-03+13:42:14 test builtins passed at 2022-08-03+13:42:22 [ 286 tests 0 errors ] test case begins at 2022-08-03+13:42:22 test case passed at 2022-08-03+13:42:22 [ 22 tests 0 errors ] test comvar begins at 2022-08-03+13:42:22 test comvar passed at 2022-08-03+13:42:22 [ 102 tests 0 errors ] test comvario begins at 2022-08-03+13:42:23 comvario.sh[26]: warning: -lm does not support signbit(-NaN) test comvario passed at 2022-08-03+13:42:30 [ 73 tests 0 errors ] test coprocess begins at 2022-08-03+13:42:30 test coprocess passed at 2022-08-03+13:42:34 [ 35 tests 0 errors ] test cubetype begins at 2022-08-03+13:42:34 test cubetype passed at 2022-08-03+13:42:35 [ 68 tests 0 errors ] test enum begins at 2022-08-03+13:42:35 test enum passed at 2022-08-03+13:42:35 [ 47 tests 0 errors ] test exit begins at 2022-08-03+13:42:35 test exit passed at 2022-08-03+13:42:35 [ 35 tests 0 errors ] test expand begins at 2022-08-03+13:42:36 test expand passed at 2022-08-03+13:42:36 [ 7 tests 0 errors ] test functions begins at 2022-08-03+13:42:36 test functions passed at 2022-08-03+13:42:38 [ 121 tests 0 errors ] test glob begins at 2022-08-03+13:42:38 test glob passed at 2022-08-03+13:42:39 [ 174 tests 0 errors ] test grep begins at 2022-08-03+13:42:39 test grep passed at 2022-08-03+13:42:39 [ 1 test 0 errors ] test heredoc begins at 2022-08-03+13:42:39 test heredoc passed at 2022-08-03+13:42:41 [ 43 tests 0 errors ] test io begins at 2022-08-03+13:42:41 test io passed at 2022-08-03+13:42:45 [ 162 tests 0 errors ] test jobs begins at 2022-08-03+13:42:45 test jobs passed at 2022-08-03+13:42:46 [ 25 tests 0 errors ] test leaks begins at 2022-08-03+13:42:46 leaks.sh[168]: warning: skipping test for known leak "defining associative array in subshell"; export DEBUG=y to test and help us fix it at: #94 leaks.sh[353]: warning: skipping test for known leak "set PATH attribute in main shell"; export DEBUG=y to test and help us fix it at: #405 leaks.sh[361]: warning: skipping test for known leak "unset PATH in main shell"; export DEBUG=y to test and help us fix it at: #405 leaks.sh[374]: warning: skipping test for known leak "set PATH value in subshell"; export DEBUG=y to test and help us fix it at: #405 leaks.sh[379]: warning: skipping test for known leak "run command with preceding PATH assignment in subshell"; export DEBUG=y to test and help us fix it at: #405 leaks.sh[384]: warning: skipping test for known leak "set PATH attribute in subshell"; export DEBUG=y to test and help us fix it at: #405 leaks.sh[389]: warning: skipping test for known leak "unset PATH in subshell"; export DEBUG=y to test and help us fix it at: #405 leaks.sh[413]: warning: skipping test for known leak "variable with discipline function in subshell"; export DEBUG=y to test and help us fix it at: #404 test leaks passed at 2022-08-03+13:43:25 [ 36 tests 0 errors ] test locale begins at 2022-08-03+13:43:25 test locale passed at 2022-08-03+13:43:25 [ 43 tests 0 errors ] test math begins at 2022-08-03+13:43:25 test math passed at 2022-08-03+13:43:39 [ 17 tests 0 errors ] test nameref begins at 2022-08-03+13:43:39 test nameref passed at 2022-08-03+13:43:40 [ 95 tests 0 errors ] test namespace begins at 2022-08-03+13:43:40 test namespace passed at 2022-08-03+13:43:40 [ 23 tests 0 errors ] test options begins at 2022-08-03+13:43:40 test options passed at 2022-08-03+13:43:47 [ 177 tests 0 errors ] test path begins at 2022-08-03+13:43:47 test path passed at 2022-08-03+13:43:53 [ 146 tests 0 errors ] test pointtype begins at 2022-08-03+13:43:53 test pointtype passed at 2022-08-03+13:43:53 [ 36 tests 0 errors ] test posix begins at 2022-08-03+13:43:53 test posix passed at 2022-08-03+13:43:53 [ 61 tests 0 errors ] test pty begins at 2022-08-03+13:43:53 pty.sh[35]: warning: pty not confirmed to work correctly on this system -- tests skipped test pty passed at 2022-08-03+13:43:53 [ 46 tests 0 errors ] test quoting begins at 2022-08-03+13:43:53 test quoting passed at 2022-08-03+13:43:55 [ 96 tests 0 errors ] test quoting2 begins at 2022-08-03+13:43:55 test quoting2 passed at 2022-08-03+13:43:55 [ 81 tests 0 errors ] test readcsv begins at 2022-08-03+13:43:55 test readcsv passed at 2022-08-03+13:43:55 [ 4 tests 0 errors ] test readonly begins at 2022-08-03+13:43:55 test readonly passed at 2022-08-03+13:43:55 [ 8 tests 0 errors ] test recttype begins at 2022-08-03+13:43:55 test recttype passed at 2022-08-03+13:43:55 [ 8 tests 0 errors ] test restricted begins at 2022-08-03+13:43:55 test restricted passed at 2022-08-03+13:43:56 [ 21 tests 0 errors ] test return begins at 2022-08-03+13:43:56 test return passed at 2022-08-03+13:43:56 [ 47 tests 0 errors ] test select begins at 2022-08-03+13:43:56 test select passed at 2022-08-03+13:43:56 [ 4 tests 0 errors ] test sh_match begins at 2022-08-03+13:43:56 test sh_match passed at 2022-08-03+13:43:57 [ 129 tests 0 errors ] test sigchld begins at 2022-08-03+13:43:57 test sigchld passed at 2022-08-03+13:44:19 [ 14 tests 0 errors ] test signal begins at 2022-08-03+13:44:19 signal.sh[263]: FAIL: interrupt --- test failed -- expected '3-intr', got '3-0000 2-0000' signal.sh[263]: FAIL: interrupt -t- test failed -- expected '3-intr 2-intr 1-intr 1-0258', got '3-0000 2-0000 1-intr 1-0000' signal.sh[263]: FAIL: interrupt x-- test failed -- expected '3-intr 2-intr', got '3-0000 2-0000' signal.sh[263]: FAIL: interrupt xt- test failed -- expected '3-intr 2-intr 1-intr 1-0000', got '3-0000 2-0000 1-intr 1-0000' test signal passed at 2022-08-03+13:44:25 [ 55 tests 0 errors ] test statics begins at 2022-08-03+13:44:25 test statics passed at 2022-08-03+13:44:25 [ 7 tests 0 errors ] test subshell begins at 2022-08-03+13:44:25 test subshell passed at 2022-08-03+13:44:57 [ 150 tests 0 errors ] test substring begins at 2022-08-03+13:44:57 test substring passed at 2022-08-03+13:44:58 [ 217 tests 0 errors ] test tilde begins at 2022-08-03+13:44:58 test tilde passed at 2022-08-03+13:44:58 [ 24 tests 0 errors ] test timetype begins at 2022-08-03+13:44:58 test timetype passed at 2022-08-03+13:44:58 [ 18 tests 0 errors ] test treemove begins at 2022-08-03+13:44:58 test treemove passed at 2022-08-03+13:44:58 [ 10 tests 0 errors ] test types begins at 2022-08-03+13:44:58 test types passed at 2022-08-03+13:44:58 [ 99 tests 0 errors ] test variables begins at 2022-08-03+13:44:58 test variables passed at 2022-08-03+13:45:07 [ 193 tests 0 errors ] test vartree1 begins at 2022-08-03+13:45:07 test vartree1 passed at 2022-08-03+13:45:07 [ 9 tests 0 errors ] test vartree2 begins at 2022-08-03+13:45:07 test vartree2 passed at 2022-08-03+13:45:08 [ 21 tests 0 errors ] Total errors: 150 CPU time user: system: main: 0m00.082s 0m00.108s tests: 0m18.384s 0m16.442s

On Wed, Aug 3, 2022 at 8:20 AM Martijn Dekker ***@***.***> wrote: ksh2020 diehards will come around eventually I suppose. This project is

alive and I'm not planning to go anywhere, ksh2020 is very much dead and I've got Siteshwar's blessing as its successor.

I've never heard from anyone at IBM, nor do I have access to an AIX

system since polarhome shut down. I would love to test ksh on AIX again. I take it that it still builds and works? Do you happen to know where I could get an AIX shell account for testing purposes without paying through the nose?

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[johnsonjh]

I am putting some AIX stuff at #504

I'm going to build and test both dev and 1.0.0, and with all the XLC frontends with V16 and OXL V17 as well as GCC 8/9/10 as time permits.

[jghub]

a big thank you from my side as well! I am very happy to see this happening.

I've installed it today and can confirm that compilation on macOS is painless (which definitely is an improvement in itself...). so ksh93u+m is now up and running on my machine.

BUT:

bin/package test

crashes immediately with

ksh(71816,0x117947dc0) malloc: *** error for object 0x7f8393c06c68: pointer being freed was not allocated
ksh(71816,0x117947dc0) malloc: *** set a breakpoint in malloc_error_break to debug
Abort

this is on macOS 10.15.7 ( Darwin Kernel Version 19.6.0). is this a known issue?

[johnsonjh]

On Darwin 21.6.0/macOS 12.5, all the tests run successfully

[jghub]

good to know. seems another reason to no longer postpone the OS update: indeed, 10.15 is a bit old already ;).
but still this (malloc/free error) might hint at some problem or other.

[McDutchie]

No, that's not a known problem and everything is working without issue on macOS 10.14.6 (which is older still) and with just a few failures on Mac OS X 10.3 on my museum-grade Power Mac G5. So, that's a surprise. It should definitely work on old macOS versions.

Question: does bin/shtests -p work?

[McDutchie]

By the way, welcome back! We're still using shbench to make sure we're not introducing any performance regressions. :)

[jghub]

thanks and happy to hear that. :). maybe you/someone else can add better/more specific benchmarks -- those that are there are ultimately rather arbitrary and I have no idea how good the coverage is. if something is definitely missing, let me know and I might try to add a suitable further benchmark.

[jghub]

Question: does bin/shtests -p work?

yes. some warnings in `leaks.sh'. one error:

	basic.sh[504]: FAIL: pipefail causing /usr/bin/true to wait for other end of pipe
test basic failed at 2022-08-03+17:49:01 with exit code 1 [ 147 tests 1 error ]

[McDutchie]

Thanks. Haven't seen that failure before, either. It could be an intermittent as that test is time-sensitive. Could you try again and see if it persists?

As for bin/package tests failing, the package script now prefers to use a ksh in your $PATH over one from the build directory, as I got tired of having the build fail whenever I broke something :) The regression tests obviously test the newly built ksh, but the package script uses another ksh to get there. So, since it crashes immediately, it could be you have a broken ksh version in your $PATH or as the shell you're currently using. Does that help?

[jghub]

Thanks. Haven't seen that failure before, either. It could be an intermittent as that test is time-sensitive. Could you try again and see if it persists?

yes, reproducible in five consecutive runs.

The regression tests obviously test the newly built ksh, but the package script uses another ksh to get there. So, since it crashes immediately, it could be you have a broken ksh version in your $PATH or as the shell you're currently using. Does that help?

not sure :). my setup currently is:

• /bin/ksh (apple provided) still used as my login shell
•  soft link ksh in $HOME/bin pointing to another soft link ksh93u+m in the same place that is pointing to ...ksh-1.0.0/arch/darwin.i386-64/bin/ksh
• $HOME/bin "early" on $PATH
• so when in toplevel of ksh-1.0.0. tree, which ksh tells me I am going to use $HOME/bin/ksh -- which should be fine.
• the shell where I do the test run, too, is ksh93u+m.

[jghub]

I looked further into the "which ksh is used" issue: $SHELL is pointing to /bin/ksh all the time (which is probably correct since that's the login shell). maybe that's the reason that `bin/package test' tries to use that one?

[McDutchie]

Unfortunately the 1.0.0 release is fatally broken, see #507. I'm releasing 1.0.1 and everyone should update ASAP.

[jghub]

ok, so I tried: I run know into the "wrong ksh instance" issue (?) even when issuing

bin/package make

I do not really understand why this is happening to me with the setup described previously. it should be possible to compile even if $SHELL points to /bin/ksh but ksh93u+m is found by which ksh when in toplevel of project dir, no?

only after pointing my ksh link to mksh rather than the u+m/1.0.0 binary the new make run succeeded. I don't get it...

[JohnoKing]

This should be a simplified reproducer for the crash:

$ ENV=/dev/null ksh -ic 'alias r=foo; unalias r'
free(): invalid pointer
Abort(coredump)

FWIW I have encountered other crashes caused by the predefined aliases (see commits 5d50f82 and 7e7f137). In ksh2020 the crashing situation is a bit worse, as r cannot be removed with unalias r.

$ ksh2020 -c 'unalias r'
free(): invalid pointer
Abort(coredump)

[posguy99]

@McDutchie Related to r, here's something odd (this is a freshly started shell):

Created new issue #510 for the recursion error with r.

[McDutchie]

@JohnoKing's reproducer is actually a separate crash. Here is a patch that should fix both crashes. I've no time to explain how it works now, but please test it.

Patch

diff --git a/src/cmd/ksh93/bltins/typeset.c b/src/cmd/ksh93/bltins/typeset.c
index 07a2d5695..486f24417 100644
--- a/src/cmd/ksh93/bltins/typeset.c
+++ b/src/cmd/ksh93/bltins/typeset.c
@@ -1286,7 +1286,7 @@ static int unall(int argc, char **argv, register Dt_t *troot)
 	register const char *name;
 	volatile int r;
 	Dt_t	*dp;
-	int nflag=0,all=0,isfun,jmpval,nofree_attr;
+	int nflag=0,all=0,isfun,jmpval;
 	struct checkpt buff;
 	NOT_USED(argc);
 	if(troot==sh.alias_tree)
@@ -1388,13 +1388,6 @@ static int unall(int argc, char **argv, register Dt_t *troot)
 					sh_assignok(np, !nv_isattr(np,NV_NODISC|NV_ARRAY) && !nv_isvtree(np));
 				}
 			}
-			/*
-			 * Preset aliases have the NV_NOFREE attribute and cannot be safely freed from memory.
-			 * _nv_unset discards this flag so it's obtained now to prevent an invalid free crash.
-			 */
-			if(troot==sh.alias_tree)
-				nofree_attr = nv_isattr(np,NV_NOFREE);	/* note: returns bitmask, not boolean */
-
 			if(!nv_isnull(np) || nv_size(np) || nv_isattr(np,~(NV_MINIMAL|NV_NOFREE)))
 				_nv_unset(np,0);
 			if(troot==sh.var_tree && sh.st.real_fun && (dp=sh.var_tree->walk) && dp==sh.st.real_fun->sdict)
@@ -1411,7 +1404,10 @@ static int unall(int argc, char **argv, register Dt_t *troot)
 			{
 				if(sh.subshell && !sh.subshare)
 					sh_subfork();	/* avoid affecting the parent shell's alias table */
-				nv_delete(np,troot,nofree_attr);
+				_nv_unset(np,NV_RDONLY|nv_isattr(np,NV_NOFREE));
+				dtdelete(troot,np);
+				if(!sh.bltin_aliases || np < sh.bltin_aliases || np > &sh.bltin_aliases[sh.bltin_num_aliases])
+					free(np);
 			}
 		}
 		else if(troot==sh.alias_tree)
diff --git a/src/cmd/ksh93/include/shell.h b/src/cmd/ksh93/include/shell.h
index 8ab90b835..cb7607959 100644
--- a/src/cmd/ksh93/include/shell.h
+++ b/src/cmd/ksh93/include/shell.h
@@ -251,6 +251,8 @@ struct Shell_s
 	pid_t		current_ppid;	/* PPID of current ksh process (updates when subshell forks) */
 	unsigned char	sigruntime[2];
 	Namval_t	*bltin_nodes;
+	Namval_t	*bltin_aliases;
+	int		bltin_num_aliases;
 	Namval_t	*bltin_cmds;
 	History_t	*hist_ptr;
 	char		*shpath;
diff --git a/src/cmd/ksh93/sh/init.c b/src/cmd/ksh93/sh/init.c
index aad6999b3..8d901ccd8 100644
--- a/src/cmd/ksh93/sh/init.c
+++ b/src/cmd/ksh93/sh/init.c
@@ -1627,9 +1627,10 @@ int sh_reinit(char *argv[])
 		if((dp = sh.alias_tree)->walk)
 			dp = dp->walk;
 		npnext = (Namval_t*)dtnext(sh.alias_tree,np);
-		nofree = nv_isattr(np,NV_NOFREE);			/* note: returns bitmask, not boolean */
-		_nv_unset(np,NV_RDONLY);				/* also clears NV_NOFREE attr, if any */
-		nv_delete(np,dp,nofree);
+		_nv_unset(np,NV_RDONLY|nv_isattr(np,NV_NOFREE));
+		dtdelete(sh.alias_tree,np);
+		if(!sh.bltin_aliases || np < sh.bltin_aliases || np > &sh.bltin_aliases[sh.bltin_num_aliases])
+			free(np);
 	}
 	/* Delete hash table entries */
 	for(np = dtfirst(sh.track_tree); np; np = npnext)
@@ -1966,6 +1967,11 @@ Dt_t *sh_inittree(const struct shtable2 *name_vals)
 		sh.bltin_nodes = np;
 		nvars = n;
 	}
+	else if(name_vals==shtab_aliases)
+	{
+		sh.bltin_aliases = np;
+		sh.bltin_num_aliases = n;
+	}
 	else if(name_vals==(const struct shtable2*)shtab_builtins)
 		sh.bltin_cmds = np;
 	base_treep = treep = dtopen(&_Nvdisc,Dtoset);

[posguy99]

Works for me.

$ ENV=/./dev/null arch/darwin.i386-64/bin/ksh
$ alias r=foo                                                                                                          
$ bin/package
darwin.i386-64

and

$ ENV=/dev/null arch/darwin.i386-64/bin/ksh -ic 'alias r=foo; unalias r'                                   
$ 

[McDutchie]

Thanks for testing. I ended up going with a slightly different approach that simplifies things and allows removing workarounds instead of adding them. See 9067bb3 for full explanation.

[benalt613]

I compiled it in Cygwin and notice that in vim, highlighting text doesn't copy it. It does copy outside of VIM. It also does so in Bash and with 93u+ 2012-08-01 which was the last version I was using.

[benalt613]

Is there a way to compile it so that the shell understands files without case insensitivity for Windows? Or perhaps some setting from the command line? In my 2012 version, it worked like that, but not so with ksh 93u+m/1.0.0.

[McDutchie]

Note that we're on release 1.0.3 by now. Please use the latest for several more bug fixes.

I'm not a vim user, but ksh has zero involvement in highlighting or copying text from the terminal, so whatever problem you are having with that must be caused by something else. Are there any other vim users here who might be able to weigh in on this?

Case (in)sensitivity for globbing (pathname expansion) and completion can be controlled using the new globcasedetect option which you can turn on and off with set.

Hope this helps...

[benalt613]

Thanks. That's exactly what I was looking for. The highlighting issue is strange because I use mintty and when I use the bash shell, it works fine and then I run ksh on top and it no longer copies from vim.

I just noticed now that it works fine if I use /usr/bin/vi, but in vim highlighting changes it to "visual mode" and I think that is the issue. vi though shows vim when starting without specifying a file.