Hi all, I received an e-mail looking for the ksh-88 source code. A quick search for it on-line doesn't reveal it. Does anybody have a copy? Cheers, Warren Original e-mail: I recently built a PiDP11 and have been enjoying going back in time to 2.11BSD.. I was at UC Davis in the the early 1980's and we had a few PDP-11/70's running 2.8/2.9 BSD. Back then we reached out to David Korn and he sent us the source for KSH -- this would have been in 1985ish if I remember, and we compiled it for 2.9 & 4.1BSD, Xenix, and some other variants that used K&R C. It may have been what was later called ksh88. I wish I still had the files from then.. I was wondering if you might know if there's an older version like this or one that's been ported for 2.11BSD? Many thanks, Joe
[-- Attachment #1: Type: text/plain, Size: 2475 bytes --] If you were outside of AT&T, it was distributed via AT&T Summit's 'toolchest' thingy (and were as a single license to join it and but separate fees for each tool - if you wanted sub-license there was a secondary process which I forget the details -- I remember used it so we could make ksh, mk and ditroff standard on the MASSCOMP and later Stellar boxes). My memory is that the toolchest was created before SVR4, I want to say SVR2 (maybe as late as SVR3) timeframe. Its origin is it was a way to get some of the tools that came from different teams around the labs out without having to including them in a full release. Earlier, Brian's ditroff and Dennis's compiler were licensed (together) but using the original licensing/distribution scheme. As tools like ksh and mk came on the scene, Otis Wilson asked a number of us customers what to do. The toolchest was born from that discussion. It was cool in the after you ordered, you go a uucp address to 'pull' the bits for your site from the toolchest. No tapes were written - which is why I think find things now may be hard. That said, I've not found a repository of the toolchest stuff as I'm not so sure ATT really released all of it in the sense of the basic system itself. For instance, the support for the JERQ (including the games) were all in the toolchest and last spring a few of us were looking for the GBACA sources. I'm not sure if they were found. Basically, you need to find someone that had had a toolchest license for that specific tool and still has the bits somewhere. Clem On Tue, Dec 22, 2020 at 5:44 PM Warren Toomey <wkt@tuhs.org> wrote: > Hi all, I received an e-mail looking for the ksh-88 source code. A quick > search for it on-line doesn't reveal it. Does anybody have a copy? > > Cheers, Warren > > Original e-mail: > I recently built a PiDP11 and have been enjoying going back in time > to 2.11BSD.. I was at UC Davis in the the early 1980's and we had > a few PDP-11/70's running 2.8/2.9 BSD. Back then we reached out to > David Korn and he sent us the source for KSH -- this would have been > in 1985ish if I remember, and we compiled it for 2.9 & 4.1BSD, Xenix, > and some other variants that used K&R C. It may have been what was > later called ksh88. I wish I still had the files from then.. > > I was wondering if you might know if there's an older version like this > or one that's been ported for 2.11BSD? > Many thanks, > Joe > [-- Attachment #2: Type: text/html, Size: 3647 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2699 bytes --] 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@ccc.com> wrote: > If you were outside of AT&T, it was distributed via AT&T Summit's > 'toolchest' thingy (and were as a single license to join it and but > separate fees for each tool - if you wanted sub-license there was a > secondary process which I forget the details -- I remember used it so we > could make ksh, mk and ditroff standard on the MASSCOMP and later Stellar > boxes). > > My memory is that the toolchest was created before SVR4, I want to say > SVR2 (maybe as late as SVR3) timeframe. Its origin is it was a way to get > some of the tools that came from different teams around the labs out > without having to including them in a full release. Earlier, Brian's > ditroff and Dennis's compiler were licensed (together) but using the > original licensing/distribution scheme. As tools like ksh and mk came on > the scene, Otis Wilson asked a number of us customers what to do. The > toolchest was born from that discussion. It was cool in the after you > ordered, you go a uucp address to 'pull' the bits for your site from the > toolchest. No tapes were written - which is why I think find things now > may be hard. > > That said, I've not found a repository of the toolchest stuff as I'm not > so sure ATT really released all of it in the sense of the basic system > itself. For instance, the support for the JERQ (including the games) were > all in the toolchest and last spring a few of us were looking for the GBACA > sources. I'm not sure if they were found. > > Basically, you need to find someone that had had a toolchest license for > that specific tool and still has the bits somewhere. > > Clem > > On Tue, Dec 22, 2020 at 5:44 PM Warren Toomey <wkt@tuhs.org> wrote: > >> Hi all, I received an e-mail looking for the ksh-88 source code. A quick >> search for it on-line doesn't reveal it. Does anybody have a copy? >> >> Cheers, Warren >> >> Original e-mail: >> I recently built a PiDP11 and have been enjoying going back in time >> to 2.11BSD.. I was at UC Davis in the the early 1980's and we had >> a few PDP-11/70's running 2.8/2.9 BSD. Back then we reached out to >> David Korn and he sent us the source for KSH -- this would have been >> in 1985ish if I remember, and we compiled it for 2.9 & 4.1BSD, Xenix, >> and some other variants that used K&R C. It may have been what was >> later called ksh88. I wish I still had the files from then.. >> >> I was wondering if you might know if there's an older version like this >> or one that's been ported for 2.11BSD? >> Many thanks, >> Joe >> > [-- Attachment #2: Type: text/html, Size: 4180 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1137 bytes --] there's a plain ksh88 in here: bitsavers/bits/HP/HP_9000/HPUX_9/9.10_S300_Source_Product.cpio.gz The open sourced Solaris 8 tarball contains ksh88i I'm sure there's more ;) But what a shame that the 1985ish ksh got lost. On Tue, Dec 22, 2020 at 2:44 PM Warren Toomey <wkt@tuhs.org> wrote: > Hi all, I received an e-mail looking for the ksh-88 source code. A quick > search for it on-line doesn't reveal it. Does anybody have a copy? > > Cheers, Warren > > Original e-mail: > I recently built a PiDP11 and have been enjoying going back in time > to 2.11BSD.. I was at UC Davis in the the early 1980's and we had > a few PDP-11/70's running 2.8/2.9 BSD. Back then we reached out to > David Korn and he sent us the source for KSH -- this would have been > in 1985ish if I remember, and we compiled it for 2.9 & 4.1BSD, Xenix, > and some other variants that used K&R C. It may have been what was > later called ksh88. I wish I still had the files from then.. > > I was wondering if you might know if there's an older version like this > or one that's been ported for 2.11BSD? > Many thanks, > Joe > [-- Attachment #2: Type: text/html, Size: 1629 bytes --]
Warren Toomey <wkt@tuhs.org> wrote: > Hi all, I received an e-mail looking for the ksh-88 source code. A quick > search for it on-line doesn't reveal it. Does anybody have a copy? https://archive.org/details/ATTUNIXSystemVRelease4Version2 has source for several releases. click "show all" on the right under "download options", the file sysvr4.tar.bz2 has source for ksh88: from cmd/ksh/sh/msg.c: msg.c: MSG e_version = "\n@(#)Version M-11/16/88d\0\n"; I think this was for x86 PCs. I haven't tried to build it. The date on the files is Jan 25 1993. scot
I have ksh88f that I got from the Toolchest. My files are dated
April 6, 1991.
If anyone wants it, please let me know.
Arnold
Warren Toomey <wkt@tuhs.org> wrote:
> Hi all, I received an e-mail looking for the ksh-88 source code. A quick
> search for it on-line doesn't reveal it. Does anybody have a copy?
>
> Cheers, Warren
>
> Original e-mail:
> I recently built a PiDP11 and have been enjoying going back in time
> to 2.11BSD.. I was at UC Davis in the the early 1980's and we had
> a few PDP-11/70's running 2.8/2.9 BSD. Back then we reached out to
> David Korn and he sent us the source for KSH -- this would have been
> in 1985ish if I remember, and we compiled it for 2.9 & 4.1BSD, Xenix,
> and some other variants that used K&R C. It may have been what was
> later called ksh88. I wish I still had the files from then..
>
> I was wondering if you might know if there's an older version like this
> or one that's been ported for 2.11BSD?
> Many thanks,
> Joe
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@minnie.tuhs.org> wrote: > Warren Toomey <wkt@tuhs.org> wrote: > >> Hi all, I received an e-mail looking for the ksh-88 source code. A quick >> search for it on-line doesn't reveal it. Does anybody have a copy? > > > https://archive.org/details/ATTUNIXSystemVRelease4Version2 > has source for several releases. > > click "show all" on the right under "download options", > the file sysvr4.tar.bz2 has source for ksh88: > > from cmd/ksh/sh/msg.c: > msg.c: MSG e_version = "\n@(#)Version M-11/16/88d\0\n"; > > I think this was for x86 PCs. I haven't tried to build it. > The date on the files is Jan 25 1993. > > scot >
[-- Attachment #1: Type: text/plain, Size: 518 bytes --] On Wed, Dec 23, 2020 at 1:03 AM Thomas Paulsen <thomas.paulsen@firemail.de> wrote: > you mean: > http://www.bitsavers.org/bits/HP/HP_9000/HPUX_9/9.10_S300_Source_Product.cpio.gz yes copy paste is hard ;) > there's a plain ksh88 in here: > bitsavers/bits/HP/HP_9000/HPUX_9/9.10_S300_Source_Product.cpio.gz > > The open sourced Solaris 8 tarball contains ksh88i > > I'm sure there's more ;) > > But what a shame that the 1985ish ksh got lost. > > > > > *Gesendet mit Firemail.de - Freemail* [-- Attachment #2: Type: text/html, Size: 2119 bytes --]
On Tue, Dec 22, 2020 at 08:29:49PM -0500, John P. Linderman wrote:
> Does it have to be ksh88? [1]https://github.com/att/ast has ksh93
> source. -- jpl
I think the original poster couldn't get ksh93 to compile on 2.11BSD.
Thanks though, Warren
Hi, Here are some ksh versions... http://cyrillelefevre.free.fr/ksh/ ksh86a-toolchest.tar.bz2 314427 ksh88c-hpux-9.10.tar.bz2 169413 ksh88d-svr4.tar.bz2 132718 ksh88f-i18n-irix-6.5.5.tar.bz2 160563 ksh88f-irix-6.5.7.tar.bz2 215090 ksh88g-sco-unixware7.tar.bz2 195282 ksh88h-sco-unixware7.tar.bz2 147194 ksh88i-solaris-2.5.tar.bz2 149477 ksh88i-solaris-2.6.tar.bz2 159219 ksh88i-solaris-2.7.tar.bz2 163976 ksh88i-solaris-2.8.tar.bz2 164771 ksh93e-sco-unixware7.tar.bz2 542380 Le 23/12/2020 à 08:19, Efton Collins a écrit : > 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 at minnie.tuhs.org> wrote: >> Warren Toomey <wkt at tuhs.org> wrote: >> >>> Hi all, I received an e-mail looking for the ksh-88 source code. A quick >>> search for it on-line doesn't reveal it. Does anybody have a copy? >> https://archive.org/details/ATTUNIXSystemVRelease4Version2 >> has source for several releases. >> >> click "show all" on the right under "download options", >> the file sysvr4.tar.bz2 has source for ksh88: >> >> from cmd/ksh/sh/msg.c: >> msg.c: MSG e_version = "\n@(#)Version M-11/16/88d\0\n"; >> >> I think this was for x86 PCs. I haven't tried to build it. >> The date on the files is Jan 25 1993. >> >> scot >> > -- mailto:Cyrille.Lefevre-lists@laposte.net
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: > Hi, Here are some ksh versions... > > http://cyrillelefevre.free.fr/ksh/ > > ksh86a-toolchest.tar.bz2 314427 > ksh88c-hpux-9.10.tar.bz2 169413 > ksh88d-svr4.tar.bz2 132718 > ksh88f-i18n-irix-6.5.5.tar.bz2 160563 > ksh88f-irix-6.5.7.tar.bz2 215090 > ksh88g-sco-unixware7.tar.bz2 195282 > ksh88h-sco-unixware7.tar.bz2 147194 > ksh88i-solaris-2.5.tar.bz2 149477 > ksh88i-solaris-2.6.tar.bz2 159219 > ksh88i-solaris-2.7.tar.bz2 163976 > ksh88i-solaris-2.8.tar.bz2 164771 > ksh93e-sco-unixware7.tar.bz2 542380 > > Le 23/12/2020 ? 08:19, Efton Collins a ?crit?: > >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 at minnie.tuhs.org> wrote: > >>Warren Toomey <wkt at tuhs.org> wrote: > >> > >>>Hi all, I received an e-mail looking for the ksh-88 source code. A quick > >>>search for it on-line doesn't reveal it. Does anybody have a copy? > >>https://archive.org/details/ATTUNIXSystemVRelease4Version2 > >>has source for several releases. > >> > >>click "show all" on the right under "download options", > >>the file sysvr4.tar.bz2 has source for ksh88: > >> > >>from cmd/ksh/sh/msg.c: > >>msg.c: MSG e_version = "\n@(#)Version M-11/16/88d\0\n"; > >> > >>I think this was for x86 PCs. I haven't tried to build it. > >>The date on the files is Jan 25 1993. > >> > >>scot > >> > > > -- > mailto:Cyrille.Lefevre-lists@laposte.net > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
[-- Attachment #1: Type: text/plain, Size: 2430 bytes --] On Tue, Dec 21, 2021, 10:22 AM Larry McVoy <lm@mcvoy.com> 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? > Bash is GPLd. Ksh isn't. :) Warner On Tue, Dec 21, 2021 at 02:55:55PM +0100, Cyrille Lefevre via TUHS wrote: > > Hi, Here are some ksh versions... > > > > http://cyrillelefevre.free.fr/ksh/ > > > > ksh86a-toolchest.tar.bz2 314427 > > ksh88c-hpux-9.10.tar.bz2 169413 > > ksh88d-svr4.tar.bz2 132718 > > ksh88f-i18n-irix-6.5.5.tar.bz2 160563 > > ksh88f-irix-6.5.7.tar.bz2 215090 > > ksh88g-sco-unixware7.tar.bz2 195282 > > ksh88h-sco-unixware7.tar.bz2 147194 > > ksh88i-solaris-2.5.tar.bz2 149477 > > ksh88i-solaris-2.6.tar.bz2 159219 > > ksh88i-solaris-2.7.tar.bz2 163976 > > ksh88i-solaris-2.8.tar.bz2 164771 > > ksh93e-sco-unixware7.tar.bz2 542380 > > > > Le 23/12/2020 ? 08:19, Efton Collins a ?crit?: > > >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 at minnie.tuhs.org> wrote: > > >>Warren Toomey <wkt at tuhs.org> wrote: > > >> > > >>>Hi all, I received an e-mail looking for the ksh-88 source code. A > quick > > >>>search for it on-line doesn't reveal it. Does anybody have a copy? > > >>https://archive.org/details/ATTUNIXSystemVRelease4Version2 > > >>has source for several releases. > > >> > > >>click "show all" on the right under "download options", > > >>the file sysvr4.tar.bz2 has source for ksh88: > > >> > > >>from cmd/ksh/sh/msg.c: > > >>msg.c: MSG e_version = "\n@(#)Version M-11/16/88d\0\n"; > > >> > > >>I think this was for x86 PCs. I haven't tried to build it. > > >>The date on the files is Jan 25 1993. > > >> > > >>scot > > >> > > > > > -- > > mailto:Cyrille.Lefevre-lists@laposte.net > > > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > [-- Attachment #2: Type: text/html, Size: 4555 bytes --]
[-- Attachment #1: Type: text/plain, Size: 970 bytes --] On Tue, Dec 21, 2021 at 11:22 AM Larry McVoy <lm@mcvoy.com> 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? > Ubuntu chose it as the default shell for sysvinit startup scripts in 2006 (from which it spread to BSD) precisely because it was much faster than bash. It's also smaller: bash is a memory hog. When I wrote a whole (batch) application in about 120 Perl and shell scripts in 1999-2001, I often needed multiple shell scripts running simultaneously, sometimes for concurrency and sometimes just from scripts calling other scripts. So I made sure everything ran under Solaris sh, which was a modified Bourne shell at that time and so was much lighter than bash, which I used for development. Nowadays I'd use dash in the same circumstances. [-- Attachment #2: Type: text/html, Size: 1772 bytes --]
On 12/21/21 11:42 AM, John Cowan wrote: > > > On Tue, Dec 21, 2021 at 11:22 AM Larry McVoy <lm@mcvoy.com > <mailto:lm@mcvoy.com>> 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? > > > Ubuntu chose it as the default shell for sysvinit startup scripts in 2006 > (from which it spread to BSD) precisely because it was much faster than > bash. It's also smaller: bash is a memory hog. 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@case.edu http://tiswww.cwru.edu/~chet/
[-- Attachment #1: Type: text/plain, Size: 1074 bytes --] Yes, sorry: I edited the posting heavily and I missed that some pronouns now had the wrong antecedent. On Tue, Dec 21, 2021 at 11:47 AM Chet Ramey <chet.ramey@case.edu> wrote: > On 12/21/21 11:42 AM, John Cowan wrote: > > > > > > On Tue, Dec 21, 2021 at 11:22 AM Larry McVoy <lm@mcvoy.com > > <mailto:lm@mcvoy.com>> 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? > > > > > > Ubuntu chose it as the default shell for sysvinit startup scripts in 2006 > > (from which it spread to BSD) precisely because it was much faster than > > bash. It's also smaller: bash is a memory hog. > > 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@case.edu http://tiswww.cwru.edu/~chet/ > [-- Attachment #2: Type: text/html, Size: 1870 bytes --]
[-- Attachment #1: Type: text/plain, Size: 386 bytes --] On 12/21/21 9:27 AM, Warner Losh wrote: > Bash is GPLd. Ksh isn't. :) 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 [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4017 bytes --]
I have moved to mksh http://www.mirbsd.org/mksh.htm mksh(1) R59c This is the website of the MirBSD™ Korn Shell, an actively developed free implementation of the Korn Shell programming language and a successor to the Public Domain Korn Shell (pdksh). Regards, -- Boyd Gerber <gerberb@zenez.com> 801 849-0213 ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
[-- Attachment #1: Type: text/plain, Size: 127 bytes --] > I have moved to mksh > http://www.mirbsd.org/mksh.htm > I use http://nadvsh.sourceforge.net/ when I don't use the rc port. [-- Attachment #2: Type: text/html, Size: 479 bytes --]
First of all, there is a big difference between ksh88 and ksh94. The latter is closer to bash, but it's ancient software. bash is clearly more advanced. ksh is retro computing. --------------------------------------------------------------------------- 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?
>> Bash is GPLd. Ksh isn't. :) > What is the effective difference between GPLed software; Bash, vs > non-GPLed software; Ksh? > > Why, as a lay user, would I care? As an end user, you would not care. 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. > I get the historical interest, but in today's world, is there any > advantage to ksh over bash? 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: https://github.com/att/ast/issues/1466 So I guess, for some people at least, there are indeed reasons to prefer it, including (according to users in those github issues) performance. 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: http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/ -Jason * 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. for S in ksh93 pdksh bash zsh ; do echo "===> ${S} <===" ; eval "${S} -c 'printf \"%(%F)T\n\" \"last thursday\"'" ; echo "" ; done ===> ksh93 <=== 2021-12-16 ===> pdksh <=== printf: illegal format character ( ===> bash <=== bash: line 1: printf: last thursday: invalid number 1969-12-31 ===> zsh <=== zsh:printf:1: %(: invalid directive
"Thomas Paulsen" <thomas.paulsen@firemail.de> wrote: > ksh is retro computing. Ksh is still being worked on,just not by David Korn. See https://github.com/ksh93/ksh Arnold
Le 21/12/2021 à 17:42, John Cowan a écrit : > On Tue, Dec 21, 2021 at 11:22 AM Larry McVoy <lm@mcvoy.com > <mailto:lm@mcvoy.com>> 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? > > Ubuntu chose it as the default shell for sysvinit startup scripts in > 2006 (from which it spread to BSD) precisely because it was much faster > than bash. It's also smaller: bash is a memory hog. 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
Le 21/12/2021 à 23:15, Thomas Paulsen a écrit : > First of all, there is a big difference between ksh88 and ksh94. The latter is closer to bash, but it's ancient software. bash is clearly more advanced. ksh is retro computing. s/94/93/ ksh93 was more advanced than bash for years... regarding https://tldp.org/LDP/abs/html/bashver4.html, ksh93 is just missing mapfile and some features like ${x^}, ${x,}, '\uXXX', others things were implemented for years... in fact, bash4 implements man ksh93 :-) /me -- mailto:Cyrille.Lefevre-lists@laposte.net
On 12/22/21 9:35 AM, Cyrille Lefevre via TUHS wrote: > in fact, bash4 implements man ksh93 :-) 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@case.edu http://tiswww.cwru.edu/~chet/
Thomas Paulsen: bash is clearly more advanced. ksh is retro computing. ==== Shell wars are, in the end, no more interesting than editor wars. I use bash on Linux systems because it's the least-poorly supported of the Bourne-family shells, besides which bash is there by default. Ksh isn't. I use ksh on OpenBSD systems because it's the least-poorly supported of the Bourne-family shells, besides which kh is there by default. Bash isn't. I don't actually care for most of the extra crap in either of those shells. I don't want my shell to do line editing or auto-completion, and I find the csh-derived history mechanisms more annoying than useful so I turn them off too. To my mind, the Research 10/e sh had it about right, including the simple way functions were exported and the whatis built-in that told you whether something was a variable or a shell function or an external executable, and printed the first two in forms easily edited on the screen and re-used. Terminal programs that don't let you easily edit input or output from the screen and re-send it, and programs that abet them by spouting gratuitous ANSI control sequences: now THAT's what I call retro-computing. Probably further discussion of any of this belongs in COFF. Norman Wilson Toronto ON
Le 21/12/2021 à 14:55, Cyrille Lefevre a écrit : > Hi, Here are some ksh versions... > > http://cyrillelefevre.free.fr/ksh/ > > ksh86a-toolchest.tar.bz2 314427 > ksh88c-hpux-9.10.tar.bz2 169413 > ksh88d-svr4.tar.bz2 132718 > ksh88f-irix-6.5.5f.tar.bz2 160563 > ksh88f-irix-6.5.5m.tar.bz2 160563 > ksh88f-irix-6.5.7m.tar.bz2 215090 > ksh88g-sco-unixware7.tar.bz2 195282 > ksh88h-sco-unixware7.tar.bz2 147194 > ksh88i-solaris-2.5.tar.bz2 149477 > ksh88i-solaris-2.6.tar.bz2 159219 > ksh88i-solaris-2.7.tar.bz2 163976 > ksh88i-solaris-2.8.tar.bz2 164771 > ksh93e-sco-unixware7.tar.bz2 542380 added : dclemans_ksh-0.3.tar.Z 162394 ksh93u-apple.tar.bz2 4545249 and some bourne shell versions... http://cyrillelefevre.free.fr/sh/ sh5-ultrix-4.3-bsd.tar.bz2 41341 sh-aix-4.1.3.tar.bz2 61194 sh-bsd-4.4-lite2+1hour.tar.bz2 50660 sh-dec-osf1-1.0.tar.bz2 58670 sh-dec-osf1-2.0.tar.bz2 58691 sh-hpux-9.10.tar.bz2 52270 sh-irix-3.7.tar.bz2 61028 sh-irix-6.5.5f.tar.bz2 60260 sh-irix-6.5.5m.tar.bz2 60295 sh-irix-6.5.7m.tar.bz2 60220 sh-opensolaris-b147.tar.bz2 53857 sh-sco-unixware7.tar.bz2 55594 sh-sco-unixware7-osr.tar.bz2 50062 sh-solaris-2.6.tar.bz2 51006 sh-solaris-2.8.tar.bz2 53597 sh-sunos-4.1.4.tar.bz2 39230 sh-svr4.tar.bz2 47766 sh-ultrix-4.3-bsd.tar.bz2 28799 sh-ultrix-osf1-1.0.tar.bz2 56072 sh-usl-4.2.tar.bz2 54212 Regards, /me -- mailto:Cyrille.Lefevre-lists@laposte.net
[-- Attachment #1: Type: text/plain, Size: 786 bytes --] On Wed, Dec 22, 2021 at 9:41 AM Norman Wilson <norman@oclsc.org> wrote: > Shell wars are, in the end, no more interesting than editor wars. > +1. One person's "fully-featured software" is another person's "ten pounds of crap in a five-pound bag". > Bourne-family shells All of which, considered as programming languages, are badly designed, in the usual way of sofa beds and other allegedly dual-purpose pieces of furniture. Scsh is a shell that's a high-quality programming language (namely Scheme), and I have just discovered xonsh, which is like scsh for Python. I have some ideas for a shell based on rc and Lua. > To my mind, the Research 10/e sh had it about right, > Unfortunately, approximately nobody except you has access to its man page. Can you post or email it? [-- Attachment #2: Type: text/html, Size: 2157 bytes --]
John Cowan: Unfortunately, approximately nobody except you has access to [the 10/e sh] man page. Can you post or email it? === I am happy to remind you that you're a few years out of date: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/man/man1/sh.1 Norman Wilson Toronto ON
> On 23 Dec 2021, at 17:23, John Cowan <cowan@ccil.org> wrote: > Unfortunately, approximately nobody except you has access to its man > page. Can you post or email it? If you’re having trouble using the source, also available at <http://man.cat-v.org/unix_10th/1/sh> Silas
[-- 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 --]
[-- Attachment #1: Type: text/plain, Size: 363 bytes --] > 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. > Your limited understanding is limited and/or incorrect, particularly for operating system vendors. This list is not the place to discuss the GPL, but please stop. [-- Attachment #2: Type: text/html, Size: 681 bytes --]
[-- Attachment #1: Type: text/plain, Size: 4314 bytes --] > 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. From what I read, you are correct -it doesn't. At least that's what the FSF 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@minnie.tuhs.org> wrote: > 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: Type: text/html, Size: 5471 bytes --]