From: Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
To: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] ksh88 source code?
Date: Fri, 24 Dec 2021 15:51:29 -0700 [thread overview]
Message-ID: <c7cf70cf-17ea-c4db-e4e2-95169665e8e1@spamtrap.tnetconsulting.net> (raw)
In-Reply-To: <alpine.LRH.2.23.453.2112212026560.4901@waffle.shalott.net>
[-- Attachment #1: Type: text/plain, Size: 3171 bytes --]
On 12/21/21 11:23 PM, jason-tuhs@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
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4017 bytes --]
next prev parent reply other threads:[~2021-12-24 22:51 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-22 22:43 Warren Toomey
2020-12-22 23:01 ` Clem Cole
2020-12-23 1:29 ` John P. Linderman
2020-12-23 22:57 ` Warren Toomey
2020-12-23 3:30 ` Rico Pajarola
2020-12-23 9:03 ` Thomas Paulsen
2020-12-23 9:14 ` Rico Pajarola
2020-12-23 5:46 ` Scot Jenkins via TUHS
2020-12-23 7:19 ` Efton Collins
2021-12-21 13:55 ` Cyrille Lefevre via TUHS
2021-12-21 16:21 ` Larry McVoy
2021-12-21 16:27 ` Warner Losh
2021-12-21 17:15 ` Grant Taylor via TUHS
2021-12-21 17:31 ` Boyd Lynn Gerber
2021-12-21 19:09 ` Richard Salz
2021-12-22 6:23 ` jason-tuhs
2021-12-24 22:51 ` Grant Taylor via TUHS [this message]
2021-12-24 23:15 ` Richard Salz
2021-12-24 23:34 ` Michael Huff
2021-12-21 16:42 ` John Cowan
2021-12-21 16:47 ` Chet Ramey
2021-12-21 17:09 ` John Cowan
2021-12-22 11:11 ` Cyrille Lefevre via TUHS
2021-12-21 22:15 ` Thomas Paulsen
2021-12-22 7:44 ` arnold
2021-12-22 14:35 ` Cyrille Lefevre via TUHS
2021-12-22 14:36 ` Chet Ramey
2021-12-23 13:39 ` [TUHS] Bourne shell source code (was Re: ksh88 source code?) Cyrille Lefevre via TUHS
2020-12-23 6:56 ` [TUHS] ksh88 source code? arnold
2021-12-22 14:40 Norman Wilson
2021-12-23 17:23 ` John Cowan
2021-12-23 20:08 ` silas poulson
2021-12-23 19:10 Norman Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c7cf70cf-17ea-c4db-e4e2-95169665e8e1@spamtrap.tnetconsulting.net \
--to=tuhs@minnie.tuhs.org \
--cc=gtaylor@tnetconsulting.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).