RFD: bash compatibility mode

[Martijn Dekker]

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?

Discussion also at: https://github.com/ksh93/ksh/issues/9

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

[Andras Farkas]

On Sat, Jun 13, 2020 at 8:52 PM Martijn Dekker <mar...@inlv.org> 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?

I am just a ksh user (both interactive and scripting) and what I think is this:
If I wanted bash compatibility, I'd use bash itself. I use ksh since
I want ksh.
Removing a bash compatibility option is not merely neutral, but a
positive given where ksh, bash, and ksh's bash compatibility are
today.
No objections!

> Discussion also at: https://github.com/ksh93/ksh/issues/9

Everything I see here also points toward my own opinion on this. :B

[Danny Weldon]

On Sun, 14 Jun 2020 at 14:56, Andras Farkas <deepblu...@gmail.com> wrote:
>
> On Sat, Jun 13, 2020 at 8:52 PM Martijn Dekker <mar...@inlv.org> 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.

True. So why, then, could this ever have been included in the source? :)

> >
> > Would anyone object to getting rid?

Yes, I would.

> I am just a ksh user (both interactive and scripting) and what I think is this:
> If I wanted bash compatibility, I'd use bash itself. I use ksh since
> I want ksh.
> Removing a bash compatibility option is not merely neutral, but a
> positive given where ksh, bash, and ksh's bash compatibility are
> today.
> No objections!
> > Discussion also at: https://github.com/ksh93/ksh/issues/9
> Everything I see here also points toward my own opinion on this. :B

> If I wanted bash compatibility, I'd use bash itself.

That's fine, just use bash then in that case.

So let's say you have a production bash script that runs a bit slow,
using this bash compatibility option would theoretically allow you to
simply change the hash bang and get possibly a 500% speed up,
depending on what you were doing. And for this, no, you probably
don't need 100% feature-for-feature and bug-for-bug compatibility,
depending. It needs just enough compatibility for someone to get
their script to run, and if not, they can add the functionality
themselves or request it.

I believe there is no harm in leaving the code in as it is valuable at
least for the sake of learning.

And please don't make the mistake of the last project and throw out
everything that they didn't care about or understand.


--
Regards

Danny

[Martijn Dekker]

Op 14-06-20 om 12:09 schreef Danny Weldon:

> On Sun, 14 Jun 2020 at 14:56, Andras Farkas <deepblu...@gmail.com> wrote:
>>
>> On Sat, Jun 13, 2020 at 8:52 PM Martijn Dekker <mar...@inlv.org> 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.
>
> True. So why, then, could this ever have been included in the source? :)

bash used to be extremely slow. There could have been a serious
performance advantage, as you say. But bash 5 is quite a lot faster.

Korn and his colleagues were also people who just liked to try out
things. They worked in a research lab, after all. The code is full of
evidence of that.

> Yes, I would.

Thanks, noted.

[...]

> I believe there is no harm in leaving the code in as it is valuable at
> least for the sake of learning.

I don't think that argument holds water. The code is staying right there
in the repo's commit history, so anyone who wants to learn can easily
check out an earlier commit. It's also permanently archived at the
att/ast repo.

Meanwhile, yes, it is in the way, actually. The more #ifdefs cluttering
up the code, the harder it is to read, and the harder it is to fix.

> And please don't make the mistake of the last project and throw out
> everything that they didn't care about or understand.

Agreed. I have no intention of doing so.

But I don't think this falls under that category, at all. Because the
fact is, it cannot be used now. It doesn't even compile.

Korn might have been fine with shipping broken code, but I am not. I
think it's an embarrassment.

So, given that you feel strongly about keeping it, I think it falls to
you, and to anyone else who might be interested, to fix it -- or to
recruit the people who can fix it.

Because of your objection, I am leaving it in for now. But by the time
we're getting close to ready for a release (which will surely take a
while), either this has been fixed, or it gets removed. And if it gets
fixed after that, it can always be restored.

- Martijn