Siteshwar Vashisht wrote:
> > Last time I got him (I did no try to contact him later) he answered my
> > questions, but it may be that he will not actively help in the development.
>
> This discussion is diverting from original topic of pipefail standardization,
> but still I would try to clarify few things.
If we have a nearly final conclusion on how to deal with this, I could try to
contact him again.
> > This is the wrong method. The right method is to read the source again and
> > again until you understand it. This is what I did with the Bourne Shell and
> > this helps me to understand the ksh93 source. Note that in his life before
> > AT, he designed supersonic wings. So he is used to think different than
> > most
> > people.
>
> You have a fair point about reading sources.
Well, I know that my "bsh" from 1984 is easier to maintain than the Bourne
Shell because it is written in a simpler way. Now that I fully understand the
Bourne Shell, I prefer it ove my old shell.
> The biggest change we have made is, we made it easier to build. This has only
> helped our cause because now people are able to build ksh easily on platforms
> like FreeBSD, OpenBSD etc. It was not impossible to build it earlier on these
> platforms but the build process was so arcane that half of the potential
> contributors will give up trying to build it.
In 2006, when I first personally met David, I had a discussion about his
buildsystem that really is from Glenn Fowler (who BTW answers mail typically
with less than a week delay). It turns out, that the ast build system is
implemented in a completely different way than the Schily Makefilesystem, but
it has the same basic concept: It uses leaf makefiles that look very similar
because these makefiles just conatain a list of source files and compiler flags.
The knowledge on how to basically build commands is in the makefile system.
The main difference is that ast is based on knowledge that is coded in the
"nmake" program while the schily makefilesystem codes the same knowledge in the
"make" language as part of object specific make rules.
Both methods grant portability to more platforms than the GNU method.
I believe that if we like to cntinue this discussion, it should be done in
private as the build system is not related to POSIX.
> > If ksh93 is not maintained, it will loose importance, but this should not
> > result in quick changes. A good concept would e.g. be to introduce mandatory
> > code reviews for changes before they could make it into the pulic git.
> >
> > I would like to see a restart from the v- state and have code reviews for
>
> You are right about the fact we have less experience with ksh source code and
> we have introduced bugs while trying to improve it's code quality. But the
> right method is not to start from scratch with `ksh93v-`. Right method is to
> improve our test coverage and find defects before they get shipped into a
Did you run the hand crafted unit tests that are included in the ksh93 source?
What I believe is missing for ksh93 is stochastic testing with unexpected
random
input. I friend helps me to do this with the Bourne Shell and we discovered and
fixed hundreds of bugs this way, some of them have been in the source since the
beginning in 1976.
> release. And before you say it, I am not promising the next release will 100%
> bug free or will not have regression. All legacy softwares that I know,
> specially
> shells, have done a historically bad job at testing. I see this as an
> opportunity to change that. It's amazing to hear that dgk has a background in
> aviation, but aviation industry is known for it's insane focus on quality and
> testing. I see that focus missing in ksh. Why should a shell crash when
> compiler
> optimization level is changed ?
During my nearly 40 years of programming experiences, I did observe more than a
dozen cases where the reason for a problem was in the optimizer of the compiler.
If I did see the piece of code that causes the problem, I could give a comment.
> I agree that we need more code reviews from someone like you who has more
> experience with ksh source code. I could not find you on GitHub, but can
> request
> for reviews over e-mail. If you have seen any questionable changes in current
> upstream, please open (reopen) related issue or send us an e-mail. If your
> counterargument is that all changes are questionable then I have got nothing
> to say to you.
I did not yet create an account on github, should I create one?
> We would like to keep ksh as close as possible to POSIX too. We surely agree
> on
> this.
Fine
> We are in no hurry to make a release, even if it takes next 4 years of our
> life.
> And it may not be even perfect. Whether it will be worth using or not, should
> be
> left to be judged by ksh community. That said, it's more appropriate to have
> these discussions on ast-developers mailing list or GitHub.
This seems to be a good base. Being in a hurry
