@zeke it seems like you are conflating the submodule with the ksh program
itself. The submodule is not going anywhere and it not required to build CDE as
a whole but is a program that helps give CDE it's value. Requiring ksh as a
standalone program however, was originally required to run ksh's i
On Fri, 26 Mar 2021, Zeke Williams wrote:
Can we remove it and just have the already installed ksh do the work
instead?
In addition to what others said - ksh93 should be embeddable, so in theory
one day it should be possible to build dtksh which depends on already installed
ksh93 libraries.
T
> There was some progress made recently towards (1) - big thanks to Chase
for taking up ksh93 upgrade.
Very nice. You think we should maintain a CDE only version of ksh93 to
avoid having to deal with the freebsd example that was provided and to
maintain it better so it can work with CDE? Call it so
On 3/26/21 12:19 PM, Brent Busby wrote:
Zeke Williams writes:
I already have ksh installed under /bin in my distro. I had to
download from github ksh93 because the sourceforge git didn't come
with it and the patch as part of compilation failed to apply to be
able to compile it and resulted wit
On 3/26/21 12:23 PM, Zeke Williams wrote:
Strange how this specific submodule didn't work, but the rest did.
After deleting the dtksh directory and removing any references to
dtksh from three other files, I compiled CDE without issue. CDE knows
my shell is set to /bin/bash, no errors so far. So
Zeke Williams writes:
> I already have ksh installed under /bin in my distro. I had to
> download from github ksh93 because the sourceforge git didn't come
> with it and the patch as part of compilation failed to apply to be
> able to compile it and resulted with an error. Is there anything
> man
Strange how this specific submodule didn't work, but the rest did. After
deleting the dtksh directory and removing any references to dtksh from
three other files, I compiled CDE without issue. CDE knows my shell is set
to /bin/bash, no errors so far. So I'm still not sure what why need dtksh
if it'
You need to do a recursive checkout of the repository and we use ksh93
as a submodule...
so a
git clone --recursive ...
Or if you already cloned CDE w/o the above option, do a:
git submodule update --init
in the checked out sources
We build ksh93 as a part of dtksh...
And yes, I would love
I already have ksh installed under /bin in my distro. I had to download
from github ksh93 because the sourceforge git didn't come with it and the
patch as part of compilation failed to apply to be able to compile it and
resulted with an error. Is there anything mandatory that ksh93 does for
CDE? Ca
On 3/26/21 11:19 AM, Zeke Williams wrote:
Thanks for the reply. Another person emailed me directly stating
disagreement on moving things around because it would break packages.
I want to move things around because various repos like slackbuilds
will never accept CDE in its current state of inst
Thanks for the reply. Another person emailed me directly stating
disagreement on moving things around because it would break packages. I
want to move things around because various repos like slackbuilds will
never accept CDE in its current state of installing to /usr/dt rather than
how packages cur
On 3/26/21 7:08 AM, Zeke Williams wrote:
How should I start helping with porting to GNU autotools on the
autotools branch so imake can be removed and CDE installs in proper
directories rather than under /usr/dt. Should I just delete the
current imake files and make a fresh autoconf setup by scr
How should I start helping with porting to GNU autotools on the autotools
branch so imake can be removed and CDE installs in proper directories
rather than under /usr/dt. Should I just delete the current imake files and
make a fresh autoconf setup by scratch? Or what should I do?
__
13 matches
Mail list logo
