Does it have to be ksh88? https://github.com/att/ast has ksh93 source. -- jpl On Tue, Dec 22, 2020 at 6:03 PM Clem Cole <clemc(a)ccc.com> wrote:

On Wed, Dec 23, 2020 at 1:03 AM Thomas Paulsen <thomas.paulsen(a)firemail.de> wrote: yes copy paste is hard ;)

here is a link to a ksh version that seems to predate ksh88, msg.c says "Version 06/03/86a": https://github.com/weiss/original-bsd/tree/master/local/toolchest/ksh I found the link at the bottom of this interesting page: https://www.in-ulm.de/~mascheck/various/shells/ksh_versions.html and this link contains a surprising amount of information on many shell versions released over the years - https://www.in-ulm.de/~mascheck/various/shells On 12/22/20, Scot Jenkins via TUHS <tuhs(a)minnie.tuhs.org> wrote:

I get the historical interest, but in today's world, is there any advantage to ksh over bash? I get that lots of scripts are run with /bin/sh and it is nice when that is fast, but aren't the cpus fast enough these days that it sort of doesn't matter? On Tue, Dec 21, 2021 at 02:55:55PM +0100, Cyrille Lefevre via TUHS wrote: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

On 12/21/21 9:27 AM, Warner Losh wrote: At the risk of showing my ignorance.... What is the effective difference between GPLed software; Bash, vs non-GPLed software; Ksh? Why, as a lay user, would I care? I mostly care that I am allowed to use it by some license so that I'm not pirating software. -- Grant. . . . unix || die

I use http://nadvsh.sourceforge.net/ when I don't use the rc port.

On 12/21/21 11:23 PM, jason-tuhs(a)shalott.net wrote: That tends to explain why I've not personally cared. 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. 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. 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.) That makes sense. Interesting. Thank you for the informative reply Jason. -- Grant. . . . unix || die

made available. But I'm not aware that using GPLed parts means that /everything/ /else/ must also be made available. appears to say themselves: https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndNonfreeOnSameMachine There's been some attempts over the years (eg Microsoft's "get the facts" campaign) to muddy the waters on that issue and paint the GNU license as acting "cancerous"; but I'm not aware of any legal precedents backing that up. Another part of the same page that you might find interesting (regarding distributing sources): https://www.gnu.org/licenses/gpl-faq.en.html#DistributeWithSourceOnInternet Of course if someone is acting as an owner or employee of a company they'll want to consult their legal staff in addition to reading what the GNU have to say as well. /disclaimer; I do not work in IT, but have used Unix and Linux for 25 years now -make of that what you will On Fri, Dec 24, 2021 at 1:52 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: > On 12/21/21 11:23 PM, jason-tuhs(a)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. > > 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 > >

On 12/21/21 11:42 AM, John Cowan wrote: You're talking about dash, I think. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

Le 21/12/2021 à 17:42, John Cowan a écrit : it seems bash4 have solved the performance penalty : https://github.com/ksh-community/shbench/blob/master/bench/gsub.ksh /me -- mailto:Cyrille.Lefevre-lists@laposte.net

"Thomas Paulsen" <thomas.paulsen(a)firemail.de> wrote: Ksh is still being worked on,just not by David Korn. See https://github.com/ksh93/ksh Arnold

On 12/22/21 9:35 AM, Cyrille Lefevre via TUHS wrote: Well, that's not true. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/