[TUHS] ksh88 source code?

[Grant Taylor]

On 12/21/21 11:23 PM, jason-tuhs at shalott.net wrote:
> As an end user, you would not care.

That tends to explain why I've not personally cared.

> As a vendor or distributor, you would care.  Anyone doing an OS or other 
> software distribution (think the BSDs, of course; but also think Apple 
> or Microsoft) needs to care.  Anyone selling a hardware device with 
> embedded software (think switches/routers; think IOT devices; think 
> consumer devices like DVRs; etc) needs to care.  GPL (or similar 
> "virally" licensed) software carries legal implications for anyone 
> selling or distributing products that contain such software; and this 
> can be a motivation to use software with less-restrictive license terms.

Okay.

My limited understanding is that the GPLed parts of the product must be 
made available.  But I'm not aware that using GPLed parts means that 
/everything/ /else/ must also be made available.

Also, I believe /made/ /available/ means that it must be accessible or 
provided when asked.  Thus it does not mean that the GPLed code needs to 
be shipped with the product.

> I'm aware of a few random features that are in ksh93 but not other 
> shells (random, trivial, example that I saw just today*: "printf 
> %(FORMAT)T"). That said, my first impulse would have been to say no, 
> there aren't any meaningful (technical) advantages to ksh over bash -- 
> except that it seems there's still some amount of active development 
> going on in ksh:

The biggest motivation I had in a previous job was to make sure that my 
account's shell was set to a shell that lived on the root file system.

I could easily have that shell test to see if my preferred shell was 
available and start or exec it.  That way I could still log in if the 
file system with my preferred shell was not mounted.  As if I needed to 
address the underlying issue that was preventing the desired shell from 
being accessible.  E.g. /usr/bin/bash wasn't available b/c /usr wasn't 
automatically mounted at boot.

> So I guess, for some people at least, there are indeed reasons to prefer 
> it, including (according to users in those github issues) performance.

At my last job I helped administer some systems that didn't have any 
shells other than was was in the base OS installation.  (We won't talk 
about why.)

> On the licensing front, the GPL is an issue for bash; but zsh is 
> available as a more modern, fully-featured shell that avoids any GPL 
> issues.  This is why Apple switched the default shell in OSX from bash 
> to zsh: they wanted to avoid the GPLv3.  Previously, they had been 
> shipping the last GPLv2 version of bash, which was from 2006.  According 
> to this blog, they've been avoiding any GPLv3 code and actively working 
> to remove even GPLv2 code in OSX for quite a while:

That makes sense.

> * bash seems to recognize %(FORMAT)T, but only takes epoch seconds as an 
> argument.  ksh93 takes anything vaguely date-like.  zsh and pdksh don't 
> recognize it at all.

Interesting.

Thank you for the informative reply Jason.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211224/db6b1aad/attachment.bin>