command -x utility ... can be used as a built-in alternative for xargs. In contrast to xargs implementations it tries to max out the getconf ARG_MAX buffer to reduce the number of utility executions and thus might be faster.

However, its available buf size calculation is wrong: ignores terminating \0 and last char of argv[]/env[]/auxv[] strings. Also, most execve implementations (Solaris, Linux, Darwin, NetBSD, OpenBSD) add a pointer for all related strings to the buffer, so they need to be taken into account as well (FreeBSD seems to be the only exception here).

Furthermore the related error handler does not expect, that execve may return with E2BIG as well, which causes an endless loop if E2BIG occures.

Finally, the command should be enhanced, so that it tries to fail early, if there is no sufficient buf space available and it should try much harder to avoid failing with E2BIG.

See also att/ast#1048

See also ksh93/ksh@acf84e9 - however, this commit is wrong wrt. space calculation, wastes a lot of space, gives up to early, dropped the error handling and thus is not reliable/usable. In contrast to its headline it does definitely not fix the problem on Solaris. Also the alignment statement is wrong - the string section[s] (argv, env, auxv) and str pointer section might be aligned to sizeof(void *) - so max. 4*15 = 60 bytes on 64bit (but there is no alignment for each string). IMHO there is no need to take this into account because the calculation already reserves 1024 bytes (POSIX suggests 2048 bytes) for implementation details like this.

The builtin cd does not appear to check its environment for HOME when determining where to change the working directory when given no arguments.

# HOME=/bin cd; pwd
/root # Should be /bin

This otherwise works in every shell-including bourne-and is specified by POSIX:

2. If no directory operand is given and the HOME environment variable is set to a non-empty value, the cd utility shall behave as if the directory named in the HOME environment variable was specified as the directory operand.

ksh93u+ (Version AJM 93u+ 2012-08-01) compiled from source on cygwin64
CYGWIN_NT-10.0 WSHQ1803 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
behaves exactly like bug described in RELEASE:

08-12-07 A timing bug on some systems (for example darwin), that could
cause the last process of a pipeline entered interactively to fail
with an "Exec format error" has been fixed.

the error code is 126
setting CCFLAGS=-D_AST_no_spawnveg=1 helped

also lib\libast\path\pathnative.c relies on cygwin_conv_to_win32_path which is not supplied, i had it replaced with cygwin_conv_path

Apple just released macOS 10.15.5, and a secuity vuln they claim they fixed is this one. If you look at the CVE, it refers to a krader patch against what I think is ksh2020?

Apple's open source site ends at 10.15.3, so I can't see what they patched.

At 10.15.3, they were using 93u+.

Someone tell me, please, they haven't jumped tracks. I haven't installed the update yet, and don't really want to, but do want to, because it fixes a whale of a lot of security holes besides this one.

https://nvd.nist.gov/vuln/detail/CVE-2019-14868
https://support.apple.com/en-us/HT211170

att/ast@c7de8b6

I accidentally noted the following behaviour:

 printf '%.1f\n' 0.19  # --> 0.2  good
 printf '%.2f\n' 0.019  # --> 0.01  BAD
 printf '%.1g\n' 0.019  # --> 0.02 good

so %f format seems partly broken...

@jelmd/All,

Thanks for maintaining this. I wanted to know if there is a way to create an rpm out of this out of the box? or a tar may be?

/bin/package write rpm ?
Thanks in advance.

Apple's official build of ksh on macOS is maintained on their Darwin site. We should merge their patches and ensure our build works from here-on on macOS.

That done we should encourage update of Homebrew's formula. Likewise for MacPorts.

All is on att/ast#1478

PS. Any plans to make forst release?

I created a video of the issue:
https://www.youtube.com/watch?v=oPERMapfapo

Emacs 26.1, ssh 93u+, Debian Linux 10.

^L's are output while moving the mode line in the middle of two buffers. This behavior does not occur using Emacs as a shell.

How can it be diagnosed if the problem is ksh or Emacs?

Thanks

Is this project in active development? If so, is it serious work or, say, hobbyist type? Just wondering. I have not been pleased with the direction the KSH2020 project has been going, and it seems to have petered out anyway. I am just wondering where this project is going and what plans are in works.

Cheers,
Russ

Obsolete command line options should probably be trashed in the next + 1 release -- not the next release as supposedly the next release will be our gold master of 93u+.

Test case A:

1. Type backslash
2. Type Ctrl-B
3. Carrot B appears
4. The expected result is to go backwards one character, instead of printing Carrot B

There is been discussion that this behavior is expected based on p106 of Korn's book. At the same time typing backslash and Ctrl-C works as expected without printing Carrot C. Backslash Ctrl-D behaves the same as Test case A.

There is a video reproducing this at:
https://www.youtube.com/watch?v=ojfAgdnwQzw&feature=youtu.be

Notes from KSH mailing list discussion:
Kurtis: That behavior is present in the ksh93u+ release and thus is not something introduced since the most recent stable release seven years ago. Note that the unexpected behavior is due to the backslash. Without the char under the cursor being a backslash [ctrl-B] and [ctrl-F] behave as you would expect. This affects pretty much every control char such as [ctrl-A] to move to the start of the line. Whether this behavior is good or bad is debatable. If you feel it should be changed, despite being long standing behavior, please open an issue

The problem isn't the presence of parenthesis; it's the backslash. Type a\[ctrl-B]. This behavior only happens if the most recent character you typed is a backslash. So you can type a()b, then move the cursor inside the parens, type \[ctrl-B] and the same thing will happen. Personally, I think the magic backslash is a misfeature. You can always type [ctrl-V][ctrl-B] to insert a literal [ctrl-B]. Feel free to open an issue. Even better, create a patch for us to review.

On that platform /bin/ksh is 93t+ 2010-03-05 and exhibits the behavior you described. You should be able to run /bin/ksh --version to figure out which ksh variant you're using.

Having said all that I agree with you the behavior is confusing and should be changed regardless of how many years it has been in effect.

by default time reports two decimal digits. this is controlled by the variable TIMEFORMAT. changing the latter to, e,g, TIMEFORMAT=$'\nreal\t%3R\tuser\t%3U\tsys\t%3S' enforces reporting of 3 decimal digits (more are not supported anyway according to manpage). however, the third digit is always reported as zero. example

 TIMEFORMAT=$'\nreal\t%3R\tuser\t%3U\tsys\t%3S'
time sleep 1.235 # → real	1.260	user	0.010	sys	0.000

(the observed output is of course somewhat variable but the third digit is reported consistently as 0).
this is also broken in 93v- but works correctly in ksh2020.

such high precision timing (1 ms accuracy) usually is not of much relevance but it can be different during benchmarking when computing averages and standard deviations of multiple repeated runs.

After 2020-02-14 (this repo's base) one freebsd 12 patch got merged into ast/ksh.
Task: syn with att/ast#1473

We suggest in the instructions to override CCFLAGS like this:

./bin/package make \
    SHELL=/bin/bash CCFLAGS="-xc99 -D_XPG6 -m64 -xO4" LDFLAGS="-m64"

However, there are some places like for example lib/ast/libast/Makefile:

where CCFLAGS gets overwritten anyway. If we override that, and CC.DLL is needed to be to set -fPIC and things like that we may end up in problems with linking.

I don't have a clear reproduction case for this issue right now, but I have noticed builds breaking when trying to set CCFLAGS to quell clang warnings.

the following command fails to print the expected output
and writes a file named $'\312\004' to the working directory

% echo abc > >(cat)

expected output

% echo abc > >(cat)
abc