ksh 93u+m: KornShell reboot, take 3

[Martijn Dekker]

Short version:

- New ksh 93u+m branch based on 93u+: https://github.com/modernish/ksh
- Currently the only actively developed ksh93 fork
- Loads of bugs fixed already, loads more fixes to follow
- Regression test suite fixed to working state, preventing more bugs
- Please test, and send bug reports and patches to github, or this list
- If ksh-community ever get started, so much the better; they can take
all the fixes. Meanwhile, I'm done with waiting. Let's get to work!

Long version:

1. Why?
2. Policy
3. My qualifications

WHY?

Between 2017 and 2020 there was an ultimately unsuccessful attempt to
breathe new life into the KornShell by extensively refactoring the last
unstable AST beta version (93v-). While that ksh2020 branch is now
abandoned and still has many critical bugs, it also had a lot of bugs
fixed. More importantly, the AST issue tracker now contains a lot of
documentation on how to fix those bugs, which makes it possible to
backport many of them to the last stable release instead.

In February 2020, having concluded the AST 93v- beta was too broken to
base new work on, others decided to start a new fork based on the last
stable 93u+ 2012-08-01 release. Unfortunately, the new ksh-community
organisation is yet to see any significant activity three and a half
months after its bootstrapping. I hope that will change; this fork is
not intended as hostile.

The last stable ksh93 release from 2012 is the least buggy release
currently available, but it still has many serious bugs. So it is well
past time to start fixing those bugs, leave the rest of the code alone,
and get an improved release out there.

As far as I know, 93u+m is currently the only actively developed
fork/branch of ksh93. Many bugs are already fixed, many more are waiting
to be fixed, and I'm sure there are many more yet to be reported and/or
discovered. The goal is to work towards the most solid ksh93 release
ever, without compromising on performance or compatibility.

My ongoing discussion with the ksh-community folks can be seen here:
https://github.com/ksh-community/ksh/issues/11

POLICY

1. No new features. Bug fixes only.
2. No major rewrites. No refactoring code that is not fully understood.
3. No changes in documented behaviour, except if required for compliance
with the POSIX shell language standard which David Korn intended for
ksh to follow.
4. No 100% bug compatibility. Broken and undocumented behaviour
gets fixed.
5. No bureaucracy, no formalities. Just fix it, or report it: create
issues, send pull requests. Every interested party is invited to
contribute.
6. To help increase everyone's understanding of this code base,
fixes and significant changes should be fully documented in commit
messages.

MY QUALIFICATIONS

It has been correctly pointed out that ksh should be maintained by
someone qualified. So, what qualifies me to maintain a fork (even if, as
I hope, it will be temporary until ksh-community gets its act together)?

I live and breathe shell. Whereas many people have a disdain for POSIXy
shell languages (which was IMHO the fatal flaw of the most active
ksh2020 developer), I have a real love for them and I see a lot of
potential that is untapped to this day -- particularly in a shell like
ksh93 which combines great functionality with great performance.

I have a real respect for the history and nature of a project like ksh.
I want ksh to live, but stay itself. I don't believe in massive
overhauls, nor in refactoring for the sake of it. I believe the 93u+m
bugfix version's behaviour should change no more, and no less, than the
minimum necessary to fix bugs.

I'm a member of the Austin Group, where I've argued with the POSIX
standard developers quite a bit and occasionally even convinced them of
my point of view. My name is among the hundreds acknowledged in the
POSIX standard (PDF version).

I've been developing a novel and robust cross-platform shell language
enhancement library for about five years, which has many innovative
features not seen elsewhere, and which also works on ksh 93u+ 2012
(working around its many bugs): https://github.com/modernish/modernish

Unlike the Bell Labs ksh/AST authors, I am a bit of a perfectionist. You
can really tell ksh was a research project; the code shows a lot of
signs of being written by people excited to invent and try new concepts,
and not so excited to do the boring work of ensuring correctness. My
appetite for innovation is more than satisfied by working on modernish.
I find fixing bugs and breakage equally satisfying, and I intend to do
just that when working on ksh.

Developing modernish has made me very good at breaking shells, and
particularly gave me an an intimate familiarity with many of the bugs in
ksh 93u+ 2012 version. Most active POSIX shell authors (of bash, dash,
NetBSD sh, mksh, yash, zsh) have been getting to know me over the last
five years as I kept sending them bug reports and patches, sometimes for
decades-old bugs. You can find my name in all their changelogs and/or
commit messages. I've had a particularly active collaboration with kre
(Robert Elz) of NetBSD sh, who sent me test versions with my initials in
the version ID :) As a result NetBSD 9.0 is now the first release that
has a sh that can properly be called POSIX compliant.

I don't pretend to understand everything, or even most things, about the
barely-commented ksh93 code base. Unfortunately the only people with an
intimate understanding of the same worked at AT&T Bell Labs and are now
inactive. But my understanding has been growing by watching ksh2020
develop and then unravel. I am also good at knowing my limits; if I
don't understand it, I don't touch it. And I am more than ready to
accept patches by those who understand what I don't; you just have to
convince me that you know what you are doing :)

The proof of the pudding is in the eating. I've already done a lot of
ground work that is out there in public. (There's already someone
sending pull requests as well, I've got four merged so far.) How
qualified I really am can only be shown by the quality of my work, which
is up to the community to judge.

So I invite everyone to review the git log regularly, and open bugs or
pull requests. If you're too old-school for that, sending reports or
patches to this list is also fine (unless the community on this list
objects to that, in which case I can start my own list).

- Martijn

--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/modernish/ksh

[Kamil Dudka]

Thank you for working on this!  I think your policy works much better than what ksh-comunity is trying to enforce in their imaginary world.  I also like the work that has been done on your fork so far.  Really appreciated.  Keep up the good work.

[Siteshwar Vashisht]

----- Original Message -----
> From: "Martijn Dekker" <mar...@inlv.org>
> To: korn-...@googlegroups.com
> Sent: Wednesday, June 10, 2020 3:19:28 AM
> Subject: ksh 93u+m: KornShell reboot, take 3

Thanks for taking the initiative.

>
> Short version:
>
> - New ksh 93u+m branch based on 93u+: https://github.com/modernish/ksh

I don't trust this commit[1] and your entire work is based on it. Have you verified that files were not tempered with and this commit represents what the commit message say (i.e. it does not deviate from ksh version 2012-08-01) ? I would suggest you to base your work on master branch from att/ast[2].

> - Currently the only actively developed ksh93 fork
> - Loads of bugs fixed already, loads more fixes to follow
> - Regression test suite fixed to working state, preventing more bugs
> - Please test, and send bug reports and patches to github, or this list
> - If ksh-community ever get started, so much the better; they can take
> all the fixes. Meanwhile, I'm done with waiting. Let's get to work!

As I mentioned earlier, people behind ksh-community lack any ability to do useful work. It's unlikely I will support that fork of ksh.

You might be interested in this repository too[3].

> --
> You received this message because you are subscribed to the Google Groups
> "Korn Shell" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to korn-shell+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/korn-shell/2c0d6f5d-1289-9888-a187-46eb2d68d064%40inlv.org.
>
>


[1] https://github.com/modernish/ksh/commit/e7f25423818abe159edf52f5799d66bd3621ab0b
[2] https://github.com/att/ast/commits/master
[3] https://github.com/posix-shell-tests/posix-shell-tests

--
--
Siteshwar Vashisht

[Martijn Dekker]

Op 10-06-20 om 15:37 schreef Siteshwar Vashisht:
> From: "Martijn Dekker" <mar...@inlv.org>

>> Short version:
>>
>> - New ksh 93u+m branch based on 93u+:
>> https://github.com/modernish/ksh
>
> I don't trust this commit[1] and your entire work is based on it.
> Have you verified that files were not tempered with and this commit
> represents what the commit message say (i.e. it does not deviate from
> ksh version 2012-08-01) ?

That is a valid point. Personally I didn't see cause to think that these
people might have malicious intentions, but on the other hand, paranoia
is underrated.

So, I'll verify it now, by comparing the 14th February state that
ksh-community forked off from
<https://github.com/att/ast/commit/a30e7b7f> to the first commit on the
93u+m branch. Please follow along:

$ mkdir verify && cd verify
$ git clone https://github.com/modernish/ksh
$ cd ksh
$ git log --reverse --pretty=format:%h | head -n 1 # find 1st commit
e7f25423
$ git remote add ast https://github.com/att/ast
$ git fetch ast
$ git diff a30e7b7f e7f25423

Now, we know the ksh-community folks removed a bunch of non-ksh
utilities (which I agree with, or at least did at the time -- see
further on), so removed files are irrelevant for this purpose. To detect
possible tampering, I'm using my pager to search the 43 MB of 'git diff'
output for '+++ b/', which finds every file that was changed or added,
while ignoring removed files.

This shows 8 changed or added files:

1. an added .gitignore

2. an edited README.md

3. a corrected copyright year in the bin/package licence header
(yes, it should be 2012 and not 2020)

4. an added docs/repo-boostrap.md (how to reproduce the bootstrap)

5. some cosmetic edits to documentation file lib/package/INIT.html

6. remove non-ksh utils docs from lib/package/ast-ksh.README

7. remove non-ksh utils docs from lib/package/ast-ksh.html

8. non-substantial diffs in src/cmd/INIT/proto.c indicating the file
was regenerated

...and that's it. No other changes, except for many removed files.

Do you think this sufficient to demonstrate the integrity of the
ksh-community fork and mine?

> I would suggest you to base your work on master branch from
> att/ast[2].

Actually, in hindsight, I sort of wish I had.

At the time, I agreed with the ksh-community's removal of all the extra
non-ksh utilities. I saw no reason to duplicate that non-trivial work
myself, so it seemed more opportune to use the fork with it already done.

However, I am starting to find that removing nmake wasn't such a good
idea after all. nmake is what generates the machine code-style Mamfiles
from the Makefiles. So the removal of nmake has made any changes to the
Makefiles ineffective. Yes, the build system is capable of falling back
to just mamake and Mamfiles, but that's just what it is: a fallback.
Editing Mamfiles by hand is something I've tried. Would not recommend.

And removing the pty utility (pseudo-terminal for scripting interactive
sessions) was not such a good idea either, because now there is no way
for the pty.sh regression tests to work. And they are the only
regression tests for the interactive shell. Detecting regressions for
the interactive shell is important -- after all it's still one of the
primary uses of a shell. So I want to re-import pty, without getting all
the other baggage if possible. But there is no feasible way to do that
without nmake to regenerate all the machine-generated stuff.

I'm still in the process of deciding what to do about that. Maybe I'll
just re-import the whole set of utilities from att/ast/master after all.
It would be a quick fix, and the extra baggage is probably not that
harmful and we can get rid of individual utils again later.

Anyway, having demonstrated sufficiently (I hope) that the ksh-community
fork didn't change anything about ksh or libast or anything else
substantial, I'm not going to rebase my fork off of att/ast. That would
require redoing far too much work at this point -- and seriously
inconvenience one developer who has joined me in the meantime, sending
multiple pull requests per day.

> As I mentioned earlier, people behind ksh-community lack any ability
> to do useful work. It's unlikely I will support that fork of ksh.

I will refrain from commenting on that assessment. I like to judge code,
not people. When (if?) they get started, the quality of their work will
reveal itself soon enough.

But I will say that shbench is a rather nice little performance testing
tool... https://github.com/ksh-community/shbench

> You might be interested in this repository too[3].

[...]
> [3] https://github.com/posix-shell-tests/posix-shell-tests

Thanks. I'm aware of it, as a matter of fact.

Unfortunately I cannot use any of these tests, as they are under the GNU
General Public License v2.0, which is incompatible with the Eclipse
Public License v1.0 which AT&T have chosen.

[joerg van den hoff]

On Wednesday, 10 June 2020 15:37:49 UTC+2, Siteshwar Vashisht wrote:

----- Original Message -----
> From: "Martijn Dekker" <mar...@inlv.org>
> To: korn-...@googlegroups.com
> Sent: Wednesday, June 10, 2020 3:19:28 AM
> Subject: ksh 93u+m: KornShell reboot, take 3

Thanks for taking the initiative.

>
> Short version:
>
> - New ksh 93u+m branch based on 93u+: https://github.com/modernish/ksh

I don't trust this commit[1] and your entire work is based on it. Have you verified that files were not tempered with and this commit represents what the commit message say (i.e. it does not deviate from ksh version 2012-08-01) ? I would suggest you to base your work on master branch from att/ast[2].

siteshwar,

if you would have bothered to look here https://github.com/ksh-community/ksh/blob/master/docs/repo-boostrap.md, you might have been able to avoid this minor FUD campaign. so rest assured that everything is perfectly in order with that repo (or invest the 5 minutes to convince yourself).

> - Currently the only actively developed ksh93 fork
> - Loads of bugs fixed already, loads more fixes to follow
> - Regression test suite fixed to working state, preventing more bugs
> - Please test, and send bug reports and patches to github, or this list
> - If ksh-community ever get started, so much the better; they can take
>    all the fixes. Meanwhile, I'm done with waiting. Let's get to work!

As I mentioned earlier, people behind ksh-community lack any ability to do useful work. It's unlikely I will support that fork of ksh.

that seems to be wishful thinking on your side. you do not have any justification for that claim. this, too, is just FUD. I would appreciate if you could stop this rather unpleasant behaviour, ok? it is not helpful. just wait and see what does or does not happen in the long run at ksh-community. than you might voice an opinion. right now I would only accept "moving too slow".

regarding martijn's initiative, I personally fully welcome it. I am also confident that that there will be no hard feelings or silly competition between the guys at ksh-community and him since the principal approach (don't repeat the ksh2020 mess, tread carefully) seems quite similar. so I am optimistic for the future. and if most of the relevant work ends up to be done in martijn's fork: fine with me. AFAIAC one just should strive at a single agreed upon location that then can serve as the new upstream etc. need not be at ksh-community. but could be. one will have to wait and see, how things work out within the next 6-12 months, I'd say.

br/joerg (a.k.a. jgub  at github...)

 

> email to korn-...@googlegroups.com.

[Siteshwar Vashisht]

----- Original Message -----
> From: "Martijn Dekker" <mar...@inlv.org>
> To: korn-...@googlegroups.com

This type of idiotic behavior is exactly why I want to stay away from their fork. Ideally they should have pulled from upstream ast codebase and selectively made changes in separate commits to make it clear what was the intention of their changes. Instead they tried to "bootstrap" by commiting thousands of lines of code in a single commit and making multiple changes with no clear commit message.

>
> ...and that's it. No other changes, except for many removed files.
>
> Do you think this sufficient to demonstrate the integrity of the
> ksh-community fork and mine?

For my work, I will stay away from any code that's touched by people behind ksh-community. I will leave it upto what do you want to base your work on.

You don't need to integrate the code from these tests in your repository. You can run the tests separately.

>
> - Martijn
>
> --
> || modernish -- harness the shell
> || https://github.com/modernish/modernish
> ||
> || KornShell lives!
> || https://github.com/modernish/ksh
>

> --
> You received this message because you are subscribed to the Google Groups
> "Korn Shell" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to korn-shell+...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/korn-shell/aeda64ef-2fce-82f2-bef9-7eaff6678191%40inlv.org.
>
>

--
--
Siteshwar Vashisht

[joerg van den hoff]

martijn,

considering that siteshwar has decided to augment FUD accusations by plain old invectives, it seems pointless to ask him again to switch to a sober and constructive (or should I call it "no drama"?) modus operandi. so I will leave him alone to his ranting (as long as my powers of self-restraint don't fail me, that is).

regarding the sparse factual content of his post (objecting with inadequate wording against the way the repo was bootstrapped and whether that is a big deal -- involuntarily funny in view of the fact how ksh2020 checkins and changes were partly handled btw...), please  make up your own mind how big a deal this way of bootstrapping the repo is/was.

in fact, I had a discussion with 'jelmd' at the time and he had good arguments to set it up like he did (saving *him* time, e.g.. but having cost *you* now  some time to double-check that, indeed, the repo started from a sane state -- sorry for that: it was one of my arguments at the time against jelmd's approach ;)). but I would suggest that you discuss these issues with him directly, if you find it necessary or useful.  but it probably is just distracting and tangential to the relevant future issues. yesterday's story, basically.

for the future there is a very clear intention to follow the only sane approach in ksh-community: "atomic" clearly documented checkins etc.

br/joerg

> email to korn-...@googlegroups.com.

[Kamil Dudka]

Martijn, thank you for digging all the info above!

> This type of idiotic behavior is exactly why I want to stay away from their
> fork. Ideally they should have pulled from upstream ast codebase and
> selectively made changes in separate commits to make it clear what was the
> intention of their changes. Instead they tried to "bootstrap" by commiting
> thousands of lines of code in a single commit and making multiple changes
> with no clear commit message.

I totally agree that the bootstrap could have been done better. On the other
hand we do not have per-commit history for the ksh93u+ release either, do we?

It looks like none of the above changes would lead to unrecoverable problems
later on. A significant amount of work has been done on top of the mentioned
bootstrap already. Unless someone volunteers to rebase all the work on top
of something else, I see no reason to block further progress on this project.

Kamil

[Martijn Dekker]

Op 11-06-20 om 12:47 schreef Siteshwar Vashisht:

> This type of idiotic behavior is exactly why I want to stay away from
> their fork. Ideally they should have pulled from upstream ast
> codebase and selectively made changes in separate commits to make it
> clear what was the intention of their changes. Instead they tried to
> "bootstrap" by commiting thousands of lines of code in a single
> commit and making multiple changes with no clear commit message.

I agree that is not optimal. As you can see in my repo, I strongly
believe in full documentation in git commit messages.

However, note that they detailed exactly what they did in bootstrap.md,
and made the bootstrap reproducible. That is, in fact, documentation.

>> ...and that's it. No other changes, except for many removed files.
>>
>> Do you think this sufficient to demonstrate the integrity of the
>> ksh-community fork and mine?
>
> For my work, I will stay away from any code that's touched by people
> behind ksh-community. I will leave it upto what do you want to base
> your work on.

The fact is, they haven't actually touched any code yet! I do believe
I've demonstrated that. And that is why I've now taken the initiative.

However (please correct me if I'm wrong), you appear to be in charge of
whatever ksh93 goes into Red Hat and derived distros. And that is important.

And I do find that removing nmake and pty, at least, was a mistake,
which is now causing me considerable inconvenience. The interactive
shell *must* be subject to regression tests.

So, between that, and your strong feelings about it, I may just have
re-bootstrap a new repo off of ast, cherry-pick all my commits up to
now, and accept the loss of the issue tracker. If it's going to happen,
it had better happen very soon, because it will only get more difficult
as time goes on. <sigh>

>>> You might be interested in this repository too[3].
>> [...]
>>> [3] https://github.com/posix-shell-tests/posix-shell-tests
>>
>> Thanks. I'm aware of it, as a matter of fact.
>>
>> Unfortunately I cannot use any of these tests, as they are under
>> the GNU General Public License v2.0, which is incompatible with the
>> Eclipse Public License v1.0 which AT&T have chosen.
>
> You don't need to integrate the code from these tests in your
> repository. You can run the tests separately.

Yes, thanks, I will do just that when I find the time. A quick trial run
shows that at least some of the failures are due to yash specificities,
so cherry-picking potential fixes is non-trivial. But I will do.

- M.

[Martijn Dekker]

Op 11-06-20 om 14:01 schreef Kamil Dudka:

> I totally agree that the bootstrap could have been done better. On the other
> hand we do not have per-commit history for the ksh93u+ release either, do we?

No, we sure don't! The Bell Labs folks were very lax about documenting
their changes (those are some of the sloppiest changelogs I've ever
seen) and loathe to document their code at all.

> It looks like none of the above changes would lead to unrecoverable problems
> later on. A significant amount of work has been done on top of the mentioned
> bootstrap already. Unless someone volunteers to rebase all the work on top
> of something else, I see no reason to block further progress on this project.

But what about Siteshwar's stance on this? Isn't his support important?
Who is actually in charge of the ksh93 port at Red Hat?

[Martijn Dekker]

Op 11-06-20 om 13:25 schreef joerg van den hoff:

> considering that siteshwar has decided to augment FUD accusations by
> plain old invectives,

[...]

I don't think this is a productive line of discussion. Can we please
stick to discussing code and issues, instead of criticising behaviour
and speculating on motives?

Disregarding his behaviour, Siteshwar had one concrete point of
principle: the ksh-community bootstrapping process was suboptimal. I do
believe I just found you agreeing with that.

Now, whether that is a fatal flaw or not, is a matter that opinions can
legitimately diverge on. I think it's non-fatal, Siteshwar disagrees.

If re-forking off the ast base will eventually cause my code to have a
wider support from the community, then I'm going to have to bite the
bullet and do it -- and soon, before it becomes completely unfeasible.

Having wider community support for my code is in the interest of
ksh-community as well, if you ever get around to getting started and
want to import my work.

It would be a real shame if rebasing 93u+m caused me to lose the support
of you guys. But as for the code, based on the current situation, it's
neither here nor there. Neither ksh-community nor the old ksh2020 team
are producing any.

[joerg van den hoff]

On Thursday, 11 June 2020 14:30:04 UTC+2, Martijn Dekker wrote:

Op 11-06-20 om 14:01 schreef Kamil Dudka:
> I totally agree that the bootstrap could have been done better.  On the other
> hand we do not have per-commit history for the ksh93u+ release either, do we?

No, we sure don't! The Bell Labs folks were very lax about documenting
their changes (those are some of the sloppiest changelogs I've ever
seen) and loathe to document their code at all.

> It looks like none of the above changes would lead to unrecoverable problems
> later on.  A significant amount of work has been done on top of the mentioned
> bootstrap already.  Unless someone volunteers to rebase all the work on top
> of something else, I see no reason to block further progress on this project.

But what about Siteshwar's stance on this? Isn't his support important?
Who is actually in charge of the ksh93 port at Red Hat?

my 2c: I am with kamil dudka here: why start over, exactly, if it is agreed that your starting point is sane (modulo nmake, pty maybe)? I also still believe, that the people who decided to set up ksh-community _will_ and can contribute notably and that one should try to pool all available resources rather than to make a point of having nothing to do with people at ksh-community.

siteshwar's agenda is quite obviously driven by other motives ("retribution" and "revenge" comes to my mind, I must say). that is not for the benefit and in the interest of ksh in my view.

br/joerg

[joerg van den hoff]

On Thursday, 11 June 2020 14:44:25 UTC+2, Martijn Dekker wrote:

Op 11-06-20 om 13:25 schreef joerg van den hoff:
> considering that siteshwar has decided to augment FUD accusations by
> plain old invectives,
[...]

I don't think this is a productive line of discussion. Can we please
stick to discussing code and issues, instead of criticising behaviour
and speculating on motives?

fine with me. that was the message, actually. calling an invective ("idiotic") an invective is legitimate, though.

 

Disregarding his behaviour, Siteshwar had one concrete point of
principle: the ksh-community bootstrapping process was suboptimal. I do
believe I just found you agreeing with that.

I said I had that discussion but jelmd had better arguments in the end :). and the repo is  a clean starting point (minus some bits you are missing and which might be reintroduced). 

 

Now, whether that is a fatal flaw or not, is a matter that opinions can
legitimately diverge on. I think it's non-fatal, Siteshwar disagrees.

he disagrees because he wants to settle a score. lamentable but seems quite obvious to me. quite obviously, the bootstrap is accetable and not fatally flawed.

 

If re-forking off the ast base will eventually cause my code to have a
wider support from the community, then I'm going to have to bite the
bullet and do it -- and soon, before it becomes completely unfeasible.

Having wider community support for my code is in the interest of
ksh-community as well, if you ever get around to getting started and
want to import my work.

It would be a real shame if rebasing 93u+m caused me to lose the support
of you guys. But as for the code, based on the current situation, it's
neither here nor there. Neither ksh-community nor the old ksh2020 team
are producing any.

well,  at least ksh-community did start over while krader/siteshwar never considered to continue ksh2020 and siteswhar refused to participate despite invitation to engage in revival of ks93u+.

and "the community" is small in any case. ksh-community by no means wants to monopolize anything. quite to the contrary. we tried this step (install that github "organisation") with the hope it would attract people like you and otherwise the plan to try and  make ksh93u+ maintained as good as possible in the future by ourselves.

the last months have been a 'black hole' for external reasons (those which for some reason or other seem not to have touched you adversely (quite in contrast to the rest of the world ;)). but that will change, hopefully, soon.

so whatever your decision is, finally, please be aware that siteshwar seems to be the *only* guy out there who simply does not want that ksh-community might be involved. the other red hat engineer (kamil dudka) seems a bit more sober here (that's my impression).

I definitely would prefer if things could just proceed in a constructive way and without "egos" all over the place.

br/joerg

[Martijn Dekker]

Op 11-06-20 om 14:44 schreef joerg van den hoff:
[...]

> I also still believe, that the people who decided to set up ksh-community
> _will_ and can contribute notably and that one should try to pool all
> available resources rather than to make a point of having nothing to do
> with people at ksh-community.

I have to say I am becoming more sceptical of that as time goes on.
Nearly four months now with nothing at all.

You claim not to have time to contribute anything. But you clearly have
time to compose flames and repeatedly speculate on motives.

I am not questioning your basic integrity -- neither of you personally,
nor of the ksh-community code. But I find myself, once again,
unimpressed with the unpleasant behaviour of both camps.

So, that decides it for me. Rebase off ast, it is. Because the current
official repo is now properly disassociated from both sides. At this
point, it'll be about a day of work.

ksh-community remains absolutely welcome to take all my work whenever
you're ready, and I remain absolutely willing to work with you guys
whenever you actually decide to do some work.

- M.

[Kamil Dudka]

On Thursday, June 11, 2020 2:30:02 PM CEST Martijn Dekker wrote:
> Op 11-06-20 om 14:01 schreef Kamil Dudka:
> > I totally agree that the bootstrap could have been done better. On the
> > other hand we do not have per-commit history for the ksh93u+ release
> > either, do we?
> No, we sure don't! The Bell Labs folks were very lax about documenting
> their changes (those are some of the sloppiest changelogs I've ever
> seen) and loathe to document their code at all.
>
> > It looks like none of the above changes would lead to unrecoverable
> > problems later on. A significant amount of work has been done on top of
> > the mentioned bootstrap already. Unless someone volunteers to rebase all
> > the work on top of something else, I see no reason to block further
> > progress on this project.
> But what about Siteshwar's stance on this? Isn't his support important?

Yes, it is. I just wanted to avoid you giving up on this project because
of overly strict requirements stated by consumers of your voluntary work.

> Who is actually in charge of the ksh93 port at Red Hat?

Siteshwar is currently the primary maintainer of ksh in Fedora and Red Hat
Enterprise Linux. We have ksh2020 in Fedora now but it is unlikely that it
would survive there for a long time unless someone resurrected the ksh2020
upstream project.

Kamil

> - Martijn

[Martijn Dekker]

Op 11-06-20 om 15:15 schreef Kamil Dudka:

> Yes, it is. I just wanted to avoid you giving up on this project because
> of overly strict requirements stated by consumers of your voluntary work.

Don't worry. At this point, I'm getting obsessed. So much potential, so
much breakage. It. Must. Be. Fixed. ;)

>> Who is actually in charge of the ksh93 port at Red Hat?
>
> Siteshwar is currently the primary maintainer of ksh in Fedora and Red Hat
> Enterprise Linux. We have ksh2020 in Fedora now but it is unlikely that it
> would survive there for a long time unless someone resurrected the ksh2020
> upstream project.

Right, thanks, that's what I thought.

Between that and all the continuing unpleasantness between him and
ksh-community, I've decided to rebase my fork off of the official ast
repo, because it is now properly disassociated from both sides of that camp.

Hard pass on getting involved with interpersonal nonsense. I am here to
fix ksh.

- M.

[joerg van den hoff]

On Thursday, 11 June 2020 15:09:16 UTC+2, Martijn Dekker wrote:

Op 11-06-20 om 14:44 schreef joerg van den hoff:
[...]
> I also still believe, that the people who decided to set up ksh-community
> _will_ and can contribute notably and that one should try to pool all
> available resources rather than to make a point of having nothing to do
> with people at ksh-community.

I have to say I am becoming more sceptical of that as time goes on.
Nearly four months now with nothing at all.

time will tell, of course.

 

You claim not to have time to contribute anything. But you clearly have

I _stated_ this circumstance since I know that's the situation (disclaimer: me personally, I am sure more fluent in ksh than in C and will

not be the one really "messing" with the ksh C code seriously if I can avoid it so the "no time" mostly refers to jelmd  and jens-maus in the present context)

 

time to compose flames and repeatedly speculate on motives.

 

I take the time to participate in a discussion since I care about ksh as a  properly maintained tool in the future and I am sorry that siteshwar acts the way he does. I don't compose flames.

I repeatedly have drawn attention to the history of the ksh2020 discussion and the stance siteshwar has taken including names calling, recently. I agree that it remains speculation what his motives for the names calling and his hostile behaviour are. it is uncalled for no matter what.

 

I am not questioning your basic integrity -- neither of you personally,

hopefully. why should you?

 

nor of the ksh-community code. But I find myself, once again,

ditto.

 

unimpressed with the unpleasant behaviour of both camps.

as far as I am included in this assessment, I don't accept it as being supported by my contributions here or on github. I acknowledge it as your view, though.

 

So, that decides it for me. Rebase off ast, it is. Because the current
official repo is now properly disassociated from both sides. At this
point, it'll be about a day of work.

your decision, obviously. unnecessary friction will be caused in my view. but I do hope this move pays out in unlimited and competent support by siteshwar. honestly.

 

 
ksh-community remains absolutely welcome to take all my work whenever
you're ready, and I remain absolutely willing to work with you guys
whenever you actually decide to do some work.

either it will happen or it wont. we will see. I do wish you much success in any case

joerg

[jelmd]

 Hi Martijn,

actually I decided to stay away from this hostile ML - I'm really tired
from all these fruitless discussion and if there is know how, or real
problem discussion, it should be attached to the related issue on gitub
or documentation, not on an unstructured ML, especially not on one,
which can be ditched any time by those guys, who are spreading FUD all

the time there (and just because they are from RH, it does not imply, that

they are a priori right). However, because @jghub thinks, it might be worth to

give you some hints I'll give it a try (but please don't expect, that I follow this ML):

Actually I really wonder, why you got into panic by such a little bit
FUD and why do you not trust your own work and intellect? You already
verified, that the ksh-kommunity/ksh repo is authentic (thanks for this
BTW, exactly for this reason I wrote the docs/repo-boostrap.md) and you
draw the right conclusions. Can't really understand your sudden
unfounded change in mind - IMHO you start to make the same failures, as
the previously failed experiment, but perhaps that's their intention
and certainly the outcome of a one-man-show.

However, @jghub mentioned, that you have a problem with nmake and possibly pty.sh. Just
read the `package --man` (the heart of the ast build system) and I'm

sure, you see the damn easy solution to your problem.

However, just to save you a little bit time: Yes, if one wants to change the Makefiles all

the time (I'm not sure why), one should use nmake, because Mamfiles get
re-generated, when the related packages (e.g. INIT*.tgz and ast-ksh*.tgz
- you know, the ones, which got published for decades on the AT&T
  download site and used to create the ksh-kommunity repo) get created.

So, to get nmake, do what you do with your other build tools (e.g.
compiler) as well: install it. There is no need to merge in the source
code of the compiler or any other tool into the source tree of his own
project. I assume, you have already checked out and build the att/ast
repo (lets say ${ASTREPO}) and at least checked out the
ksh-kommunity/ksh repo (lets say ${KSHREPO}). In this case a solution is:

```
cd ${ASTREPO}
bin/package write tgz binary ast-make        #¹
cd ${KSHREPO}
ln -s ${ASTREPO}/lib/package/tgz/ast-make.*.tgz
bin/package read ast-make
```

That's it. `bin/package make` etc. will automatically pick it up and use
it. This solves your pty.sh problem as well. Since pty.sh is already in
the ksh source tree, I guess you refer to the pty utility used in it. It
gets bundled with the nmake package and thus gets installed as well and
is usable out of the box.

So you only need to build the ast-make package once (or download it from
a related site). When you check out an ast project like ksh, just
cp/symlink it to your ast project (e.g. ksh) root or its
lib/package/tgz/ dir and read it in.

If you just need the pty utility and not the whole ast-make package,
copying ${ASTREPO}/arch/*/bin/pty somewhere into your $PATH should be
sufficient as well.

Hope this helps.

Regards,
jel.

#¹ That's actually how gsf produced the packages, which got published on
   the AT&T's download site and used to populate the ksh-kommunity/ksh
   repo. So if you do not trust bin/package, actually you can't trust nmake and
   all the other tools incl. ksh in the att/ast repo as well. So really
   a little bit too paranoid for my taste ...

[Andras Farkas]

I'm super hyped to see this.
I'll note I only found out about this from this email (and this ML) so
to continue to post announcements here (despite the ML owners) would
be useful for me and other people without GitHub accounts.
Thanks for the work, and thanks for posting about it.
:D

On Tue, Jun 9, 2020 at 9:19 PM Martijn Dekker <mar...@inlv.org> wrote:
> Short version:
>
> - New ksh 93u+m branch based on 93u+: https://github.com/modernish/ksh
> - Currently the only actively developed ksh93 fork
> - Loads of bugs fixed already, loads more fixes to follow
> - Regression test suite fixed to working state, preventing more bugs
> - Please test, and send bug reports and patches to github, or this list
> - If ksh-community ever get started, so much the better; they can take
> all the fixes. Meanwhile, I'm done with waiting. Let's get to work!
>
> Long version:

[snip]