Re: [cdesktopenv-devel] [PATCH] Fix build under LLVM15

[Chase via cdesktopenv-devel]

You must not directly edit any file under ksh93, instead, pull the newest point 
release from the source and merge it. Its a git subtree so I'm not quite sure 
how that works.



Thank you for your time,
-Chase

Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, February 15th, 2023 at 12:19 PM, Cy Schubert 
 wrote:


> Fix many -Wint-conversion errors such as the example below, including
> an aso atomics error.
> 
> connect.c:87:12: error: incompatible pointer to integer conversion
> initializing 'LONG' (aka 'int') with an expression of type 'void '
> [-Wint-conversion]
> DB_ADDR mdba = NULL; / db address of current member record */
> ^ 
> ---
> cde/lib/DtHelp/AccessCCDF.c | 2 ++
> cde/lib/DtSearch/raima/connect.c | 4 +--
> cde/programs/dtappbuilder/src/ab/pal_button.c | 30 
> cde/programs/dtappbuilder/src/ab/pal_choice.c | 22 ++--
> .../dtappbuilder/src/ab/pal_combobox.c | 16 -
> cde/programs/dtappbuilder/src/ab/pal_cpanel.c | 14 
> .../dtappbuilder/src/ab/pal_custdlg.c | 14 
> cde/programs/dtappbuilder/src/ab/pal_drawp.c | 16 -
> .../dtappbuilder/src/ab/pal_fchooser.c | 6 ++--
> cde/programs/dtappbuilder/src/ab/pal_group.c | 36 +--
> cde/programs/dtappbuilder/src/ab/pal_label.c | 14 
> cde/programs/dtappbuilder/src/ab/pal_list.c | 24 ++---
> .../dtappbuilder/src/ab/pal_mainwin.c | 8 ++---
> cde/programs/dtappbuilder/src/ab/pal_menu.c | 28 +++
> .../dtappbuilder/src/ab/pal_menubar.c | 4 +--
> cde/programs/dtappbuilder/src/ab/pal_scale.c | 24 ++---
> cde/programs/dtappbuilder/src/ab/pal_sep.c | 22 ++--
> .../dtappbuilder/src/ab/pal_spinbox.c | 22 ++--
> cde/programs/dtappbuilder/src/ab/pal_termp.c | 18 +-
> cde/programs/dtappbuilder/src/ab/pal_textf.c | 16 -
> cde/programs/dtappbuilder/src/ab/pal_textp.c | 22 ++--
> .../dtksh/ksh93/src/lib/libast/aso/aso.c | 2 +-
> 22 files changed, 183 insertions(+), 181 deletions(-)
> 
> 
> 
> Cheers,
> Cy Schubert cy.schub...@cschubert.com
> 
> FreeBSD UNIX: c...@freebsd.org Web: https://FreeBSD.org
> 
> NTP: c...@nwtime.org Web: https://nwtime.org
> 
> 
> e^(i*pi)+1=0
> ___
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel


___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] generify source code

[Chase via cdesktopenv-devel]

3 Patches:

- remove manual lcrypt flags, since we detect them in autotools, also removed 
manually linking libc in some solaris defines, as doing so violates posix and 
even then autotools can handle this directly without us.
-  Clean up some defines in DtTerm, these were mostly duplicates of OS defines 
specified by us
- The big one, generifying the source code. I made any defines that specified 
Linux, all three BSDs and Solaris to be default code, this allows for some 
currently unsupported OSes like minix and gnu hurd to actually start the 
building process without running into errors about the OS not being recognized 
(I'm pretty sure they'll error out elsewhere but it won't be because we didn't 
have a default configuration).

Thank you for your time,
-Chase

Sent with [Proton Mail](https://proton.me/) secure email.From f3d5df0cf41e3b50d0b03c518683dbb0ce2b5884 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Wed, 3 Aug 2022 18:07:57 -0500
Subject: [PATCH 1/3] Remove detected -lcrypt flag

---
 cde/lib/DtHelp/Makefile.am|  2 +-
 cde/lib/DtSearch/Makefile.am  |  6 --
 cde/lib/DtWidget/Makefile.am  |  2 +-
 cde/lib/tt/lib/Makefile.am|  2 +-
 cde/programs/dtaction/Makefile.am | 12 
 5 files changed, 3 insertions(+), 21 deletions(-)

diff --git a/cde/lib/DtHelp/Makefile.am b/cde/lib/DtHelp/Makefile.am
index a3b59681b..04730f098 100644
--- a/cde/lib/DtHelp/Makefile.am
+++ b/cde/lib/DtHelp/Makefile.am
@@ -16,7 +16,7 @@ libDtHelp_la_CFLAGS = -I./il -I./jpeg -I../DtSvc/DtUtil2 -DDTLIB \
 libDtHelp_la_LIBADD = $(JPEGLIB) il/libil.la $(LTLIBICONV)
 
 if SOLARIS
-libDtHelp_la_LIBADD += -lw -lgen -lc
+libDtHelp_la_LIBADD += -lw -lgen
 endif
 
 
diff --git a/cde/lib/DtSearch/Makefile.am b/cde/lib/DtSearch/Makefile.am
index 5c359728f..fdd8f7585 100644
--- a/cde/lib/DtSearch/Makefile.am
+++ b/cde/lib/DtSearch/Makefile.am
@@ -21,10 +21,6 @@ endif
 
 libDtSearch_la_LIBADD = raima/libraima.la
 
-if SOLARIS
-libDtSearch_la_LIBADD += -lc
-endif
-
 libDtSearch_la_SOURCES = apndext.c	ausdopen.c	ausexit.c \
 			 bmstrstr.c	boolpars.c	boolsrch.c \
 			 boolyac.y	cuslang.c	dbchange.c \
@@ -39,5 +35,3 @@ libDtSearch_la_SOURCES = apndext.c	ausdopen.c	ausexit.c \
 			 ocf.c		opendblk.c	ophuf.c \
 			 readchar.c	strupr.c	userint.c \
 			 vedelete.c	vestatis.c	vstfunct.c
-
-
diff --git a/cde/lib/DtWidget/Makefile.am b/cde/lib/DtWidget/Makefile.am
index 182717e2e..ca9eda4b9 100644
--- a/cde/lib/DtWidget/Makefile.am
+++ b/cde/lib/DtWidget/Makefile.am
@@ -17,7 +17,7 @@ endif
 
 if SOLARIS
 libDtWidget_la_CFLAGS += -DNO_REGCOMP
-libDtWidget_la_LIBADD = -lc -lw -lintl
+libDtWidget_la_LIBADD = -lw -lintl
 endif
 
 
diff --git a/cde/lib/tt/lib/Makefile.am b/cde/lib/tt/lib/Makefile.am
index b9e17b595..6fa386ad6 100644
--- a/cde/lib/tt/lib/Makefile.am
+++ b/cde/lib/tt/lib/Makefile.am
@@ -18,7 +18,7 @@ libtt_la_LIBADD = api/c/libapi.la api/dnd/libdnd.la db/libdb.la mp/libmp.la \
 
 if SOLARIS
 # This stuff should be figured out by configure
-libtt_la_LIBADD += -lnsl -lsocket -lintl -lc -lw
+libtt_la_LIBADD += -lnsl -lsocket -lintl -lw
 endif
 
 if LINUX
diff --git a/cde/programs/dtaction/Makefile.am b/cde/programs/dtaction/Makefile.am
index 6dde85bec..245d887ce 100644
--- a/cde/programs/dtaction/Makefile.am
+++ b/cde/programs/dtaction/Makefile.am
@@ -5,15 +5,3 @@ bin_PROGRAMS = dtaction
 dtaction_SOURCES = Main.c
 
 dtaction_LDADD = $(DTCLIENTLIBS) $(XTOOLLIB)
-
-if LINUX
-dtaction_LDADD += -lcrypt
-endif
-
-if FREEBSD
-dtaction_LDADD += -lcrypt
-endif
-
-if NETBSD
-dtaction_LDADD += -lcrypt
-endif
-- 
2.34.1

From e0df1d4a9298e60548917de616cf6041e7f8c46b Mon Sep 17 00:00:00 2001
From: Chase 
Date: Wed, 3 Aug 2022 18:41:37 -0500
Subject: [PATCH 2/3] lib/DtTerm/TermPrim: clean up defines

---
 cde/lib/DtTerm/TermPrim/Makefile.am   | 20 +---
 cde/lib/DtTerm/TermPrim/TermPrimOSDepI.h  |  8 
 cde/lib/DtTerm/TermPrim/TermPrimSetPty.c  |  6 +++---
 cde/lib/DtTerm/TermPrim/TermPrimSubproc.c | 16 ++--
 4 files changed, 14 insertions(+), 36 deletions(-)

diff --git a/cde/lib/DtTerm/TermPrim/Makefile.am b/cde/lib/DtTerm/TermPrim/Makefile.am
index 6ecc554f4..6c404dd7a 100644
--- a/cde/lib/DtTerm/TermPrim/Makefile.am
+++ b/cde/lib/DtTerm/TermPrim/Makefile.am
@@ -35,24 +35,6 @@ libTermPrim_la_SOURCES = TermPrim.c \
 
 if SOLARIS
 libTermPrim_la_SOURCES += TermPrimGetPty-svr4.c
-AM_CPPFLAGS += -DSUN_ARCHITECTURE
-endif
-
-# Use the posix pts api, like linux
-if BSD
-libTermPrim_la_SOURCES += TermPrimGetPty-pts.c
-# uses CSRG_BASED global define
-endif
-
-if FREEBSD
-AM_CPPFLAGS += -DFREEBSD_ARCHITECTURE
-endif
-
-if OPENBSD
-AM_CPPFLAGS += -DOPENBSD_ARCHITECTURE
-endif
-
-if LINUX
+else
 libTermPrim_la_SOURCES += TermPrimGetPty-pts.c
-AM_CPPFLAGS += -DLINUX_ARCHITECTURE
 endif
diff --git a/cde/lib/DtTerm/TermPrim/TermPrimOSDepI.h b/cde/lib/DtTerm/TermPrim/TermPrimOSDepI.h
index d79c22f69..a9a74df21 100644
--- a/cde/lib/DtTerm/TermPrim/TermPrimOSDepI.h
+++ b/cde/lib/DtTerm/TermPri

[cdesktopenv-devel] [PATCH] detect libm and libdl

[Chase via cdesktopenv-devel]

This is based off of current master instead of the libmd patch as it doesn't 
seem like it will be merged (though I could edit it to build on all systems 
except linux so no wiki edits need be made).

Thank you for your time,
-Chase

Sent with [Proton Mail](https://proton.me/) secure email.From b9cf8af1036cb1a8e5aea1be37ae7f88e5cd40c1 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sat, 30 Jul 2022 20:55:31 -0500
Subject: [PATCH 2/2] configure: detect libm

---
 cde/configure.ac| 3 +++
 cde/lib/DtHelp/Makefile.am  | 2 +-
 cde/lib/DtSearch/Makefile.am| 2 +-
 cde/programs/dtappbuilder/src/ab/Makefile.am| 2 +-
 cde/programs/dtappbuilder/src/abmf/Makefile.am  | 2 +-
 cde/programs/dtappbuilder/src/libABobj/Makefile.am  | 4 +---
 cde/programs/dtappbuilder/src/libAButil/Makefile.am | 4 ++--
 cde/programs/dtcm/server/Makefile.am| 2 +-
 cde/programs/dthelp/dthelpprint/Makefile.am | 2 +-
 9 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/cde/configure.ac b/cde/configure.ac
index 88f662625..5946c27a3 100644
--- a/cde/configure.ac
+++ b/cde/configure.ac
@@ -506,6 +506,9 @@ AC_CHECK_LIB(Xdmcp, XdmcpFlush, [XDMCPLIB="-lXdmcp"], [XDMCPLIB=""],
  [${EXTRA_INCS} ${EXTRA_LIBS}])
 AC_SUBST(XDMCPLIB)
 
+AC_SEARCH_LIBS(cos, m, [], [
+	AC_MSG_ERROR([cos not found, your system probably doesn't obey posix])])
+
 AC_SEARCH_LIBS(dlopen, [dl dld], [], [
 	AC_MSG_ERROR([dlopen not found, your system probably doesn't obey posix]
 	)])
diff --git a/cde/lib/DtHelp/Makefile.am b/cde/lib/DtHelp/Makefile.am
index 8aad06f3f..a3b59681b 100644
--- a/cde/lib/DtHelp/Makefile.am
+++ b/cde/lib/DtHelp/Makefile.am
@@ -16,7 +16,7 @@ libDtHelp_la_CFLAGS = -I./il -I./jpeg -I../DtSvc/DtUtil2 -DDTLIB \
 libDtHelp_la_LIBADD = $(JPEGLIB) il/libil.la $(LTLIBICONV)
 
 if SOLARIS
-libDtHelp_la_LIBADD += -lw -lgen -lm -lc
+libDtHelp_la_LIBADD += -lw -lgen -lc
 endif
 
 
diff --git a/cde/lib/DtSearch/Makefile.am b/cde/lib/DtSearch/Makefile.am
index fce13b0b6..5c359728f 100644
--- a/cde/lib/DtSearch/Makefile.am
+++ b/cde/lib/DtSearch/Makefile.am
@@ -22,7 +22,7 @@ endif
 libDtSearch_la_LIBADD = raima/libraima.la
 
 if SOLARIS
-libDtSearch_la_LIBADD += -lm -lc
+libDtSearch_la_LIBADD += -lc
 endif
 
 libDtSearch_la_SOURCES = apndext.c	ausdopen.c	ausexit.c \
diff --git a/cde/programs/dtappbuilder/src/ab/Makefile.am b/cde/programs/dtappbuilder/src/ab/Makefile.am
index e40629c7e..c0dee1a6f 100644
--- a/cde/programs/dtappbuilder/src/ab/Makefile.am
+++ b/cde/programs/dtappbuilder/src/ab/Makefile.am
@@ -47,7 +47,7 @@ dtbuilder_LDADD = ../libABil/libABil.a  ../libABobjXm/libABobjXm.a  \
 ../libABobj/libABobj.a ../libAButil/libAButil.a \
 $(LIBWIDGET) $(LIBTERM) $(LIBHELP) $(LIBSVC) \
 $(LIBTT) $(LIBXIN) -lUil $(MRESOURCELIB) $(XTOOLLIB) ${X_LIB} \
-$(UTILLIB) -lm
+	$(UTILLIB)
 
 dtbuilder_CFLAGS = -DPIXMAP_WORKAROUND $(ABINCLUDES)
 
diff --git a/cde/programs/dtappbuilder/src/abmf/Makefile.am b/cde/programs/dtappbuilder/src/abmf/Makefile.am
index 4578520f1..ee697131a 100644
--- a/cde/programs/dtappbuilder/src/abmf/Makefile.am
+++ b/cde/programs/dtappbuilder/src/abmf/Makefile.am
@@ -44,7 +44,7 @@ dtcodegen_SOURCES = abmf.c  args.c \
 		utils_header_file.c write_c.c \
 		write_code.c
 
-#ab_func_strings_LDADD = -lm ../libAButil/libAButil.a
+#ab_func_strings_LDADD = ../libAButil/libAButil.a
 
 #ab_func_strings_SOURCES = ab_func_strings.c
 
diff --git a/cde/programs/dtappbuilder/src/libABobj/Makefile.am b/cde/programs/dtappbuilder/src/libABobj/Makefile.am
index f74e52884..af17282a9 100644
--- a/cde/programs/dtappbuilder/src/libABobj/Makefile.am
+++ b/cde/programs/dtappbuilder/src/libABobj/Makefile.am
@@ -4,10 +4,8 @@ ABINCLUDES = ../include
 
 EXTRA_DEFINES =  -D_POSIX_SOURCE=1
 
-EXTRALIBS = -lm
-
 if SOLARIS
-EXTRALIBS += -lgen
+EXTRALIBS = -lgen
 endif
 
 noinst_LIBRARIES = libABobj.a
diff --git a/cde/programs/dtappbuilder/src/libAButil/Makefile.am b/cde/programs/dtappbuilder/src/libAButil/Makefile.am
index d683a00e8..af3aa55ac 100644
--- a/cde/programs/dtappbuilder/src/libAButil/Makefile.am
+++ b/cde/programs/dtappbuilder/src/libAButil/Makefile.am
@@ -21,13 +21,13 @@ libAButil_a_SOURCES = abio.c  \
 		  util_file.c \
 		  util_string.c
 
-#util_test_LDADD = libAButil.a -lm
+#util_test_LDADD = libAButil.a
 
 #util_test_CFLAGS = $(EXTRA_DEFINES) -I$(ABINCLUDES)
 
 #util_test_SOURCES = util_test.c
 
-#istr_test_LDADD = libAButil.a -lm
+#istr_test_LDADD = libAButil.a
 
 #istr_test_CFLAGS = $(EXTRA_DEFINES) -I$(ABINCLUDES)
 
diff --git a/cde/programs/dtcm/server/Makefile.am b/cde/programs/dtcm/server/Makefile.am
index bd49c472c..a4ac7dc55 100644
--- a/cde/programs/dtcm/server/Makefile.am
+++ b/cde/programs/dtcm/server/Makefile.am
@@ -7,7 +7,7 @@ rpc_cmsd_CFLAGS = -I../../../lib/csa $(DT_INCDIR) $(CSA_INCDIR)
 rpc_cmsd_LDADD = $(LIBCSA) $(DTCLIENTLIBS) $(

Re: [cdesktopenv-devel] [PATCH] Use system md5

[Chase via cdesktopenv-devel]

NetBSD and OpenBSD have this function in their libc, FreeBSD and opensolaris 
have this function in a bundled libmd with the system. Linux is the only system 
it doesn't come with and it can be installed on most systems as libmd or libbsd 
(this one is deprecated). It's not a very painful band-aid to rip off.

Thank you for your time,
-Chase

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Wednesday, July 27th, 2022 at 6:42 PM, Jon Trulson  wrote:

> On 7/27/22 14:52, Chase via cdesktopenv-devel wrote:
>
>> I made a second attempt at this and made the configure script detect which 
>> library has md5, this manages to work for dtcm and dtmail, it should be much 
>> more portable than before. I don't think that ~1300 LOC that we no longer 
>> have to maintain is a small gain, there is already a huge amount of code to 
>> maintain, if someone else is working on an exact copy and distributing it as 
>> a library it only makes sense to use theirs.
>
> But are you willing to go through the wikis for each OS and update them with 
> the names of the proper packages that need to be installed?
>
> -jon
>
>> Thank you for your time,
>> -Chase
>>
>> Sent with [Proton Mail](https://proton.me/) secure email.
>>
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>>
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
> Jon Trulson
>
>   "The less you know, the more you believe."
>-- Bono___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] Use system md5

[Chase via cdesktopenv-devel]

I made a second attempt at this and made the configure script detect which 
library has md5, this manages to work for dtcm and dtmail, it should be much 
more portable than before. I don't think that ~1300 LOC that we no longer have 
to maintain is a small gain, there is already a huge amount of code to 
maintain, if someone else is working on an exact copy and distributing it as a 
library it only makes sense to use theirs.

Thank you for your time,
-Chase

Sent with [Proton Mail](https://proton.me/) secure email.From 7be5ad1de48a451270a61d96eded7d1f04426659 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Wed, 27 Jul 2022 15:01:03 -0500
Subject: [PATCH] Use system libmd5

---
 cde/configure.ac  |   4 +
 cde/programs/dtcm/dtcm/Makefile.am|   2 +-
 cde/programs/dtcm/dtcm/md5.c  | 387 --
 cde/programs/dtcm/dtcm/md5.h  | 113 -
 cde/programs/dtcm/dtcm/md5global.h|  96 -
 .../dtmail/libDtMail/Common/APOPServer.C  |   2 +-
 .../dtmail/libDtMail/Common/Makefile.am   |   4 +-
 cde/programs/dtmail/libDtMail/Common/md5.C| 366 -
 cde/programs/dtmail/libDtMail/Common/md5.h|  92 -
 .../dtmail/libDtMail/Common/md5global.h   |  75 
 .../dtmail/libDtMail/Common/str_utils.C   |  83 
 .../dtmail/libDtMail/RFC/MIMEBodyPart.C   |   2 +-
 cde/programs/dtmail/libDtMail/RFC/RFCMIME.C   |   2 +-
 13 files changed, 9 insertions(+), 1219 deletions(-)
 delete mode 100644 cde/programs/dtcm/dtcm/md5.c
 delete mode 100644 cde/programs/dtcm/dtcm/md5.h
 delete mode 100644 cde/programs/dtcm/dtcm/md5global.h
 delete mode 100644 cde/programs/dtmail/libDtMail/Common/md5.C
 delete mode 100644 cde/programs/dtmail/libDtMail/Common/md5.h
 delete mode 100644 cde/programs/dtmail/libDtMail/Common/md5global.h
 delete mode 100644 cde/programs/dtmail/libDtMail/Common/str_utils.C

diff --git a/cde/configure.ac b/cde/configure.ac
index d2551a566..8e7594cda 100644
--- a/cde/configure.ac
+++ b/cde/configure.ac
@@ -453,6 +453,10 @@ AC_INCLUDES_DEFAULT
 #include 
 ])
 
+AC_SEARCH_LIBS(MD5Init, [md bsd], [], [
+	AC_MSG_ERROR([unable to find a library for MD5 functionality])
+])
+
 dnl check sizeof time_t for RPC
 AC_CHECK_SIZEOF([int])
 AC_CHECK_SIZEOF([long])
diff --git a/cde/programs/dtcm/dtcm/Makefile.am b/cde/programs/dtcm/dtcm/Makefile.am
index 93fbbf3a1..98e8730cc 100644
--- a/cde/programs/dtcm/dtcm/Makefile.am
+++ b/cde/programs/dtcm/dtcm/Makefile.am
@@ -23,7 +23,7 @@ dtcm_SOURCES = MonthPanel.cRFCMIME.c   about.c \
find.c  fns.c   font.c \
format.cgoto.c  graphics.c \
group_editor.c  help.c  i18nxlate.c \
-   icon.c  md5.c   misc.c \
+   icon.c  misc.c \
monthglance.c   namesvc.c   print.c \
props.c props_pu.c  reminders.c \
rfp.c   select.csession.c \
diff --git a/cde/programs/dtcm/dtcm/md5.c b/cde/programs/dtcm/dtcm/md5.c
deleted file mode 100644
index a2ae1b8f5..0
--- a/cde/programs/dtcm/dtcm/md5.c
+++ /dev/null
@@ -1,387 +0,0 @@
-/*
- * CDE - Common Desktop Environment
- *
- * Copyright (c) 1993-2012, The Open Group. All rights reserved.
- *
- * These libraries and programs are free software; you can
- * redistribute them and/or modify them under the terms of the GNU
- * Lesser General Public License as published by the Free Software
- * Foundation; either version 2 of the License, or (at your option)
- * any later version.
- *
- * These libraries and programs are distributed in the hope that
- * they will be useful, but WITHOUT ANY WARRANTY; without even the
- * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
- * PURPOSE. See the GNU Lesser General Public License for more
- * details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with these libraries and programs; if not, write
- * to the Free Software Foundation, Inc., 51 Franklin Street, Fifth
- * Floor, Boston, MA 02110-1301 USA
- */
-static char sccsid[] = "$XConsortium: md5.c /main/2 1996/03/25 10:28:16 rswiston $";
-/*
- *   COMPONENT_NAME: desktop
- *
- *   FUNCTIONS: Decode
- *		Encode
- *		F
- *		FF
- *		G
- *		GG
- *		H
- *		HH
- *		I
- *		II
- *		MD5Final
- *		MD5Init
- *		MD5Transform
- *		MD5Update
- *		MD5_memcpy
- *		MD5_memset
- *		ROTATE_LEFT
- *
- *   ORIGINS: 119
- *
- */
-/*
- *+SNOTICE
- *
- *
- *	$Revision: /main/2 $
- *
- *	RESTRICTED CONFIDENTIAL INFORMATION:
- *	
- *	The information in this document is subject to special
- *	restrictions in a confidential disclosure agreement bertween
- *	HP, IBM, Sun, USL, SCO and Univel.  Do not distribute this
- *	document outside HP, IBM, Sun, USL, SCO, or Univel wihtout
- *	Sun's specific written approval.  This documment and all copies
- *	and derivative works thereof must be returned or

Re: [cdesktopenv-devel] New release upcoming...

[Chase via cdesktopenv-devel]

I don't think it's a good idea, Fedora 36 doesn't work according to 
https://sourceforge.net/p/cdesktopenv/discussion/general/thread/2b0bd87053/

It's a problem with KSH93, upstream has already fixed it. I don't know how to 
work with subtrees so I can't really update it myself.

Thank you for your time,
-Chase

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Tuesday, July 5th, 2022 at 2:17 PM, Jon Trulson  wrote:

> Hi,
>
> It's past time for our yearly release, so I'd like to release next weekend 
> unless there is some pressing patch(es) that need to go in beforehand.
>
> --
> Jon Trulson
>
>   "The less you know, the more you believe."
>-- Bono___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] dtksh: Upgrade ksh93 to 1.0.0-beta.2 2021-12-28

[Chase via cdesktopenv-devel]

Nice, I was thinking of taking this up but you did this nicely. A question for 
you, apparently our code uses a "LockKshFileDescriptors" function that locks 
the first 10 file descriptors, is this still necessary with the new ksh?
Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐

On Friday, December 31st, 2021 at 11:58 PM, Martijn Dekker  
wrote:

> Hello,
>
> ksh 93u+m maintainer here. I finally got cde to build (on Slackware
>
> 14.2), so this upgrades ksh93 and updates the build system accordingly.
>
> Please excuse the intrusion, this patch is too big for the mailing list,
>
> so here it is in direct email (attached, created with 'git format-patch').
>
> cde/programs/dtksh/ksh93/**:
>
> -   Upgraded. A load of bugs fixed, some minor features added.
>
> See NEWS from 2021-02-01 upwards.
>
> cde/programs/dtksh/Makefile.am:
> -   Don't cd into ksh93 any more to invoke the package or shtests
>
> scripts; they now automatically find their directories.
> -   Pass $(CFLAGS) to build ksh with optimisation.
> -   Remove -D_std_malloc flag as vmalloc is now deprecated and disabled
>
> by default.
> -   Add a 'make check' target to Makefile.am that runs the ksh93
>
> regression tests on dtksh to make sure the additions don't interfere
>
> with anything. It skips running the tests with shcomp because CDE
>
> doesn't use that. The tests all pass here on Slackware 14.2. :-)
>
> cde/programs/dtksh/init.patch:
> -   Removed; I've upstreamed it. It was the only one that wasn't upstreamed
>
> yet, and more code cleanups are coming, breaking downstream patches. If
>
> something needs updating, just email me a diff.
>
> cde/programs/dtksh/dtkcmds.h:
> -   Update the ADDBUILTIN macro to remove the PROTO macro use. The
>
> proto(1) tool, responsible for all such pre-C89 K&R C compatibility
>
> voodoo, has been removed, so that macro is no longer defined.
>
> cde/programs/dtksh/setup.sh:
> -   Workaround script removed. I rewrote 'bin/package flat make' in a way
>
> that works correctly and changed Makefile.am to use that instead.
>
> Hope this helps. Happy new year.
>
> --
>
> || modernish -- harness the shell
>
> || https://github.com/modernish/modernish
>
> ||
>
> || KornShell lives!
>
> || https://github.com/ksh93/ksh


___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] use builtin onsgmls versus our included one

[Chase via cdesktopenv-devel]

Fair warning, I have only tested this on linux.

Thank you for your time,
-Chase

0001-Use-built-in-onsgml-parser-versus-our-old-one.patch
Description: Binary data
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] How to compile projects created with application builder

[Chase via cdesktopenv-devel]

Could you post your full build log?

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐

On Wednesday, October 6th, 2021 at 8:00 PM, Marco Diego Aurélio Mesquita 
 wrote:

> Minor progress: got it to compile with:
>
> cc -o project project.o dtb_utils.o main_ui.o main_stubs.o
>
> -L/usr/dt/lib -L/X11/lib -lDtWidget -lDtHelp -lDtSvc -lXm -lXt -lXext
>
> -lX11 -lICE -lSM -lm -ltt -lDtXinerama
>
> To make it run, I had to type
>
> LD_LIBRARY_PATH=/usr/dt/lib ./project
>
> But when it runs, it segfaults. Backtrace is:
>
> #0 _dl_runtime_resolve_xsave () at ../sysdeps/x86_64/dl-trampoline.h:153
>
> #1 0x77b44afc in _XtWaitForSomething ()
>
> from /lib/x86_64-linux-gnu/libXt.so.6
>
> #2 0x77b45b90 in XtAppProcessEvent ()
>
> from /lib/x86_64-linux-gnu/libXt.so.6
>
> #3 0x77b3a463 in XtAppMainLoop ()
>
> from /lib/x86_64-linux-gnu/libXt.so.6
>
> #4 0x6834 in main (argc=1, argv=0x7fffdfb8) at project.c:227
>
> cdesktopenv-devel mailing list
>
> cdesktopenv-devel@lists.sourceforge.net
>
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel


___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] make /var/spool/calendar for the user upon installation

[Chase via cdesktopenv-devel]

 recover from previous errors
>>>>>
>>>>> However, I was able to compile a randomly selected library (DtMrm),
>>>>> which seems like a major improvement. Thanks!
>>>>>
>>>>> Although UnixWare has been convenient for me to test against on hardware
>>>>> I own, my preference would be to have a lean, open source SVR4 system
>>>>> someday that anyone can use. What do you think of Solaris? I've been
>>>>> running version 8 lately and found it to be pretty similar to UnixWare,
>>>>> but I do not know what the legal situation is with the earlier source
>>>>> code releases.
>>>>>
>>>>> Also, I found out that libXfont is not taking advantage of FreeType's
>>>>> support for using the now unpatented bytecode interpreter. I think it is
>>>>> a rather substantial improvement and could help with internationalizing
>>>>> CDE, because some of the free Microsoft web fonts, like Tahoma, support
>>>>> many Unicode scripts within a single font. Also, the CJK bitmaps, MS
>>>>> Gothic, SimSun, PMingLiu, and Gulim, take heavy advantage of the
>>>>> bytecode interpreter from my understanding. I've attached a patch and
>>>>> some examples.
>>>>>
>>>>> --8<---cut here---start->8---
>>>>> --- src/Freetype/ftfuncs.c
>>>>> +++ src/FreeType/ftfuncs.c
>>>>> @@ -3136,7 +3136,7 @@
>>>>> int face_number, ttcap_spacing;
>>>>> struct TTCapInfo tmp_ttcap;
>>>>> struct TTCapInfo *ins_ttcap;
>>>>>
>>>>> -   FT_Int32 load_flags = FT_LOAD_DEFAULT; /* orig: FT_LOAD_RENDER | 
>>>>> FT_LOAD_MONOCHROME */
>>>>>
>>>>> -   FT_Int32 load_flags = FT_LOAD_TARGET_MONO; /* orig: FT_LOAD_RENDER | 
>>>>> FT_LOAD_MONOCHROME */
>>>>> char dynStrRealFileName = NULL; / foo.ttc */
>>>>> char dynStrFTFileName = NULL; / :1:foo.ttc */
>>>>> char *dynStrTTCapCodeRange = NULL;
>>>>> --8<---cut here---end--->8---
>>>>>
>>>>> Unlike bitmap fonts that have to be digitally recast for each pixel
>>>>> size, using a bytecoded TrueType font would allow for arbitrary scaling
>>>>> using the X11 core font subsystem. I imagine that it would look quite
>>>>> nice on a HiDPI display.
>>>>>
>>>>> Thanks,
>>>>> Lev
>>>>>
>>>>> P.S.: For anyone else interested in obscure Unix systems, I've gotten
>>>>> the Jam build system to work with old K&R compilers, even ones like
>>>>> ULTRIX/VAX's that do not support string literal concatenation, etc.
>>>>> It also now features support for recursively scanning includes for IFFE
>>>>> headers and generating the appropriate configuration.
>>>>> It's on GitHub at lkujaw/jam.
>>>>>
>>>>> Chase writes:
>>>>>
>>>>>> Here is also another patch that might hopefully make some progress on 
>>>>>> generating makefiles with unportable statements, lev, would you care to 
>>>>>> tell me if this commit changes anything when building on unixware with a 
>>>>>> pregenerated configure script?
>>>>>> Thank you for your time,
>>>>>> -Chase
>>>>>> ‐‐‐ Original Message ‐‐‐
>>>>>> On Sunday, March 14, 2021 6:52 PM, Chase via cdesktopenv-devel
>>>>>> cdesktopenv-devel@lists.sourceforge.net
>>>>>> wrote:
>>>>>>
>>>>>>> ugh, CTRL+enter is never consistent between apps.
>>>>>>>
>>>>>>> 1.  libmmdb.a is now built inside DtMmdb, since building sources 
>>>>>>> outside of the directory messes up dependency tracking
>>>>>>> 2.  the pmaker and dfiles programs seem to generate files that have no 
>>>>>>> differences between platforms, so therefor lets just commit them.
>>>>>>>
>>>>>>> Thank you for your time,
>>>>>>> -Chase
>>>>>>> ‐‐‐ Original Message ‐‐‐
>>>>>>> On Sunday, March 14, 2021 6:49 PM, Chase
>>>>>>> nicetry...@protonmail.ch
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Some notes:
>>>>>>>> Thank you for your time,
>>>>>>>> -Chase
>>>>>>>> ‐‐‐ Original Message ‐‐‐
>>>>>>>> On Sunday, March 14, 2021 4:48 PM, Jon Trulson
>>>>>>>> j...@radscan.com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Go ahead and post a patch... Not sure when I can take a look, but the 
>>>>>>>>> likely issue is the order of the libraries on the link line.
>>>>>>>>> -jon
>>>>>>>>> On 3/11/21 4:06 PM, Chase via cdesktopenv-devel wrote:
>>>>>>>>>
>>>>>>>>>> By the way, I have made Makefile.am for the dtinfo program (not 
>>>>>>>>>> dtinfogen) that compile, but I can't get the convenience libraries 
>>>>>>>>>> to work, they keep outputting missing symbols as errors. I can 
>>>>>>>>>> provide a patch if anyone is interested/willing to take a look.
>>>>>>>>>> Thank you for your time,
>>>>>>>>>> -Chase
>>>>>>>>>> ‐‐‐ Original Message ‐‐‐
>>>>>>>>>> On Tuesday, March 9, 2021 6:15 PM, Chase
>>>>>>>>>> nicetry...@protonmail.ch
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> The wiki says the user should create /var/spool/calendar for proper 
>>>>>>>>>>> calendar functioning, lets do this for the user instead upon 
>>>>>>>>>>> installation.
>>>>>>>>>>> Thank you for your time,
>>>>>>>>>>> -Chase
>>>>>>>>>>
>>>>>>>>>> cdesktopenv-devel mailing list
>>>>>>>>>> cdesktopenv-devel@lists.sourceforge.net
>>>>>>>>>>
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jon Trulson
>>>>>>>>> "Entropy. It isn't what it used to be."
>>>>>>>>> -- Sheldon
>>>>>
>>>>> X-No-Archive: Yes - savehttp://groups.google.com/
>>>
>>> --
>>> Jon Trulson
>>>
>>>   "Entropy.  It isn't what it used to be."
>>>-- Sheldon
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] make /var/spool/calendar for the user upon installation

[Chase via cdesktopenv-devel]

L;
>>> --8<---cut here---end--->8---
>>>
>>> Unlike bitmap fonts that have to be digitally recast for each pixel
>>> size, using a bytecoded TrueType font would allow for arbitrary scaling
>>> using the X11 core font subsystem. I imagine that it would look quite
>>> nice on a HiDPI display.
>>>
>>> Thanks,
>>> Lev
>>>
>>> P.S.: For anyone else interested in obscure Unix systems, I've gotten
>>> the Jam build system to work with old K&R compilers, even ones like
>>> ULTRIX/VAX's that do not support string literal concatenation, etc.
>>> It also now features support for recursively scanning includes for IFFE
>>> headers and generating the appropriate configuration.
>>> It's on GitHub at lkujaw/jam.
>>>
>>> Chase writes:
>>>
>>>> Here is also another patch that might hopefully make some progress on 
>>>> generating makefiles with unportable statements, lev, would you care to 
>>>> tell me if this commit changes anything when building on unixware with a 
>>>> pregenerated configure script?
>>>> Thank you for your time,
>>>> -Chase
>>>> ‐‐‐ Original Message ‐‐‐
>>>> On Sunday, March 14, 2021 6:52 PM, Chase via cdesktopenv-devel
>>>> cdesktopenv-devel@lists.sourceforge.net
>>>> wrote:
>>>>
>>>>> ugh, CTRL+enter is never consistent between apps.
>>>>>
>>>>> 1.  libmmdb.a is now built inside DtMmdb, since building sources outside 
>>>>> of the directory messes up dependency tracking
>>>>> 2.  the pmaker and dfiles programs seem to generate files that have no 
>>>>> differences between platforms, so therefor lets just commit them.
>>>>>
>>>>> Thank you for your time,
>>>>> -Chase
>>>>> ‐‐‐ Original Message ‐‐‐
>>>>> On Sunday, March 14, 2021 6:49 PM, Chase
>>>>> nicetry...@protonmail.ch
>>>>> wrote:
>>>>>
>>>>>> Some notes:
>>>>>> Thank you for your time,
>>>>>> -Chase
>>>>>> ‐‐‐ Original Message ‐‐‐
>>>>>> On Sunday, March 14, 2021 4:48 PM, Jon Trulson
>>>>>> j...@radscan.com
>>>>>> wrote:
>>>>>>
>>>>>>> Go ahead and post a patch... Not sure when I can take a look, but the 
>>>>>>> likely issue is the order of the libraries on the link line.
>>>>>>> -jon
>>>>>>> On 3/11/21 4:06 PM, Chase via cdesktopenv-devel wrote:
>>>>>>>
>>>>>>>> By the way, I have made Makefile.am for the dtinfo program (not 
>>>>>>>> dtinfogen) that compile, but I can't get the convenience libraries to 
>>>>>>>> work, they keep outputting missing symbols as errors. I can provide a 
>>>>>>>> patch if anyone is interested/willing to take a look.
>>>>>>>> Thank you for your time,
>>>>>>>> -Chase
>>>>>>>> ‐‐‐ Original Message ‐‐‐
>>>>>>>> On Tuesday, March 9, 2021 6:15 PM, Chase
>>>>>>>> nicetry...@protonmail.ch
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> The wiki says the user should create /var/spool/calendar for proper 
>>>>>>>>> calendar functioning, lets do this for the user instead upon 
>>>>>>>>> installation.
>>>>>>>>> Thank you for your time,
>>>>>>>>> -Chase
>>>>>>>>
>>>>>>>> cdesktopenv-devel mailing list
>>>>>>>> cdesktopenv-devel@lists.sourceforge.net
>>>>>>>>
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>>>>>>>
>>>>>>> --
>>>>>>> Jon Trulson
>>>>>>> "Entropy. It isn't what it used to be."
>>>>>>> -- Sheldon
>>>
>>> X-No-Archive: Yes - savehttp://groups.google.com/
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] make /var/spool/calendar for the user upon installation

[Chase via cdesktopenv-devel]

So it sounds like the makefile incompatibilities have been solved, and now it's 
an issue of the code itself having problems with compatibility, so if you would 
like to fix and maintain unixware support, be my guest. The makefiles appear to 
have incompatibilites commented out and replaced with portable statements, so 
maybe the *BSDs will be able to use their native make now? In any case, I'd 
like to have this merged.

As for a lightweight system v, I think solaris would be your best bet, but why 
not go for a modern opensolaris fork that is actually maintained like DilOS or 
Tribblix (theres even a video of this one running CDE on youtube)?


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Sunday, March 28, 2021 1:27 AM, Lev  wrote:

>
>
> Hi Chase,
>
> Apologies, I haven't been able to spend as much time working on CDE and the
> Korn shell as I would like recently.
>
> I wanted to let you know that I couldn't use the autoconf v. 2.63 bundled
> with Oracle Linux 6 (i386):
> configure.ac:3: error: possibly undefined macro: AC_CONFIG_MACRO_DIRS
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.
>
> Like last time, I had to hack the configure script to work around missing
> dependencies, but I encountered this Xinerama-related build failure
> right away:
>
> /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H
> -I. -I../../include -DANSICPP -DMULTIBYTE -DNLS16 -DOSMAJORVERSION=4
> -DOSMINORVERSION=15 -g -c -o DtXinerama.lo DtXinerama.c libtool:
> compile: cc -DHAVE_CONFIG_H -I. -I../../include -DANSICPP -DMULTIBYTE
> -DNLS16 -DOSMAJORVERSION=4 -DOSMINORVERSION=15 -g -c DtXinerama.c -KPIC
> -DPIC -o .libs/DtXinerama.o UX:acomp: ERROR:
> "../../include/DtXinerama.h", line 38: cannot find include file:
>  UX:acomp: ERROR:
> "../../include/DtXinerama.h", line 43: Syntax error before or at:
> XineramaScreenInfo UX:acomp: ERROR: "../../include/DtXinerama.h", line
> 43: cannot recover from previous errors
>
> However, I was able to compile a randomly selected library (DtMrm),
> which seems like a major improvement. Thanks!
>
> Although UnixWare has been convenient for me to test against on hardware
> I own, my preference would be to have a lean, open source SVR4 system
> someday that anyone can use. What do you think of Solaris? I've been
> running version 8 lately and found it to be pretty similar to UnixWare,
> but I do not know what the legal situation is with the earlier source
> code releases.
>
> Also, I found out that libXfont is not taking advantage of FreeType's
> support for using the now unpatented bytecode interpreter. I think it is
> a rather substantial improvement and could help with internationalizing
> CDE, because some of the free Microsoft web fonts, like Tahoma, support
> many Unicode scripts within a single font. Also, the CJK bitmaps, MS
> Gothic, SimSun, PMingLiu, and Gulim, take heavy advantage of the
> bytecode interpreter from my understanding. I've attached a patch and
> some examples.
>
> --8<---cut here---start->8---
> --- src/Freetype/ftfuncs.c
> +++ src/FreeType/ftfuncs.c
> @@ -3136,7 +3136,7 @@
> int face_number, ttcap_spacing;
> struct TTCapInfo tmp_ttcap;
> struct TTCapInfo *ins_ttcap;
>
> -   FT_Int32 load_flags = FT_LOAD_DEFAULT; /* orig: FT_LOAD_RENDER | 
> FT_LOAD_MONOCHROME */
>
> -   FT_Int32 load_flags = FT_LOAD_TARGET_MONO; /* orig: FT_LOAD_RENDER | 
> FT_LOAD_MONOCHROME */
> char dynStrRealFileName = NULL; / foo.ttc */
> char dynStrFTFileName = NULL; / :1:foo.ttc */
> char *dynStrTTCapCodeRange = NULL;
> --8<---cut here---end--->8---
>
>
> Unlike bitmap fonts that have to be digitally recast for each pixel
> size, using a bytecoded TrueType font would allow for arbitrary scaling
> using the X11 core font subsystem. I imagine that it would look quite
> nice on a HiDPI display.
>
> Thanks,
> Lev
>
> P.S.: For anyone else interested in obscure Unix systems, I've gotten
> the Jam build system to work with old K&R compilers, even ones like
> ULTRIX/VAX's that do not support string literal concatenation, etc.
> It also now features support for recursively scanning includes for IFFE
> headers and generating the appropriate configuration.
> It's on GitHub at lkujaw/jam.
>
> Chase writes:
>
> > Here is also another patch that might hopefully make some progress on 
> > generating makefiles with unportable statements, lev, would you care to 
> > tell me if this commit changes anything when building on unixware with a 
> > pregenerated 

Re: [cdesktopenv-devel] Why do we require ksh93 to compile CDE?

[Chase via cdesktopenv-devel]

@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 installation 
script among other things, but yet another thing that autotools solves for us, 
is that we no longer have to use the install script plus databases as autotools 
can install for us. If someone could compile a list of scripts that require ksh 
to run I could take a look at them. I know that our docbook to manpage 
converter needs ksh, but strangely enough debian has their own copy of this 
program that they maintain separately from us which doesn't use ksh, maybe we 
could use it: https://sources.debian.org/src/docbook-to-man/1:2.0.0-45/

@marcin In terms of getting a ksh library distributed, I really wouldn't hold 
my breath about it. Right or wrong, and good for the CDE project or not, it 
turns out that deleting your entire repo history due to a few debatably bad 
actors and then telling everyone to simply fork ksh and finally abandoning it 
really shakes people's confidence in ksh. Not to mention the preferred fork at 
the time, ksh-community, immediately falling on it's face and dying right out 
of the gate. It would probably take years of convincing that ksh93u+m is a 
worthy successor to ksh, and Martijn himself has said he still considers the 
project to be an alpha. Getting linux distros to agree on making it the new 
distributed ksh, let alone the libraries that no one except us would even use 
as most forks of ksh are actually in house implementations, or do anything for 
that matter would be like trying to herd cats. One thing that would be helpful 
though in this regard, we need to import pmain.o from upstream, which means 
that technically, dtksh is EPLv1 licensed, as we have our main() from pmain.c 
which is EPL licensed, and all other assets are EPLv1 with the exception of our 
builtins and environment variables tacked on to init.c which are LGPL, so 
basically an extra lgpl library. If we were to make our own main(), that would 
mean that the main program is LGPL and all the libraries it calls are EPL, so 
therefor it would be a LGPL program. There are only two issues: 1. How do we 
write a main() that is different enough from pmain.c to be considered its own 
work? I doubt that AT&T would ever sue, but you never know... 2. I've tried to 
do this an it complains about missing symbols. I am not going to work on this 
since I am happy that it works at all, but if you really want to pursue this 
whole library idea, that would probably be step 1.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Friday, March 26, 2021 2:56 PM, Zeke Williams  wrote:

>> 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 something else so it can co-exist 
> with the OS version of ksh93. Just a thought I had.
>
> On Fri, Mar 26, 2021 at 3:44 PM Marcin Cieslak  wrote:
>
>> 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.
>>
>> Two things need to be done for that:
>>
>> 1. dtksh build system needs to be rebuild to allow that (if at all possible).
>> 2. operating systems need to start shipping not only ksh binary but also
>> its shared libraries.
>>
>> There was some progress made recently towards (1) - big thanks to Chase
>> for taking up ksh93 upgrade.
>>
>> Marcin___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] make /var/spool/calendar for the user upon installation

[Chase via cdesktopenv-devel]

Some notes:

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Sunday, March 14, 2021 4:48 PM, Jon Trulson  wrote:

> Go ahead and post a patch... Not sure when I can take a look, but the likely 
> issue is the order of the libraries on the link line.
>
> -jon
>
> On 3/11/21 4:06 PM, Chase via cdesktopenv-devel wrote:
>
>> By the way, I have made Makefile.am for the dtinfo program (not dtinfogen) 
>> that compile, but I can't get the convenience libraries to work, they keep 
>> outputting missing symbols as errors. I can provide a patch if anyone is 
>> interested/willing to take a look.
>>
>> Thank you for your time,
>> -Chase
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Tuesday, March 9, 2021 6:15 PM, Chase 
>> [](mailto:nicetry...@protonmail.ch) wrote:
>>
>>> The wiki says the user should create /var/spool/calendar for proper 
>>> calendar functioning, lets do this for the user instead upon installation.
>>>
>>> Thank you for your time,
>>> -Chase
>>
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>>
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] make /var/spool/calendar for the user upon installation

[Chase via cdesktopenv-devel]

By the way, I have made Makefile.am for the dtinfo program (not dtinfogen) that 
compile, but I can't get the convenience libraries to work, they keep 
outputting missing symbols as errors. I can provide a patch if anyone is 
interested/willing to take a look.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Tuesday, March 9, 2021 6:15 PM, Chase  wrote:

> The wiki says the user should create /var/spool/calendar for proper calendar 
> functioning, lets do this for the user instead upon installation.
>
> Thank you for your time,
> -Chase___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] make /var/spool/calendar for the user upon installation

[Chase via cdesktopenv-devel]

The wiki says the user should create /var/spool/calendar for proper calendar 
functioning, lets do this for the user instead upon installation.

Thank you for your time,
-ChaseFrom 418144f7902355f39851451dc28ef7d2058bb98b Mon Sep 17 00:00:00 2001
From: Chase 
Date: Tue, 9 Mar 2021 17:59:00 -0600
Subject: [PATCH] dtcm: make /var/spool/calendar for user

---
 cde/programs/dtcm/dtcm/Makefile.am | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/cde/programs/dtcm/dtcm/Makefile.am b/cde/programs/dtcm/dtcm/Makefile.am
index 7a616ba6d..2ade8 100644
--- a/cde/programs/dtcm/dtcm/Makefile.am
+++ b/cde/programs/dtcm/dtcm/Makefile.am
@@ -44,3 +44,6 @@ dtcm_lookup_SOURCES = cm_lookup.c
 dtcm_editor_SOURCES = datefield.c deskset.c   dssw.c \
 		  dtcm_editor.c   help.c  misc.c \
 		  reminders.c rfp.c
+
+install-exec-hook:
+	mkdir -p /var/spool/calendar
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] dtinfo: make auxillary dirs build

[Chase via cdesktopenv-devel]

Along with this, I did get a rare build failure in dthelp again, in 
pass1/build, it looked the same as the errors I was getting in canon1/build and 
pass2/build, so I am disabling parallel building there too. dtinfo and 
dtinfogen still look fairly complex, I think I am going to try and find out why 
make distcheck fails, as apparently it can help tell why a directory gets 
unconditionally rebuilt.

Thank you for your time,
-ChaseFrom b4365035b26e44c4644450114831a5c16cad3dc7 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sat, 27 Feb 2021 21:21:34 -0600
Subject: [PATCH] dtinfo: make auxillary libs and programs build

---
 cde/configure.ac  | 60 ++---
 cde/programs/Makefile.am  |  4 +-
 .../dthelp/parser/pass1/build/Makefile.am |  2 +
 cde/programs/dtinfo/DtMmdb/Makefile.am| 14 ++--
 .../dtinfo/DtMmdb/btree_berkeley/Makefile.am  | 13 ++--
 .../dtinfo/DtMmdb/diskhash/Makefile.am|  2 +-
 .../dtinfo/DtMmdb/oliasdb/Makefile.am |  2 +-
 .../dtinfo/DtMmdb/utility/Makefile.am | 22 ++
 cde/programs/dtinfo/Makefile.am   |  4 +-
 .../dtinfo/clients/dtinfo_start/Makefile.am   |  6 +-
 .../dtinfo/install/lib/bitmaps/Makefile.am| 67 ---
 .../dtinfo/install/lib/fonts/Makefile.am  |  4 +-
 cde/programs/dtinfo/dtinfo/src/Makefile.am| 11 +++
 cde/programs/dtinfo/dtinfogen/Makefile.am |  2 +
 .../dtinfo/dtinfogen/mmdb/Makefile.am |  2 +
 cde/programs/dtinfo/mmdb/HardCopy/Makefile.am | 21 ++
 cde/programs/dtinfo/mmdb/Makefile.am  | 26 +++
 .../dtinfo/mmdb/StyleSheet/Makefile.am| 42 
 cde/programs/dtinfo/mmdb/api/Makefile.am  | 14 
 cde/programs/dtinfo/mmdb/btree/Makefile.am|  9 +++
 .../dtinfo/mmdb/btree_berkeley/Makefile.am| 34 ++
 .../dtinfo/mmdb/compression/Makefile.am   | 16 +
 cde/programs/dtinfo/mmdb/diskhash/Makefile.am | 11 +++
 cde/programs/dtinfo/mmdb/dstr/Makefile.am | 21 ++
 cde/programs/dtinfo/mmdb/dti_cc/Makefile.am   | 15 +
 cde/programs/dtinfo/mmdb/dti_excs/Makefile.am | 26 +++
 cde/programs/dtinfo/mmdb/dynhash/Makefile.am  | 11 +++
 cde/programs/dtinfo/mmdb/hmphf/Makefile.am| 14 
 cde/programs/dtinfo/mmdb/index/Makefile.am| 17 +
 cde/programs/dtinfo/mmdb/mgrs/Makefile.am | 13 
 cde/programs/dtinfo/mmdb/misc/Makefile.am |  9 +++
 cde/programs/dtinfo/mmdb/object/Makefile.am   | 25 +++
 cde/programs/dtinfo/mmdb/oliasdb/Makefile.am  | 33 +
 cde/programs/dtinfo/mmdb/schema/Makefile.am   | 19 ++
 cde/programs/dtinfo/mmdb/storage/Makefile.am  | 22 ++
 cde/programs/dtinfo/mmdb/utility/Makefile.am  | 52 ++
 cde/programs/dtinfo/tools/misc/Makefile.am| 18 +
 cde/programs/dtinfo/tools/misc/treeres.src|  0
 38 files changed, 585 insertions(+), 98 deletions(-)
 delete mode 100644 cde/programs/dtinfo/dtinfo/install/lib/bitmaps/Makefile.am
 create mode 100644 cde/programs/dtinfo/dtinfo/src/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/HardCopy/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/StyleSheet/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/api/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/btree/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/btree_berkeley/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/compression/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/diskhash/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/dstr/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/dti_cc/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/dti_excs/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/dynhash/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/hmphf/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/index/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/mgrs/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/misc/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/object/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/oliasdb/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/schema/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/storage/Makefile.am
 create mode 100644 cde/programs/dtinfo/mmdb/utility/Makefile.am
 create mode 100644 cde/programs/dtinfo/tools/misc/Makefile.am
 mode change 100755 => 100644 cde/programs/dtinfo/tools/misc/treeres.src

diff --git a/cde/configure.ac b/cde/configure.ac
index 45fb04a98..69e83d8a8 100644
--- a/cde/configure.ac
+++ b/cde/configure.ac
@@ -311,6 +311,12 @@ if test -z "$ac_cv_path_XRDB"; then
MISSING_PROGS="xrdb ${MISSING_PROGS}"
 fi
 
+AC_PATH_PROG(PERL, perl)
+if test -z "$ac_cv_path_PERL"; then
+   MISSING_PROGS="perl ${MISSING_PROGS}"
+fi
+
+
 dnl we need to use cpp for some things, like tooltalk and other
 dnl runtime uses.  So look for the system's cpp.  NOTE: this

[cdesktopenv-devel] [PATCH] fix spurious compilation failure

[Chase via cdesktopenv-devel]

Sometimes when compiling dthelp, the targets somehow get run out of order and 
files aren't being generated, so I am disabling parallel building in the build 
directory of the pass2 and canon1 parsers.

Thank you for your time,
-ChaseFrom b78fcd5ce58fb11221c59850883400a326e78222 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Mon, 22 Feb 2021 18:20:19 -0600
Subject: [PATCH] dthelp: fix spurious compilation failure

---
 cde/programs/dthelp/parser/canon1/build/Makefile.am | 2 ++
 cde/programs/dthelp/parser/pass2/build/Makefile.am  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/cde/programs/dthelp/parser/canon1/build/Makefile.am b/cde/programs/dthelp/parser/canon1/build/Makefile.am
index e82964b05..7b169c3bb 100644
--- a/cde/programs/dthelp/parser/canon1/build/Makefile.am
+++ b/cde/programs/dthelp/parser/canon1/build/Makefile.am
@@ -1,5 +1,7 @@
 MAINTAINERCLEANFILES = Makefile.in
 
+.NOTPARALLEL:
+
 noinst_PROGRAMS = build
 
 HELPTAG   = ..
diff --git a/cde/programs/dthelp/parser/pass2/build/Makefile.am b/cde/programs/dthelp/parser/pass2/build/Makefile.am
index 582bb0f43..c2fc5e0b0 100644
--- a/cde/programs/dthelp/parser/pass2/build/Makefile.am
+++ b/cde/programs/dthelp/parser/pass2/build/Makefile.am
@@ -1,5 +1,7 @@
 MAINTAINERCLEANFILES = Makefile.in
 
+.NOTPARALLEL:
+
 noinst_PROGRAMS = build
 
 HTAG2   = ..
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] make dtappbuilder build in parallel with autotools

[Chase via cdesktopenv-devel]

I was trying to find a way to make dtappbuilder stop rebuilding itself every 
time, I thought this would solve it but it didn't, however it does let us build 
it in parallel.

Thank you for your time,
-ChaseFrom 3e67f92766ac3ee0f00dc36cbb9cf059ae4b7279 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sun, 21 Feb 2021 13:38:27 -0600
Subject: [PATCH] dtappbuilder: make it build in parallel

---
 cde/programs/dtappbuilder/src/ab/Makefile.am | 156 ++-
 1 file changed, 9 insertions(+), 147 deletions(-)

diff --git a/cde/programs/dtappbuilder/src/ab/Makefile.am b/cde/programs/dtappbuilder/src/ab/Makefile.am
index f54178d1e..c4048c7f6 100644
--- a/cde/programs/dtappbuilder/src/ab/Makefile.am
+++ b/cde/programs/dtappbuilder/src/ab/Makefile.am
@@ -6,16 +6,21 @@ ABINCLUDES = -I../include -I../include/ab_private -I../libABil
 
 bin_PROGRAMS = dtbuilder
 
+BUILT_SOURCES = dtbuilder.h dtbuilder.c about_box_ui.h appfw_ui.h \
+		attch_ed_ui.h brws_ui.h button_ui.h cgen_env_ui.h \
+		choice_ui.h color_chooser_ui.h combobox_ui.h conn_ui.h \
+		cpanel_ui.h custdlg_ui.h dnd_ed_ui.h drawp_ui.h fchooser_ui.h \
+		group_ui.h help_ed_ui.h label_ui.h list_ui.h mainwin_ui.h \
+		menu_ui.h menubar_ui.h message_ed_ui.h palette_ui.h \
+		panedwin_ed_ui.h proj_ui.h revolv_ui.h scale_ui.h sep_ui.h \
+		spinbox_ui.h termp_ui.h textf_ui.h textp_ui.h
+
 appdefaults_DATA = Dtbuilder
 
 DTCODEGENCAT = NLSPATH=$(top_builddir)/programs/dtappbuilder/src/abmf/dtcodegen.cat
 
 DTCODEGEN = $(DTCODEGENCAT) ../abmf/dtcodegen
 
-# Due to the way dtcodegen works, especially with the -merge option, we need
-# to disable parallel builds (-j) here to avoid corrupting everything.
-.NOTPARALLEL:
-
 if BSD
 UTILLIB = -lutil
 endif
@@ -190,366 +195,223 @@ if SOLARIS
 
 dtbuilder.h + dtb_utils.c + dtb_utils.h: dtbuilder.bip dtbuilder.c dtbuilder.msg
 	$(DTCODEGEN) -changed -merge -p dtbuilder.bip -main
-dtbuilder.o: dtbuilder.c dtbuilder.bip $(TARGETS.h) $(TARGETS.h.merged)
 
 PROJFILE = dtbuilder
 
 about_box_ui.c + about_box_ui.h + about_box_stubs.c: $(PROJFILE).bip about_box.bil
 	$(DTCODEGEN) -changed -merge -p $(PROJFILE).bip about_box.bil
-about_box_ui.o: about_box_ui.c about_box_ui.h about_box.bil
-about_box_stubs.o: about_box_stubs.c about_box_ui.c about_box_ui.h about_box.bil
 
 appfw_ui.c + appfw_ui.h + appfw_stubs.c: $(PROJFILE).bip appfw.bil
 	$(DTCODEGEN) -changed -merge -p $(PROJFILE).bip appfw.bil
-appfw_ui.o: appfw_ui.c appfw_ui.h appfw.bil
-appfw_stubs.o: appfw_stubs.c appfw_ui.c appfw_ui.h appfw.bil
 
 attch_ed_ui.c + attch_ed_ui.h + attch_ed_stubs.c: $(PROJFILE).bip attch_ed.bil
 	$(DTCODEGEN) -changed -merge -p $(PROJFILE).bip attch_ed.bil
-attch_ed_ui.o: attch_ed_ui.c attch_ed_ui.h attch_ed.bil
-attch_ed_stubs.o: attch_ed_stubs.c attch_ed_ui.c attch_ed_ui.h attch_ed.bil
 
 brws_ui.c + brws_ui.h + brws_stubs.c: $(PROJFILE).bip brws.bil
 	$(DTCODEGEN) -changed -merge -p $(PROJFILE).bip brws.bil
-brws_ui.o: brws_ui.c brws_ui.h brws.bil
-brws_stubs.o: brws_stubs.c brws_ui.c brws_ui.h brws.bil
 
 button_ui.c + button_ui.h + button_stubs.c: $(PROJFILE).bip button.bil
 	$(DTCODEGEN) -changed -merge -p $(PROJFILE).bip button.bil
-button_ui.o: button_ui.c button_ui.h button.bil
-button_stubs.o: button_stubs.c button_ui.c button_ui.h button.bil
 
 cgen_env_ui.c + cgen_env_ui.h + cgen_env_stubs.c: $(PROJFILE).bip cgen_env.bil
 	$(DTCODEGEN) -changed -merge -p $(PROJFILE).bip cgen_env.bil
-cgen_env_ui.o: cgen_env_ui.c cgen_env_ui.h cgen_env.bil
-cgen_env_stubs.o: cgen_env_stubs.c cgen_env_ui.c cgen_env_ui.h cgen_env.bil
 
 cgen_props_ui.c + cgen_props_ui.h + cgen_props_stubs.c: $(PROJFILE).bip cgen_props.bil
 	$(DTCODEGEN) -changed -merge -p $(PROJFILE).bip cgen_props.bil
-cgen_props_ui.o: cgen_props_ui.c cgen_props_ui.h cgen_props.bil
-cgen_props_stubs.o: cgen_props_stubs.c cgen_props_ui.c cgen_props_ui.h cgen_props.bil
 
 cgen_win_ui.c + cgen_win_ui.h + cgen_win_stubs.c: $(PROJFILE).bip cgen_win.bil
 	$(DTCODEGEN) -changed -merge -p $(PROJFILE).bip cgen_win.bil
-cgen_win_ui.o: cgen_win_ui.c cgen_win_ui.h cgen_win.bil
-cgen_win_stubs.o: cgen_win_stubs.c cgen_win_ui.c cgen_win_ui.h cgen_win.bil
 
 choice_ui.c + choice_ui.h + choice_stubs.c: $(PROJFILE).bip choice.bil
 	$(DTCODEGEN) -changed -merge -p $(PROJFILE).bip choice.bil
-choice_ui.o: choice_ui.c choice_ui.h choice.bil
-choice_stubs.o: choice_stubs.c choice_ui.c choice_ui.h choice.bil
 
 color_chooser_ui.c + color_chooser_ui.h + color_chooser_stubs.c: $(PROJFILE).bip color_chooser.bil
 	$(DTCODEGEN) -changed -merge -p $(PROJFILE).bip color_chooser.bil
-color_chooser_ui.o: color_chooser_ui.c color_chooser_ui.h color_chooser.bil
-color_chooser_stubs.o: color_chooser_stubs.c color_chooser_ui.c color_chooser_ui.h color_chooser.bil
 
 combobox_ui.c + combobox_ui.h + combobox_stubs.c: $(PROJFILE).bip combobox.bil
 	$(DTCODEGEN) -changed -merge -p $(PROJFILE).bip combobox.bil
-combobox_ui.o: combobox_ui.c combobox_ui.h combobox.bil
-combobox_stubs.o: combobox_stubs.c combobox_ui.c combobox

[cdesktopenv-devel] dthelp/parser/pass2: make it build

[Chase via cdesktopenv-devel]

Well thats it for dthelp, the final boss seems to be dtinfo, seems extremely 
complicated from the glance I took at it...

Thank you for your time,
-ChaseFrom e63a070a4a101c816d3d7a442f0b5ad2c81591da Mon Sep 17 00:00:00 2001
From: Chase 
Date: Mon, 15 Feb 2021 21:31:52 -0600
Subject: [PATCH] dthelp/parser/pass2: make it build

---
 cde/.gitignore| 41 ++
 cde/configure.ac  |  6 ++
 cde/programs/dthelp/parser/Makefile.am|  4 +-
 .../dthelp/parser/pass2/build/Makefile.am | 56 +++
 .../dthelp/parser/pass2/eltdef/Makefile.am| 52 +
 .../dthelp/parser/pass2/htag2/Makefile.am | 42 ++
 .../dthelp/parser/pass2/parser/Makefile.am| 50 +
 .../dthelp/parser/pass2/util/Makefile.am  | 21 +++
 8 files changed, 269 insertions(+), 3 deletions(-)
 create mode 100644 cde/programs/dthelp/parser/pass2/build/Makefile.am
 create mode 100644 cde/programs/dthelp/parser/pass2/eltdef/Makefile.am
 create mode 100644 cde/programs/dthelp/parser/pass2/htag2/Makefile.am
 create mode 100644 cde/programs/dthelp/parser/pass2/parser/Makefile.am
 create mode 100644 cde/programs/dthelp/parser/pass2/util/Makefile.am

diff --git a/cde/.gitignore b/cde/.gitignore
index 4972fbb7b..5c9269386 100644
--- a/cde/.gitignore
+++ b/cde/.gitignore
@@ -598,6 +598,47 @@ programs/dthelp/parser/pass1/parser/dthelp_htag1
 programs/dthelp/parser/pass1/parser/error
 programs/dthelp/parser/pass1/util/context
 programs/dthelp/parser/pass1/util/fclndir
+programs/dthelp/parser/pass2/build/arc.h
+programs/dthelp/parser/pass2/build/build
+programs/dthelp/parser/pass2/build/case.c
+programs/dthelp/parser/pass2/build/context.h
+programs/dthelp/parser/pass2/build/delim.dat
+programs/dthelp/parser/pass2/build/delim.h
+programs/dthelp/parser/pass2/build/dtd.h
+programs/dthelp/parser/pass2/build/entity.h
+programs/dthelp/parser/pass2/build/error
+programs/dthelp/parser/pass2/build/template
+programs/dthelp/parser/pass2/eltdef/case.c
+programs/dthelp/parser/pass2/eltdef/context.h
+programs/dthelp/parser/pass2/eltdef/delim.dat
+programs/dthelp/parser/pass2/eltdef/delim.h
+programs/dthelp/parser/pass2/eltdef/efile.c
+programs/dthelp/parser/pass2/eltdef/eltdef
+programs/dthelp/parser/pass2/eltdef/entfile.c
+programs/dthelp/parser/pass2/eltdef/entity2.h
+programs/dthelp/parser/pass2/eltdef/error
+programs/dthelp/parser/pass2/eltdef/estring.h
+programs/dthelp/parser/pass2/eltdef/globdec.h
+programs/dthelp/parser/pass2/eltdef/globdef.h
+programs/dthelp/parser/pass2/eltdef/if.h
+programs/dthelp/parser/pass2/eltdef/pfile.c
+programs/dthelp/parser/pass2/eltdef/pval.h
+programs/dthelp/parser/pass2/eltdef/sfile.c
+programs/dthelp/parser/pass2/eltdef/signon.h
+programs/dthelp/parser/pass2/eltdef/signonx.h
+programs/dthelp/parser/pass2/eltdef/stfile.c
+programs/dthelp/parser/pass2/eltdef/tfile.c
+programs/dthelp/parser/pass2/htag2/LocaleXlate.c
+programs/dthelp/parser/pass2/htag2/XlationSvc.c
+programs/dthelp/parser/pass2/parser/dthelp_htag2
+programs/dthelp/parser/pass2/parser/case.c
+programs/dthelp/parser/pass2/parser/context.h
+programs/dthelp/parser/pass2/parser/delim.dat
+programs/dthelp/parser/pass2/parser/delim.h
+programs/dthelp/parser/pass2/parser/error
+programs/dthelp/parser/pass2/parser/parser
+programs/dthelp/parser/pass2/util/context
+programs/dthelp/parser/pass2/util/fclndir
 programs/dthelp/parser/helptag/dthelptag
 
 # programs/dtinfo
diff --git a/cde/configure.ac b/cde/configure.ac
index 969faa1ff..45fb04a98 100644
--- a/cde/configure.ac
+++ b/cde/configure.ac
@@ -526,6 +526,12 @@ programs/dthelp/parser/canon1/build/Makefile
 programs/dthelp/parser/canon1/eltdef/Makefile
 programs/dthelp/parser/canon1/helptag/Makefile
 programs/dthelp/parser/canon1/parser/Makefile
+programs/dthelp/parser/pass2/Makefile
+programs/dthelp/parser/pass2/util/Makefile
+programs/dthelp/parser/pass2/build/Makefile
+programs/dthelp/parser/pass2/eltdef/Makefile
+programs/dthelp/parser/pass2/htag2/Makefile
+programs/dthelp/parser/pass2/parser/Makefile
 programs/dthelp/parser/helptag/Makefile
 
 programs/nsgmls/Makefile
diff --git a/cde/programs/dthelp/parser/Makefile.am b/cde/programs/dthelp/parser/Makefile.am
index af5381c79..4e0157e31 100644
--- a/cde/programs/dthelp/parser/Makefile.am
+++ b/cde/programs/dthelp/parser/Makefile.am
@@ -1,5 +1,3 @@
 MAINTAINERCLEANFILES = Makefile.in
 
-SUBDIRS = pass1 canon1 helptag
-
-#NOTYET pass2
+SUBDIRS = pass1 canon1 pass2 helptag
diff --git a/cde/programs/dthelp/parser/pass2/build/Makefile.am b/cde/programs/dthelp/parser/pass2/build/Makefile.am
new file mode 100644
index 0..582bb0f43
--- /dev/null
+++ b/cde/programs/dthelp/parser/pass2/build/Makefile.am
@@ -0,0 +1,56 @@
+MAINTAINERCLEANFILES = Makefile.in
+
+noinst_PROGRAMS = build
+
+HTAG2   = ..
+HTAG2SRC= $(HTAG2)/htag2
+SDLPARSERSRC = $(HTAG2)/parser
+SDLELTDEFSRC = $(HTAG2)/eltdef
+SDLDTDFILE   = $(HTAG2SRC)/sdl.dtd
+SDLUTILSRC

[cdesktopenv-devel] dthelp/parser/canon1: make it build

[Chase via cdesktopenv-devel]

Title is self explainatory.

Thank you for your time,
-ChaseFrom 04a7b4c8e33c721453c2e0cc311d96460e8d8f1b Mon Sep 17 00:00:00 2001
From: Chase 
Date: Mon, 15 Feb 2021 19:27:54 -0600
Subject: [PATCH] dthelp/parser/canon1: get it to build

---
 cde/.gitignore| 41 ++
 cde/configure.ac  |  6 ++
 cde/programs/dthelp/parser/Makefile.am|  4 +-
 .../dthelp/parser/canon1/build/Makefile.am| 55 +++
 .../dthelp/parser/canon1/eltdef/Makefile.am   | 53 ++
 .../dthelp/parser/canon1/helptag/Makefile.am  | 43 +++
 .../dthelp/parser/canon1/parser/Makefile.am   | 49 +
 .../dthelp/parser/canon1/util/Makefile.am | 21 +++
 8 files changed, 270 insertions(+), 2 deletions(-)
 create mode 100644 cde/programs/dthelp/parser/canon1/build/Makefile.am
 create mode 100644 cde/programs/dthelp/parser/canon1/eltdef/Makefile.am
 create mode 100644 cde/programs/dthelp/parser/canon1/helptag/Makefile.am
 create mode 100644 cde/programs/dthelp/parser/canon1/parser/Makefile.am
 create mode 100644 cde/programs/dthelp/parser/canon1/util/Makefile.am

diff --git a/cde/.gitignore b/cde/.gitignore
index 35e050793..4972fbb7b 100644
--- a/cde/.gitignore
+++ b/cde/.gitignore
@@ -517,6 +517,47 @@ programs/dtexec/DtSvcLock.h
 programs/dtexec/MsgLog.c
 
 # programs/dthelp
+programs/dthelp/parser/canon1/build/arc.h
+programs/dthelp/parser/canon1/build/build
+programs/dthelp/parser/canon1/build/case.c
+programs/dthelp/parser/canon1/build/context.h
+programs/dthelp/parser/canon1/build/delim.dat
+programs/dthelp/parser/canon1/build/delim.h
+programs/dthelp/parser/canon1/build/dtd.h
+programs/dthelp/parser/canon1/build/entity.h
+programs/dthelp/parser/canon1/build/error
+programs/dthelp/parser/canon1/build/template
+programs/dthelp/parser/canon1/eltdef/case.c
+programs/dthelp/parser/canon1/eltdef/context.h
+programs/dthelp/parser/canon1/eltdef/delim.dat
+programs/dthelp/parser/canon1/eltdef/delim.h
+programs/dthelp/parser/canon1/eltdef/efile.c
+programs/dthelp/parser/canon1/eltdef/eltdef
+programs/dthelp/parser/canon1/eltdef/entfile.c
+programs/dthelp/parser/canon1/eltdef/entity2.h
+programs/dthelp/parser/canon1/eltdef/error
+programs/dthelp/parser/canon1/eltdef/estring.h
+programs/dthelp/parser/canon1/eltdef/globdec.h
+programs/dthelp/parser/canon1/eltdef/globdef.h
+programs/dthelp/parser/canon1/eltdef/if.h
+programs/dthelp/parser/canon1/eltdef/pfile.c
+programs/dthelp/parser/canon1/eltdef/pval.h
+programs/dthelp/parser/canon1/eltdef/sfile.c
+programs/dthelp/parser/canon1/eltdef/signon.h
+programs/dthelp/parser/canon1/eltdef/signonx.h
+programs/dthelp/parser/canon1/eltdef/stfile.c
+programs/dthelp/parser/canon1/eltdef/tfile.c
+programs/dthelp/parser/canon1/helptag/LocaleXlate.c
+programs/dthelp/parser/canon1/helptag/XlationSvc.c
+programs/dthelp/parser/canon1/parser/dthelp_ctag1
+programs/dthelp/parser/canon1/parser/case.c
+programs/dthelp/parser/canon1/parser/context.h
+programs/dthelp/parser/canon1/parser/delim.dat
+programs/dthelp/parser/canon1/parser/delim.h
+programs/dthelp/parser/canon1/parser/error
+programs/dthelp/parser/canon1/parser/parser
+programs/dthelp/parser/canon1/util/context
+programs/dthelp/parser/canon1/util/fclndir
 programs/dthelp/parser/pass1/build/arc.h
 programs/dthelp/parser/pass1/build/build
 programs/dthelp/parser/pass1/build/case.c
diff --git a/cde/configure.ac b/cde/configure.ac
index 9d30ce995..969faa1ff 100644
--- a/cde/configure.ac
+++ b/cde/configure.ac
@@ -520,6 +520,12 @@ programs/dthelp/parser/pass1/build/Makefile
 programs/dthelp/parser/pass1/eltdef/Makefile
 programs/dthelp/parser/pass1/helptag/Makefile
 programs/dthelp/parser/pass1/parser/Makefile
+programs/dthelp/parser/canon1/Makefile
+programs/dthelp/parser/canon1/util/Makefile
+programs/dthelp/parser/canon1/build/Makefile
+programs/dthelp/parser/canon1/eltdef/Makefile
+programs/dthelp/parser/canon1/helptag/Makefile
+programs/dthelp/parser/canon1/parser/Makefile
 programs/dthelp/parser/helptag/Makefile
 
 programs/nsgmls/Makefile
diff --git a/cde/programs/dthelp/parser/Makefile.am b/cde/programs/dthelp/parser/Makefile.am
index 549ce80f6..af5381c79 100644
--- a/cde/programs/dthelp/parser/Makefile.am
+++ b/cde/programs/dthelp/parser/Makefile.am
@@ -1,5 +1,5 @@
 MAINTAINERCLEANFILES = Makefile.in
 
-SUBDIRS = pass1 helptag
+SUBDIRS = pass1 canon1 helptag
 
-#NOTYET canon1 pass2
+#NOTYET pass2
diff --git a/cde/programs/dthelp/parser/canon1/build/Makefile.am b/cde/programs/dthelp/parser/canon1/build/Makefile.am
new file mode 100644
index 0..e82964b05
--- /dev/null
+++ b/cde/programs/dthelp/parser/canon1/build/Makefile.am
@@ -0,0 +1,55 @@
+MAINTAINERCLEANFILES = Makefile.in
+
+noinst_PROGRAMS = build
+
+HELPTAG   = ..
+HELPTAGSRC= $(HELPTAG)/helptag
+HELPPARSERSRC = $(HELPTAG)/parser
+HELPELTDEFSRC = $(HELPTAG)/eltdef
+HELPDTDFILE   = $(HELPTAGSRC)/hptag.dtd
+HELPUTILSRC   = $(HELPTAG)/util
+HELPBUILDSRC  = $(

[cdesktopenv-devel] [PATCH] dtksh: allow parallel building

[Chase via cdesktopenv-devel]

This patch allows dtksh to be built in parallel in the autotools branch.

Thank you for your time,
-ChaseFrom 733dd2cff4a860dc8e3d4970e91a6139a560fa36 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Fri, 12 Feb 2021 10:06:33 -0600
Subject: [PATCH] dtksh: allow parallel building

---
 cde/.gitignore |  1 +
 cde/programs/dtksh/Makefile.am | 12 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/cde/.gitignore b/cde/.gitignore
index c08a0282a..35e050793 100644
--- a/cde/.gitignore
+++ b/cde/.gitignore
@@ -829,6 +829,7 @@ programs/dtinfo/tools/misc/treeres
 programs/dtksh/FEATURE
 programs/dtksh/dtksh
 programs/dtksh/init.c
+programs/dtksh/DtFuncs.dtsh
 programs/dtksh/examples/CallDataTest4
 programs/dtksh/examples/CallbackTest2
 programs/dtksh/examples/DtCursorTest2
diff --git a/cde/programs/dtksh/Makefile.am b/cde/programs/dtksh/Makefile.am
index 7cc303ae3..098c71e2a 100644
--- a/cde/programs/dtksh/Makefile.am
+++ b/cde/programs/dtksh/Makefile.am
@@ -1,9 +1,6 @@
 MAINTAINERCLEANFILES = Makefile.in
 
-# Can't build multi-core in here yet.
-.NOTPARALLEL:
-
-CLEANFILES = init.c FEATURE
+CLEANFILES = init.c FEATURE DtFuncs.dtsh
 
 SUBDIRS = examples
 
@@ -21,6 +18,8 @@ KSH93LIBSHELL = $(KSH93SRC)/lib/libshell.a
 
 bin_PROGRAMS = dtksh
 
+BUILT_SOURCES = init.c
+
 dtksh_CPPFLAGS = -I$(KSH93SRC)/include/ast -I$(KSH93SRC)/src/cmd/ksh93/include \
 		 -I$(KSH93SRC)/src/cmd/ksh93 -I${srcdir}/lib/DtPrint \
 		 -I${srcdir}/lib/DtHelp '-DAST_VERSION=2011' \
@@ -70,10 +69,11 @@ init.c:
 
 libshell.a: $(KSH93SLIBSHELL) dtksh-init.o
 	$(CP) $(KSH93LIBSHELL) libshell.a; \
-	ar d libshell.a init.o; \
+	$(AR) d libshell.a init.o; \
 	$(AR) cq libshell.a dtksh-init.o
 
 clean-local:
-	cd ksh93 && ./bin/package clean
+	cd ksh93 && ./bin/package flat clean
 
 DtFuncs.dtsh:
+	$(CP) DtFuncs.sh DtFuncs.dtsh
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] make ttsnoop build under autotools

[Chase via cdesktopenv-devel]

Attempt #2, this time properly tested with parallel building

Thank you for your time,
-ChaseFrom 652de3d0cb01506d922538e0acaa1be4f51ab639 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Wed, 10 Feb 2021 16:28:52 -0600
Subject: [PATCH] ttsnoop: make it build under autotools

---
 cde/.gitignore   |   1 +
 cde/configure.ac |   2 +
 cde/programs/Makefile.am |   4 +-
 cde/programs/ttsnoop/Makefile.am | 178 +++
 4 files changed, 183 insertions(+), 2 deletions(-)
 create mode 100644 cde/programs/ttsnoop/Makefile.am

diff --git a/cde/.gitignore b/cde/.gitignore
index f3a8815d0..c08a0282a 100644
--- a/cde/.gitignore
+++ b/cde/.gitignore
@@ -7,6 +7,7 @@
 
 # Backups and editor created backups
 *.bak
+*.BAK
 *~
 .depend
 
diff --git a/cde/configure.ac b/cde/configure.ac
index 800d03eb4..9d30ce995 100644
--- a/cde/configure.ac
+++ b/cde/configure.ac
@@ -613,6 +613,8 @@ programs/fontaliases/freebsd/C/Makefile
 
 programs/dtdspmsg/Makefile
 
+programs/ttsnoop/Makefile
+
 programs/dtimsstart/Makefile
 
 programs/dtpdm/Makefile
diff --git a/cde/programs/Makefile.am b/cde/programs/Makefile.am
index 4c3dcd435..0cd943da0 100644
--- a/cde/programs/Makefile.am
+++ b/cde/programs/Makefile.am
@@ -4,7 +4,7 @@ SUBDIRS = backdrops icons dsdm dtmail dtpad dtfile dtwm dtlogin \
 dtsession dthello dtstyle dtexec dtdbcache dticon dtterm dtcalc \
 	dtaction dtspcd dtscreen dtksh dtcm dtsearchpath dtappbuilder palettes \
 	dtappintegrate dtprintegrate dtconfig dtcreate dtprintinfo fontaliases \
-	dtdspmsg dtimsstart dtpdm dtsr dtpdmd types \
+	dtdspmsg ttsnoop dtimsstart dtpdm dtsr dtpdmd types \
 	tttypes util dtopen localized dthelp nsgmls dtdocbook
 
-# NOTYET =dtinfo ttsnoop
+# NOTYET = dtinfo
diff --git a/cde/programs/ttsnoop/Makefile.am b/cde/programs/ttsnoop/Makefile.am
new file mode 100644
index 0..bbb52594a
--- /dev/null
+++ b/cde/programs/ttsnoop/Makefile.am
@@ -0,0 +1,178 @@
+MAINTAINERCLEANFILES = Makefile.in
+
+appdefaultsdir = $(CDE_INSTALLATION_TOP)/app-defaults/C
+
+dist_appdefaults_DATA = Ttsnoop
+
+AB_MAKEFILES = \
+	Makefile.aix \
+	Makefile.hpux \
+	Makefile.sunos \
+	Makefile.linux \
+	Makefile.freebsd \
+	Makefile.netbsd \
+	Makefile.openbsd
+
+DTCODEGENCAT = NLSPATH=$(top_builddir)/programs/dtappbuilder/src/abmf/dtcodegen.cat
+
+DTCODEGEN = $(DTCODEGENCAT) $(top_builddir)/programs/dtappbuilder/src/abmf/dtcodegen
+
+CLEANFILES = Ttsnoop .dtcodegen.log *.BAK *.delta *.patched $(AB_MAKEFILES) \
+	 *_stubs.C *_ui.c
+
+.NOTPARALLEL:
+
+bin_PROGRAMS = ttsnoop
+
+ttsnoop_LDADD = $(DTCLIENTLIBS) $(XTOOLLIB) $(LIBTERM)
+
+BUILT_SOURCES = ttsnoop_ui.h apiTracer_ui.h ttChooser_ui.h patternProps_ui.h \
+		stringChooser_ui.h messageProps_ui.h sessionChooser_ui.h \
+		fileChooser_ui.h argChooser_ui.h callbackChooser_ui.h \
+		ttsnoop.h
+
+ttsnoop_SOURCES = stringChooser_stubs.C ttChooser_stubs.C \
+		  ttsnoop_ui.c 		apiTracer_stubs.C \
+		  argChooser_stubs.C 	callbackChooser_stubs.C \
+		  fileChooser_stubs.C 	messageProps_stubs.C \
+	   	  patternProps_stubs.C 	sessionChooser_stubs.C \
+		  ttsnoop.C 		ttsnoop_stubs.C \
+	  	  apiTracer_ui.c	argChooser_ui.c \
+		  callbackChooser_ui.c  dtb_utils.c \
+		  fileChooser_ui.c  messageProps_ui.c \
+		  patternProps_ui.c sessionChooser_ui.c \
+		  stringChooser_ui.cttChooser_ui.c \
+	 	  tt_c++.C 		DtTt.C
+
+ttsnoop_ui.c ttsnoop_ui.h ttsnoop_stubs.C: ttsnoop.bip ttsnoop.bil ttsnoop_stubs.C.src
+	$(CP) ttsnoop_stubs.C.src ttsnoop_stubs.c
+	-if [ ! -w ttsnoop_stubs.c ]; then \
+		chmod +w ttsnoop_stubs.c; fi
+	$(DTCODEGEN) -changed -merge -p ttsnoop.bip ttsnoop.bil
+	$(RM) ttsnoop_stubs.C
+	mv ttsnoop_stubs.c ttsnoop_stubs.C
+	cat externC.h ttsnoop_ui.h closeBrace.h > ttsnoop_ui.h.patched
+	mv ttsnoop_ui.h.patched ttsnoop_ui.h
+	$(SED) \
+	-e 's/^DtbTt/extern String snooperArgv[];DtbTt/' \
+	-e 's/XmNheight, 257,//' \
+	-e 's/XmNwidth, 580,//' \
+	-e 's/XmNcolumns, 80,//' \
+	-e 's/XmNrows, 24/DtNsubprocessArgv, snooperArgv/' \
+	ttsnoop_ui.c > ttsnoop_ui.c.patched
+	mv ttsnoop_ui.c.patched ttsnoop_ui.c
+
+apiTracer_ui.c apiTracer_ui.h apiTracer_stubs.C: ttsnoop.bip apiTracer.bil apiTracer_stubs.C.src
+	$(CP) apiTracer_stubs.C.src apiTracer_stubs.c
+	-if [ ! -w apiTracer_stubs.c ]; then \
+		chmod +w apiTracer_stubs.c; fi
+	$(DTCODEGEN) -changed -merge -p ttsnoop.bip apiTracer.bil
+	$(RM) apiTracer_stubs.C
+	mv apiTracer_stubs.c apiTracer_stubs.C
+	cat externC.h apiTracer_ui.h closeBrace.h > apiTracer_ui.h.patched
+	mv apiTracer_ui.h.patched apiTracer_ui.h
+	$(SED) -e 's/^DtbApi/extern String apiTracerArgv[];DtbApi/' \
+	-e 's/XmNrows, 24/XmNrows, 24, DtNsubprocessArgv, apiTracerArgv/' \
+	apiTracer_ui.c > apiTracer_ui.c.patched
+	mv apiTracer_ui.c.patched apiTracer_ui.c
+
+ttChooser_ui.c ttChooser_ui.h ttChooser_stubs.C: ttsnoop.bip ttChooser.bil ttChooser_stubs.C.src
+	$(CP) ttChooser_stubs.C.src ttChooser_stubs.c
+	-if [ ! -w ttChooser_stubs.c ]; then \
+		chmod +w ttChooser_st

Re: [cdesktopenv-devel] Setting custom wallpaper on other workspaces

[Chase via cdesktopenv-devel]

Hello,
Please take a look at the wiki article for backdrops: 
https://sourceforge.net/p/cdesktopenv/wiki/Setting%20Your%20Own%20Backdrop/


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Wednesday, February 10, 2021 4:02 AM, cyrus torros 
 wrote:

> I am looking for a way to set a custom backdrop on workspaces 2, 3,
> and 4. Tools like nitrogen don't seem to be capable of it? Is it not
> possible/
>
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] dthelp/parser/helptag: build under autotools

[Chase via cdesktopenv-devel]

So, this was an easy task, however, I do not think that I am capable of doing 
the rest of dthelp, is is some complex stuff. As for dtinfo, I still need to 
investigate it more...

Thank you for your time,
-ChaseFrom 1504a82780e979262249263d56077ec8f024404f Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sun, 7 Feb 2021 14:48:51 -0600
Subject: [PATCH] dthelp/parser/helptag: build under autotools

---
 cde/.gitignore | 1 +
 cde/configure.ac   | 1 +
 cde/programs/dthelp/parser/Makefile.am | 4 ++--
 cde/programs/dthelp/parser/helptag/Makefile.am | 8 
 cde/programs/dthelp/parser/helptag/helptag.cpp | 0
 5 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 cde/programs/dthelp/parser/helptag/Makefile.am
 mode change 100755 => 100644 cde/programs/dthelp/parser/helptag/helptag.cpp

diff --git a/cde/.gitignore b/cde/.gitignore
index 03da06818..f3a8815d0 100644
--- a/cde/.gitignore
+++ b/cde/.gitignore
@@ -556,6 +556,7 @@ programs/dthelp/parser/pass1/parser/dthelp_htag1
 programs/dthelp/parser/pass1/parser/error
 programs/dthelp/parser/pass1/util/context
 programs/dthelp/parser/pass1/util/fclndir
+programs/dthelp/parser/helptag/dthelptag
 
 # programs/dtinfo
 programs/dtinfo/clients/dtinfo_start/dtinfo_start
diff --git a/cde/configure.ac b/cde/configure.ac
index a2a2779ca..9d30ce995 100644
--- a/cde/configure.ac
+++ b/cde/configure.ac
@@ -520,6 +520,7 @@ programs/dthelp/parser/pass1/build/Makefile
 programs/dthelp/parser/pass1/eltdef/Makefile
 programs/dthelp/parser/pass1/helptag/Makefile
 programs/dthelp/parser/pass1/parser/Makefile
+programs/dthelp/parser/helptag/Makefile
 
 programs/nsgmls/Makefile
 
diff --git a/cde/programs/dthelp/parser/Makefile.am b/cde/programs/dthelp/parser/Makefile.am
index 4e38114c9..549ce80f6 100644
--- a/cde/programs/dthelp/parser/Makefile.am
+++ b/cde/programs/dthelp/parser/Makefile.am
@@ -1,5 +1,5 @@
 MAINTAINERCLEANFILES = Makefile.in
 
-SUBDIRS = pass1
+SUBDIRS = pass1 helptag
 
-#NOTYET canon1 pass2 helptag misc dtds
+#NOTYET canon1 pass2
diff --git a/cde/programs/dthelp/parser/helptag/Makefile.am b/cde/programs/dthelp/parser/helptag/Makefile.am
new file mode 100644
index 0..910fd7bfe
--- /dev/null
+++ b/cde/programs/dthelp/parser/helptag/Makefile.am
@@ -0,0 +1,8 @@
+MAINTAINERCLEANFILES = Makefile.in
+
+bin_SCRIPTS = dthelptag
+
+dthelptag: helptag.cpp
+	$(RM) $@
+	$(GENCPP) -P -DXCOMM=# $(LOCAL_CPP_DEFINES) $< > $@
+	chmod +x $@
diff --git a/cde/programs/dthelp/parser/helptag/helptag.cpp b/cde/programs/dthelp/parser/helptag/helptag.cpp
old mode 100755
new mode 100644
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] make ttsnoop build under autotools

[Chase via cdesktopenv-devel]

Only two programs left...

Thank you for your time,
-ChaseFrom 51e10c0b4c5b7c980ea48e7e0181e75c7a5bbf9b Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sun, 7 Feb 2021 09:37:41 -0600
Subject: [PATCH] ttsnoop: make it build under autotools

---
 cde/configure.ac |   2 +
 cde/programs/Makefile.am |   4 +-
 cde/programs/ttsnoop/Makefile.am | 172 +++
 3 files changed, 176 insertions(+), 2 deletions(-)
 create mode 100644 cde/programs/ttsnoop/Makefile.am

diff --git a/cde/configure.ac b/cde/configure.ac
index 2a8bfacd5..a2a2779ca 100644
--- a/cde/configure.ac
+++ b/cde/configure.ac
@@ -612,6 +612,8 @@ programs/fontaliases/freebsd/C/Makefile
 
 programs/dtdspmsg/Makefile
 
+programs/ttsnoop/Makefile
+
 programs/dtimsstart/Makefile
 
 programs/dtpdm/Makefile
diff --git a/cde/programs/Makefile.am b/cde/programs/Makefile.am
index 4c3dcd435..0cd943da0 100644
--- a/cde/programs/Makefile.am
+++ b/cde/programs/Makefile.am
@@ -4,7 +4,7 @@ SUBDIRS = backdrops icons dsdm dtmail dtpad dtfile dtwm dtlogin \
 dtsession dthello dtstyle dtexec dtdbcache dticon dtterm dtcalc \
 	dtaction dtspcd dtscreen dtksh dtcm dtsearchpath dtappbuilder palettes \
 	dtappintegrate dtprintegrate dtconfig dtcreate dtprintinfo fontaliases \
-	dtdspmsg dtimsstart dtpdm dtsr dtpdmd types \
+	dtdspmsg ttsnoop dtimsstart dtpdm dtsr dtpdmd types \
 	tttypes util dtopen localized dthelp nsgmls dtdocbook
 
-# NOTYET =dtinfo ttsnoop
+# NOTYET = dtinfo
diff --git a/cde/programs/ttsnoop/Makefile.am b/cde/programs/ttsnoop/Makefile.am
new file mode 100644
index 0..de6d394c5
--- /dev/null
+++ b/cde/programs/ttsnoop/Makefile.am
@@ -0,0 +1,172 @@
+MAINTAINERCLEANFILES = Makefile.in
+
+appdefaultsdir = $(CDE_INSTALLATION_TOP)/app-defaults/C
+
+dist_appdefaults_DATA = Ttsnoop
+
+AB_MAKEFILES = \
+	Makefile.aix \
+	Makefile.hpux \
+	Makefile.sunos \
+	Makefile.linux \
+	Makefile.freebsd \
+	Makefile.netbsd \
+	Makefile.openbsd
+
+DTCODEGENCAT = NLSPATH=$(top_builddir)/programs/dtappbuilder/src/abmf/dtcodegen.cat
+
+DTCODEGEN = $(DTCODEGENCAT) $(top_builddir)/programs/dtappbuilder/src/abmf/dtcodegen
+
+CLEANFILES = Ttsnoop .dtcodegen.log *.BAK *.delta *.patched $(AB_MAKEFILES)
+
+.NOTPARALLEL:
+
+bin_PROGRAMS = ttsnoop
+
+ttsnoop_LDADD = $(DTCLIENTLIBS) $(XTOOLLIB) $(LIBTERM)
+
+ttsnoop_SOURCES = stringChooser_stubs.C ttChooser_stubs.C \
+		  ttsnoop_ui.c 		apiTracer_stubs.C \
+		  argChooser_stubs.C 	callbackChooser_stubs.C \
+		  fileChooser_stubs.C 	messageProps_stubs.C \
+	   	  patternProps_stubs.C 	sessionChooser_stubs.C \
+		  ttsnoop.C 		ttsnoop_stubs.C \
+	  	  apiTracer_ui.cargChooser_ui.c \
+	  callbackChooser_ui.c  dtb_utils.c \
+	  fileChooser_ui.c  messageProps_ui.c \
+	  patternProps_ui.c sessionChooser_ui.c \
+	  stringChooser_ui.cttChooser_ui.c \
+ 	  tt_c++.C 		DtTt.C
+
+ttsnoop_ui.c ttsnoop_ui.h ttsnoop_stubs.C: ttsnoop.bip ttsnoop.bil ttsnoop_stubs.C.src
+	$(CP) ttsnoop_stubs.C.src ttsnoop_stubs.c
+	-if [ ! -w ttsnoop_stubs.c ]; then \
+		chmod +w ttsnoop_stubs.c; fi
+	$(DTCODEGEN) -changed -merge -p ttsnoop.bip ttsnoop.bil
+	$(RM) ttsnoop_stubs.C
+	mv ttsnoop_stubs.c ttsnoop_stubs.C
+	cat externC.h ttsnoop_ui.h closeBrace.h > ttsnoop_ui.h.patched
+	mv ttsnoop_ui.h.patched ttsnoop_ui.h
+	$(SED) \
+	-e 's/^DtbTt/extern String snooperArgv[];DtbTt/' \
+	-e 's/XmNheight, 257,//' \
+	-e 's/XmNwidth, 580,//' \
+	-e 's/XmNcolumns, 80,//' \
+	-e 's/XmNrows, 24/DtNsubprocessArgv, snooperArgv/' \
+	ttsnoop_ui.c > ttsnoop_ui.c.patched
+	mv ttsnoop_ui.c.patched ttsnoop_ui.c
+
+apiTracer_ui.c apiTracer_ui.h apiTracer_stubs.C: ttsnoop.bip apiTracer.bil apiTracer_stubs.C.src
+	$(CP) apiTracer_stubs.C.src apiTracer_stubs.c
+	-if [ ! -w apiTracer_stubs.c ]; then \
+		chmod +w apiTracer_stubs.c; fi
+	$(DTCODEGEN) -changed -merge -p ttsnoop.bip apiTracer.bil
+	$(RM) apiTracer_stubs.C
+	mv apiTracer_stubs.c apiTracer_stubs.C
+	cat externC.h apiTracer_ui.h closeBrace.h > apiTracer_ui.h.patched
+	mv apiTracer_ui.h.patched apiTracer_ui.h
+	$(SED) -e 's/^DtbApi/extern String apiTracerArgv[];DtbApi/' \
+	-e 's/XmNrows, 24/XmNrows, 24, DtNsubprocessArgv, apiTracerArgv/' \
+	apiTracer_ui.c > apiTracer_ui.c.patched
+	mv apiTracer_ui.c.patched apiTracer_ui.c
+
+ttChooser_ui.c ttChooser_ui.h ttChooser_stubs.C: ttsnoop.bip ttChooser.bil ttChooser_stubs.C.src
+	$(CP) ttChooser_stubs.C.src ttChooser_stubs.c
+	-if [ ! -w ttChooser_stubs.c ]; then \
+		chmod +w ttChooser_stubs.c; fi
+	$(DTCODEGEN) -changed -merge -p ttsnoop.bip ttChooser.bil
+	$(RM) ttChooser_stubs.C
+	mv ttChooser_stubs.c ttChooser_stubs.C
+	cat externC.h ttChooser_ui.h closeBrace.h > ttChooser_ui.h.patched
+	mv ttChooser_ui.h.patched ttChooser_ui.h
+
+patternProps_ui.c patternProps_ui.h patternProps_stubs.C: ttsnoop.bip patternProps.bil patternProps_stubs.C.src
+	$(CP) patternProps_stubs.C.src patternProps_stubs.c
+	-if [ ! -w patternProps_stubs.c ]; then \
+		chmod +w patternPro

Re: [cdesktopenv-devel] Parallel build support for Imake

[Chase via cdesktopenv-devel]

My purpose is not to decrease supported operating systems with the introduction 
of automake. Automake was (at least in theory) supposed to be a build system 
that we wouldn't have to maintain ourselves with the most supported operating 
systems that could be build projects without the tools even being installed, 
plus features like cross compiling, custom directory installation and in line 
changing of compilers and other resources that would require the user to change 
the config file with automake. If older versions of GNU make and autoconf work 
for you to build CDE, then what is the issue? We could simply just make sure we 
don't introduce any features that were implemented after a certain release. Its 
either that or you tell GNU about the issues. They advertise everything from 
AIX3 to z/OS unix being supported, so it would really make me scratch my head 
if they suddenly decided they didn't want to do compatibility with old 
operating systems anymore.


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Saturday, February 6, 2021 4:08 PM, Lev  wrote:

> Hi Chase,
>
> I am not sure what behavior GNU is expecting, but older releases of GNU make 
> and autoconf worked fine. It seems that if the purpose of autoconf is 
> increased portability, the onus should be on them to repair breakages, not on 
> vendors who have customers demanding compatibility with decades old UNIX 
> behavior. Ultimately the choice is yours if these systems are worth 
> supporting or not, but if CDE is going to drop support, why not switch to 
> something like meson, which is where Xorg is going? Most projects are trying 
> to migrate away from autoconf to cmake, meson, etc.
>
> Kind regards,
> Lev
>
> > On Feb 6, 2021, at 14:40, Chase nicetry...@protonmail.ch wrote:
> > Keyword directory. An empty argument != directory. I have a hard time 
> > believing that Xinuos would let their OS become unusable for automake, have 
> > you emailed them at all about the issues you've been facing?
> > Thank you for your time,
> > -Chase
> > ‐‐‐ Original Message ‐‐‐
> > On Saturday, February 6, 2021 3:30 PM, Lev int...@mailbox.org wrote:
> >
> > > Hi Chase,
> > > I just tried to build GNU make on UnixWare and it errors out right away: 
> > > ../build-aux/depcomp: line 126: syntax error at line 127: ‘done’ 
> > > unexpected
> > > I don’t think UNIX compatibility is really a GNU priority unfortunately…
> > > It is actually documented in the System V interface Definition (Volume 
> > > II, page 128) that:
> > > “If the removal of a non-empty, write-protected directory is attempted, 
> > > the command will always fail (even if the -f option is used), resulting 
> > > in an error message.”
> > > This behavior was POSIX compliant until 2017, and I have a hard time 
> > > believing that the committee did not even consult the SVID.
> > > Kind regards,
> > > Lev
> > >
> > > > On Feb 6, 2021, at 13:55, Chase nicetry...@protonmail.ch wrote:
> > > > While this is impressive, it still won't be relevant for very long due 
> > > > to our impending transition to autotools, did you ever get that 
> > > > make=gmake hack to work? I was also thinking that a good way to solve 
> > > > the rm problem would be to build the upstream ksh and link it to 
> > > > /bin/sh, since their rm is builtin and conforms to POSIX.
> > > > Thank you for your time,
> > > > -Chase
> > > > ‐‐‐ Original Message ‐‐‐
> > > > On Saturday, February 6, 2021 1:09 PM, Lev via cdesktopenv-devel 
> > > > cdesktopenv-devel@lists.sourceforge.net wrote:
> > > >
> > > > > Hello,
> > > > > This patch allows for parallel ‘make World’ with imake.
> > > > > If we are interested in cross-compilation support, I could work on 
> > > > > that as well.
> > > > > Kind regards,
> > > > > Lev
> > > > > cdesktopenv-devel mailing list
> > > > > cdesktopenv-devel@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Parallel build support for Imake

[Chase via cdesktopenv-devel]

Keyword directory. An empty argument != directory. I have a hard time believing 
that Xinuos would let their OS become unusable for automake, have you emailed 
them at all about the issues you've been facing?


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Saturday, February 6, 2021 3:30 PM, Lev  wrote:

> Hi Chase,
>
> I just tried to build GNU make on UnixWare and it errors out right away: 
> ../build-aux/depcomp: line 126: syntax error at line 127: ‘done’ unexpected
>
> I don’t think UNIX compatibility is really a GNU priority unfortunately…
>
> It is actually documented in the System V interface Definition (Volume II, 
> page 128) that:
> “If the removal of a non-empty, write-protected directory is attempted, the 
> command will always fail (even if the -f option is used), resulting in an 
> error message.”
>
> This behavior was POSIX compliant until 2017, and I have a hard time 
> believing that the committee did not even consult the SVID.
>
> Kind regards,
> Lev
>
> > On Feb 6, 2021, at 13:55, Chase nicetry...@protonmail.ch wrote:
> > While this is impressive, it still won't be relevant for very long due to 
> > our impending transition to autotools, did you ever get that make=gmake 
> > hack to work? I was also thinking that a good way to solve the rm problem 
> > would be to build the upstream ksh and link it to /bin/sh, since their rm 
> > is builtin and conforms to POSIX.
> > Thank you for your time,
> > -Chase
> > ‐‐‐ Original Message ‐‐‐
> > On Saturday, February 6, 2021 1:09 PM, Lev via cdesktopenv-devel 
> > cdesktopenv-devel@lists.sourceforge.net wrote:
> >
> > > Hello,
> > > This patch allows for parallel ‘make World’ with imake.
> > > If we are interested in cross-compilation support, I could work on that 
> > > as well.
> > > Kind regards,
> > > Lev
> > > cdesktopenv-devel mailing list
> > > cdesktopenv-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Default font change

[Chase via cdesktopenv-devel]

I can get behind this, I know there was talk of using motif's XFT support for a 
bit, but I don't think anything ever came of it...

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Saturday, February 6, 2021 1:20 PM, Lev via cdesktopenv-devel 
 wrote:

> Hello,
>
> I would like to gather feedback from everyone on the list on whether we 
> should switch the default font (a bitmap rendering of Lucida) to a manually 
> adjusted screen font designed to maximize legibility.
>
> I’ve attached before and after screenshots. On my LCD screen, I think this 
> actually looks better (sharper while minimizing jaggedness) than 
> anti-aliasing.
>
> Kind regards,
> Lev___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Parallel build support for Imake

[Chase via cdesktopenv-devel]

While this is impressive, it still won't be relevant for very long due to our 
impending transition to autotools, did you ever get that make=gmake hack to 
work? I was also thinking that a good way to solve the rm problem would be to 
build the upstream ksh and link it to /bin/sh, since their rm is builtin and 
conforms to POSIX.


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Saturday, February 6, 2021 1:09 PM, Lev via cdesktopenv-devel 
 wrote:

> Hello,
>
> This patch allows for parallel ‘make World’ with imake.
>
> If we are interested in cross-compilation support, I could work on that as 
> well.
>
> Kind regards,
> Lev
>
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] SPARC patch

[Chase via cdesktopenv-devel]

Swift,
I would really like to see a build on current version of AIX 7.2 since IBM has 
said they will support it for the next decade, HPUX I can take or leave if you 
can manage, but i would also prefer that to be 11.31. As for compilers, I would 
just go for the safe option for now, gcc, it will be easier to debug any issues 
with that and then you could move on to the daring stuff. This isn't my 
project, but when it comes to platform support, I ask myself 3 questions:
1. Is it still updated?
2. Will it cause bitrot/ifdef hell/ is it standards compliant?
3. Will someone maintain it and verify it works?

So i dont have anything against, say, unixware being readded, but it should be 
Xinuos's most recent 2018 edition, not something ancient.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Tuesday, February 2, 2021 4:52 PM, Swift Griggs  
wrote:

> On Tue, 2 Feb 2021, Chase via cdesktopenv-devel wrote:
>
> > Personally, I think that your time would be used better if you helped us
> > test and fix any issues with the AIX and HPUX port.
>
> I have access to POWER hardware but only Power7 and older stuff (I have
> some POWER6 and RS/6000 PPC hardware too). However, I have the full suite
> of AIX available. I could try a test build. Do you know if it'd require
> gcc or xlC? I might also be able to host a POWER box for us to use online.
> It would probably make sense to use something old like 4.3, 5.1, 5.3, or
> 6.1. Binary compatibility would insure it'd run on 7.x and you'd still
> cover most of the hobbyists who are on 6.1 and earlier. Just my $0.02. Let
> me know your thoughts, Chase.
>
> > These haven't been tested in possibly decades and at least for the HPUX
> > port, I have strongly considered just removing it from the repo
>
> I support HPUX (and pretty much all the legacy Unixen) and on both
> platforms (PA-RISC and Itanium). I don't know if you know this, but fairly
> recently Qemu has been able to run HPUX (PA-RISC / HP9000 only). I think I
> have images for 10.20 and 11.11 both (and I can share them or host them).
> I could probably create one for 11.31, (HP9k) also, if it doesn't crash
> the emulator. I know 11.11 runs great and it has binary compat with newer
> versions also.
>
> The problem is that getting a good compiler on HPUX is difficult. Only gcc
> is really an option because the HP C compiler is licensed-only and I know
> of no way around that (gcc for PA-RISC ISA is no-bueno, too - very slow
> but might work, it'd probably be gcc295 or gcc3). HPE still occasionally
> sells a copy, and it's one of the few things I haven't collected a license
> for over the years. If anyone else can help here, let me know.
>
> I would be happy to setup an emulated HP box on a static IP so we could
> give it shot. I could pull it down and try to get a build going then get
> you guys involved if that would help?
>
> > it's death date is 2025
>
> That is EOL for 11iv3, which came out in 2010 or 2011. They've just kept
> issuing patches for it. I can't believe it's even gone this long, but HP
> was a hot mess and HPE is probably going to be even worse. Time will tell.
>
> > and even the linux kernel guys have orphaned support for itanium, i.e.
>
> That's okay. Linux never figured out EPIC. If you install Linux on an
> Itanium, make sure to put a layer of paint on the room you are in so you
> can entertain yourself by watching it dry before the install finishes.
> It's not just bad, it's downright awful. SGI had to load their Altix
> machines to the hilt with CPU just to get any type of decent performance
> out of them. Maybe the EPIC ISA is "epic" for someone, but Linux ain't
> that someone (I hear it's good for OpenVMS shrug ... ok-cool.). HPUX
> runs pretty mediocre on it, but it's not the
> oh-my-gosh-this-thing-is-so-slow-it-is-broken experience you have with
> Linux. I would advise anyone interested to not waste their time.
>
> > the only architecture it will run on after March of this year (HP9000 is
> > slated for EOL then).
>
> Since the initial burns on Itanium from Intel themselves and then Oracle,
> even HP(E) has been a bit gunshy about the Itanium. I don't have any
> numbers to prove it, but I suspect many of the last 12 years they have
> sold more HP9000 hardware than Integrity hardware based on the "Itanic".
> They definitely seem to have sold more HP9k Superdomes than I2 Superdomes,
> all total.
>
> I've fiddled with Unix boxes since around '92 and the other thing I'd
> point out is that all the nice workstation hardware is HP9000, with most
> of the Integrity stuff being server-based. Of course, that

Re: [cdesktopenv-devel] Fwd: [cdesktopenv:code] Merge request: Added PAM support to CDE.

[Chase via cdesktopenv-devel]

These patches would also need to be ported to automake. Its a shame that all 
these new contributors show up when we are almost done with automake and are 
making their contributions targeted for imake...

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Wednesday, February 3, 2021 6:40 PM, Jon Trulson  wrote:

> I'm forwarding this to the list...
>
> The PR looks interesting. I have not looked at it yet as SF seems to make 
> that more difficult than it should be, but this seems like a very good thing. 
> I'm just looking for eyeballs and opinions here.
>
> -jon
>
>  Forwarded Message 
> Subject:  [cdesktopenv:code] Merge request: Added PAM support to CDE.
> Date: Tue, 02 Feb 2021 17:22:33 -
> From: Liang Chang 
> [](mailto:l-ch...@users.sourceforge.net)
>
> Reply-To: Merge Request #21: Added PAM support to CDE. 
> [](mailto:nore...@sourceforge.net)
>
> To:   Merge Request #21: Added PAM support to CDE. 
> [](mailto:nore...@sourceforge.net)
>
> Merge request: Added PAM support to CDE.
>
> ---
>
> Liang Chang has requested to merge changes from 
> ssh://@git.code.sf.net/u/l-chang/cdesktopenv at commit [e38633] into the 
> branch master
>
> No need to set SUID on dtsession anymore.
> With PAM, a normal user could use his own password to unlock screen.
> Tested on FreeBSD, NetBSD and Linux.
>
> For FreeBSD and NetBSD, need to install a PAM module:
> https://sourceforge.net/p/cdesktopenv/discussion/general/thread/d8d1781162/#48ae
>
> ---
>
> Sent from sourceforge.net because you indicated interest in 
> https://sourceforge.net/p/cdesktopenv/code/merge-requests/21/
>
> To unsubscribe from further messages, please visit 
> https://sourceforge.net/auth/subscriptions/___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] SPARC patch

[Chase via cdesktopenv-devel]

1. I've heard about a test suite in the wiki, but I have little knowledge about 
it, is this what the examples directory is for?
2. While getting SPI on board would be nice, I doubt they would be interested 
in a niche project like ours.
3. MIT licensing isn't happening from what I've been told, not only would The 
Open Group need to get on board, but every contributor in the CONTRIBUTORS list 
(some of their emails don't even work anymore)

Personally, I think that your time would be used better if you helped us test 
and fix any issues with the AIX and HPUX port. These haven't been tested in 
possibly decades and at least for the HPUX port, I have strongly considered 
just removing it from the repo, it's death date is 2025 and even the linux 
kernel guys have orphaned support for itanium, i.e. the only architecture it 
will run on after March of this year (HP9000 is slated for EOL then).

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Monday, February 1, 2021 6:25 PM, Lev via cdesktopenv-devel 
 wrote:

> Hello,
>
> Several tickets have been opened concerning CDE compilation failures on SPARC 
> systems due to GOT limits. This patch should remedy the main issue and I’ll 
> try to followup to see if there are others.
>
> As an aside, I really enjoy seeing the diversity of platforms and 
> architectures that CDE enthusiasts are using.
>
> I had a couple of other questions:
>
> -   Does anyone have access to the CDE test suite or QATS for Motif? Being 
> able to run automated regression tests would be a huge help.
> -   What about reaching out to a group like Software in the Public Interest 
> to assist us organizationally?
>
> Personally, if I am going to be making a lot of changes to this project 
> or the future UNIX port, I’d like to be able to assign my copyright to a 
> trustee to make any future MIT transition easier. They might also be able to 
> assist licensing negotiations with the Open Group as a non-profit with 
> expertise.
>
> Kind regards,
> Lev
>
>
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] dtksh: make it build under autotools

[Chase via cdesktopenv-devel]

Fedora and family don't install patch by default, so we need to specifically 
test for it. Also, apparently distclean crashes when it reaches the JP locale.

On a side note, I am still of the opinion that we should replace tradcpp with 
sed wherever possible, it would be one less program that we would have to 
maintain and build, and some tests I ran show that sed is slightly faster. I 
could do the work to replace it if need be.

Thank you for your time,
-ChaseFrom a4a354dc44430379bdabdd8291e98101ffc7bbc5 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sun, 31 Jan 2021 10:58:17 -0600
Subject: [PATCH 1/2] dtksh: make it build under autotools

---
 cde/configure.ac|   3 +
 cde/programs/Makefile.am|   4 +-
 cde/programs/dtksh/Makefile.am  |  69 
 cde/programs/dtksh/examples/Makefile.am | 104 
 cde/programs/dtksh/ksh93|   2 +-
 5 files changed, 146 insertions(+), 36 deletions(-)
 create mode 100644 cde/programs/dtksh/examples/Makefile.am

diff --git a/cde/configure.ac b/cde/configure.ac
index 2b0ad349f..8678e3542 100644
--- a/cde/configure.ac
+++ b/cde/configure.ac
@@ -566,6 +566,9 @@ programs/dtspcd/Makefile
 
 programs/dtscreen/Makefile
 
+programs/dtksh/Makefile
+programs/dtksh/examples/Makefile
+
 programs/dtcm/Makefile
 programs/dtcm/libDtCmP/Makefile
 programs/dtcm/server/Makefile
diff --git a/cde/programs/Makefile.am b/cde/programs/Makefile.am
index 74ead60c8..4c3dcd435 100644
--- a/cde/programs/Makefile.am
+++ b/cde/programs/Makefile.am
@@ -2,9 +2,9 @@ MAINTAINERCLEANFILES = Makefile.in
 
 SUBDIRS = backdrops icons dsdm dtmail dtpad dtfile dtwm dtlogin \
 dtsession dthello dtstyle dtexec dtdbcache dticon dtterm dtcalc \
-	dtaction dtspcd dtscreen dtcm dtsearchpath dtappbuilder palettes \
+	dtaction dtspcd dtscreen dtksh dtcm dtsearchpath dtappbuilder palettes \
 	dtappintegrate dtprintegrate dtconfig dtcreate dtprintinfo fontaliases \
 	dtdspmsg dtimsstart dtpdm dtsr dtpdmd types \
 	tttypes util dtopen localized dthelp nsgmls dtdocbook
 
-# NOTYET = dtksh dtinfo ttsnoop
+# NOTYET =dtinfo ttsnoop
diff --git a/cde/programs/dtksh/Makefile.am b/cde/programs/dtksh/Makefile.am
index 001512ae1..aa92483c2 100644
--- a/cde/programs/dtksh/Makefile.am
+++ b/cde/programs/dtksh/Makefile.am
@@ -1,3 +1,9 @@
+MAINTAINERCLEANFILES = Makefile.in
+
+CLEANFILES = init.c FEATURE
+
+SUBDIRS = examples
+
 kshdir = ${libdir}/dtksh
 
 dist_ksh_SCRIPTS = DtFuncs.dtsh
@@ -8,41 +14,39 @@ if SOLARIS
 .NO_PARALLEL:
 endif
 
-SUBDIRS = examples ksh93
-KSH93OBJ = $(KSH93SRC)/ksh93.o
-KSH93LIBSHELL = $(KSH93SRC)/src/cmd/ksh93/libshell.a
+KSH93LIBSHELL = $(KSH93SRC)/lib/libshell.a
 
 bin_PROGRAMS = dtksh
 
 dtksh_CPPFLAGS = -I$(KSH93SRC)/include/ast -I$(KSH93SRC)/src/cmd/ksh93/include \
-	   -I$(KSH93SRC)/src/cmd/ksh93 -I${srcdir}/lib/DtPrint \
-	   -I${srcdir}/lib/DtHelp
-dtksh_LDADD = $(DTHELPLIB) $(DTWIDGETLIB) $(DTSVCLIB) $(DTPRINTLIB) $(TTLIB) \
-	  -lXm $(XTOOLLIB) ${X_LIB} $(KSH93SRC)/lib/libcmd.a  \
-	  $(KSH93SRC)/lib/libast.a -lm
+		 -I$(KSH93SRC)/src/cmd/ksh93 -I${srcdir}/lib/DtPrint \
+		 -I${srcdir}/lib/DtHelp '-DAST_VERSION=2011' \
+		 -DSHOPT_STATS -DSHOPT_NAMESPACE -DSHOPT_2DMATCH \
+		 -DSHOPT_MULTIBYTE -DSHOPT_BGX -DSHOPT_AUDIT -D_PACKAGE_ast \
+		 -DSHOPT_DYNAMIC -D_BLD_shell -DSHOPT_KIA -DKSHELL \
+		 -DSHOPT_HISTEXPAND -DSHOPT_EDPREDICT -DSHOPT_ESH -DSHOPT_VSH \
+		 -DSHOPT_FIXEDARRAY '-DERROR_CONTEXT_T=Error_context_t' \
+		 -DSHOPT_SUID_EXEC -D_API_ast=20100309 -DSHOPT_BRACEPAT \
+		 -DBUILD_DTKSH
+
+dtksh_LDADD = $(DTCLIENTLIBS) -lXm pmain.o $(XTOOLLIB) ${X_LIB} \
+	  libshell.a $(KSH93SRC)/lib/libcmd.a $(KSH93SRC)/lib/libast.a \
+	  $(KSH93SRC)/lib/libdll.a -lm
 
 if LINUX
 dtksh_LDADD += -ldl
 endif
 
 if SOLARIS
-dtksh_CPPFLAGS += -DDYNLIB
-endif
-
-if HPUX
-dtksh_CFLAGS += -Wl,-E -DHPUX_DYNLIB -Wp,-H12000
-dtksh_LDADD += -lm -ldld
+dtksh_LDADD += -lsecdb -lsocket -lnsl
 endif
 
 if AIX
-dtksh_CPPFLAGS += -DDYNLIB -D_IBMRPC_
-dtksh_LDADD += -bE:dtksh.exp
+dtksh_CPPFLAGS += -D_IBMRPC_
+dtksh_LDFLAGS = -bE:dtksh.exp
 endif
 
-dtksh_SOURCES = \
-userinit.c \
-builtins.c \
-aliases.c \
+dtksh_SOURCES = init.c \
 widget.c \
 dtkcvt.c \
 dtkcmds.c \
@@ -51,23 +55,22 @@ dtksh_SOURCES = \
 xmcmds.c \
 xmwidgets.c \
 extra.c \
-xmdtksym.c \
 findsym.c \
 msgs.c
 
-all:: dtksh
+init.c:
+	cd ksh93; ./bin/package flat make CCFLAGS='$(SUIDEXECDEFINES) -g -D_std_malloc'
+	cp ./ksh93/src/cmd/ksh93/sh/init.c init.c
+	patch --posix init.c -i init.patch
+	./setup.sh
 
-$(KSH93SRC)/ksh93.o:
-cd $(KSH93SRC); $(MAKE)
 
-# Must replace standard ksh tables of builtins and aliases
-# with our augmented versions.
+libshell.a: $(KSH93SLIBSHELL) dtksh-init.o
+	$(CP) $(KSH93LIBSHELL) libshell.a; \
+	ar d 

Re: [cdesktopenv-devel] master-ksh93-upgrade branch merged into master

[Chase via cdesktopenv-devel]

Very nice, could you also merge it with autotools-conversion so I can work on 
autotooling it?

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Saturday, January 30, 2021 6:07 PM, Jon Trulson  wrote:

> Hi,
>
> The master-ksh93-upgrade branch has been merged into master and deleted. 
> Thanks to Chase for his hard work on improving the ksh93 used in CDE!
>
> This means checking out the tree will be a bit different. You can pass the 
> '--recursive' option to the clone command to also checkout the required ksh93 
> submodule at the correct location. If you have already cloned the repo, you 
> can change directory into the CDE repo and run:
>
> git submodule update --init
>
> I've done some build testing on Ubuntu and all seems well.
>
> We are using the ksh93u+m maintained at https://github.com/ksh93/ksh
>
> Currently we are using the hash 47468f.
>
> Enjoy!
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] PowerPC and musl fixes

[Chase via cdesktopenv-devel]

I just did some light research, and it appears that unixware is the one in the 
wrong with this issue, rm -f not outputting diagnostics info is POSIX, so 
unixware needs to conform to posix. We are CDE, the common desktop environment, 
therefor we need to use the common standards.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22074
https://www.austingroupbugs.net/view.php?id=542


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Thursday, January 28, 2021 8:03 PM, Lev  wrote:

> Hi Chase,
>
> I ran autoreconf on Linux and copied it over to my UnixWare system. After 
> manually patching the ‘configure' script to work around new build 
> requirements like Xinerama, pkg-config, and freetype, the build fails because 
> it tries calling the am—refresh target and it can’t find aclocal. Touch’ing 
> all the files solved that issue but the automake-generated Makefiles contain 
> macros that do not function with UNIX make, like $< outside inference rules; 
> this leads make to run commands that are missing their arguments. In 
> contrast, cde-2.2.1 mostly works once BOOTSTRAPCFLAGS are properly defined. 
> Sadly, I don’t see how this endeavor is going to work in the long run, 
> especially if autoconf drops compatibility with the SVR4 utilities (the 
> reason for the ‘rm’ warning.)
>
> When I have more time, I think I will pivot towards getting the new ksh93 
> working without regressions on UnixWare and other SVR4 platforms first. 
> Perhaps the best approach later is to configure Imake with iffe (possibly 
> sync’ing the defines with the autoconf one for source code portability), 
> restore Motif's Imake support, and backport bug-fixes to 2.2.1 as part of a 
> "CDE classic" project that bundles dependencies like Tcl and patches for 
> these systems.
>
> Kind regards,
> Lev
>
> > On Jan 27, 2021, at 19:32, Chase nicetry...@protonmail.ch wrote:
> > Not to my knowledge, no. I wonder, would committing the configure file 
> > alleviate any of the issues you have with the autotools? If we commit the 
> > configure file, you wouldn't need to install the autotools or m4 (you'd 
> > still need it to build nsgmls but hopefully we will get rid of this soon 
> > for system onsgmls) to build in theory. I was actually going to propose to 
> > do this a while ago so that the future debian package wouldn't depend on 
> > the autotools but I was busy with the whole ksh replacement project.
> > Thank you for your time,
> > -Chase
> > ‐‐‐ Original Message ‐‐‐
> > On Tuesday, January 26, 2021 10:23 PM, Lev int...@mailbox.org wrote:
> >
> > > Hi Jon and Chase,
> > >
> > > > On Jan 26, 2021, at 18:56, Jon Trulson j...@radscan.com wrote:
> > > > On 1/25/21 8:54 PM, Lev wrote:
> > > >
> > > > > Hi Jon,
> > > > > Thank you for committing that, it should be the last ksh93 patch. Did 
> > > > > you get a chance to look at the other five patches I sent on 17th? I 
> > > > > don’t believe they are in yet.
> > > >
> > > > I must have missed them... I remember skipping some of them because I 
> > > > had already applied them. If I look at the log in master, there are 
> > > > several patched from you regarding musl...
> > > > If there are some I missed (possible since some of them were embedded 
> > > > in threads), re-send them (minus any ksh stuff) and I'll merge them.
> > >
> > > Thanks, I’ve attached the (rebased) patches.
> > >
> > > > > I don’t know if this got lost in the shuffle, but since you mentioned 
> > > > > potentially fixing autoconf as an alternative to imake, I am curious 
> > > > > if you have any thoughts on Thomas Dickey’s fork of autoconf 2.59 
> > > > > (https://invisible-island.net/autoconf/
> > > > > ). I doubt I would be able to match the excellent work he’s done in 
> > > > > order to keep xterm and ncurses compiling everywhere (even OS/2 and 
> > > > > VMS), but as far as I can tell, upstream is not interested in these 
> > > > > patches.
> > > >
> > > > Ahh... no I wasn't proposing to take over autoconf development :)
> > > > There is another CDE branch called autotools-conversion. A lot of work 
> > > > is already done and most of CDE can be built. I just need to get that 
> > > > finished and then the imake support would be removed and the result 
> > > > merged into master. This probably won't happen for awhile, so imake is 
> > > > safe for now :)
> > >
> > > Alright, I think that was a misunderstanding on my part on then. The 
> > > incompatibilities aren’t with CDE’s autotools support but the autotools 
> > > themselves. About the ‘adopting imake’ comment: I tried to get some 
> > > context on what spurred the autotools conversion in the first place and 
> > > found ’The sorry state of imake’ thread. Chase, if you wouldn’t mind, was 
> > > Alan Coopersmith still looking for a maintainer last time you spoke?
> > >
> > > > > Also, if you don’t mind my asking, whatever happened to 
> > > > > Accelerated-X? It seems that X.org
> > > > > development is slowing considerably with the asce

Re: [cdesktopenv-devel] PowerPC and musl fixes

[Chase via cdesktopenv-devel]

Have you tried reporting any of these issues to the GNU project? I feel like 
reporting/fixing it upstream would be significantly less of a time sync and 
would be beneficial for everyone to have the makefiles be posix compliant and 
such.


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Thursday, January 28, 2021 8:03 PM, Lev  wrote:

> Hi Chase,
>
> I ran autoreconf on Linux and copied it over to my UnixWare system. After 
> manually patching the ‘configure' script to work around new build 
> requirements like Xinerama, pkg-config, and freetype, the build fails because 
> it tries calling the am—refresh target and it can’t find aclocal. Touch’ing 
> all the files solved that issue but the automake-generated Makefiles contain 
> macros that do not function with UNIX make, like $< outside inference rules; 
> this leads make to run commands that are missing their arguments. In 
> contrast, cde-2.2.1 mostly works once BOOTSTRAPCFLAGS are properly defined. 
> Sadly, I don’t see how this endeavor is going to work in the long run, 
> especially if autoconf drops compatibility with the SVR4 utilities (the 
> reason for the ‘rm’ warning.)
>
> When I have more time, I think I will pivot towards getting the new ksh93 
> working without regressions on UnixWare and other SVR4 platforms first. 
> Perhaps the best approach later is to configure Imake with iffe (possibly 
> sync’ing the defines with the autoconf one for source code portability), 
> restore Motif's Imake support, and backport bug-fixes to 2.2.1 as part of a 
> "CDE classic" project that bundles dependencies like Tcl and patches for 
> these systems.
>
> Kind regards,
> Lev
>
> > On Jan 27, 2021, at 19:32, Chase nicetry...@protonmail.ch wrote:
> > Not to my knowledge, no. I wonder, would committing the configure file 
> > alleviate any of the issues you have with the autotools? If we commit the 
> > configure file, you wouldn't need to install the autotools or m4 (you'd 
> > still need it to build nsgmls but hopefully we will get rid of this soon 
> > for system onsgmls) to build in theory. I was actually going to propose to 
> > do this a while ago so that the future debian package wouldn't depend on 
> > the autotools but I was busy with the whole ksh replacement project.
> > Thank you for your time,
> > -Chase
> > ‐‐‐ Original Message ‐‐‐
> > On Tuesday, January 26, 2021 10:23 PM, Lev int...@mailbox.org wrote:
> >
> > > Hi Jon and Chase,
> > >
> > > > On Jan 26, 2021, at 18:56, Jon Trulson j...@radscan.com wrote:
> > > > On 1/25/21 8:54 PM, Lev wrote:
> > > >
> > > > > Hi Jon,
> > > > > Thank you for committing that, it should be the last ksh93 patch. Did 
> > > > > you get a chance to look at the other five patches I sent on 17th? I 
> > > > > don’t believe they are in yet.
> > > >
> > > > I must have missed them... I remember skipping some of them because I 
> > > > had already applied them. If I look at the log in master, there are 
> > > > several patched from you regarding musl...
> > > > If there are some I missed (possible since some of them were embedded 
> > > > in threads), re-send them (minus any ksh stuff) and I'll merge them.
> > >
> > > Thanks, I’ve attached the (rebased) patches.
> > >
> > > > > I don’t know if this got lost in the shuffle, but since you mentioned 
> > > > > potentially fixing autoconf as an alternative to imake, I am curious 
> > > > > if you have any thoughts on Thomas Dickey’s fork of autoconf 2.59 
> > > > > (https://invisible-island.net/autoconf/
> > > > > ). I doubt I would be able to match the excellent work he’s done in 
> > > > > order to keep xterm and ncurses compiling everywhere (even OS/2 and 
> > > > > VMS), but as far as I can tell, upstream is not interested in these 
> > > > > patches.
> > > >
> > > > Ahh... no I wasn't proposing to take over autoconf development :)
> > > > There is another CDE branch called autotools-conversion. A lot of work 
> > > > is already done and most of CDE can be built. I just need to get that 
> > > > finished and then the imake support would be removed and the result 
> > > > merged into master. This probably won't happen for awhile, so imake is 
> > > > safe for now :)
> > >
> > > Alright, I think that was a misunderstanding on my part on then. The 
> > > incompatibilities aren’t with CDE’s autotools support but the autotools 
> > > themselves. About the ‘adopting imake’ comment: I tried to get some 
> > > context on what spurred the autotools conversion in the first place and 
> > > found ’The sorry state of imake’ thread. Chase, if you wouldn’t mind, was 
> > > Alan Coopersmith still looking for a maintainer last time you spoke?
> > >
> > > > > Also, if you don’t mind my asking, whatever happened to 
> > > > > Accelerated-X? It seems that X.org
> > > > > development is slowing considerably with the ascendance of Wayland.
> > > >
> > > > XiG died in 2012... It was a good run. It's the second company I worked 
> > > > for that I got in early, a

Re: [cdesktopenv-devel] PowerPC and musl fixes

[Chase via cdesktopenv-devel]

Not to my knowledge, no. I wonder, would committing the configure file 
alleviate any of the issues you have with the autotools? If we commit the 
configure file, you wouldn't need to install the autotools or m4 (you'd still 
need it to build nsgmls but hopefully we will get rid of this soon for system 
onsgmls) to build in theory. I was actually going to propose to do this a while 
ago so that the future debian package wouldn't depend on the autotools but I 
was busy with the whole ksh replacement project.


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Tuesday, January 26, 2021 10:23 PM, Lev  wrote:

> Hi Jon and Chase,
>
> > On Jan 26, 2021, at 18:56, Jon Trulson j...@radscan.com wrote:
> > On 1/25/21 8:54 PM, Lev wrote:
> >
> > > Hi Jon,
> > > Thank you for committing that, it should be the last ksh93 patch. Did you 
> > > get a chance to look at the other five patches I sent on 17th? I don’t 
> > > believe they are in yet.
> >
> > I must have missed them... I remember skipping some of them because I had 
> > already applied them. If I look at the log in master, there are several 
> > patched from you regarding musl...
> > If there are some I missed (possible since some of them were embedded in 
> > threads), re-send them (minus any ksh stuff) and I'll merge them.
>
> Thanks, I’ve attached the (rebased) patches.
>
> > > I don’t know if this got lost in the shuffle, but since you mentioned 
> > > potentially fixing autoconf as an alternative to imake, I am curious if 
> > > you have any thoughts on Thomas Dickey’s fork of autoconf 2.59 
> > > (https://invisible-island.net/autoconf/
> > > ). I doubt I would be able to match the excellent work he’s done in order 
> > > to keep xterm and ncurses compiling everywhere (even OS/2 and VMS), but 
> > > as far as I can tell, upstream is not interested in these patches.
> >
> > Ahh... no I wasn't proposing to take over autoconf development :)
> > There is another CDE branch called autotools-conversion. A lot of work is 
> > already done and most of CDE can be built. I just need to get that finished 
> > and then the imake support would be removed and the result merged into 
> > master. This probably won't happen for awhile, so imake is safe for now :)
>
> Alright, I think that was a misunderstanding on my part on then. The 
> incompatibilities aren’t with CDE’s autotools support but the autotools 
> themselves. About the ‘adopting imake’ comment: I tried to get some context 
> on what spurred the autotools conversion in the first place and found ’The 
> sorry state of imake’ thread. Chase, if you wouldn’t mind, was Alan 
> Coopersmith still looking for a maintainer last time you spoke?
>
> > > Also, if you don’t mind my asking, whatever happened to Accelerated-X? It 
> > > seems that X.org
> > > development is slowing considerably with the ascendance of Wayland.
> >
> > XiG died in 2012... It was a good run. It's the second company I worked for 
> > that I got in early, and then had the misfortune to ride it down into the 
> > dirt. I have several million shares if anyone's interested... :D
> > But WRT Wayland, I've been hearing that it's going to kill X11 for over a 
> > decade now. I will believe it when I see it :)
> > But yeah - no one is 'innovating' in X11 anymore, it's "Done".
> > One thing I really depend on a lot is the ability to run X11 apps over the 
> > network. I do not think that is possible in wayland - maybe via their 
> > Xwayland stuff? Haven't really looked very deep into Wayland in a few years.
> > -jon
>
> Sorry to hear that. Did anything survive regarding its architecture? I 
> remember it required a kernel module, but I can’t remember the reason why 
> instead of writing to the card’s framebuffer in /dev/mem. I wonder if X11 
> could have taken a different path, and I imagine you have a unique knowledge 
> of the history behind the X Consortium, XFree86, and the rebranding/merger 
> ofX.org. As a software engineer, did you have any impressions/opinions 
> regarding XIE, STSF, and Display Postscript? XRender and Xft do not really 
> seem to mesh well with X11’s client-server architecture.
>
> Kind regards,
> Lev
>
> > > Kind regards,
> > > Lev
> > >
> > > > On Jan 23, 2021, at 17:11, Jon Trulson j...@radscan.com
> > > > wrote:
> > > > On 1/18/21 8:21 AM, Lev via cdesktopenv-devel wrote:
> > > >
> > > > > Here’s a revised copy of the ksh fixes I submitted before that 
> > > > > properly tests for POSIX-compliant terminal handling capabilities 
> > > > > rather than attempting to get OLDTERMIO working. I think these 
> > > > > patches are ready to be committed.
> > > >
> > > > Sorry I missed this one. I've added it to master. However, I think any 
> > > > future ksh changes should go to the ksh93 maintainer... I'd like to get 
> > > > Chase's ksh tree merged to master soon...
> > > > Thanks!
> > > > -jon
> > > >
> > > > > Kind regards,
> > > > > Lev
> > > > >
> > > > > > On Jan 17, 2021, at 19:17, Lev via cdesktopenv-de

Re: [cdesktopenv-devel] [PATCH] updated ksh to most recent commit

[Chase via cdesktopenv-devel]

I think you could also use

git clone --recurse-submodules

to clone in the source and the submodule in the same pass.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Sunday, January 24, 2021 1:37 PM, Jon Trulson  wrote:

> On 1/23/21 8:36 PM, Chase wrote:
>
>> Jon,
>> Hmm, If I am understanding you correctly (which I don't think I am), git 
>> wouldn't properly clone the submodule into the ksh93 directory? Maybe if 
>> thats the case, it could be fixed with adding in an empty ksh93 directory 
>> for it to clone into to the repo. It is worth noting however that git 
>> submodules will always be blank until you pull them in with the submodule 
>> command. It has always worked that way for me at least.
>
> Ok... I am not at all familiar with the use of sobmosules - surprisingly in 
> my day job, I've never had to deal with them. I'll do some experimenting and 
> see what is a good set of instructions for making sure people get the right 
> stuff. Main issue is what SF itself tells you to run to checkout the code - 
> just a straight up git clone http: Anyway, was just curious.
>
>> As for a new release, did I miss a release? where is 2.3.1 and 2.3.2? 
>> Sourceforge only shows up to 2.3.0...
>
> I think you missed 2...
>
> 2.3.1 was released 11/16/19, 2.3.2 was released 1/14/20... See:
>
> https://sourceforge.net/projects/cdesktopenv/files/src/
>
> The 'Download' button on the CDE summary page does download 2.3.2...
>
> -jon
>
>> The git command looks good. All in all, seems like a solid plan, looking 
>> forward to it!
>>
>> Thank you for your time,
>> -Chase
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Saturday, January 23, 2021 8:17 PM, Jon Trulson 
>> [](mailto:j...@radscan.com) wrote:
>>
>>> On 1/22/21 4:41 PM, Chase via cdesktopenv-devel wrote:
>>>
>>>> Since Lev fixed the errors in upstream for musl and upstreamed them, lets 
>>>> pull that in so any potential merge to master also can safely build on 
>>>> musl (thus the old changes from Lev we would throw away for old ksh would 
>>>> be replaced with the new changes)l. I also threw in compiler warning fixes 
>>>> for xmcmds.c.
>>>
>>> Chase,
>>>
>>> merged to master-ksh93-upgrade.
>>>
>>> I also merged master into this branch, which went fairly well. But I did 
>>> run into a problem.
>>>
>>> No matter what I did, the special 'gitlink' entry for 
>>> cde/programs/dtksh/ksh93 always disappeared in favor of an empty ksh93 
>>> directory. In the end, I just manually re-added the module and did a build. 
>>> The build worked, and ran fine in the little testing I did.
>>>
>>> Please look over what I did with regard to having to re-add the ksh93 
>>> submodule.
>>>
>>> Anyway, if this looks good from your side, let me know. What I would like 
>>> to then do is tag master as 2.3.2a, increment the version number to 2.3.2b, 
>>> and then merge this branch into master.
>>>
>>> We will also need to change the instructions on the wiki for checking out 
>>> from git (when this gets merged into master). Am I correct in that 
>>> something like the following should suffice?
>>>
>>> git clone git://git.code.sf.net/p/cdesktopenv/code cdesktopenv-code
>>> git submodule update --init
>>>
>>> Should do the trick? I suspect that will confuse people who forget... If 
>>> you have suggestions, let me know. Is it possible to have the build 
>>> update/checkout the submodule automatically if it hasn't already been 
>>> updated/checked out?
>>>
>>> After letting it stew for a few weeks in master, I'd then like to do a 
>>> release, but that will require someone being able to test on various 
>>> operating systems.
>>>
>>> Anyway, nice work - it will be good to have a newer, better supported ksh 
>>> in CDE.
>>>
>>> -jon
>>>
>>>> Thank you for your time,
>>>> -Chase
>>>>
>>>> ___
>>>> cdesktopenv-devel mailing list
>>>> cdesktopenv-devel@lists.sourceforge.net
>>>>
>>>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>>>
>>> --
>>> Jon Trulson
>>>
>>>   "Entropy.  It isn't what it used to be."
>>>-- Sheldon
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] updated ksh to most recent commit

[Chase via cdesktopenv-devel]

Jon,
Hmm, If I am understanding you correctly (which I don't think I am), git 
wouldn't properly clone the submodule into the ksh93 directory? Maybe if thats 
the case, it could be fixed with adding in an empty ksh93 directory for it to 
clone into to the repo. It is worth noting however that git submodules will 
always be blank until you pull them in with the submodule command. It has 
always worked that way for me at least.

As for a new release, did I miss a release? where is 2.3.1 and 2.3.2? 
Sourceforge only shows up to 2.3.0...

The git command looks good. All in all, seems like a solid plan, looking 
forward to it!

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Saturday, January 23, 2021 8:17 PM, Jon Trulson  wrote:

> On 1/22/21 4:41 PM, Chase via cdesktopenv-devel wrote:
>
>> Since Lev fixed the errors in upstream for musl and upstreamed them, lets 
>> pull that in so any potential merge to master also can safely build on musl 
>> (thus the old changes from Lev we would throw away for old ksh would be 
>> replaced with the new changes)l. I also threw in compiler warning fixes for 
>> xmcmds.c.
>
> Chase,
>
> merged to master-ksh93-upgrade.
>
> I also merged master into this branch, which went fairly well. But I did run 
> into a problem.
>
> No matter what I did, the special 'gitlink' entry for 
> cde/programs/dtksh/ksh93 always disappeared in favor of an empty ksh93 
> directory. In the end, I just manually re-added the module and did a build. 
> The build worked, and ran fine in the little testing I did.
>
> Please look over what I did with regard to having to re-add the ksh93 
> submodule.
>
> Anyway, if this looks good from your side, let me know. What I would like to 
> then do is tag master as 2.3.2a, increment the version number to 2.3.2b, and 
> then merge this branch into master.
>
> We will also need to change the instructions on the wiki for checking out 
> from git (when this gets merged into master). Am I correct in that something 
> like the following should suffice?
>
> git clone git://git.code.sf.net/p/cdesktopenv/code cdesktopenv-code
> git submodule update --init
>
> Should do the trick? I suspect that will confuse people who forget... If you 
> have suggestions, let me know. Is it possible to have the build 
> update/checkout the submodule automatically if it hasn't already been 
> updated/checked out?
>
> After letting it stew for a few weeks in master, I'd then like to do a 
> release, but that will require someone being able to test on various 
> operating systems.
>
> Anyway, nice work - it will be good to have a newer, better supported ksh in 
> CDE.
>
> -jon
>
>> Thank you for your time,
>> -Chase
>>
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>>
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] updated ksh to most recent commit

[Chase via cdesktopenv-devel]

Since Lev fixed the errors in upstream for musl and upstreamed them, lets pull 
that in so any potential merge to master also can safely build on musl (thus 
the old changes from Lev we would throw away for old ksh would be replaced with 
the new changes)l. I also threw in compiler warning fixes for xmcmds.c.

Thank you for your time,
-ChaseFrom 097193515abb880129b8fcf8c198ceb523b7cd42 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Fri, 22 Jan 2021 17:36:32 -0600
Subject: [PATCH] dtksh: update ksh to commit 47468f (fix musl compiler errors)

---
 cde/programs/dtksh/dtksh.h  | 2 --
 cde/programs/dtksh/ksh93| 2 +-
 cde/programs/dtksh/xmcmds.c | 4 ++--
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/cde/programs/dtksh/dtksh.h b/cde/programs/dtksh/dtksh.h
index 1313c414f..5bc6e1069 100644
--- a/cde/programs/dtksh/dtksh.h
+++ b/cde/programs/dtksh/dtksh.h
@@ -33,8 +33,6 @@
 #ifndef _Dtksh_dtksh_h
 #define _Dtksh_dtksh_h
 
-#include "nval.h"
-
 #define SUCCESS		0
 #define FAIL		(-1)
 
diff --git a/cde/programs/dtksh/ksh93 b/cde/programs/dtksh/ksh93
index 6025c8125..47468f56c 16
--- a/cde/programs/dtksh/ksh93
+++ b/cde/programs/dtksh/ksh93
@@ -1 +1 @@
-Subproject commit 6025c8125e596ccf5e25c651a8800c072310f3a4
+Subproject commit 47468f56c2d0506045120fb4d0709f3a734693f5
diff --git a/cde/programs/dtksh/xmcmds.c b/cde/programs/dtksh/xmcmds.c
index 7afbfae5d..5f6c3ded9 100644
--- a/cde/programs/dtksh/xmcmds.c
+++ b/cde/programs/dtksh/xmcmds.c
@@ -174,7 +174,7 @@ static int Text_VarAndWidget(
 int argc,
 char *argv[]) ;
 static int Text_WidgetAndBoolean( 
-void (*func)(Widget w, int b),
+void (*func)(Widget w, char b),
 int argc,
 char *argv[]) ;
 static int Text_WidgetAndOneParam( 
@@ -4062,7 +4062,7 @@ do_XmTextGetString(
 
 static int
 Text_WidgetAndBoolean(
-void (*func)(Widget w, int b),
+void (*func)(Widget w, char b),
 int argc,
 char *argv[] )
 {
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] CDE imake branch and other fixes

[Chase via cdesktopenv-devel]

Lev,
I just don't understand what the big issue with autotools is. We gutted a lot 
of the legacy OS code a few years ago (ultrix, unixware, even weird ones like 
uxpds), but if someone were to want these platforms back, I feel that using 
autotools would be an even better solution, since autotools supports building 
and feature testing on all these platforms, and instead of having big chunks of 
ifdef OS you can just implement features tests, whereas imake stopped receiving 
updates in 2000, and imake in general stopped being supported in 2014. I was 
the one that really spearheaded that we use autotools since it has a much 
larger platform support base than cmake or meson do, and I did so in case 
someone really wanted to bring back the old platform support.

I'd really like you to see the light on this one, if theres one thing that CDE 
doesn't need, its a fork.


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Tuesday, January 19, 2021 10:52 PM, Lev via cdesktopenv-devel 
 wrote:

> Hello,
>
> I intend on porting CDE/Motif 2.1 to SVR4 and possibly other niche platforms, 
> so I’ve set up a branch at https://github.com/lev105/cde-imake/ so as to not 
> interfere with the good work here to get CDE up to date with the autotools 
> suite, etc.
>
> Without being able to test on a SVID3-compliant OS, it’s difficult for me to 
> be able to gauge which changes risk worsening compatibility with older 
> systems, and CDE is a wonderful, lightweight desktop for them. Like a lot of 
> other folks, this will be something I balance in a small amount of free time, 
> but I hope these efforts will be useful for others. I’ve already got fairly 
> extensive changes to support compiling CDE on platforms without XPG 
> internationalization, and I am going to try getting fixes upstream for CDE 
> and ksh93 (looks like musl support has already been committed) if they fit 
> within their respective roadmaps. Maybe I could adopt imake if there wouldn’t 
> be any objection?
>
> Kind regards,
> Lev
>
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH][master-ksh93-upgrade] make it build under solaris and make patch obey POSIX

[Chase via cdesktopenv-devel]

Lev,
I git-ified you patch and sent it upstream, but in the future, if you make more 
changes to ksh, push them upstream to https://github.com/ksh93/ksh where the 
new ksh lives, they do no good simply sitting in our mailing list. I've also 
seen some talk about using the old at&t ksh, but this simply isn't possible or 
desirable, so much work has been put into this fork that solved many issues not 
only for dtksh, but ksh as a whole.


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Monday, January 18, 2021 9:34 PM, Lev  wrote:

> Hi Marcin,
>
> Thanks for the idea. I was able to workaround the LFS64 issue (see the 
> attached patch) with the new ksh 93u, but I ran into some other issues with 
> localization (iswalpha is redefined for some reason) and ulimit support that 
> are going to take some time to resolve.
>
> I haven’t had a chance to try it on SVR4 platforms yet, but the new ksh93 
> does state that "ksh does not currently build on AIX,” and “[t]here are many 
> regression test failures on NetBSD.” It seems that they are still in the 
> process of getting nmake working again.
>
> Kind regards,
> Lev
>
> > On Jan 18, 2021, at 14:25, Marcin Cieslak sa...@saper.info wrote:
> > On Mon, 18 Jan 2021, Lev wrote:
> >
> > > What would your advice be for anyone wanting to continue using CDE on 
> > > platforms that are unsupported by the autotools or ksh?
> >
> > Would the original ksh93u work for those platforms?
> > Or https://github.com/att/ast master which is close?
> > ksh93 has its own autoconfiguration thing, iffe, which
> > is quite nice once one gets used to it. I think musl
> > could be supported by writing some iffe rules...
> > Marcin




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH][master-ksh93-upgrade] make it build under solaris and make patch obey POSIX

[Chase via cdesktopenv-devel]

I would like master to be merged, yes. I am a bit confused though, what 
constitutes a path forward? I have satisfied all of the testing requirements 
(minus NetBSD), and I can't find any of the regression test faults that Marcin 
was talking about by using libc malloc. This would eliminate our need for a ksh 
to build with for dtksh (and it could probably be easily removed elsewhere as 
well), as ./bin/package was written to be shell agnostic. I could also start 
working on autotooling it when it gets merged.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Monday, January 18, 2021 6:48 PM, Jon Trulson  wrote:

> On 1/18/21 9:31 AM, Lev via cdesktopenv-devel wrote:
>
>> Hi Chase,
>>
>> Thanks to your advice about the submodule, I was able to make some progress. 
>> Unfortunately, I am now getting a lot of errors from the headers, e.g.:
>> [...]
>> I had been hoping to get a Motif 2.1 compatible version of CDE working on 
>> UnixWare, but I believe these changes, using autoconf and an out of tree 
>> ksh, are going to pose significant challenges for the future portability of 
>> CDE because it would be contingent on support by other projects. A similar 
>> transition by X.org resulted in OpenBSD implementing their own makefile 
>> build system with Xenocara, and I have had experience with autoconf releases 
>> after 2.13 turning into an effort trying to debug some rather inscrutable 
>> m4. Imake, for all its limitations, generates easy to understand Makefiles, 
>> is simple to configure manually if need be, and only assumes a knowledge of 
>> make and the cpp.
>>
>> What would your advice be for anyone wanting to continue using CDE on 
>> platforms that are unsupported by the autotools or ksh?
>
> Well, autotools is they way we are heading. There is already quite a lot of 
> work already done on the autotools branch. imake is dead and is very hard for 
> new users to 'get'. I intend, once everything can be built from autotools 
> (see the autotools-conversion branch), to completely remove all that is imake 
> from the tree once and for all. IT sucks. It requires special syntactic C 
> preprocessor behavior. I have no intention of continuing to support imake 
> once we can safely ditch it.
>
> For ksh, we can stick with the iffe stuff it is using now, until they 
> (upstream) change it to something else. Even in the current master - we just 
> call the ksh build scripts from Imake. We will do the same from autotools. If 
> some day ksh moves to autotools or something else, we can just arrange to 
> call it, whatever it winds up being.
>
> As for running on platforms unsupported by autotools - sorry, do we care? I 
> know unixware used to support it, I used to run unixware... 20 years or so 
> ago... If the OS is not being updated, why would we waste time appealing to 
> the lowest common denominator?
>
> I know ksh is a problem and it always astonished me that we actually needed a 
> running ksh on the system in order to build CDE. That is a dep we should get 
> rid of. We should not need ksh to build ksh, or any other part of CDE if we 
> can avoid it.
>
> So - I will hold off on applying patches until we have a path forward. Chase: 
> If you would like I can update the master-ksh93-upgrade with latest master. 
> Let me know.
>
> -jon
>
>> Kind regards,
>> Lev
>>
>>> On Jan 17, 2021, at 20:13, Chase
>>> [](mailto:nicetry...@protonmail.ch)
>>> wrote:
>>>
>>> I would not get too ahead of yourself with that, we are planning on making 
>>> the jump to the gnu autotools pretty soon, imake has a multitude of issues 
>>> that, if we want to see significant progress in the fields of OS packaging 
>>> and cross compiling, it will need to be done away with. Upstream might 
>>> appreciate any help with turning nmake into plain makefiles or autotooling 
>>> it however. It also just occured to me why your build was failing, after 
>>> you checkout master-ksh93-upgrade, make sure you do "git submodule update 
>>> --init --recursive" or else git will not pull in the submodule, thats why 
>>> your ./bin/package was missing. If you still have technical problems with 
>>> it afterwards, maybe this commit from att ksh could help
>>> https://github.com/att/ast/pull/260
>>> Thank you for your time,
>>> -Chase
>>>
>>> ‐‐‐ Original Message ‐‐‐
>>> On Sunday, January 17, 2021 9:02 PM, Lev
>>> [](mailto:int...@mailbox.org)
>>> wrote:
>>>
>>>> Hi Chase,
>>>>
>>>> I am thinking of revamping the bundled dtksh to build 

Re: [cdesktopenv-devel] [PATCH][master-ksh93-upgrade] make it build under solaris and make patch obey POSIX

[Chase via cdesktopenv-devel]

I would not get too ahead of yourself with that, we are planning on making the 
jump to the gnu autotools pretty soon, imake has a multitude of issues that, if 
we want to see significant progress in the fields of OS packaging and cross 
compiling, it will need to be done away with. Upstream might appreciate any 
help with turning nmake into plain makefiles or autotooling it however. It also 
just occured to me why your build was failing, after you checkout 
master-ksh93-upgrade, make sure you do "git submodule update --init 
--recursive" or else git will not pull in the submodule, thats why your 
./bin/package was missing. If you still have technical problems with it 
afterwards, maybe this commit from att ksh could help 
https://github.com/att/ast/pull/260


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Sunday, January 17, 2021 9:02 PM, Lev  wrote:

> Hi Chase,
>
> I am thinking of revamping the bundled dtksh to build directly with imake 
> instead of nmake, using a ksh93 configure script to generate a .cf file with 
> the appropriate defines as a replacement for iffe. If this isn’t the ksh 2020 
> fork but the new ksh 93u one, backporting the fixes shouldn’t be too 
> difficult because they basically started from scratch to my understanding.
>
> Kind regards,
> Lev
>
> > On Jan 17, 2021, at 17:28, Chase via cdesktopenv-devel 
> > cdesktopenv-devel@lists.sourceforge.net wrote:
> > Lev,
> > This is a known issue with upstream ksh93: 
> > https://github.com/ksh93/ksh/issues/3, maybe I am being a bit 
> > inconsiderate, but I think that the benefit of us not having to maintain 
> > our own decade old out of tree fork of ksh93 anymore is a worthy trade off 
> > for musl support. Could any of your most recent patches be applied 
> > upstream? I saw that you did edit a few files in the ksh93 tree.
> > Thank you for your time,
> > -Chase




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH][master-ksh93-upgrade] make it build under solaris and make patch obey POSIX

[Chase via cdesktopenv-devel]

Marcin,
I just ran the test suite and had no failures related to memory allocation, the 
only failure I ran into was this one:
test path begins at 2021-01-17+18:15:48
path.sh[356]: $SHELL -c of unreadable empty script should fail -- 
expected 126, got /tmp/ksh93.shtests.19281.6143/path.C/script: cannot open 126

Lev,
This is a known issue with upstream ksh93: 
https://github.com/ksh93/ksh/issues/3, maybe I am being a bit inconsiderate, 
but I think that the benefit of us not having to maintain our own decade old 
out of tree fork of ksh93 anymore is a worthy trade off for musl support. Could 
any of your most recent patches be applied upstream? I saw that you did edit a 
few files in the ksh93 tree.


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Sunday, January 17, 2021 5:54 PM, Marcin Cieslak  wrote:

> On Sun, 17 Jan 2021, Chase wrote:
>
> > Marcin you were right, it was ast malloc causing problems, I asked the 
> > leader of ksh if there was any way to disable it and he told me to pass 
> > -D_std_malloc. OpenBSD works perfectly now. Patch attached. I think we 
> > could safely merge this branch now if there are no further objections...
>
> Not quite - from what I've read using standard libc malloc breaks ksh93 
> subtly some tests of the test suite
> (haven't check with the fork you are using).
>
> What might happen here is that we pass the area allocated by ksh93 malloc but 
> that
> is about to be released using free() coming from libc...
>
> Thinking a bit about it, this might create bigger problems with dtksh, yuck
>
> Marcin




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH][master-ksh93-upgrade] make it build under solaris and make patch obey POSIX

[Chase via cdesktopenv-devel]

Marcin you were right, it was ast malloc causing problems, I asked the leader 
of ksh if there was any way to disable it and he told me to pass -D_std_malloc. 
OpenBSD works perfectly now. Patch attached. I think we could safely merge this 
branch now if there are no further objections...


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Sunday, January 17, 2021 2:48 PM, Marcin Cieslak  wrote:

> On Sun, 17 Jan 2021, Chase via cdesktopenv-devel wrote:
>
> > Not Working:
> > OpenBSD 6.7, segfaults whenever free() is called, but this does work with 
> > the old version, so it is a regression, but OpenBSD couldn't even boot when 
> > I compiled normal master, it hung at dthello
>
> Is this free() used in ksh, or libc free()? ksh93 brings in a library called 
> libast which includes its own malloc
> implementation. You might need to compile ksh93 and libast with debug symbols 
> to see what's going on there.
>
> One problem with libast's own malloc is that it uses ancient UNIX system call 
> sbrk(2) which
> is slowly phased out by FreeBSD - that's the reason why we can't have ksh93 
> on the latest FreeBSD
> systems on aarch64 architecture - the system call is simply not there.
>
> Marcin

From 91e4c5a954d3f5db0317413281ee718e3690d3dd Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sun, 17 Jan 2021 17:22:16 -0600
Subject: [PATCH] dtksh: use std malloc instead of ast malloc

---
 cde/programs/dtksh/Imakefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cde/programs/dtksh/Imakefile b/cde/programs/dtksh/Imakefile
index 18bad1f92..b2d6275ba 100644
--- a/cde/programs/dtksh/Imakefile
+++ b/cde/programs/dtksh/Imakefile
@@ -104,7 +104,7 @@ libshell.a: $(KSH93LIBSHELL) init.o
 	$(AR) libshell.a init.o
 
 pmain.o:
-	cd ksh93; ./bin/package flat make CCFLAGS='$(SUIDEXECDEFINES) -g'
+	cd ksh93; ./bin/package flat make CCFLAGS='$(SUIDEXECDEFINES) -g -D_std_malloc'
 	cp ./ksh93/src/cmd/ksh93/sh/init.c init.c
 	patch --posix init.c -i init.patch
 	./setup.sh
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH][master-ksh93-upgrade] make it build under solaris and make patch obey POSIX

[Chase via cdesktopenv-devel]

ool (p=0x633d4994d0, argpool=Variable "argpool" 
is not available.
)
at /usr/src/lib/libc/stdlib/malloc.c:1355
#4  0x0063de9b764a in ofree (argpool=0x7f7e7700, p=0x633d4994d0,
clear=0, check=0, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:1369
#5  0x0063de9b7580 in free (ptr=0x633d4994d0)
at /usr/src/lib/libc/stdlib/malloc.c:1488
#6  0x00612343e1a6 in stdCB (widget=0x6400fdec00,
clientData=0x63d5804400 "\200\fK�c", callData=0x7f7e7908 "\n")
at dtkcmds.c:3739
#7  0x0063d4f2e085 in XtCallCallbackList ()
   from /usr/X11R6/lib/libXt.so.11.0
#8  0x0063c5239fff in ActivateCommon (wid=0x6400fdec00,
event=0x7f7e7d60) at PushB.c:2229
#9  0x0063d4f6dba2 in HandleActions () from /usr/X11R6/lib/libXt.so.11.0
#10 0x0063d4f6b215 in _XtTranslateEvent ()
   from /usr/X11R6/lib/libXt.so.11.0
#11 0x0063d4f3eef9 in XtDispatchEventToWidget ()
   from /usr/X11R6/lib/libXt.so.11.0
#12 0x0063d4f3f85b in _XtDefaultDispatcher ()
---Type  to continue, or q  to quit---
   from /usr/X11R6/lib/libXt.so.11.0
#13 0x0063d4f3f34a in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.11.0
#14 0x0063d4f4c92e in XtAppProcessEvent ()
   from /usr/X11R6/lib/libXt.so.11.0
#15 0x0063d4f3fcd3 in XtMainLoop () from /usr/X11R6/lib/libXt.so.11.0
#16 0x00612343cf00 in do_XtMainLoop (argc=1, argv=0x636dc3a340)
at dtkcmds.c:
#17 0x00612340b97d in sh_exec (t=0x636dc3a2e0, flags=4)
at /home/cde/cde/programs/dtksh/ksh93/src/cmd/ksh93/sh/xec.c:1333
#18 0x00612338807c in exfile (shp=0x6123553270, iop=0x633d494ca0, fno=10)
at /home/cde/cde/programs/dtksh/ksh93/src/cmd/ksh93/sh/main.c:580
#19 0x00612338903c in sh_main (ac=2, av=0x7f7e8d88, userinit=0)
at /home/cde/cde/programs/dtksh/ksh93/src/cmd/ksh93/sh/main.c:350
#20 0x006123380379 in main (argc=2, argv=0x7f7e8d88)
at /home/cde/cde/programs/dtksh/ksh93/src/cmd/ksh93/sh/pmain.c:45
Current language:  auto; currently asm



Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Sunday, January 17, 2021 2:48 PM, Marcin Cieslak  wrote:

> On Sun, 17 Jan 2021, Chase via cdesktopenv-devel wrote:
>
> > Not Working:
> > OpenBSD 6.7, segfaults whenever free() is called, but this does work with 
> > the old version, so it is a regression, but OpenBSD couldn't even boot when 
> > I compiled normal master, it hung at dthello
>
> Is this free() used in ksh, or libc free()? ksh93 brings in a library called 
> libast which includes its own malloc
> implementation. You might need to compile ksh93 and libast with debug symbols 
> to see what's going on there.
>
> One problem with libast's own malloc is that it uses ancient UNIX system call 
> sbrk(2) which
> is slowly phased out by FreeBSD - that's the reason why we can't have ksh93 
> on the latest FreeBSD
> systems on aarch64 architecture - the system call is simply not there.
>
> Marcin




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH][master-ksh93-upgrade] make it build under solaris and make patch obey POSIX

[Chase via cdesktopenv-devel]

So here is where I am at with testing alternate platforms with the new imported 
ksh:
Working:
Linux Mint 20
CentOS 8 (patch needs to be explicitly installed for some reason, even though 
it is a POSIX utility)
FreeBSD 12.1
Openindiana hipster* (I needed to add a custom patch in dtdocbook that points 
make to the write version of tcl, -ltcl is incorrect, -ltcl8.6 isn't, not sure 
when this was changes since I don't use openindiana normally, but I am not 
going to mess with it since I know some people still use legacy opensolaris and 
I assume it is -ltcl on there)

Not Working:
OpenBSD 6.7, segfaults whenever free() is called, but this does work with the 
old version, so it is a regression, but OpenBSD couldn't even boot when I 
compiled normal master, it hung at dthello
manjaro, fedora 33, opensuse: this was only because the gcc 10 patches haven't 
been applied to master-ksh93-upgrade yet, if centos 8 works, these probably 
should as well

Unknown: NetBSD, couldn't get package manager to cooperate

Not tested: solaris 11.4, aix, hpux (lack of legal way to get them)

I feel like this should be sufficient, I wouldn't know where to start with the 
OpenBSD segfault however, I know almost nothing about how they do memory 
management...

Thank you for your time,
-ChaseFrom 6eea340e2219cac27ec5e59dd2eba61ba9e98597 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sat, 16 Jan 2021 14:53:03 -0600
Subject: [PATCH 1/2] dtksh/Imakefile: make patch obey POSIX

---
 cde/programs/dtksh/Imakefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cde/programs/dtksh/Imakefile b/cde/programs/dtksh/Imakefile
index 177019904..78c00ba9b 100644
--- a/cde/programs/dtksh/Imakefile
+++ b/cde/programs/dtksh/Imakefile
@@ -107,7 +107,7 @@ libshell.a: $(KSH93LIBSHELL) init.o
 pmain.o:
 	cd ksh93; ./bin/package flat make CCFLAGS='$(SUIDEXECDEFINES) -g'
 	cp ./ksh93/src/cmd/ksh93/sh/init.c init.c
-	patch -u init.c -i init.patch
+	patch --posix init.c -i init.patch
 	./setup.sh
 
 SpecialObjectRule(init.o, $(NULL), -DSHOPT_STATS -DSHOPT_NAMESPACE -DSHOPT_2DMATCH -DSHOPT_PFSH -DSHOPT_MULTIBYTE -DSHOPT_BGX -DSHOPT_AUDIT '-D_API_ast=20100309' -D_PACKAGE_ast -DSHOPT_DYNAMIC -D_BLD_shell -DSHOPT_KIA -DKSHELL -DSHOPT_HISTEXPAND -DSHOPT_EDPREDICT -DSHOPT_ESH -DSHOPT_VSH -DSHOPT_FIXEDARRAY '-DERROR_CONTEXT_T=Error_context_t' -DSHOPT_SUID_EXEC -DSHOPT_BRACEPAT -DBUILD_DTKSH -l$(KSH93SRC)/lib/libcmd.a  -l$(KSH93SRC)/lib/libast.a -l$(KSH93SRC)/lib/libdll.a)
-- 
2.17.1

From d1f670996475f1fe743725f1774fb048a0a8b1dd Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sun, 17 Jan 2021 14:16:11 -0600
Subject: [PATCH 2/2] dtksh: make it build under openindiana

---
 cde/programs/dtksh/Imakefile   |  3 +--
 cde/programs/dtksh/dtkcmds.c   |  2 --
 cde/programs/dtksh/dtkcvt.c|  2 --
 cde/programs/dtksh/dtksh.h |  2 --
 cde/programs/dtksh/init.patch  | 24 +++-
 cde/programs/dtksh/ksh93   |  2 +-
 cde/programs/dtksh/widget.c|  2 --
 cde/programs/dtksh/widget.h|  2 --
 cde/programs/dtksh/xmcmds.c|  2 --
 cde/programs/dtksh/xmcvt.c |  2 --
 cde/programs/dtksh/xmwidgets.c |  2 --
 11 files changed, 9 insertions(+), 36 deletions(-)

diff --git a/cde/programs/dtksh/Imakefile b/cde/programs/dtksh/Imakefile
index 78c00ba9b..18bad1f92 100644
--- a/cde/programs/dtksh/Imakefile
+++ b/cde/programs/dtksh/Imakefile
@@ -29,8 +29,7 @@ LOCAL_LDFLAGS = -bE:dtksh.exp
 #ifdef SunArchitecture
 .NO_PARALLEL:
 
-/* These need to be manually set for Solaris due to a bug in the build system */
-KSH_LDFLAGS = -lm -lsocket
+SYS_LIBRARIES = -lm -lsecdb -lsocket -lnsl
 #endif
 
 DEPEND_DEFINES = $(DEPENDDEFINES)
diff --git a/cde/programs/dtksh/dtkcmds.c b/cde/programs/dtksh/dtkcmds.c
index 43c5b1baa..8528e8a29 100644
--- a/cde/programs/dtksh/dtkcmds.c
+++ b/cde/programs/dtksh/dtkcmds.c
@@ -58,9 +58,7 @@
 #include "hash.h"
 #include "stdio.h"
 #include "defs.h"
-#define NO_AST
 #include "dtksh.h"
-#undef NO_AST
 #include "xmksh.h"
 #include "dtkcmds.h"
 #include "xmcvt.h"
diff --git a/cde/programs/dtksh/dtkcvt.c b/cde/programs/dtksh/dtkcvt.c
index f2414376c..2b0a2d36a 100644
--- a/cde/programs/dtksh/dtkcvt.c
+++ b/cde/programs/dtksh/dtkcvt.c
@@ -55,9 +55,7 @@
 #include 
 #include "hash.h"
 #include "stdio.h"
-#define NO_AST
 #include "dtksh.h"
-#undef NO_AST
 #include "xmksh.h"
 #include "XtCvtrs.h"
 #include "dtkcmds.h"
diff --git a/cde/programs/dtksh/dtksh.h b/cde/programs/dtksh/dtksh.h
index 0205c0d95..1313c414f 100644
--- a/cde/programs/dtksh/dtksh.h
+++ b/cde/programs/dtksh/dtksh.h
@@ -33,9 +33,7 @@
 #ifndef _Dtksh_dtksh_h
 #define _Dtksh_dtksh_h
 
-#if !defined(NO_AST)
 #include "nval.h"
-#endif
 
 #define SUCCESS		0
 #define FAIL		(-1)
diff --git a/cde/programs/dtksh/init.patch b/cde/programs/dtksh/init.patch
index 7da703098..8fd85079f 100644
--- a/cde/programs/dtksh/init.patch
+++ b/cde/programs/dtksh/init.patch
@@ -1,31 +1,22 @@
 ./ksh93/src/cmd/ksh93/sh/init.c	2020-11-22 15:34:35.964537420 -0600
-+++ init.c	2020-12-31 19:

Re: [cdesktopenv-devel] [PATCH] use flat make instead of make shell command

[Chase via cdesktopenv-devel]

Actually, ignore that last patch, I have an even better one: this one gets rid 
of init.c entirely and instead uses a patch file to augment it when the 
makefile copies it over, thus avoiding the error and allowing us to keep 
./bin/package flat make in the dtksh Imakefile where it belongs. Merge this one 
after the very first patch i posted in this thread.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Tuesday, December 29, 2020 9:44 PM, Chase  wrote:

> I appear to have missed a non-fatal error in the depend process. I will need 
> to move building ksh back to the top makefile, however this will probably be 
> able to be moved back when I port it to autotools. Patch attached (merge this 
> after the first patch I attached).
>
> Thank you for your time,
> -Chase
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, December 28, 2020 10:49 PM, Chase via cdesktopenv-devel 
>  wrote:
>
>> Marcin pointed out to me that the shell command in make is a gnu extension 
>> and is thus not portable. The solution to this was to use "flat make" that 
>> puts the ksh binary in a static directory, which also allowed me to undo the 
>> weird workaround I had to implement in the topmost makefile. This commit 
>> also trims some fat by removing unused symbols and a strange hpux dynlib 
>> implementation (hpux is posix anyways).
>>
>> Thank you for your time,
>> -ChaseFrom aa7d1fba3576f02960810c0eba6f33203986b337 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Thu, 31 Dec 2020 21:42:58 -0600
Subject: [PATCH] dtksh: use a patchfile to augment init.c instead of copying
 it entirely

---
 cde/.gitignore|2 +-
 cde/databases/CDE-MIN.udb |2 +-
 cde/programs/dtksh/Imakefile  |5 +-
 cde/programs/dtksh/init.c | 2142 -
 cde/programs/dtksh/init.patch |   58 +
 5 files changed, 63 insertions(+), 2146 deletions(-)
 delete mode 100644 cde/programs/dtksh/init.c
 create mode 100644 cde/programs/dtksh/init.patch

diff --git a/cde/.gitignore b/cde/.gitignore
index ea560b40a..18675565c 100644
--- a/cde/.gitignore
+++ b/cde/.gitignore
@@ -908,7 +908,7 @@ programs/dtinfo/tools/misc/treeres
 # program/dtksh
 programs/dtksh/FEATURE
 programs/dtksh/dtksh
-programs/dtksh/suid_exec
+programs/dtksh/init.c
 programs/dtksh/examples/CallDataTest4
 programs/dtksh/examples/CallbackTest2
 programs/dtksh/examples/DtCursorTest2
diff --git a/cde/databases/CDE-MIN.udb b/cde/databases/CDE-MIN.udb
index 8dcaaf651..409e26c11 100644
--- a/cde/databases/CDE-MIN.udb
+++ b/cde/databases/CDE-MIN.udb
@@ -214,7 +214,7 @@ programs/dtksh/dtksh
 	mode = 0555
 }
 #
-programs/dtksh/suid_exec
+programs/dtksh/ksh93/bin/suid_exec
 { default
 	install_target = /usr/dt/bin/suid_exec
 	owner = root
diff --git a/cde/programs/dtksh/Imakefile b/cde/programs/dtksh/Imakefile
index 298ccc806..aa6579a31 100644
--- a/cde/programs/dtksh/Imakefile
+++ b/cde/programs/dtksh/Imakefile
@@ -106,8 +106,9 @@ libshell.a: $(KSH93LIBSHELL) init.o
 
 pmain.o:
 	cd ksh93; ./bin/package flat make CCFLAGS='$(SUIDEXECDEFINES) -g'
+	cp ./ksh93/src/cmd/ksh93/sh/init.c init.c
+	patch -u init.c -i init.patch
 	./setup.sh
-	cp ./ksh93/bin/suid_exec suid_exec
 
 SpecialObjectRule(init.o, $(NULL), -DSHOPT_STATS -DSHOPT_NAMESPACE -DSHOPT_2DMATCH -DSHOPT_PFSH -DSHOPT_MULTIBYTE -DSHOPT_BGX -DSHOPT_AUDIT '-D_API_ast=20100309' -D_PACKAGE_ast -DSHOPT_DYNAMIC -D_BLD_shell -DSHOPT_KIA -DKSHELL -DSHOPT_HISTEXPAND -DSHOPT_EDPREDICT -DSHOPT_ESH -DSHOPT_VSH -DSHOPT_FIXEDARRAY '-DERROR_CONTEXT_T=Error_context_t' -DSHOPT_SUID_EXEC -DSHOPT_BRACEPAT -DBUILD_DTKSH -l$(KSH93SRC)/lib/libcmd.a  -l$(KSH93SRC)/lib/libast.a -l$(KSH93SRC)/lib/libdll.a)
 
@@ -115,5 +116,5 @@ ComplexProgramTarget($(PROGRAMS))
 
 clean::
 	cd ksh93; ./bin/package flat clean
-	rm -f suid_exec
+	rm -f init.c
 	rm -rf FEATURE
diff --git a/cde/programs/dtksh/init.c b/cde/programs/dtksh/init.c
deleted file mode 100644
index 7f05ce1fb..0
--- a/cde/programs/dtksh/init.c
+++ /dev/null
@@ -1,2142 +0,0 @@
-/***
-*  *
-*   This software is part of the ast package   *
-*  Copyright (c) 1982-2012 AT&T Intellectual Property  *
-*  and is licensed under the   *
-* Eclipse Public License, Version 1.0  *
-*by AT&T Intellectual Property *
-*  *
-*A copy of the License is available at *
-*  http://www.eclipse.org/org/documents/epl-v10.html   *
-* (with md5 checksum b35adb5213ca9657e911e9befb180842)

Re: [cdesktopenv-devel] [PATCH] use flat make instead of make shell command

[Chase via cdesktopenv-devel]

I appear to have missed a non-fatal error in the depend process. I will need to 
move building ksh back to the top makefile, however this will probably be able 
to be moved back when I port it to autotools. Patch attached (merge this after 
the first patch I attached).

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Monday, December 28, 2020 10:49 PM, Chase via cdesktopenv-devel 
 wrote:

> Marcin pointed out to me that the shell command in make is a gnu extension 
> and is thus not portable. The solution to this was to use "flat make" that 
> puts the ksh binary in a static directory, which also allowed me to undo the 
> weird workaround I had to implement in the topmost makefile. This commit also 
> trims some fat by removing unused symbols and a strange hpux dynlib 
> implementation (hpux is posix anyways).
>
> Thank you for your time,
> -ChaseFrom 5c2b9087cc643ca193efd694b8db90a648c069d3 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Tue, 29 Dec 2020 21:38:08 -0600
Subject: [PATCH] dtksh: fix init.c .depend error

---
 cde/Makefile | 6 ++
 cde/programs/dtksh/Imakefile | 1 -
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/cde/Makefile b/cde/Makefile
index fcc8639c5..095d71e28 100644
--- a/cde/Makefile
+++ b/cde/Makefile
@@ -23,6 +23,11 @@
FLAGS = $(MFLAGS) -f Makefile.ini BOOTSTRAPCFLAGS="$(BOOTSTRAPCFLAGS)"
 CDE_CONFIGURATION_TOP = /etc/dt
 CDE_INSTALLATION_TOP = /usr/dt
+SUIDEXECDEFINES = \
+-DPROFILEPATH=\"$(CDE_CONFIGURATION_TOP)/config/profile\" \
+-DSUIDPROFILEPATH=\"$(CDE_CONFIGURATION_TOP)/config/suid_profile\" \
+-DSUIDEXECPATH=\"$(CDE_INSTALLATION_TOP)/bin/suid_exec\" \
+-DCDE_INSTALLATION_TOP=\"$(CDE_INSTALLATION_TOP)\" -DBUILD_DTKSH
 
 all:
 	@$(MAKE_CMD) xmakefile-exists || $(MAKE) all-initial
@@ -60,6 +65,7 @@ World:
 	$(MAKE_CMD) $(MFLAGS) Makefiles.doc
 	$(MAKE_CMD) $(MFLAGS) clean
 	$(MAKE_CMD) $(MFLAGS) clean.doc
+	cd programs/dtksh/ksh93; ./bin/package flat make CCFLAGS='$(SUIDEXECDEFINES) -g'
 	$(MAKE_CMD) $(MFLAGS) includes
 	$(MAKE_CMD) $(MFLAGS) includes.doc
 	$(MAKE_CMD) $(MFLAGS) depend
diff --git a/cde/programs/dtksh/Imakefile b/cde/programs/dtksh/Imakefile
index 298ccc806..ec6a48bc0 100644
--- a/cde/programs/dtksh/Imakefile
+++ b/cde/programs/dtksh/Imakefile
@@ -105,7 +105,6 @@ libshell.a: $(KSH93LIBSHELL) init.o
 	$(AR) libshell.a init.o
 
 pmain.o:
-	cd ksh93; ./bin/package flat make CCFLAGS='$(SUIDEXECDEFINES) -g'
 	./setup.sh
 	cp ./ksh93/bin/suid_exec suid_exec
 
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] use flat make instead of make shell command

[Chase via cdesktopenv-devel]

Marcin pointed out to me that the shell command in make is a gnu extension and 
is thus not portable. The solution to this was to use "flat make" that puts the 
ksh binary in a static directory, which also allowed me to undo the weird 
workaround I had to implement in the topmost makefile. This commit also trims 
some fat by removing unused symbols and a strange hpux dynlib implementation 
(hpux is posix anyways).

Thank you for your time,
-ChaseFrom 1985958d646be497694798a08e07dd0fdbf1cd02 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Mon, 28 Dec 2020 20:35:39 -0600
Subject: [PATCH] dtksh: use bin/package flat make instead of shell

Shell isn't portable, so upstream ksh93 has a "flat" function that we can use
to put binaries in a static place that doesn't require a shell command. We still
do need an intermediate setup.sh shell script due to a bug in ksh that object
files aren't being put in lib, and FEATURE not in include. We also cut out some
 unused symbols, and a hpux specific implementation of dynlib (new hpux should
 conform to the posix implementation anyhow.)
---
 cde/.gitignore  |   5 +-
 cde/Makefile|   9 -
 cde/programs/dtksh/Imakefile|  34 +-
 cde/programs/dtksh/README-DEVELOPER |   3 +-
 cde/programs/dtksh/exksh.h  | 240 --
 cde/programs/dtksh/findsym.c|  31 +-
 cde/programs/dtksh/ksh93|   2 +-
 cde/programs/dtksh/setup.sh |   9 +
 cde/programs/dtksh/xmdtksym.c   | 465 
 cde/programs/dtksh/xmdtksym.h   |  51 ---
 10 files changed, 28 insertions(+), 821 deletions(-)
 delete mode 100644 cde/programs/dtksh/exksh.h
 create mode 100755 cde/programs/dtksh/setup.sh
 delete mode 100644 cde/programs/dtksh/xmdtksym.c
 delete mode 100644 cde/programs/dtksh/xmdtksym.h

diff --git a/cde/.gitignore b/cde/.gitignore
index 81888d17d..ea560b40a 100644
--- a/cde/.gitignore
+++ b/cde/.gitignore
@@ -906,6 +906,7 @@ programs/dtinfo/tools/misc/pmaker
 programs/dtinfo/tools/misc/treeres
 
 # program/dtksh
+programs/dtksh/FEATURE
 programs/dtksh/dtksh
 programs/dtksh/suid_exec
 programs/dtksh/examples/CallDataTest4
@@ -1033,10 +1034,6 @@ programs/fontaliases/sun/ja/dtinfo.pcf.gz
 programs/fontaliases/sun/ja/dtinfo.pcf.Z
 programs/fontaliases/sun/ja/fonts.dir
 
-# programs/ksh93
-programs/dtksh/ksh93/man/man1/sh.1
-programs/dtksh/ksh93/man/man3/nval.3
-
 # programs/localized
 programs/localized/C/types/*.dt
 programs/localized/C/types/*.dt.tmsg
diff --git a/cde/Makefile b/cde/Makefile
index d338a349e..fcc8639c5 100644
--- a/cde/Makefile
+++ b/cde/Makefile
@@ -21,11 +21,6 @@
 MAKE_CMD = $(MAKE) $(MAKE_OPTS)
NMAKE_CMD = $(NMAKE) $(MAKE_OPTS)
FLAGS = $(MFLAGS) -f Makefile.ini BOOTSTRAPCFLAGS="$(BOOTSTRAPCFLAGS)"
-SUIDEXECDEFINES = \
--DPROFILEPATH=\"$(CDE_CONFIGURATION_TOP)/config/profile\" \
--DSUIDPROFILEPATH=\"$(CDE_CONFIGURATION_TOP)/config/suid_profile\" \
--DSUIDEXECPATH=\"$(CDE_INSTALLATION_TOP)/bin/suid_exec\" \
--DCDE_INSTALLATION_TOP=\"$(CDE_INSTALLATION_TOP)\" -DBUILD_DTKSH
 CDE_CONFIGURATION_TOP = /etc/dt
 CDE_INSTALLATION_TOP = /usr/dt
 
@@ -58,10 +53,6 @@ World:
 	;; esac;
 	@date
 	@echo ""
-	# this is a weird glitch in the build process, will probably be solved
-	# with autotools conversion, but we need to build here for now
-	cd programs/dtksh/ksh93; ./bin/package clean
-	cd programs/dtksh/ksh93; ./bin/package make CCFLAGS='$(SUIDEXECDEFINES) -g'
 	cd $(IMAKESRC) && $(MAKE) $(FLAGS) clean
 	$(MAKE) $(MFLAGS) Makefile.boot
 	$(MAKE_CMD) $(MFLAGS) VerifyOS
diff --git a/cde/programs/dtksh/Imakefile b/cde/programs/dtksh/Imakefile
index 7f5f524ad..298ccc806 100644
--- a/cde/programs/dtksh/Imakefile
+++ b/cde/programs/dtksh/Imakefile
@@ -8,8 +8,6 @@ SUBDIRS = examples
 
 MakeSubdirs($(SUBDIRS))
 
-HOSTDIR = $(shell ./ksh93/bin/package host)
-
 KSH93SRC = ./ksh93
 
 SYS_LIBRARIES = -lm $(DYNLIBSYSLIB) $(REGEXSYSLIB) $(ICONVSYSLIB)
@@ -19,27 +17,25 @@ SYS_LIBRARIES = -lm -ldl
 #endif
 
 #ifdef HPArchitecture
-EXTRA_DEFINES = -Wl,-E -DHPUX_DYNLIB -Wp,-H12000
+EXTRA_DEFINES = -Wl,-E -Wp,-H12000
 SYS_LIBRARIES = -lm -ldld 
 #endif
 
 #ifdef RsArchitecture
-EXTRA_DEFINES = -DDYNLIB -D_IBMRPC_
+EXTRA_DEFINES = -D_IBMRPC_
 LOCAL_LDFLAGS = -bE:dtksh.exp
 #endif
 
 #ifdef SunArchitecture
 .NO_PARALLEL:
 
-EXTRA_DEFINES = -DDYNLIB
-
 /* These need to be manually set for Solaris due to a bug in the build system */
 KSH_LDFLAGS = -lm -lsocket
 #endif
 
 DEPEND_DEFINES = $(DEPENDDEFINES)
-INCLUDES = -I. -I$(KSH93SRC)/arch/$(HOSTDIR)/include/ast \
-	   -I$(KSH93SRC)/arch/$(HOSTDIR)/src/cmd/ksh93 \
+INCLUDES = -I. -I$(KSH93SRC)/include/ast \
+	   -I$(KSH93SRC)/src/cmd/ksh93 \
 	   -I$(KSH93SRC)/src/cmd/ksh93/include -I$(KSH93SRC)/src/cmd/ksh93 \
 	   -I$(KSH93SRC)/src/lib/libast/include $(TIRPCINC)
 
@@ -54,14 +50,13 @@ INCLUDES = -I. -I$(KSH93SRC)/arch/$(HOSTDIR)/include/ast \
  */
 DEPLIBS = $(DEPDTHELPLIB) $(DEPDTSVCLIB) $(DEPDTWIDGETLIB) $(DEP

[cdesktopenv-devel] [PATCH] [KSH93-UPGRADE-MASTER] use ksh93's Empty macro instead of ""

[Chase via cdesktopenv-devel]

The maintainer of ksh93 suggested that I use the Empty macro (" \t\n"+3) 
instead of an empty string, both function the exact same but apparently there 
is a chance "" could conflict with some ksh93 internals, so I am fixing it.

Thank you for your time,
-ChaseFrom c88ab45459ff555e780b586021650eb9c5245a0d Mon Sep 17 00:00:00 2001
From: Chase 
Date: Fri, 11 Dec 2020 14:09:56 -0600
Subject: [PATCH] dtkcmds.c: use Empty macro instead of empty string

---
 cde/programs/dtksh/dtkcmds.c | 45 ++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/cde/programs/dtksh/dtkcmds.c b/cde/programs/dtksh/dtkcmds.c
index 609aa1230..43c5b1baa 100644
--- a/cde/programs/dtksh/dtkcmds.c
+++ b/cde/programs/dtksh/dtkcmds.c
@@ -57,6 +57,7 @@
 #include 
 #include "hash.h"
 #include "stdio.h"
+#include "defs.h"
 #define NO_AST
 #include "dtksh.h"
 #undef NO_AST
@@ -7897,7 +7898,7 @@ nopCreateDisc(
 
np2 = CreateEmptyNameValuePair(np, token, fp);
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -7940,7 +7941,7 @@ dftCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -7971,7 +7972,7 @@ ehCreateDisc(
token = strtok(tmpBuf, ".");
np2 = ProcessCallbackEvent(event, np, token, fp);
XtFree(tmpBuf);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8002,7 +8003,7 @@ transCreateDisc(
token = strtok(tmpBuf, ".");
np2 = ProcessCallbackEvent(event, np, token, fp);
XtFree(tmpBuf);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8042,7 +8043,7 @@ scaleCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8090,7 +8091,7 @@ arrowCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8136,7 +8137,7 @@ comboCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8185,7 +8186,7 @@ cmdCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8225,7 +8226,7 @@ dAreaCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8275,7 +8276,7 @@ dbtnCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8354,7 +8355,7 @@ fselCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8453,7 +8454,7 @@ listCreateDisc(
   np2 =  CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8501,7 +8502,7 @@ pbtnCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8555,7 +8556,7 @@ rcCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8602,7 +8603,7 @@ sbarCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8644,7 +8645,7 @@ swinCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8693,7 +8694,7 @@ sboxCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8733,7 +8734,7 @@ tbtnCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -8894,7 +8895,7 @@ textCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -9006,7 +9007,7 @@ textCreateDisc2(
 
XtFree(nameCopy);
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -9085,7 +9086,7 @@ helpCreateDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
@@ -9125,7 +9126,7 @@ dtPrintSetupProcDisc(
   np2 = CreateEmptyNameValuePair(np, token, fp);
 
XtFree(dupName);
-   fp->last = "";
+   fp->last = Empty;
return(np2);
 }
 
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.

Re: [cdesktopenv-devel] git version fails to build on Debian derivative PureOS

[Chase via cdesktopenv-devel]

Antonis,
For your locale error, if you would simply like to install CDE with english 
only, you can actually ignore that error, I always build CDE and installed it 
with this error present, as I refuse to install the other locales as I dont 
want them taking up useless space on my disk. I have not noticed any negative 
side effects of doing so other than make and the install scripts complaining. 
If you'd like, you could install an old version (2.3.0) that disables the 
alternate locales by default until something can be done about this error, I 
feel like it might have to do with the recent addition of utf8 support but I 
have no proof of this, nor do I want to point any fingers.

For your dtsrcreate error, I spun up a VM with pure os 9 running, I followed 
the instructions as if I were on the latest release of ubuntu, and aside from 
having to install bison again after I had already installed it, everything 
worked fine, could I get a log of your build?

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Thursday, November 12, 2020 3:54 AM, Antonis Tsolomitis 
 wrote:

> Both stable and git versions have the same problems on both PureOS (=Debian 
> testing) and Manjaro Linux.
> It is not only documentation that does not get build. dtstyle does not get 
> build either. dthelpview and all doc programs.
> But dtstyle why? It has nothing ti do with locale. Does it?
>
> The stable version ends up with a success message although earlier it has 
> errors.
> For example:
>
> make[4]: Entering directory '/home/atsol/Downloads/cde-2.3.2/doc/C/guides'
> LANG=C SGML_SEARCH_PATH=".:.." 
> LD_LIBRARY_PATH=../../../exports/lib:/usr/dt/lib:/usr/lib 
> DTLCXSEARCHPATH=../../../lib/DtHelp 
> DTINFO_HOME=../../../programs/dtinfo/dtinfogen 
> DTINFO_BIN=../../../programs/dtinfo/dtinfogen/install:../../../programs/dtinfo/dtinfogen/mmdb/StyleSheet:../../../programs/dtinfo/dtinfogen/mmdb/src:../../../programs/nsgmls:../../../programs/dtsr
>  ../../../programs/dtinfo/dtinfogen/infolib/etc/dtinfogen tocgen -T 
> ../../../doc/tmp -n cde -d "CDE and Motif Information Library" -f 
> usersGuide/TOC.sgm -id cde.usersGuide.toc -title "User's Guide" 
> usersGuide/book.sgm
> dtinfogen: dtsrcreate not found
> make[4]: *** [Makefile:767: usersGuide/TOC.sgm] Error 255
>
> blah blah blah (=errors for locales) and then:
>
> Full build of Release 2.3.2 of CDE complete.
>
> In the wiki there are instructions for Arch which I used for Manjaro. But I 
> will try Arch too although I do not think
> that this is the problem. I expected to compile on Debian testing but it does 
> not.
>
> Antonis.
>
> On 11/9/20 7:38 AM, Brian Cole wrote:
>
>> Aha! I can, however, also reproduce your solution:)
>> https://builds.sr.ht/~yjftsjthsd/job/337668 is the same as before, except 
>> that it starts by running:
>>
>> sudo locale-gen de_DE
>>   sudo locale-gen es_ES
>>   sudo locale-gen fr_FR
>>   sudo locale-gen it_IT
>>   sudo update-locale
>>
>> And that works:) I'm not convinced that it makes sense to require having all 
>> that (can we do a CDE build with just C/en_US?), but it does work. If we do 
>> want that to be The Solution, then at a minimum the wiki should be updated 
>> and we should find out what the equivalent is on other supported OSs.
>>
>> On Sun, Nov 8, 2020, at 11:46 PM, Brian Cole wrote:
>>
>>> FWIW, I can easily reproduce this building from master on Ubuntu 18.04;
>>> * https://builds.sr.ht/~yjftsjthsd/job/337574 is a build with just `make 
>>> World` and fails
>>> * https://builds.sr.ht/~yjftsjthsd/job/337610 is a build with `make 
>>> World.dev` and succeeds
>>> * https://builds.sr.ht/~yjftsjthsd/job/337637 is a build with `make World` 
>>> preceeded by `export LANG=C` and fails
>>> * https://builds.sr.ht/~yjftsjthsd/job/337644 is a build with `make World` 
>>> preceeded by `export LANG=it_IT.ISO8859-1` and fails
>>>
>>> (you can hit "view manifest" on the left to see the exact commands in each 
>>> build)
>>>
>>> On Sun, Nov 8, 2020, at 6:01 AM, Edmond Orignac wrote:
>>>
 Is the italian locale installed ? on Ubuntu 20.04, locale -a |grep -i 
 iso8859 gives

 de_DE.iso88591
 es_ES.iso88591
 fr_FR.iso88591
 it_IT.iso88591

 and the CDE build succeeds.

 Another possibility is that the build of the documentation fails when the 
 locale is UTF-8.

 You could try to do export LANG=C or export LANG=it_IT.ISO8859-1 before 
 make World

 to see if the build succeeds.

 As a last option, you could try to do make World.dev to exclude building 
 the documentation.

 I expect the developpers will have better ideas to try out.

 Best,

 E. Orignac

 Le 08/11/2020 à 11:23, Antonis Tsolomitis a écrit :

> I just saw that Mike T. has the same problem in Arch. So it is not a 
> Debian/PureOS problem.
>
> Antonis.
>
> On 11/8/20 12:04 PM, Antonis Tsolomitis wrote:
>
>> I am 

Re: [cdesktopenv-devel] CDE 2.3.2 fails to build with glibc 2.32

[Chase via cdesktopenv-devel]

Nina,
This appears to be an issue with the old outdated ksh that we use, this problem 
shouldn't exist on the updated master-ksh93-upgrade branch if you would like to 
try using that for the time being until it gets merged.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Wednesday, October 21, 2020 10:38 AM, Нина Диденко  
wrote:

> Meh...
> https://sourceware.org/glibc/wiki/Release/2.32#Deprectation_sys_errlist.2C__sys_errlist.2C_sys_nerr.2C_and__sys_nerr
>
> ср, 21 окт. 2020 г. в 18:33, Нина Диденко :
>
>> Thanks, Michael!
>>
>> Now I'm getting the following error:
>>
>> /nix/store/hiwz81i1g3fn3p0acjs042a4h5fri6dh-binutils-2.31.1/bin/ld: 
>> ./ksh93/lib/libast.a(fmterror.o): in function `fmterror':
>> /build/cde-2.3.2/programs/dtksh/ksh93/src/lib/libast/string/fmterror.c:102: 
>> undefined reference to `sys_nerr'
>> /nix/store/hiwz81i1g3fn3p0acjs042a4h5fri6dh-binutils-2.31.1/bin/ld: 
>> /build/cde-2.3.2/programs/dtksh/ksh93/src/lib/libast/string/fmterror.c:102: 
>> undefined reference to `sys_errlist'
>> collect2: error: ld returned 1 exit status
>> make[3]: *** [Makefile:793: dtksh] Error 1
>> make[3]: Leaving directory '/build/cde-2.3.2/programs/dtksh'
>> make[2]: *** [Makefile:737: all] Error 2
>> make[2]: Leaving directory '/build/cde-2.3.2/programs'
>> make[1]: *** [xmakefile:734: all] Error 2
>> make[1]: Leaving directory '/build/cde-2.3.2'
>> make: *** [Makefile:61: World] Error 2
>> builder for '/nix/store/yn0bax5w8lqspwcx86p21shsnp6mcmcx-cde-2.3.2.drv' 
>> failed with exit code 2
>> error: build of '/nix/store/yn0bax5w8lqspwcx86p21shsnp6mcmcx-cde-2.3.2.drv' 
>> failed
>>
>> I wonder what is the proper way to fix this. I seen some projects used hacks 
>> like this https://github.com/OpenXRay/xray-16/issues/667
>>
>> ср, 21 окт. 2020 г. в 16:14, Michael Griffin :
>>
>>> I had this problem on Fedora. I installed the rpcgen package and was able 
>>> to compile through that section.
>>>
>>> Name : rpcgen
>>> Version : 1.4
>>> Release : 4.fc32
>>> Architecture : x86_64
>>> Size : 53 k
>>> Source : rpcsvc-proto-1.4-4.fc32.src.rpm
>>> Repository : fedora
>>> Summary : RPC protocol compiler
>>> URL : https://github.com/thkukuk/rpcsvc-proto
>>> License : BSD and LGPLv2+
>>> Description : rpcgen is a tool that generates C code to implement an RPC
>>> : protocol. The input to rpcgen is a language similar to C known as
>>> : RPC Language (Remote Procedure Call Language).
>>>
>>> By my hand, I am,
>>>
>>> Michael E. Griffin
>>>
>>> On Wed, Oct 21, 2020 at 3:55 AM Нина Диденко  wrote:
>>>
 Hi.
 According to git bisect, after updating glibc from 2.31 to 2.32 in NixOS 
 distro, CDE 2.3.2 now fails to build,
 Could anyone please provide a fix?

 make[3]: Entering directory '/build/cde-2.3.2/lib/csa'
 rm -f agent.o
 gcc -g -pipe -c -O2 -fno-strict-aliasing -Wno-write-strings 
 -Wno-unused-result -ansi -I. 
 -I/nix/store/wn4skrmv9gbag04pyj76c7qaw7x4cdq1-libtirpc-1.2.7-rc4-dev/include/tirpc
  -I../.. -I../../exports/include -I../../imports/motif/include 
 -I/nix/store/ky9k6ifn9mn09lq6bb2q9npz4nx4459z-x11ProjectRoot/include 
 -D__linux__ -D__x86_64__ -D_POSIX_SOURCE -D_DEFAULT_SOURCE -D_BSD_SOURCE 
 -D_SVID_SOURCE -D__NO_STRING_INLINES -D__NO_MATH_INLINES -DANSICPP 
 -DMULTIBYTE -DNLS16 -DOSMAJORVERSION=5 -DOSMINORVERSION=4 -DFUNCPROTO=15 
 -DNARROWPROTO -D_REENTRANT -DXUSE_MTSAFE_API -DRFC_MIME -DLINE_COUNT -DV2 
 -DOW_I18N -DREL="54" -DRELMAJOR="5" -DRELMINOR="4" -fPIC agent.c
 agent.c: In function '_DtCm_init_agent':
 agent.c:150:43: error: 'AGENTVERS' undeclared (first use in this 
 function); did you mean 'AGENTVERS_2'?
 150 | (void)pmap_unset(_DtCm_transient, AGENTVERS);
 | ^
 | AGENTVERS_2
 agent.c:150:43: note: each undeclared identifier is reported only once for 
 each function it appears in
 agent.c:157:46: error: 'update_callback' undeclared (first use in this 
 function)
 157 | if (registerrpc(_DtCm_transient, AGENTVERS, update_callback,
 | ^~~
 agent.c:158:19: error: '_DtCm_update_callback_1' undeclared (first use in 
 this function); did you mean 'cmcb_update_callback_2'?
 158 | (char *(*)())_DtCm_update_callback_1, 
 (xdrproc_t)_DtCm_xdr_Table_Res_4,
 | ^~~
 | cmcb_update_callback_2
 agent.c:159:17: error: '_DtCm_xdr_Update_Status' undeclared (first use in 
 this function); did you mean '_DtCm_xdr_Appt_Status_4'?
 159 | (xdrproc_t)_DtCm_xdr_Update_Status) == -1) {
 | ^~~
 | _DtCm_xdr_Appt_Status_4
 agent.c: In function '_DtCm_destroy_agent':
 agent.c:192:44: error: 'AGENTVERS' undeclared (first use in this 
 function); did you mean 'AGENTVERS_2'?
 192 | (void) pmap_unset(_DtCm_transient, AGENTVERS);
 | ^
 | AGENTVERS_2
 agent.c: At top level:
 agent.c:297:1: error: unknown type name 'Update_Status'
 297 | Update_Status *

Re: [cdesktopenv-devel] [PATCH] update to most recent commit, fix segfault, offload local changes

[Chase via cdesktopenv-devel]

Assigning them to NULL coredumps as fp->last gets dereferenced in name.c (line 
1192).

Directions on cloning and checking out the branch:
git clone --recurse-submodules
git checkout --recurse-submodules ksh93-master-upgrade
Building should still be straightforward, make World, however, if you want to 
manually clean, a bug in how the Imakefiles would generate dependencies means 
that you need to manually run ./programs/dtksh/bin/package clean and then make 
clean

Alternatively, we could fork, but I think this should be a last resort if 
upstream dies. This could also be advantageous to us if we wanted to convert 
ksh93 to automake, but in a list of things I want to do in my life, that task 
ranks extremely low.

As for testing on alternative platforms, I really have no expertise with 
anything other than linux, maybe others would be willing to test on their 
machines, but I understand asking for work is a no-no.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Monday, October 19, 2020 7:45 PM, Jon Trulson  wrote:

> On 10/18/20 11:58 AM, Chase via cdesktopenv-devel wrote:
>
> Hi,
>
>> So, the first patch removes a lot of our custom localization changes, as 
>> between 1993 and 2012 kornshell figured out how to do i18n properly, 
>> normally I'd like to keep ksh93 functions out of dtksh, but this allows us 
>> to skip a lot of the custom code we needed to add to init.
>>
>> The second patch just brings us up to date with ksh93.
>>
>> The thirst patch finally fixes the callback segfaults for good, how it works 
>> however, is a mystery to me.
>
> This one concerns me - what you did was assign "" to a pointer. Yes, this 
> does ensure the pointer is valid, though it will point into the BSS. If 
> something is scribbling in there, it will corrupt things there.
>
> Did you try just assigning these to NULL?
>
> I've gone ahead and applied these to the master-ksh93-upgrade branch. But 
> please, check those assignments - they are suspicious.
>
>> We should now be able to merge the ksh93 branch into master unless there are 
>> any further objections.
>
> Hmm, no... A few things need to happen first, I think:
>
> - We need instructions on how to check it out and build it (I still haven't 
> attempted it yet). Now that we are using a sub module, those instructions 
> will change. These would need to go into the documentation/wiki so people can 
> build it for example.
> - this would need to be tested/built on multiple systems - different linuxen 
> and at least one of the BSDs, like FreeBSD.
> - would also need to run through the examples and things on these other 
> systems to make sure stuff works the way it is supposed to.
>
> It needs to work at least as well as the current version does, and we've 
> built that version on a lot of different systems.
>
> I would think we'd need to do these at a minimum. You have done some 
> fantastic work here though - it is just not ready to be dumped into master 
> yet without more testing, especially building on more platforms.
>
> -jon
>
>> Thank you for your time,
>> -Chase
>>
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>>
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] add extra fields to discipline functions

[Chase via cdesktopenv-devel]

This fixes a segfault when doing callback routines, however there are still 
more I need to work on.

Thank you for your time,
-ChaseFrom 03bcd6fbb3f91951ab7f797f0d2dfeb11ddbfcd2 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Fri, 9 Oct 2020 16:40:50 -0500
Subject: [PATCH] dtkcmds.c: add extra field to discipline functions

---
 cde/programs/dtksh/dtkcmds.c | 24 +++-
 cde/programs/dtksh/dtkcmds.h | 22 ++
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/cde/programs/dtksh/dtkcmds.c b/cde/programs/dtksh/dtkcmds.c
index 976096e7b..fb90a91d3 100644
--- a/cde/programs/dtksh/dtkcmds.c
+++ b/cde/programs/dtksh/dtkcmds.c
@@ -7885,6 +7885,7 @@ Namval_t *
 nopCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
Namval_t * np2;
@@ -7910,6 +7911,7 @@ Namval_t *
 dftCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
Namval_t * np2;
@@ -7948,6 +7950,7 @@ Namval_t *
 ehCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
Namval_t * np2;
@@ -7977,6 +7980,7 @@ Namval_t *
 transCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
Namval_t * np2;
@@ -8005,6 +8009,7 @@ Namval_t *
 scaleCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8043,6 +8048,7 @@ Namval_t *
 arrowCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8089,6 +8095,7 @@ Namval_t *
 comboCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8133,6 +8140,7 @@ Namval_t *
 cmdCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8180,6 +8188,7 @@ Namval_t *
 dAreaCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8218,6 +8227,7 @@ Namval_t *
 dbtnCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8266,6 +8276,7 @@ Namval_t *
 fselCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8343,6 +8354,7 @@ Namval_t *
 listCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8440,6 +8452,7 @@ Namval_t *
 pbtnCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8486,6 +8499,7 @@ Namval_t *
 rcCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8538,6 +8552,7 @@ Namval_t *
 sbarCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8583,6 +8598,7 @@ Namval_t *
 swinCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8623,6 +8639,7 @@ Namval_t *
 sboxCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8670,6 +8687,7 @@ Namval_t *
 tbtnCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8712,6 +8730,7 @@ Namval_t *
 textCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8867,6 +8886,7 @@ Namval_t *
 textCreateDisc2(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -8962,7 +8982,7 @@ textCreateDisc2(
   }
}
else
-  np2 = textCreateDisc(np, nameCopy, fp);
+  np2 = textCreateDisc(np, nameCopy, flags, fp);
 
XtFree(nameCopy);
XtFree(dupName);
@@ -8977,6 +8997,7 @@ Namval_t *
 helpCreateDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
@@ -9055,6 +9076,7 @@ Namval_t *
 dtPrintSetupProcDisc(
 Namval_t *np,
 char *name,
+	int flags,
 Namfun_t *fp )
 {
char * cbDataAddrStr;
diff --git a/cde/programs/dtksh/dtkcmds.h b/cde/programs/dtksh/dtkcmds.h
index 9d9d11e3c..6d734bb7a 100644
--- a/cde/programs/dtksh/dtkcmds.h
+++ b/cde/programs/dtksh/dtkcmds.h
@@ -578,90 +578,112 @@ extern void FreeNestedVariables( void ) ;
 extern Namval_t * nopCreateDisc( 
 Namval_t *np,
 char *name,
+			int flags,
 Namfun_t *fp) ;
 extern Namval_t * dftCreateDisc( 
 Namval_t *np,
 char *name,
+			int flags,
 Namfun_t *fp) ;
 extern Namval_t * ehCreateDisc( 
  

Re: [cdesktopenv-devel] [PATCH] [MASTER-KSH93-UPGRADE] update ksh93 to current patch

[Chase via cdesktopenv-devel]

Small update: so I found out why it was crashing, the old pbtnCreatDisc took 3 
arguments, whereas the new nv_open has 4, int flags was being passed by creatf 
as the fp argument, which threw off the whole thing, so I modified 
pbtnCreatdisc to take an int flags argument but do nothing with it. But now, 
there is a new perplexing crash, there is two different crashes that appear and 
I am not sure why one triggers and why the other triggers (I have changed 
absolutely nothing between the two crashes), but they seem to both be purely 
within the ksh93 code this time, I will attach valgrind and gdb logs for each 
error

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Friday, September 11, 2020 11:05 AM, Chase  wrote:

> for some reason my email client appened .bin to gdberrors and valgrinderrors, 
> ignore this, they are text files
>
> Thank you for your time,
> -Chase
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, September 10, 2020 10:33 PM, Chase via cdesktopenv-devel 
>  wrote:
>
>> Here is a patch to keep ksh up to speed with master, also, I have attached 
>> logs of valgrind and gdb for running ./dtksh examples/CallDataTest4, it 
>> seems that variables without a period in them work fine, but for some reason 
>> a period causes it to crash (at this line specifically:)
>>
>> echo "CallData.Reason = "${CB_CALL_DATA.REASON}
>>
>> Thank you for your time,
>> -Chase==14017== Memcheck, a memory error detector
==14017== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==14017== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==14017== Command: ./dtksh examples/CallDataTest4
==14017== 
==14017== Conditional jump or move depends on uninitialised value(s)
==14017==at 0x133A1B: nv_disc (nvdisc.c:754)
==14017==by 0x1CC115: stdCB (dtkcmds.c:3731)
==14017==by 0x5942A5A: ??? (in /usr/lib/x86_64-linux-gnu/libXm.so.4.0.4)
==14017==by 0x5D72A0C: ??? (in /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==14017==by 0x5D73936: _XtTranslateEvent (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==14017==by 0x5D4BE51: XtDispatchEventToWidget (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==14017==by 0x5D4C83C: ??? (in /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==14017==by 0x5D4C918: XtDispatchEvent (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==14017==by 0x5D585CE: XtAppProcessEvent (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==14017==by 0x5D4CD2C: XtAppMainLoop (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)==14017==by 0x1C3C84: 
do_XtMainLoop (dtkcmds.c:1109)
==14017==by 0x186F5D: sh_exec (xec.c:1319)
==14017== 
==14017== Use of uninitialised value of size 8
==14017==at 0x163DD7: nv_create (name.c:1192)
==14017==by 0x1649C8: nv_open (name.c:1397)
==14017==by 0x15ABF6: varsub (macro.c:1310)
==14017==by 0x1588F3: copyto (macro.c:623)
==14017==by 0x1571E8: sh_macexpand (macro.c:241)
==14017==by 0x1B456A: arg_expand (args.c:761)
==14017==by 0x1B4046: sh_argbuild (args.c:615)
==14017==by 0x1858F5: sh_exec (xec.c:991)
==14017==by 0x18945D: sh_exec (xec.c:1989)
==14017==by 0x1A2D1D: b_dot_cmd (misc.c:291)
==14017==by 0x18DAB3: sh_funct (xec.c:3197)
==14017==by 0x187973: sh_exec (xec.c:1481)
==14017== 
==14017== Invalid read of size 1
==14017==at 0x163DD7: nv_create (name.c:1192)
==14017==by 0x1649C8: nv_open (name.c:1397)
==14017==by 0x15ABF6: varsub (macro.c:1310)
==14017==by 0x1588F3: copyto (macro.c:623)
==14017==by 0x1571E8: sh_macexpand (macro.c:241)
==14017==by 0x1B456A: arg_expand (args.c:761)
==14017==by 0x1B4046: sh_argbuild (args.c:615)
==14017==by 0x1858F5: sh_exec (xec.c:991)
==14017==by 0x18945D: sh_exec (xec.c:1989)
==14017==by 0x1A2D1D: b_dot_cmd (misc.c:291)
==14017==by 0x18DAB3: sh_funct (xec.c:3197)
==14017==by 0x187973: sh_exec (xec.c:1481)
==14017==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==14017== 
==14017== 
==14017== Process terminating with default action of signal 11 (SIGSEGV): 
dumping core
==14017==  Access not within mapped region at address 0x0
==14017==at 0x163DD7: nv_create (name.c:1192)
==14017==by 0x1649C8: nv_open (name.c:1397)
==14017==by 0x15ABF6: varsub (macro.c:1310)
==14017==by 0x1588F3: copyto (macro.c:623)
==14017==by 0x1571E8: sh_macexpand (macro.c:241)
==14017==by 0x1B456A: arg_expand (args.c:761)
==14017==by 0x1B4046: sh_argbuild (args.c:615)
==14017==by 0x1858F5: sh_exec (xec.c:991)
==14017==by 0x18945D: sh_exec (xec.c:1989)
==14017==by 0x1A2D1D: b_dot_cmd (misc.c:291)
==14017==by 0x18DAB3: sh_funct (xec.c:3197)
==14017==by 0x187973: sh_exec (xec.c:1481)
==14017==  If you believe this happened as a result of a stack
==14017==  overflow in your program's main thread (unlikely but
==14017==  possible), you

Re: [cdesktopenv-devel] [PATCH] [MASTER-KSH93-UPGRADE] update ksh93 to current patch

[Chase via cdesktopenv-devel]

for some reason my email client appened .bin to gdberrors and valgrinderrors, 
ignore this, they are text files

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Thursday, September 10, 2020 10:33 PM, Chase via cdesktopenv-devel 
 wrote:

> Here is a patch to keep ksh up to speed with master, also, I have attached 
> logs of valgrind and gdb for running ./dtksh examples/CallDataTest4, it seems 
> that variables without a period in them work fine, but for some reason a 
> period causes it to crash (at this line specifically:)
>
> echo "CallData.Reason = "${CB_CALL_DATA.REASON}
>
> Thank you for your time,
> -Chase___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] [MASTER-KSH93-UPGRADE] update ksh93 to current patch

[Chase via cdesktopenv-devel]

Here is a patch to keep ksh up to speed with master, also, I have attached logs 
of valgrind and gdb for running ./dtksh examples/CallDataTest4, it seems that 
variables without a period in them work fine, but for some reason a period 
causes it to crash (at this line specifically:)

echo "CallData.Reason = "${CB_CALL_DATA.REASON}

Thank you for your time,
-ChaseFrom 2c283252ebc866d2224940d852728984bb37b01d Mon Sep 17 00:00:00 2001
From: Chase 
Date: Thu, 10 Sep 2020 21:58:26 -0500
Subject: [PATCH] ksh: update to commit 092b90

---
 cde/programs/dtksh/builtins.c |  77 ++---
 cde/programs/dtksh/init.c | 157 +-
 cde/programs/dtksh/ksh93  |   2 +-
 3 files changed, 86 insertions(+), 150 deletions(-)

diff --git a/cde/programs/dtksh/builtins.c b/cde/programs/dtksh/builtins.c
index a78210c1..2e59506c 100644
--- a/cde/programs/dtksh/builtins.c
+++ b/cde/programs/dtksh/builtins.c
@@ -68,7 +68,6 @@
 /*
  * IMPORTANT: The order of these struct members must be synchronous
  * with the offsets on the macros defined in include/builtins.h!
- * The order up through "local" is significant.
  */
 const struct shtable3 shtab_builtins[] =
 {
@@ -95,9 +94,6 @@ const struct shtable3 shtab_builtins[] =
 	".",		NV_BLTIN|BLT_ENV|BLT_SPC,	bltin(dot_cmd),
 	"source",	NV_BLTIN|BLT_ENV,		bltin(dot_cmd),
 	"return",	NV_BLTIN|BLT_ENV|BLT_SPC,	bltin(return),
-#if SHOPT_BASH
-	"local",	NV_BLTIN|BLT_ENV|BLT_SPC|BLT_DCL,bltin(typeset),
-#endif
 /*
  * Builtins without offset macros in include/builtins.h follow.
  */
@@ -178,7 +174,7 @@ const struct shtable3 shtab_builtins[] =
 	"__regress__",		NV_BLTIN|BLT_ENV,	bltin(__regress__),
 #endif
 #ifdef BUILD_DTKSH
-	DTK_EXTRA_TABLE
+DTK_EXTRA_TABLE
 DTK_EXTRA_TABLE2
 DTK_TK_EXTRA_TABLE
 DTK_TK_LIST_TABLE
@@ -241,13 +237,6 @@ const char sh_set[] =
 		"[+gmacs?Enables/disables \bgmacs\b editing mode.  \bgmacs\b "
 			"editing mode is the same as \bemacs\b editing mode "
 			"except for the handling of \b^T\b.]"
-#if SHOPT_BASH
-		"[+hashall?Equivalent to \b-h\b and \b-o trackall\b. Available "
-		"in bash compatibility mode only.]"
-		"[+history?Enable command history. Available in bash "
-		"compatibility mode only. On by default in interactive "
-		"shells.]"
-#endif
 #if SHOPT_HISTEXPAND
 		"[+histexpand?Equivalent to \b-H\b.]"
 #endif
@@ -268,20 +257,12 @@ const char sh_set[] =
 			"compatibility.]"
 		"[+notify?Equivalent to \b-b\b.]"
 		"[+nounset?Equivalent to \b-u\b.]"
-#if SHOPT_BASH
-		"[+onecmd?Equivalent to \b-t\b. Available in bash compatibility "
-		"mode only.]"
-		"[+physical?Equivalent to \b-P\b. Available in bash "
-		"compatibility mode only.]"
-		"[+posix?Turn on POSIX compatibility. Available in bash "
-		"compatibility mode only. Bash in POSIX mode is not the "
-		"same as ksh.]"
-#endif
 		"[+pipefail?A pipeline will not complete until all components "
 			"of the pipeline have completed, and the exit status "
 			"of the pipeline will be the value of the last "
 			"command to exit with non-zero exit status, or will "
 			"be zero if all commands return zero exit status.]"
+		"[+posix?Enable full POSIX standard compliance mode.]"
 		"[+privileged?Equivalent to \b-p\b.]"
 		"[+rc?Do not run the \b.kshrc\b file for interactive shells.]"
 		"[+showme?Simple commands preceded by a \b;\b will be traced "
@@ -310,9 +291,6 @@ const char sh_set[] =
 "[x?Execution trace.  The shell will display each command after all "
 	"expansion and before execution preceded by the expanded value "
 	"of the \bPS4\b parameter.]"
-#if SHOPT_BASH
-	"\fbash1\f"
-#endif
 #if SHOPT_BRACEPAT
 "[B?Enable {...} group expansion. On by default.]"
 #endif
@@ -348,7 +326,7 @@ const char sh_optcont[] =
 "[-1c?\n@(#)$Id: continue (AT&T Research) 1999-04-07 $\n]"
 USAGE_LICENSE
 "[+NAME?continue - continue execution at top of the loop]"
-"[+DESCRIPTION?\bcontinue\b is a shell special built-in that continues "
+"[+DESCRIPTION?\bcontinue\b is a shell special built-in that continues " 
 	"execution at the top of smallest enclosing enclosing \bfor\b, "
 	"\bselect\b, \bwhile\b, or \buntil\b loop, if any; or the top of "
 	"the \an\a-th enclosing loop if \an\a is specified.]"
@@ -380,7 +358,7 @@ USAGE_LICENSE
 	"each \aname\a that is specified, and \b=\b\avalue\a  is not "
 	"specified, the current value of the alias corresponding to "
 	"\aname\a is written to standard output.  If \b=\b\avalue\a is "
-	"specified, the alias \aname\a will be created or redefined.]"
+	"specified, the alias \aname\a will be created or redefined.]" 
 "[+?\balias\b is built-in to the shell as a declaration command so that "
 	"field splitting and pathname expansion are not performed on "
 	"the arguments.  Tilde expansion occurs on \avalue\a.  An alias "
@@ -468,7 +446,7 @@ USAGE_LICENSE
 "[+?In the first form with one operand, if \adirectory\a begins with "
 	"\b/\b, or if the first component is \b.\b or \b..\b, the "
 	"directory will be changed to th

[cdesktopenv-devel] [PATCH] dtappbuilder: make it build under autotools

[Chase via cdesktopenv-devel]

This was a lot of fun (read: pain) to get working. bil_parser.y wanted -Nm set 
for HPUX and AIX, but autotools complained that yacc options can't be 
variables, and I seriously doubt that either AIX or HPUX build even on Imake, 
so I left them out.

Thank you for your time,
-ChaseFrom 9a7027da9db35115f88aaddd4f530e18daaa8746 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sat, 5 Sep 2020 15:27:30 -0500
Subject: [PATCH] dtappbuilder: make it build under autotools

---
 cde/.gitignore|   1 -
 cde/configure.ac  |  10 +-
 cde/programs/Makefile.am  |   4 +-
 cde/programs/dtappbuilder/src/Makefile.am |  21 -
 cde/programs/dtappbuilder/src/ab/Makefile.am  | 545 +-
 cde/programs/dtappbuilder/src/ab/ab_bil.c |   1 +
 cde/programs/dtappbuilder/src/ab/ab_dnd.c |   1 +
 cde/programs/dtappbuilder/src/ab/ab_utils.c   |   2 +-
 .../dtappbuilder/src/ab/abobj_align.c |   1 +
 cde/programs/dtappbuilder/src/ab/abobj_edit.c |   1 +
 .../dtappbuilder/src/ab/abobj_events.c|   1 +
 .../dtappbuilder/src/ab/abobj_layers.c|   1 +
 .../dtappbuilder/src/ab/abobj_layout.c|   1 +
 cde/programs/dtappbuilder/src/ab/abobj_list.c |   1 +
 cde/programs/dtappbuilder/src/ab/abobj_menu.c |   3 +-
 cde/programs/dtappbuilder/src/ab/abobj_move.c |   1 +
 .../dtappbuilder/src/ab/abobj_resize.c|   1 +
 .../dtappbuilder/src/ab/abobj_select.c|   1 +
 cde/programs/dtappbuilder/src/ab/abobj_set.c  |   1 +
 cde/programs/dtappbuilder/src/ab/abobj_util.c |   1 +
 cde/programs/dtappbuilder/src/ab/brws.c   |   1 +
 cde/programs/dtappbuilder/src/ab/brws_find.c  |   1 +
 cde/programs/dtappbuilder/src/ab/brws_mthds.c |   1 +
 cde/programs/dtappbuilder/src/ab/cgen_utils.c |   1 +
 .../dtappbuilder/src/ab/conn_interpret.c  |   1 +
 cde/programs/dtappbuilder/src/ab/pal.c|   1 +
 cde/programs/dtappbuilder/src/ab/pal_button.c |   1 +
 cde/programs/dtappbuilder/src/ab/pal_choice.c |   1 +
 .../dtappbuilder/src/ab/pal_combobox.c|   1 +
 cde/programs/dtappbuilder/src/ab/pal_cpanel.c |   1 +
 cde/programs/dtappbuilder/src/ab/pal_create.c |   1 +
 .../dtappbuilder/src/ab/pal_custdlg.c |   1 +
 cde/programs/dtappbuilder/src/ab/pal_drawp.c  |   1 +
 .../dtappbuilder/src/ab/pal_fchooser.c|   1 +
 cde/programs/dtappbuilder/src/ab/pal_group.c  |   1 +
 cde/programs/dtappbuilder/src/ab/pal_label.c  |   1 +
 cde/programs/dtappbuilder/src/ab/pal_list.c   |   1 +
 .../dtappbuilder/src/ab/pal_mainwin.c |   1 +
 cde/programs/dtappbuilder/src/ab/pal_menu.c   |   1 +
 .../dtappbuilder/src/ab/pal_menubar.c |   1 +
 .../dtappbuilder/src/ab/pal_panedwin.c|   1 +
 cde/programs/dtappbuilder/src/ab/pal_scale.c  |   1 +
 cde/programs/dtappbuilder/src/ab/pal_sep.c|   1 +
 .../dtappbuilder/src/ab/pal_spinbox.c |   1 +
 cde/programs/dtappbuilder/src/ab/pal_termp.c  |   1 +
 cde/programs/dtappbuilder/src/ab/pal_textf.c  |   1 +
 cde/programs/dtappbuilder/src/ab/pal_textp.c  |   1 +
 cde/programs/dtappbuilder/src/ab/proj.c   |   1 +
 .../dtappbuilder/src/ab/projP_utils.c |   1 +
 cde/programs/dtappbuilder/src/ab/proj_utils.c |   1 +
 cde/programs/dtappbuilder/src/ab/prop.c   |   1 +
 cde/programs/dtappbuilder/src/ab/prop_items.c |   1 +
 cde/programs/dtappbuilder/src/ab/tmodeP.c |   1 +
 cde/programs/dtappbuilder/src/ab/ui_list.c|   1 +
 cde/programs/dtappbuilder/src/ab/ui_msg.c |   1 +
 cde/programs/dtappbuilder/src/ab/ui_util.c|   1 +
 .../dtappbuilder/src/abmf/Makefile.am |  72 +++
 cde/programs/dtappbuilder/src/abmf/abmf.c |   4 +-
 cde/programs/dtappbuilder/src/abmf/abmfP.h|   2 +-
 .../dtappbuilder/src/abmf/dtb_utils.c |   2 +-
 .../dtappbuilder/src/abmf/generate_code.c |   4 +-
 .../{libAButil => include/ab}/util_types.h|   0
 .../{libAButil => include/ab_private}/AB.h|   0
 .../ab_private}/MwmUtil.h |   0
 .../ab_private}/UilDef.h  |   0
 .../{libAButil => include/ab_private}/XmAll.h |   0
 .../src/{ab => include/ab_private}/ab.h   |   0
 .../src/{ab => include/ab_private}/ab_bil.h   |   0
 .../src/{ab => include/ab_private}/ab_dnd.h   |   0
 .../{ab => include/ab_private}/ab_resources.h |   0
 .../src/{ab => include/ab_private}/ab_utils.h |   0
 .../{libAButil => include/ab_private}/abio.h  |   0
 .../src/{abmf => include/ab_private}/abmf.h   |   0
 .../src/{ab => include/ab_private}/abobj.h|   0
 .../src/{ab => include/ab_private}/abobjP.h   |   0
 .../{ab => include/ab_private}/abobj_edit.h   |   0
 .../{ab => include/ab_private}/abobj_list.h   |   0
 .../{ab => include/ab_private}/abobj_set.h|   0
 .../ab_private}/abuil_load.h  |   0
 .../ab_private}/abuil_print.h |   0
 .../src/{ab => include/ab_private}/appfw.h|   0
 .../src/{ab => include/ab_private}/attch_ed.h |   0
 .../src/{libABil => include/ab_pri

Re: [cdesktopenv-devel] [PATCH] use new ksh93

[Chase via cdesktopenv-devel]

1. It is based on master, I remember you saying not to add new features to 
autotools since the focus should be on making it work.
2. I believe cloning will have to be done via git clone --recursive now, and we 
will probably have to lock ourselves to a specific SHA at a time until I can 
make a quick script that makes a patch file due to the files we need to merge 
manually so that we dont get out of sync with master (builtins.c and init.c, 
formerly userinit.c but that seems to have been merged into init.c years ago), 
i tried merging them into the project itself but they depended on our symbols, 
I was thinking maybe I could just make our files into a shared library, but 
that needs ksh's symbols, so its a cyclical dependency. I wrote in 
README-DEVELOPER about our new update process, its pretty simple: go into 
ksh93, git pull, merge the changes of builtins.c and init.c with our own.
I am not an expert by any means, most of the info I got was from here: 
https://github.blog/2016-02-01-working-with-submodules/
3. I don't think anything has been set in stone yet, I've heard some chatter 
about cmake, but I think they are open to anything except meson, as ksh2020 
used meson and as a result excluded a few more obscure unixen, such as AIX and 
HPUX. Right now their main focus is bugfixing, but more on that in #5
4. They did, this is the last bug I need to solve, they both fail for the same 
reason, valgrind says its an invalid read and gdb says its a corrupted pointer, 
the head of ksh said he would be willing to look at it, but the code needs to 
be public to try out.
5. I have high hopes for this ksh fork. The original ksh is now in maintenance 
mode and had told the community to fork it. I am not sure what you mean by the 
lack of activity, the documentation does mention the ksh-community fork and 
that having no activity despite being the fork people rallied around, but this 
is a different fork. The head of the project is very active, willing to accept 
patches (I sent a few upstream to make our dtksh work), and keeps things 
relatively stable as opposed to ksh2020 which ripped large portions of the code 
we needed out.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Saturday, August 22, 2020 2:30 PM, Jon Trulson  wrote:

> Hi Chase, a few comments/questions:
>
> -  is this patchset based off of master or the autotools branch? I would need 
> to know this in order to create a separate branch for this (which I agree 
> with doing, considering we are essentially throwing away our own ksh and 
> would then be dependent on someone else's implementation ).
>
> - How does the clone/checkout/build experience change? We do not currently 
> have any git submodules, so checking out and building the code will 
> different. Could you provide instructions/advice for others wanting to take a 
> look?
>
> - I see they still seem to be using iffe and maybe nmake - do they have any 
> plans for updating the build mechanism(s)?
>
> - WRT the failing tests - Do they work in our current ksh implementation? 
> This isn't necessarily a stopper, but would be important to know.
>
> - What's your feel for the future of this particular ksh repo... They do seem 
> to be fixing things, but also mention a lack of activity.
>
> News: https://github.com/ksh93/ksh/blame/master/NEWS
>
> TODO: https://github.com/ksh93/ksh/blob/master/TODO
>
> Seems promising, and no doubt our ksh is on the old side, so it would be good 
> to get this going if we can...
>
> -jon
>
> On 8/20/20 7:59 PM, Chase via cdesktopenv-devel wrote:
>
>> Hi all,
>> So these patches make us use the new ksh93 as a git submodule 
>> (https://github.com/ksh93/ksh), though I would like this put in its own 
>> separate branch. Reason being everything is working except two test cases, 
>> EventHandlerTest and CallDataTest4, both of which crash when trying to 
>> display environment variables related to callback data, the head of the new 
>> ksh has been willing to help, but I need to make the modifications public, 
>> plus I would like any solaris/bsd bugs to be ironed out now, as I do not 
>> have any way of testing them myself.
>>
>> Thank you for your time,
>> -Chase
>>
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>>
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] issue building on debian

[Chase via cdesktopenv-devel]

It looks like you didn't generate the extra locales needed, from the wiki:

Run dpkg-reconfigure locales and select the following off the list

- de_DE ISO-8859-1
- es_ES ISO-8859-1
- fr_FR ISO-8859-1
- it_IT ISO-8859-1

Then run the locale-gen to generate them

locale

-

gen

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Saturday, August 8, 2020 3:52 PM, knid mils  wrote:

> Hi, I am trying to get CDE working on Debian.
> I have downloaded the dependencies viia
>
> sudo apt-get install install git build-essential g++ 
> lib{xt,xmu,xft,xinerama,xpm,motif,ssl,xaw7,x11,xss,tirpc,jpeg,freetype6}-dev 
> tcl-dev ksh m4 ncompress xfonts-{100,75}dpi{,-transcoded} rpcbind bison 
> xbitmaps x11proto-fonts-dev
>
> I then cloned the repo, and tried to make it via make World. It works on it 
> for about an hour before erroring out ...
>
> Seems to be having a problem with dtdocbook, i will create a dpaste (pastebin 
> clone) link for the relevant part of the log.
>
> https://dpaste.com/8X2B4NEGQ.txt___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Dtksh broken test cases

[Chase via cdesktopenv-devel]

I am in no rush, if you'd like to verify first go right ahead, I wont be 
sending any patches until I get ksh updated.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Tuesday, August 4, 2020 6:13 PM, Jon Trulson  wrote:

> On 8/4/20 8:14 AM, Chase wrote:
>
>> I think I solved the mystery, the call command seems to come from a series 
>> of commands known as "exksh", a comment in fsym.c reads "This function is 
>> currently only used to locate a widget class record, as requested by a 
>> DtLoadWidget request. In the future, if the exksh commands are ever added 
>> back in, then it will also need to be able to locate any arbitrary symbol." 
>> So the command was in a file called docall.c that was never built since the 
>> beginning of the open source version, and eventually removed. It can be 
>> found here: 
>> https://sourceforge.net/p/cdesktopenv/code/ci/2.2.4/tree/cde/programs/dtksh/docall.c
>>
>> I guess the question now is how to proceed from here, remove the broken 
>> tests, readd the unused code, or just keep things as they are?
>
> I haven't verified this, but if you are SURE that this code (call) was 
> already disabled from the Open Group, and never used in our builds, then go 
> ahead and delete the broken tests. But, DtWsTest1 isn't one of them, and it 
> should work.
>
> -jon
>
>> Thank you for your time,
>> -Chase
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Sunday, August 2, 2020 6:06 PM, Jon Trulson 
>> [](mailto:j...@radscan.com) wrote:
>>
>>> Hi,
>>>
>>> forgot to mention, I also tried 'xplot' demo from thie following page - it 
>>> also works well...
>>>
>>> http://www.brendangregg.com/dtkshdemos.html
>>>
>>> For the xplot test, I ran (ubuntu 18.04):
>>>
>>> vmstat 1 | ~/src/xplot.dtksh -f 11 -hi 100 -t \"user\"
>>>
>>> -jon
>>>
>>> On 8/2/20 4:23 PM, Chase via cdesktopenv-devel wrote:
>>>
>>>> Hi all,
>>>> In my attempt to port in a new ksh, I ran through the test cases with the 
>>>> current shell to compare to the new one, and 3 of them do not work, 
>>>> DtWsTest1, PipeTest and XCursorTest1. At least with PipeTest and 
>>>> XCursorTest1, these seem to be caused by a missing command named "call", 
>>>> which appears to call bits of c functions and such. Did these test cases 
>>>> ever work?
>>>>
>>>> Thank you for your time,
>>>> -Chase
>>>>
>>>> ___
>>>> cdesktopenv-devel mailing list
>>>> cdesktopenv-devel@lists.sourceforge.net
>>>>
>>>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>>>
>>> --
>>> Jon Trulson
>>>
>>>   "Entropy.  It isn't what it used to be."
>>>-- Sheldon
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Dtksh broken test cases

[Chase via cdesktopenv-devel]

I think I solved the mystery, the call command seems to come from a series of 
commands known as "exksh", a comment in fsym.c reads "This function is 
currently only used to locate a widget class record, as requested by a 
DtLoadWidget request. In the future, if the exksh commands are ever added back 
in, then it will also need to be able to locate any arbitrary symbol." So the 
command was in a file called docall.c that was never built since the beginning 
of the open source version, and eventually removed. It can be found here: 
https://sourceforge.net/p/cdesktopenv/code/ci/2.2.4/tree/cde/programs/dtksh/docall.c

I guess the question now is how to proceed from here, remove the broken tests, 
readd the unused code, or just keep things as they are?

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Sunday, August 2, 2020 6:06 PM, Jon Trulson  wrote:

> Hi,
>
> forgot to mention, I also tried 'xplot' demo from thie following page - it 
> also works well...
>
> http://www.brendangregg.com/dtkshdemos.html
>
> For the xplot test, I ran (ubuntu 18.04):
>
> vmstat 1 | ~/src/xplot.dtksh -f 11 -hi 100 -t \"user\"
>
> -jon
>
> On 8/2/20 4:23 PM, Chase via cdesktopenv-devel wrote:
>
>> Hi all,
>> In my attempt to port in a new ksh, I ran through the test cases with the 
>> current shell to compare to the new one, and 3 of them do not work, 
>> DtWsTest1, PipeTest and XCursorTest1. At least with PipeTest and 
>> XCursorTest1, these seem to be caused by a missing command named "call", 
>> which appears to call bits of c functions and such. Did these test cases 
>> ever work?
>>
>> Thank you for your time,
>> -Chase
>>
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>>
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] Dtksh broken test cases

[Chase via cdesktopenv-devel]

Hi all,
In my attempt to port in a new ksh, I ran through the test cases with the 
current shell to compare to the new one, and 3 of them do not work, DtWsTest1, 
PipeTest and XCursorTest1. At least with PipeTest and XCursorTest1, these seem 
to be caused by a missing command named "call", which appears to call bits of c 
functions and such. Did these test cases ever work?

Thank you for your time,
-Chase___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] Turn dtksh aliases into builtins and discard BLT_SPC flag

[Chase via cdesktopenv-devel]

So upstream ksh has gotten rid of their predefined aliases, meaning we had to 
switch them over to builtins if we ever plan on updating ksh, the patch also 
got rid of the BLT_SPC flag for reasons best explained in this email sent by 
the ksh maintainers:

"Default aliases are an ugly hack that you are better off without. 
Disadvantages include: - 'unalias -a' becomes basically unusable as it gets rid 
of commands you probably want; - shell functions by those names are ignored 
(unless you quote their names upon invocation); - something like 'cmdname=foo; 
"$cmdname" bar baz' doesn't work if $cmdname is an alias.

I strongly recommend removing the BLT_SPC flag from all of your extra dtksh 
builtins. Making builtins "special builtins" is of no real benefit at all, 
while introducing a pointless restriction: shell functions by those names 
cannot be defined, which causes a risk of incompatibility with scripts written 
for other shells. The BLT_SPC flag is for a very few historic builtins that 
must have certain weird corner-case behaviour of "special" builtins for POSIX 
compliance and Bourne shell compatibility reasons."

Upstreaming ksh and autotooling ksh soon to follow when/if this gets merged.

Thank you for your time,
-ChaseFrom 3015b49ad10a016b6e0402274bc4ac25e639231a Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sun, 19 Jul 2020 12:32:25 -0500
Subject: [PATCH] dtksh: Turn dtksh aliases into builtins and discard BLT_SPC
 flag

Upstream ksh has removed it's builtin aliases, favoring instead to make them
all builtin commands, this would also allow us to skip having to manually
merge another file, it was explained best in this email:

"Default aliases are an ugly hack that you are better off without.
Disadvantages include:
- 'unalias -a' becomes basically unusable as it gets rid of commands you
probably want;
- shell functions by those names are ignored (unless you quote their
names upon invocation);
- something like 'cmdname=foo; "$cmdname" bar baz' doesn't work if
$cmdname is an alias.

I strongly recommend removing the BLT_SPC flag from all of
your extra dtksh builtins. Making builtins "special builtins" is of no
real benefit at all, while introducing a pointless restriction: shell
functions by those names cannot be defined, which causes a risk of
incompatibility with scripts written for other shells. The BLT_SPC flag
is for a very few historic builtins that must have certain weird
corner-case behaviour of "special" builtins for POSIX compliance and
Bourne shell compatibility reasons."
---
 cde/programs/dtksh/Imakefile |   8 +-
 cde/programs/dtksh/aliases.c | 147 --
 cde/programs/dtksh/dtextra.h | 278 +--
 3 files changed, 140 insertions(+), 293 deletions(-)
 delete mode 100644 cde/programs/dtksh/aliases.c

diff --git a/cde/programs/dtksh/Imakefile b/cde/programs/dtksh/Imakefile
index 872874d2..2d3c77ec 100644
--- a/cde/programs/dtksh/Imakefile
+++ b/cde/programs/dtksh/Imakefile
@@ -63,7 +63,6 @@ PROGRAMS = dtksh
 SRCS =  \
 		userinit.c \
 		builtins.c \
-		aliases.c \
 		widget.c \
 		dtkcvt.c \
 		dtkcmds.c \
@@ -102,14 +101,13 @@ XCOMM Must replace standard ksh tables of builtins and aliases
 XCOMM with our augmented versions.
 XCOMM
 
-libshell.a: $(KSH93SLIBSHELL) userinit.o builtins.o aliases.o
+libshell.a: $(KSH93SLIBSHELL) userinit.o builtins.o 
 	$(CP) $(KSH93LIBSHELL) libshell.a; \
-	ar d libshell.a userinit.o builtins.o aliases.o ; \
-	$(AR) libshell.a userinit.o builtins.o aliases.o
+	ar d libshell.a userinit.o builtins.o ; \
+	$(AR) libshell.a userinit.o builtins.o 
 
 SpecialObjectRule(userinit.o,$(NULL),-DSHOPT_VSH -DKSHELL -D_TRACE_ )
 SpecialObjectRule(builtins.o,$(NULL),-DSHOPT_VSH -DKSHELL -D_TRACE_ )
-SpecialObjectRule(aliases.o,$(NULL),-DSHOPT_VSH -DKSHELL -D_TRACE_ )
 
 ComplexProgramTarget($(PROGRAMS))
 
diff --git a/cde/programs/dtksh/aliases.c b/cde/programs/dtksh/aliases.c
deleted file mode 100644
index c80cfa31..
--- a/cde/programs/dtksh/aliases.c
+++ /dev/null
@@ -1,147 +0,0 @@
-/*
- * CDE - Common Desktop Environment
- *
- * Copyright (c) 1993-2012, The Open Group. All rights reserved.
- *
- * These libraries and programs are free software; you can
- * redistribute them and/or modify them under the terms of the GNU
- * Lesser General Public License as published by the Free Software
- * Foundation; either version 2 of the License, or (at your option)
- * any later version.
- *
- * These libraries and programs are distributed in the hope that
- * they will be useful, but WITHOUT ANY WARRANTY; without even the
- * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
- * PURPOSE. See the GNU Lesser General Public License for more
- * details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with these libraries and programs; if not, write
- * to the Free Software Foundation, Inc., 51 Franklin Street, Fifth
- * Floor, Boston, MA 02110-1301 USA
- */
-/* $XConsortium: alias

Re: [cdesktopenv-devel] ksh chaos

[Chase via cdesktopenv-devel]

I have to write an addendum to my first post. Upon further inspection, if I 
have read all the posts correctly, it seems that the project was being directed 
by two men who didn't care much for backwards compatibility with posix and have 
had their commit privileges revoked. However since they were some of the only 
ones working on the project, it has effectively been killed off with AT&T 
stating that they plan to archive the project and have the community fork it on 
their own. What an absolute mess...

However, some good has come out of it, we have a shell that we can integrate 
that isn't far off from the one we have now which will make porting much 
easier, and the hash library is back (I may still attempt to remove it in favor 
of our own but its no longer a top priority). The meson version is effectively 
dead as well. I think the most promising community version is this one: 
https://github.com/ksh93/ksh they state that they plan to fix all the bugs 
before they try for any new features, and I might be able to submit a patch 
with our dtksh modifications protected by ifdefs, meaning that we no longer 
have to use the super sloppy method of removing objects and inserting our own 
and instead just specify -DBUILD_DTKSH. Thoughts?

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Friday, July 3, 2020 11:27 PM, Chase via cdesktopenv-devel 
 wrote:

> Hi all,
> Recently I was attempting to fix and old patch of mine that switches ksh's 
> hash for DtHash, our builtin substitution in order to import upstream ksh. I 
> looked at ksh's github and everything seems to have imploded there. AT&T have 
> stepped in and reverted all major commits since 2012, a number of community 
> devs have quit and the project seems to be at a complete standstill. The 
> branches seems to have split into a ksh2020 branch (new commits by 
> contributors) and a ksh93v branch (2012 with few additions). How should we 
> proceed with importing a new ksh? Personally, I think ksh2020 had the right 
> idea (at least in terms of moving away from the mamfile build system), we 
> could probably take it, autotool it and hard fork from there. I will probably 
> continue to work on the patch because using our internal tools will be a lot 
> better than taking from an extremely volatile upstream, but thats not for me 
> to decide, your thoughts Jon?
>
> Marcin your input would also be appreciated as well.
>
> Thank you for your time,
> -Chase___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] ksh chaos

[Chase via cdesktopenv-devel]

Hi all,
Recently I was attempting to fix and old patch of mine that switches ksh's hash 
for DtHash, our builtin substitution in order to import upstream ksh. I looked 
at ksh's github and everything seems to have imploded there. AT&T have stepped 
in and reverted all major commits since 2012, a number of community devs have 
quit and the project seems to be at a complete standstill. The branches seems 
to have split into a ksh2020 branch (new commits by contributors) and a ksh93v 
branch (2012 with few additions). How should we proceed with importing a new 
ksh? Personally, I think ksh2020 had the right idea (at least in terms of 
moving away from the mamfile build system), we could probably take it, autotool 
it and hard fork from there. I will probably continue to work on the patch 
because using our internal tools will be a lot better than taking from an 
extremely volatile upstream, but thats not for me to decide, your thoughts Jon?

Marcin your input would also be appreciated as well.

Thank you for your time,
-Chase___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] CDE availability

[Chase via cdesktopenv-devel]

So technically I have made debian packaging, you can even see it in the source 
tree under /debian, if you are referring to getting it packaged for debian, 
this will be a much longer process that is actively being worked on. Debian has 
strict requirements on what software is allowed to do, where files are placed, 
etc, and CDE in its current state violates a lot of its rules.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Saturday, May 16, 2020 7:55 AM, Нина Диденко  wrote:

> Hi.
>
> By looking at https://repology.org/project/cdesktopenv/versions I see that 
> CDE is currently only packaged for Arch Linux, FreeBSD and NixOS operating 
> systems.
>
> Are there are plans for adding CDE to other systems like Debian?
>
> Thanks.___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION] dtopen: use sed instead of gencpp

[Chase via cdesktopenv-devel]

Well, as I said, we can use sed instead of gencpp and eventually remove gencpp 
so we wont have yet another utility to maintain anymore

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Saturday, February 1, 2020 1:52 PM, Jon Trulson  wrote:

> Please stop with the "cleanups" here...
>
> What exactly are you cleaning up?
>
> -jon
>
> On 2/1/20 12:00 PM, Chase via cdesktopenv-devel wrote:
>
>> minor cleanup
>>
>> Thank you for your time,
>> -Chase
>>
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>>
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION] dtspcd: use sed instead of gencpp

[Chase via cdesktopenv-devel]

more cleanup

Thank you for your time,
-ChaseFrom 9b5f92f93718daaf629b42d185ee4e84ad3e530b Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sat, 1 Feb 2020 13:48:33 -0600
Subject: [PATCH] dtspcd: use sed instead of GENCPP

---
 cde/programs/dtspcd/Makefile.am   | 12 +++---
 cde/programs/dtspcd/dtspcdenv.src | 70 +++
 2 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/cde/programs/dtspcd/Makefile.am b/cde/programs/dtspcd/Makefile.am
index d054eae9..e380daf2 100644
--- a/cde/programs/dtspcd/Makefile.am
+++ b/cde/programs/dtspcd/Makefile.am
@@ -2,7 +2,7 @@ MAITAINERCLEANFILES = Makefile.in
 
 bin_PROGRAMS = dtspcd
 
-dtspcd_CFLAGS = -DCDE_CONFIGURATION_TOP=\"${prefix}\" \
+dtspcd_CFLAGS = -DCDE_CONFIGURATION_TOP=\"$(CDE_CONFIGURATION_TOP)\" \
 		-DCDE_INSTALLATION_TOP=\"$(CDE_INSTALLATION_TOP)\" \
 		$(DT_INCDIR)
 
@@ -17,15 +17,15 @@ endif
 dtspcd_SOURCES = main.c spcd_event.c
 
 DEF_SYSTEM_PATH = "/bin:/usr/bin"
-LOCAL_CPP_DEFINES = -DCDE_CONFIGURATION_TOP=$(CDE_CONFIGURATION_TOP)	\
-	-DCDE_LOGFILES_TOP=$(CDE_LOGFILES_TOP) \
-	-DDEF_SYSTEM_PATH=$(DEF_SYSTEM_PATH)
+
+do_subst = $(SED) -e 's+CDE_CONFIGURATION_TOP+$(CDE_CONFIGURATION_TOP)+g' \
+	  -e 's+DEF_SYSTEM_PATH+$(DEF_SYSTEM_PATH)+g'
 
 CPP_TARGETS = dtspcdenv
 BUILT_SOURCES = $(CPP_TARGETS)
 CLEANFILES = $(CPP_TARGETS)
 
 dtspcdenv: dtspcdenv.src
-	$(RM) $@
-	$(GENCPP) -P -DXCOMM=# $(LOCAL_CPP_DEFINES) $< > $@
+	$(do_subst) $< > $@
+	chmod +x $@
 
diff --git a/cde/programs/dtspcd/dtspcdenv.src b/cde/programs/dtspcd/dtspcdenv.src
index b9f6e58c..86f490f1 100644
--- a/cde/programs/dtspcd/dtspcdenv.src
+++ b/cde/programs/dtspcd/dtspcdenv.src
@@ -1,39 +1,39 @@
-XCOMM $TOG: dtspcdenv.src /main/5 1999/02/26 11:30:21 mgreess $
-XCOMM #
-XCOMM
-XCOMM dtspcdenv
-XCOMM
-XCOMM Common Desktop Environment
-XCOMM
-XCOMM Configuration file for the dtspcd
-XCOMM
-XCOMM (c) Copyright 1996 Digital Equipment Corporation.
-XCOMM (c) Copyright 1993,1994,1996 Hewlett-Packard Company.
-XCOMM (c) Copyright 1993,1994,1996 International Business Machines Corp.
-XCOMM (c) Copyright 1993,1994,1996 Sun Microsystems, Inc.
-XCOMM (c) Copyright 1993,1994,1996 Novell, Inc. 
-XCOMM (c) Copyright 1996 FUJITSU LIMITED.
-XCOMM (c) Copyright 1996 Hitachi.
-XCOMM
-XCOMM ** DO NOT EDIT THIS FILE **
-XCOMM
-XCOMM CDE_INSTALLATION_TOP/config/dtspcdenv is a factory-default file and will
-XCOMM be unconditionally overwritten upon subsequent installations.
-XCOMM Before making changes to the file, copy it to its configuration 
-XCOMM directory, CDE_CONFIGURATION_TOP/config/.
-XCOMM
-XCOMM 
-XCOMM
-XCOMM Environment variables defined in this file will be propagated
-XCOMM to processes started by the CDE Subprocess Control daemon 'dtspcd'.  
-XCOMM
-XCOMM See the man page dtspcdenv(4M) for more information.
-XCOMM
-XCOMM 
+# $TOG: dtspcdenv.src /main/5 1999/02/26 11:30:21 mgreess $
+# #
+#
+# dtspcdenv
+#
+# Common Desktop Environment
+#
+# Configuration file for the dtspcd
+#
+# (c) Copyright 1996 Digital Equipment Corporation.
+# (c) Copyright 1993,1994,1996 Hewlett-Packard Company.
+# (c) Copyright 1993,1994,1996 International Business Machines Corp.
+# (c) Copyright 1993,1994,1996 Sun Microsystems, Inc.
+# (c) Copyright 1993,1994,1996 Novell, Inc. 
+# (c) Copyright 1996 FUJITSU LIMITED.
+# (c) Copyright 1996 Hitachi.
+#
+# ** DO NOT EDIT THIS FILE **
+#
+# CDE_INSTALLATION_TOP/config/dtspcdenv is a factory-default file and will
+# be unconditionally overwritten upon subsequent installations.
+# Before making changes to the file, copy it to its configuration 
+# directory, CDE_CONFIGURATION_TOP/config/.
+#
+# 
+#
+# Environment variables defined in this file will be propagated
+# to processes started by the CDE Subprocess Control daemon 'dtspcd'.  
+#
+# See the man page dtspcdenv(4M) for more information.
+#
+# 
 
 PATH=DEF_SYSTEM_PATH:$PATH
 
-XCOMM
-XCOMM SHELL is unset so its value in the user's password file
-XCOMM on the remote execution host will take precedence.
+#
+# SHELL is unset so its value in the user's password file
+# on the remote execution host will take precedence.
 unset SHELL
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION] dtopen: use sed instead of gencpp

[Chase via cdesktopenv-devel]

minor cleanup

Thank you for your time,
-ChaseFrom 743714ad7a190d7aaa505c80edaad3fb36fd420d Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sat, 1 Feb 2020 12:51:11 -0600
Subject: [PATCH] dtopen: replace GENCPP with sed

---
 cde/programs/dtopen/Makefile.am |  8 +++---
 cde/programs/dtopen/dtopen.src  | 46 -
 2 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/cde/programs/dtopen/Makefile.am b/cde/programs/dtopen/Makefile.am
index b069fb9c..92100d2f 100644
--- a/cde/programs/dtopen/Makefile.am
+++ b/cde/programs/dtopen/Makefile.am
@@ -6,10 +6,12 @@ LOCAL_CPP_DEFINES = -DCDE_INSTALLATION_TOP=$(CDE_INSTALLATION_TOP) \
 		-DCDE_CONFIGURATION_TOP=$(CDE_CONFIGURATION_TOP) \
 		-DKORNSHELL=$(KSH)
 
+do_subst = $(SED) -e 's+CDE_INSTALLATION_TOP+$(CDE_INSTALLATION_TOP)+g' \
+	   	  -e 's+KORNSHELL+$(KSH)+g'
+
 BUILT_SOURCES = dtopen
 CLEANFILES = $(BUILT_SOURCES)
 
 dtopen: dtopen.src
-	$(RM) $@
-	$(GENCPP) -P -DXCOMM=# $(LOCAL_CPP_DEFINES) $< > $@
-
+	$(do_subst) $< > $@
+	chmod +x $@
diff --git a/cde/programs/dtopen/dtopen.src b/cde/programs/dtopen/dtopen.src
index 72c3b3e4..55224b28 100755
--- a/cde/programs/dtopen/dtopen.src
+++ b/cde/programs/dtopen/dtopen.src
@@ -1,18 +1,18 @@
-XCOMM!KORNSHELL
-XCOMM
-XCOMM dtopen - provide an interface for some useful applications.
-XCOMM
-XCOMM #
-XCOMM #set -x   # uncomment for debugging
-XCOMM ###
-XCOMM Init
+#!KORNSHELL
+#
+# dtopen - provide an interface for some useful applications.
+#
+# #
+# #set -x   # uncomment for debugging
+# ###
+# Init
 
 DTOPEN="dtopen"   # Identity crisis
 APPNAME="$(basename "$0")"# the app to locate/run
 
-XCOMM apps to look for, given an action (based on APPNAME - see MAIN)
+# apps to look for, given an action (based on APPNAME - see MAIN)
 
-XCOMM image viewing
+# image viewing
 if [ -z "$DTOPEN_VIMAGE" ]
 then
 VIMAGE="xv display gimp"
@@ -20,7 +20,7 @@ else
 VIMAGE="$DTOPEN_VIMAGE"
 fi
 
-XCOMM video viewing
+# video viewing
 if [ -z "$DTOPEN_VVIDEO" ]
 then
 VVIDEO="vlc ffplay"
@@ -28,7 +28,7 @@ else
 VVIDEO="$DTOPEN_VVIDEO"
 fi
 
-XCOMM postscript viewing
+# postscript viewing
 if [ -z "$DTOPEN_VPS" ]
 then
 VPS="mgv gv"
@@ -36,7 +36,7 @@ else
 VPS="$DTOPEN_VPS"
 fi
 
-XCOMM PDF viewing
+# PDF viewing
 if [ -z "$DTOPEN_VPDF" ]
 then
 VPDF="okular xpdf"
@@ -44,10 +44,10 @@ else
 VPDF="$DTOPEN_VPDF"
 fi
 
-XCOMM ##
-XCOMM ## Utility Functions
+# ##
+# ## Utility Functions
 
-XCOMM ## Find the path of a program
+# ## Find the path of a program
 FindProg()
 {
 # FindProg "program"
@@ -58,7 +58,7 @@ FindProg()
 return 0
 }
 
-XCOMM ## Show an error message
+# ## Show an error message
 ErrorMsg()
 {
 # ErrorMsg "Title "Message" ["OK"]
@@ -76,7 +76,7 @@ ErrorMsg()
 return 0
 }
 
-XCOMM ## do a simple command
+# ## do a simple command
 DoSimpleCmd()
 {
 # DoSimpleCmd "commands" args
@@ -108,12 +108,12 @@ DoSimpleCmd()
 }
 
 
-XCOMM ##
-XCOMM ## MAIN
+# ##
+# ## MAIN
 
-XCOMM # We'll just look at our args and decide what to do...
+# # We'll just look at our args and decide what to do...
 
-XCOMM # Commands we'll recognize
+# # Commands we'll recognize
 
 COMMANDS="dtopen_image dtopen_pdf dtopen_ps dtopen_video"
 
@@ -137,5 +137,5 @@ case $APPNAME in
 ;;
 esac
 
-XCOMM # Fini
+# # Fini
 exit 0
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION] dtksh/examples: add automake file

[Chase via cdesktopenv-devel]

upon further inspection, we will need to get rid of XCOMM since sed allows 
comments for some reason, I could work around it but I'm too lazy, here is the 
new patches

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Friday, January 31, 2020 8:44 PM, Chase via cdesktopenv-devel 
 wrote:

> So I think that, if gcc -E isnt functioning in the way we want it anymore, we 
> should work towards moving them to sed scripts, as maintaining our own forked 
> cpp is clunky, from now on I will be using sed scripts to build scripts and 
> datafiles.
>
> Thank you for your time,
> -ChaseFrom 371e7dad673f3ea934ee45b8d22991dc1e69582a Mon Sep 17 00:00:00 2001
From: Chase 
Date: Fri, 31 Jan 2020 20:17:51 -0600
Subject: [PATCH 1/2] dtksh/examples: add automake file

---
 cde/programs/dtksh/examples/Makefile.am | 92 +
 1 file changed, 92 insertions(+)
 create mode 100644 cde/programs/dtksh/examples/Makefile.am

diff --git a/cde/programs/dtksh/examples/Makefile.am b/cde/programs/dtksh/examples/Makefile.am
new file mode 100644
index ..a87df473
--- /dev/null
+++ b/cde/programs/dtksh/examples/Makefile.am
@@ -0,0 +1,92 @@
+noinst_SCRIPTS = CallDataTest4 CallbackTest2 DtCursorTest2 DtWsTest1 \
+		 EventHandlerTest ListBounds1 ListItemPos1 ListPosSel1 \
+		 PipeTest PopupTest SelBoxResTest SessionTest TextCutBuf1 \
+		 TextDisp1 TextFXYPos1 TransEventTest TransTest1 WorkProcTest1 \
+		 XCursorTest1 XdrawTest crMovesText1
+
+do_subst = sed -e 's/XCOMM/#/g' \
+	   -e 's/CDE_INSTALLATION_TOP/$(CDE_INSTALLATION_TOP)/g'
+
+CallDataTest4: CallDataTest4.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+CallbackTest2: CallbackTest2.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+DtCursorTest2: DtCursorTest2.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+DtWsTest1: DtWsTest1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+EventHandlerTest: EventHandlerTest.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+ListBounds1: ListBounds1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+ListItemPos1: ListItemPos1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+ListPosSel1: ListPosSel1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+PipeTest: PipeTest.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+PopupTest: PopupTest.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+SelBoxResTest: SelBoxResTest
+	$(do_subst) $< > $@
+	chmod +x $@
+
+SessionTest: SessionTest.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+TextCutBuf1: TextCutBuf1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+TextDisp1: TextDisp1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+TextFXYPos1: TextFXYPos1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+TransEventTest: TransEventTest.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+TransTest1: TransTest1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+WorkProcTest1: WorkProcTest1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+XCursorTest1: XCursorTest1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+XdrawTest: XdrawTest.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+crMovesText1: crMovesText1.src
+	$(do_subst) $< > $@
+	chmod +x $@
-- 
2.17.1

From 6119a5efe2973bb55444fcc843d9ca4b8b96910a Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sat, 1 Feb 2020 12:45:20 -0600
Subject: [PATCH 2/2] dtksh/examples: make it build properly

---
 cde/programs/dtksh/examples/CallDataTest4.src | 38 -
 cde/programs/dtksh/examples/CallbackTest2.src | 40 +-
 cde/programs/dtksh/examples/DtCursorTest2.src | 32 
 cde/programs/dtksh/examples/DtWsTest1.src | 80 +--
 .../dtksh/examples/EventHandlerTest.src   | 48 +--
 cde/programs/dtksh/examples/ListBounds1.src   | 32 
 cde/programs/dtksh/examples/ListItemPos1.src  | 44 +-
 cde/programs/dtksh/examples/ListPosSel1.src   | 32 
 cde/programs/dtksh/examples/Makefile.am   |  3 +-
 cde/programs/dtksh/examples/PipeTest.src  | 38 -
 cde/programs/dtksh/examples/PopupTest.src | 34 
 cde/programs/dtksh/examples/SelBoxResTest.src | 32 
 cde/programs/dtksh/examples/SessionTest.src   | 80 +--
 cde/programs/dtksh/examples/TextCutBuf1.src   | 36 -
 cde/programs/dtksh/examples/TextDisp1.src | 48 +--
 cde/programs/dtksh/examples/TextFXYPos1.src   | 34 
 .../dtksh/examples/TransEventTest.src | 50 ++--
 cde/programs/dtksh/examples/TransTest1.src| 32 
 cde/programs/dtksh/examples/WorkProcTest1.src | 30 +++
 cde/programs/dtksh/examples/XCursorTest1.src  | 36 -
 cde/programs/dtksh/examples/XdrawTest.src | 28 +++
 cde/programs/dtksh/examples/crMovesText1.src  | 68 
 22 files changed, 447 insertions(+), 448 deletions(-)

diff --git a/cde/programs/dtksh/examples/CallDataTest4.src b/cde/programs/dtksh/examples/CallDataTest4.src
index 724b6f65..f7e94daa 100755
--- a/cde/programs/dtksh/examples/Ca

[cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION] dtksh/examples: add automake file

[Chase via cdesktopenv-devel]

So I think that, if gcc -E isnt functioning in the way we want it anymore, we 
should work towards moving them to sed scripts, as maintaining our own forked 
cpp is clunky, from now on I will be using sed scripts to build scripts and 
datafiles.

Thank you for your time,
-ChaseFrom 371e7dad673f3ea934ee45b8d22991dc1e69582a Mon Sep 17 00:00:00 2001
From: Chase 
Date: Fri, 31 Jan 2020 20:17:51 -0600
Subject: [PATCH] dtksh/examples: add automake file

---
 cde/programs/dtksh/examples/Makefile.am | 92 +
 1 file changed, 92 insertions(+)
 create mode 100644 cde/programs/dtksh/examples/Makefile.am

diff --git a/cde/programs/dtksh/examples/Makefile.am b/cde/programs/dtksh/examples/Makefile.am
new file mode 100644
index ..a87df473
--- /dev/null
+++ b/cde/programs/dtksh/examples/Makefile.am
@@ -0,0 +1,92 @@
+noinst_SCRIPTS = CallDataTest4 CallbackTest2 DtCursorTest2 DtWsTest1 \
+		 EventHandlerTest ListBounds1 ListItemPos1 ListPosSel1 \
+		 PipeTest PopupTest SelBoxResTest SessionTest TextCutBuf1 \
+		 TextDisp1 TextFXYPos1 TransEventTest TransTest1 WorkProcTest1 \
+		 XCursorTest1 XdrawTest crMovesText1
+
+do_subst = sed -e 's/XCOMM/#/g' \
+	   -e 's/CDE_INSTALLATION_TOP/$(CDE_INSTALLATION_TOP)/g'
+
+CallDataTest4: CallDataTest4.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+CallbackTest2: CallbackTest2.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+DtCursorTest2: DtCursorTest2.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+DtWsTest1: DtWsTest1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+EventHandlerTest: EventHandlerTest.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+ListBounds1: ListBounds1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+ListItemPos1: ListItemPos1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+ListPosSel1: ListPosSel1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+PipeTest: PipeTest.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+PopupTest: PopupTest.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+SelBoxResTest: SelBoxResTest
+	$(do_subst) $< > $@
+	chmod +x $@
+
+SessionTest: SessionTest.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+TextCutBuf1: TextCutBuf1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+TextDisp1: TextDisp1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+TextFXYPos1: TextFXYPos1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+TransEventTest: TransEventTest.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+TransTest1: TransTest1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+WorkProcTest1: WorkProcTest1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+XCursorTest1: XCursorTest1.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+XdrawTest: XdrawTest.src
+	$(do_subst) $< > $@
+	chmod +x $@
+
+crMovesText1: crMovesText1.src
+	$(do_subst) $< > $@
+	chmod +x $@
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION] replace ast hash with dt hash

[Chase via cdesktopenv-devel]

So this patch will be necessary for the autotooling of ksh (or at least the 
updating of it then the subsequent autotooling), as ksh no longer provides its 
hashing library this will be necessary if we want to update it (which would 
also end it's dependency on ksh, and in the future we could even work on not 
depending on ksh whatsoever). This can be applied to either 
autotools-conversion or master, as long as it finds its way into 
autotools-conversion afterwards. POSIX ksh didnt suit our uses, it can't handle 
more than one hash table per program and it also can't operate on hash tables 
except for basic lookups and entries. Side note, there is an entirely unused 
hash table in DtSvc/DtUtil2 but it is undocumented and I will probably remove 
it at some point once Dtksh is done.

Thank you for your time,
-ChaseFrom 49a8598fad096f955b17a68912874bfd5da6d8ff Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sun, 26 Jan 2020 19:27:31 -0600
Subject: [PATCH] dtksh: replace AST hash for Dt hash

---
 cde/programs/dtksh/dtkcmds.c  | 10 +++
 cde/programs/dtksh/dtkcvt.c   |  6 ++--
 cde/programs/dtksh/userinit.c |  2 +-
 cde/programs/dtksh/widget.c   | 55 ++-
 cde/programs/dtksh/xmcmds.c   |  3 +-
 cde/programs/dtksh/xmcvt.c|  2 +-
 cde/programs/dtksh/xmdtksym.c |  2 +-
 7 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/cde/programs/dtksh/dtkcmds.c b/cde/programs/dtksh/dtkcmds.c
index b47ee160..68adeff6 100644
--- a/cde/programs/dtksh/dtkcmds.c
+++ b/cde/programs/dtksh/dtkcmds.c
@@ -55,7 +55,7 @@
 #include 
 #include 
 #include 
-#include "hash.h"
+#include 
 #include "stdio.h"
 #define NO_AST
 #include "dtksh.h"
@@ -3103,14 +3103,14 @@ ConvertTypeToString(
 	char *nam;
 char * errmsg;
 
-if ((nam = hashget((Hash_table_t*)class->res, resource)) == NULL) {
+if ((nam = _DtUtilFindHash((DtHashTbl)class->res, resource)) == NULL) {
 		/* If we didn't find it in this widget's class record,
 		 * see if the parent is a constraint widget class, and
 		 * if so then see if we can find the class there.
 		 */
 		if (parent == NULL || parent->wclass == NULL ||
 	 	  parent->wclass->con == NULL ||
-  (nam = hashget((Hash_table_t*)parent->wclass->con, resource))
+  (nam = _DtUtilFindHash((DtHashTbl)parent->wclass->con, resource))
   == NULL)
 {
 			errmsg = strdup(GetSharedMsg(DT_UNDEF_RESOURCE));
@@ -3183,14 +3183,14 @@ ConvertStringToType(
 	DTKSHConversionResource = resource;  /* needed by callback converter */
 	DTKSHConversionWidget = w;	/* needed by callback converter */
 
-if ((nam = hashget((Hash_table_t*)class->res, resource)) == NULL) {
+if ((nam = _DtUtilFindHash((DtHashTbl)class->res, resource)) == NULL) {
 		/* If we didn't find it in this widget's class record,
 		 * see if the parent is a constraint widget class, and
 		 * if so then see if we can find the class there.
 		 */
 		if (parent == NULL || parent->wclass == NULL ||
 			parent->wclass->con == NULL ||
-(nam = hashget((Hash_table_t*)parent->wclass->con, 
+(nam = _DtUtilFindHash((DtHashTbl)parent->wclass->con, 
 resource)) == NULL)
 {
 			errmsg = strdup(GetSharedMsg(DT_UNDEF_RESOURCE));
diff --git a/cde/programs/dtksh/dtkcvt.c b/cde/programs/dtksh/dtkcvt.c
index 04a69594..fe92a8da 100644
--- a/cde/programs/dtksh/dtkcvt.c
+++ b/cde/programs/dtksh/dtkcvt.c
@@ -53,7 +53,7 @@
 #include 
 #include 
 #include 
-#include "hash.h"
+#include 
 #include "stdio.h"
 #define NO_AST
 #include "dtksh.h"
@@ -67,7 +67,7 @@
 #include "xmwidgets.h"
 #include "msgs.h"
 
-extern Hashtab_t * Wclasses;
+extern DtHashTbl Wclasses;
 
 
 
@@ -707,7 +707,7 @@ DtkshCvtStringToWidgetClass(
}
 
wcName = (char *)(fval->addr);
-   if ((hashInfo = hashget(Wclasses, wcName)) != NULL)
+   if ((hashInfo = _DtUtilFindHash(Wclasses, wcName)) != NULL)
{
   classtab = (classtab_t *)hashInfo;
   wc = classtab->class;
diff --git a/cde/programs/dtksh/userinit.c b/cde/programs/dtksh/userinit.c
index de269e46..fe0943c3 100644
--- a/cde/programs/dtksh/userinit.c
+++ b/cde/programs/dtksh/userinit.c
@@ -39,7 +39,7 @@
 #include 
 #include 
 #include 
-#include "hash.h"
+#include 
 #include "stdio.h"
 #define NO_AST
 #include "dtksh.h"
diff --git a/cde/programs/dtksh/widget.c b/cde/programs/dtksh/widget.c
index 8ef221e8..2601850d 100644
--- a/cde/programs/dtksh/widget.c
+++ b/cde/programs/dtksh/widget.c
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-#include "hash.h"
+#include  
 #include "stdio.h"
 #define NO_AST
 #include "dtksh.h"
@@ -55,6 +55,7 @@
 
 /* values for the flags field of the W array */
 
+#define MAXHASHSIZE		67
 #define RESOURCE_HASHSIZE	64
 #define CLASS_HASHSIZE		32
 #define WIDGETALLOC		16	/* Will realloc the widget array in this increment */
@@ -68,14 +69,14 @@ int Wtab_free = 0;	/* A count of how

Re: [cdesktopenv-devel] [PATCH][AUTOTOOLS-CONVERSION] add generated manpages

[Chase via cdesktopenv-devel]

Yes, trying to get these to generate under autotools is a mess, we are going to 
throw out the docbook sgm files, docbooktoman and the rest and just add the 
post generation manpages so we can just install them via dist_man1_MANS = 
something.1, it will speed up build times and make life easier

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Sunday, January 26, 2020 1:00 PM, Jon Trulson  wrote:

> On 1/20/20 11:39 AM, Chase via cdesktopenv-devel wrote:
>
>> these patches will make installing the manpages much easier via autotools, 
>> as we can just use man1= manpage.1 rather than the whole generated script 
>> mess I was working on earlier
>
> Hi,
>
> Can you explain this in more detail?  These patches would seem to prevent the 
> generation of manpages from the underlying docbook sources...?
>
> Currently the autotools branch does not even attempt to build anything in 
> doc/ yet, so these could not have been actually tested yet either...?
>
> -jon
>
>> Thank you for your time,
>> -Chase
>>
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>>
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION]

[Chase via cdesktopenv-devel]

I found a lot of redundant functions aping the _DtGetHourGlass function in 
libDtSvc, so I am replacing them

Thank you for your time,
-ChaseFrom 9b127e0aa7e8d71b5034caf0947a2f9b5a9a014f Mon Sep 17 00:00:00 2001
From: Chase 
Date: Tue, 21 Jan 2020 17:11:19 -0600
Subject: [PATCH] Remove redundant hourglass functions

---
 cde/include/Dt/HourGlass.h|  10 +-
 cde/lib/DtSvc/DtUtil2/HourGlass.c |  94 ++-
 cde/programs/dthello/dthello.c| 144 +---
 cde/programs/dthello/dthello.h|   2 -
 cde/programs/dtlogin/dm.h |   2 -
 cde/programs/dtlogin/util.c   | 150 +
 .../dtprintinfo/libUI/MotifUI/MotifUI.C   | 106 +---
 cde/programs/dtwm/UI.c|  23 +--
 cde/programs/dtwm/WmBitmap.h  | 156 --
 cde/programs/dtwm/WmFeedback.c|  55 +-
 cde/programs/dtwm/WmIBitmap.h |  25 ---
 cde/programs/dtwm/WmWinList.c |   9 +-
 12 files changed, 36 insertions(+), 740 deletions(-)
 delete mode 100644 cde/programs/dtwm/WmBitmap.h

diff --git a/cde/include/Dt/HourGlass.h b/cde/include/Dt/HourGlass.h
index f6ad47ef..c9ee713a 100644
--- a/cde/include/Dt/HourGlass.h
+++ b/cde/include/Dt/HourGlass.h
@@ -47,6 +47,10 @@
 #ifndef _hourglass_h
 #define _hourglass_h
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 /* _DtGetHourGlassCursor -
  *
  *   Builds and returns the appropriate HourGlass cursor.
@@ -86,9 +90,9 @@ extern void _DtTurnOffHourGlass(
   *  to remove hourglass cursor from.
   */
 
+#ifdef __cplusplus
+}
+#endif
 
 #endif /* _hourglass_h */
 /* DON'T ADD ANYTHING AFTER THIS #endif */
-
-
-
diff --git a/cde/lib/DtSvc/DtUtil2/HourGlass.c b/cde/lib/DtSvc/DtUtil2/HourGlass.c
index c43fd6f5..937343b7 100644
--- a/cde/lib/DtSvc/DtUtil2/HourGlass.c
+++ b/cde/lib/DtSvc/DtUtil2/HourGlass.c
@@ -117,55 +117,10 @@
 #include 
 #include "DtSvcLock.h"
 
-#define time32_width 32
-#define time32_height 32
-#define time32_x_hot 15
-#define time32_y_hot 15
-static unsigned char time32_bits[] = {
-   0x00, 0x00, 0x00, 0x00, 0xfe, 0xff, 0xff, 0x7f, 0xfe, 0xff, 0xff, 0x7f,
-   0x8c, 0x00, 0x00, 0x31, 0x4c, 0x00, 0x00, 0x32, 0x4c, 0x00, 0x00, 0x32,
-   0x4c, 0x00, 0x00, 0x32, 0x4c, 0x00, 0x00, 0x32, 0x4c, 0x00, 0x00, 0x32,
-   0x8c, 0x00, 0x00, 0x31, 0x0c, 0x7f, 0xfe, 0x30, 0x0c, 0xfe, 0x7f, 0x30,
-   0x0c, 0xfc, 0x3f, 0x30, 0x0c, 0xf8, 0x1f, 0x30, 0x0c, 0xe0, 0x07, 0x30,
-   0x0c, 0x80, 0x01, 0x30, 0x0c, 0x80, 0x01, 0x30, 0x0c, 0x60, 0x06, 0x30,
-   0x0c, 0x18, 0x18, 0x30, 0x0c, 0x04, 0x20, 0x30, 0x0c, 0x02, 0x40, 0x30,
-   0x0c, 0x01, 0x80, 0x30, 0x8c, 0x00, 0x00, 0x31, 0x4c, 0x80, 0x01, 0x32,
-   0x4c, 0xc0, 0x03, 0x32, 0x4c, 0xf0, 0x1f, 0x32, 0x4c, 0xff, 0xff, 0x32,
-   0xcc, 0xff, 0xff, 0x33, 0x8c, 0xff, 0xff, 0x31, 0xfe, 0xff, 0xff, 0x7f,
-   0xfe, 0xff, 0xff, 0x7f, 0x00, 0x00, 0x00, 0x00};
-
-#define time32m_width 32
-#define time32m_height 32
-static unsigned char time32m_bits[] = {
-   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-   0xcf, 0x00, 0x00, 0xf3, 0x6e, 0x00, 0x00, 0x76, 0x6e, 0x00, 0x00, 0x76,
-   0x6e, 0x00, 0x00, 0x76, 0x6e, 0x00, 0x00, 0x76, 0x6e, 0x00, 0x00, 0x76,
-   0xce, 0x00, 0x00, 0x73, 0x8e, 0x7f, 0xfe, 0x71, 0x0e, 0xff, 0xff, 0x70,
-   0x0e, 0xfe, 0x7f, 0x70, 0x0e, 0xfc, 0x3f, 0x70, 0x0e, 0xf8, 0x1f, 0x70,
-   0x0e, 0xe0, 0x07, 0x70, 0x0e, 0xe0, 0x07, 0x70, 0x0e, 0x78, 0x1e, 0x70,
-   0x0e, 0x1c, 0x38, 0x70, 0x0e, 0x06, 0x60, 0x70, 0x0e, 0x03, 0xc0, 0x70,
-   0x8e, 0x01, 0x80, 0x71, 0xce, 0x00, 0x00, 0x73, 0x6e, 0x80, 0x01, 0x76,
-   0x6e, 0xc0, 0x03, 0x76, 0x6e, 0xf0, 0x1f, 0x76, 0x6e, 0xff, 0xff, 0x76,
-   0xee, 0xff, 0xff, 0x77, 0xcf, 0xff, 0xff, 0xf3, 0xff, 0xff, 0xff, 0xff,
-   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
-
-
-#define time16_x_hot 7
-#define time16_y_hot 7
-#define time16_width 16
-#define time16_height 16
-static unsigned char time16_bits[] = {
-   0x00, 0x00, 0xfe, 0x7f, 0x14, 0x28, 0x14, 0x28, 0x14, 0x28, 0x24, 0x24,
-   0x44, 0x22, 0x84, 0x21, 0x84, 0x21, 0x44, 0x22, 0x24, 0x24, 0x14, 0x28,
-   0x94, 0x29, 0xd4, 0x2b, 0xfe, 0x7f, 0x00, 0x00};
-
-#define time16m_width 16
-#define time16m_height 16
-static unsigned char time16m_bits[] = {
-   0xff, 0xff, 0xff, 0xff, 0xfe, 0x7f, 0xfe, 0x7f, 0xfe, 0x7f, 0xfe, 0x7f,
-   0xfe, 0x7f, 0xfe, 0x7f, 0xfe, 0x7f, 0xfe, 0x7f, 0xfe, 0x7f, 0xfe, 0x7f,
-   0xfe, 0x7f, 0xfe, 0x7f, 0xff, 0xff, 0xff, 0xff};
-
+#include 
+#include 
+#include 
+#include 
 
 /Public Function Declarations/
 
@@ -205,8 +160,8 @@ Cursor
 _DtGetHourGlassCursor(
 Display *dpy )
 {
-unsigned char *bits;
-unsigned char *maskBits;
+char *bits;
+char *maskBits;
 unsigned int width;
 unsigned int height;
 unsigned int xHotspot;
@@ -237,21 +192,21 @@ _DtGetHourGlassCursor(
 
 if (useLargeCursors)
 {
-	width = time32_width;
-	height = time32_height;
-	bit

Re: [cdesktopenv-devel] CDE 2.3.2 has been released

[Chase via cdesktopenv-devel]

I guess I'll take the silence as a no to my previous question, though as a 
programmer I was never good at taking social queues haha.

I feel like the same could be said for this entire project, especially with 
wayland right around the corner, but people still like their niches. We should 
keep in mind that this is a historical project, and I think that removing 
things that could be fixed and that had a purpose within the desktop would be a 
disservice.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Wednesday, January 15, 2020 7:26 PM, Jon Trulson  wrote:

> On 1/15/20 5:41 PM, Richard L. Hamilton wrote:
>
>> I think I once compiled a non-recent version of open-source CDE for Solaris 
>> 11 (SPARC), and it mostly worked, although dtmail was definitely unusable.
>
> dtmail is useless.  So much work would need to go into it ,to bring it up to 
> modern standards, and I don't see anyone stepping up to do it.
>
> I would like to 'retire' it.
>
> dtappbuilder is another one that seemed cool at the time, but who uses it?  
> Who would use it today if it worked well?
>
> That's another one I'd like to 'retire'.
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] CDE 2.3.2 has been released

[Chase via cdesktopenv-devel]

Now that we have a contact with CERT, could we ask them if VU#179804 and 
CA-1999-08 from the wiki still apply to our code?

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Wednesday, January 15, 2020 4:11 PM, Jon Trulson  wrote:

> On 1/15/20 3:04 PM, Swift Griggs wrote:
>
>> Jon this whole situation with Solaris having it's own code base  which goes 
>> back to 1.x. I'm curious if that is why there are a lot of tools and utils 
>> (mostly ones starting with "sd") which aren't part of the open source 
>> version?
>
> Yes - Sun used the 1.x base, and made many modifucations and added several of 
> their own home-grown tools.
>
>> Ie.. they must have made those tools specifically for their version of CDE 
>> and thus they never saw the "light of day" since Solaris never open sourced 
>> their CDE.
>
> Correct.
>
>> Also, what was the deal back in the OpenSolaris days before Oracle killed 
>> it? Did that codebase have CDE? I also wonder about Illumos. Do they still 
>> have a CDE codebase, too? I'm guessing Sun just didn't release it with the 
>> rest of the code.
>
> Due to the licensing restriction of CDE, sun never released the source for 
> that.  They were moving toward gnome at the time I think.
>
>> Not that it really matters. I'm just asking for the sake of trivia and 
>> posterity. However, I would like to motivate myself enough to take on 
>> writing one or two replacements for some of the cooler tools from Sun's CDE. 
>> However, lately I've been just stuck doing MOTIF tutorials on my SGI IRIX 
>> systems under Indigo Magic / 4DWM. It might not be CDE, but it's a kissing 
>> cousin in my opinion.
>
> Well, we could use a new dtmail, and dtappbuilder needs love, and... :)
>
>> I also wanted to congratulate you and the team on the new release.
>
> Thanks!
>
> -jon
>
>> -S
>>
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
> Jon Trulson
>
>   "Entropy.  It isn't what it used to be."
>-- Sheldon___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Vulnerability Reports?

[Chase via cdesktopenv-devel]

Yes, this place is the place to do it, if you need to do it confidentially with 
someone, project leader is j...@radscan.com

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Friday, January 10, 2020 2:35 PM, Madison Quinn Oliver  
wrote:

> Hi all,
>
> Where is the appropriate place to send vulnerability reports that affect CDE? 
> Should the details be sent to this mailing list or is there a more 
> appropriate place?
>
> Thank you,
>
> --
>
> Madison Oliver
>
> Software Engineering Institute
>
> SEI #2417
>
> 412-268-4717___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] various patches to dtksh

[Chase via cdesktopenv-devel]

forgot to remove the function prototypes from extra.h, see patch below

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Sunday, December 15, 2019 10:38 AM, Chase via cdesktopenv-devel 
 wrote:

> These will be my last patches before the holidays, none of these import the 
> new ksh, they are just various cleanup of the source I had to do every time I 
> imported a new one. If by January when I come back, nothing is done with ksh, 
> I will take another stab at it.
>
> On an unrelated note, I think its time we commit the man pages, I have 
> searched all over for a modern sgml to man replacement, but it seems like 
> none exist, this would also cut our build time down and allow easier 
> conversion to utf8.
>
> Thank you for your time,
> -ChaseFrom cf9122c78744372f90c9c8fd66c45d80fe25a6eb Mon Sep 17 00:00:00 2001
From: Chase 
Date: Sun, 15 Dec 2019 15:02:21 -0600
Subject: [PATCH 4/4] extra.h: remove unused prototypes

---
 cde/programs/dtksh/extra.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/cde/programs/dtksh/extra.h b/cde/programs/dtksh/extra.h
index 4cb732f8..4ac9565f 100644
--- a/cde/programs/dtksh/extra.h
+++ b/cde/programs/dtksh/extra.h
@@ -43,26 +43,12 @@
 #define _Dtksh_extra_h
 
 
-
 extern void env_set( 
 char *var) ;
 extern void env_set_gbl( 
 char *vareqval) ;
 extern char * env_get( 
 char *var) ;
-extern void * xkhash_init( 
-int num) ;
-extern void xkhash_override( 
-Hash_table_t *tbl,
-const char *name,
-void *val) ;
-extern void * xkhash_find( 
-Hash_table_t *tbl,
-const char *name) ;
-extern void xkhash_add( 
-Hash_table_t *tbl,
-const char *name,
-char *val) ;
 extern int ksh_eval( 
 char *cmd) ;
 extern void env_set_var( 
@@ -87,6 +73,5 @@ extern void printerrf(
 char *arg7) ;
 
 
-
 #endif /* _Dtksh_extra_h */
 /* DON'T ADD ANYTHING AFTER THIS #endif */
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Upstream ksh problemsX

[Chase via cdesktopenv-devel]

I think I am going to give this issue a break and see what Marcin has up his 
sleeve


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Monday, November 25, 2019 5:03 PM, Jon Trulson  wrote:

> Well perhaps both of you could explain the situation... I've loosely
> monitored the ksh situation over the last couple of years and they have
> been making great progress on stripping out older stuff. But I haven't
> even downloaded or built their stuff, unlike both of you have I assume,
> so what is the situation here?
>
> I was not aware there were two versions - a new ksh2020. What I did not
> want to do is incorporate an old (though newer than ours) ksh
> implementation that would not be supported going forward. Then we are
> still in the same boat essentially.
>
> Is there much of a point otherwise?
>
> As for hash - what is it used for? Do we need it? I think it's
> unlikely they would want to re-introduce something they have already
> removed, though feel free to ask. But first, do you know if we really
> need it?
>
> I confess not spending much time in investigating ksh - there are other
> things going on I'm more interested in for the shorter term, like
> autotools support, utf8, and the "Documentation Problem" that nobody
> wants to touch.
>
> Also Chase, there were a couple of reasons I didn't like the patch:
>
> 1.  38MB single patch. How does one review that?
> 2.  patch did not build/work. Likely untested on other systems like fbsd
> as well.
>
> 3.  I found out that we were just incorporating a "new" old ksh that
> would not be supported going forward.
>
> I'm all for upgrading ksh, but for such a large and important subsystem,
> I insist that it be done right, and preferably will not require me to
> go back and fix a bunch of problems that should have been identified and
> fixed before it was submitted.
>
> I have already more than enough work to do in what limited spare time I 
> get.
>
> So, you guys tell me - what is a reasonable plan going forward WRT ksh?
> Is 'hash' the only problem? Am I underestimating the work that might
> be required to autotools any version we end up incorporating? Have
>     either of you done any POC testing to see if it will even work in 
> principle?
>
> Inquiring minds want to know. :)
>
> -jon
>
> On 11/25/19 2:27 PM, Chase via cdesktopenv-devel wrote:
>
>
> > Ksh2020, I submitted a patch importing the ksh93v branch, but Jon said he 
> > wanted to do away with nmake entirely and import ksh2020. As he has push 
> > access and I don't, that's what I've been working on :)
> > Thank you for your time,
> > -Chase
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, November 25, 2019 3:19 PM, Marcin Cieslak sa...@saper.info wrote:
> >
> > > On Mon, 25 Nov 2019, Chase via cdesktopenv-devel wrote:
> > >
> > > > So as I was upgrading our ksh, I have ran into a problem, hash.h, 
> > > > commonly found in libast, is no where to be found in the new sources, 
> > > > come to find out that they have removed the entire hash part of the 
> > > > library because it was "unused". The way I see it we have three paths 
> > > > going forward if we still want to use the latest and greatest ksh, from 
> > > > easiest to hardest:
> > > > 1.) Ask upstream to revert their patch removing the code
> > > > 2.) Readd the code and maintain it ourselves (I think this should only 
> > > > be done if #1 fails)
> > > > 3.) Refactor our code not to use their hash code
> > > > I lean towards #1, but I thought I'd consult the group before I did 
> > > > anything.
> > >
> > > o
> > > Hi Chase,
> > > do you meaning as you were upgrading to the 2020 neo-ksh version or 
> > > ksh93v?
> > > I had a look at ksh93v build system this weekend and with few improvements
> > > I think it could be pushed to CDE as is (without a much promised solution
> > > with a shared library :))
> > > Marcin
> >
> > cdesktopenv-devel mailing list
> > cdesktopenv-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
>
> Jon Trulson
>
> "Entropy. It isn't what it used to be."
> -- Sheldon
>
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Upstream ksh problemsX

[Chase via cdesktopenv-devel]

Ksh2020, I submitted a patch importing the ksh93v branch, but Jon said he 
wanted to do away with nmake entirely and import ksh2020. As he has push access 
and I don't, that's what I've been working on :)


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Monday, November 25, 2019 3:19 PM, Marcin Cieslak  wrote:

> On Mon, 25 Nov 2019, Chase via cdesktopenv-devel wrote:
>
> > So as I was upgrading our ksh, I have ran into a problem, hash.h, commonly 
> > found in libast, is no where to be found in the new sources, come to find 
> > out that they have removed the entire hash part of the library because it 
> > was "unused". The way I see it we have three paths going forward if we 
> > still want to use the latest and greatest ksh, from easiest to hardest:
> > 1.) Ask upstream to revert their patch removing the code
> > 2.) Readd the code and maintain it ourselves (I think this should only be 
> > done if #1 fails)
> > 3.) Refactor our code not to use their hash code
> > I lean towards #1, but I thought I'd consult the group before I did 
> > anything.
>
> o
> Hi Chase,
>
> do you meaning as you were upgrading to the 2020 neo-ksh version or ksh93v?
> I had a look at ksh93v build system this weekend and with few improvements
> I think it could be pushed to CDE as is (without a much promised solution
> with a shared library :))
>
> Marcin




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] Upstream ksh problems

[Chase via cdesktopenv-devel]

So as I was upgrading our ksh, I have ran into a problem, hash.h, commonly 
found in libast, is no where to be found in the new sources, come to find out 
that they have removed the entire hash part of the library because it was 
"unused". The way I see it we have three paths going forward if we still want 
to use the latest and greatest ksh, from easiest to hardest:

1.) Ask upstream to revert their patch removing the code
2.) Readd the code and maintain it ourselves (I think this should only be done 
if #1 fails)
3.) Refactor our code not to use their hash code

I lean towards #1, but I thought I'd consult the group before I did anything.

Thank you for your time,
-Chase___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] utf8-conversion branch merged to master

[Chase via cdesktopenv-devel]

Do you think importing debian's version of instant (docbook2man) would help at 
all? https://packages.debian.org/sid/docbook-to-man


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Monday, November 18, 2019 6:51 PM, Jon Trulson  wrote:

> Hi,
>
> I've just merged the utf8-conversion branch to master. This branch
> converts the languages from ISO8859-1 to UTF-8. This was done for the
> message catalogs, resources and other related files.
>
> However, documentation (help, manpages, and the dtinfo guides) are still
> always built using the ISO8859-1 locales.
>
> To support UTF-8 documentation, our docbook sources and text need to be
> updated to something from this century, and ideally from this decade.
> In addition, a conversion to XML would also be required as a result.
> So, until that happens, we still need ISO8859-1 for the docs. This also
> means viewing the docs while in a utf8 locale may show anomalies as
> non-utf8 8 bit sequences might not be rendered properly.
>
> I had tried to convert the docs blindly to utf-8, which worked fine
> initially, but the tools we are using crapped out all over the place,
> and especially instant (used to create the help text) crashed quite
> frequently. I hate instant.
>
> So, I decided not to 'hack' it - it needs to be done correctly.
>
> There are undoubtedly some issues with this conversion - for example
> dtterm does not handle UTF-8 sequences properly where 2 or more
> characters are supposed to be drawn in the same cell (overlay ed) for
> example. As always, patches welcome.
>
> A choice of good ISO10646 X11 fonts also needs to be selected. Ideally
> fonts that look decent and have a good coverage of the utf-8 character
> space and will work properly with CDE's rather awkward font configurator.
>
> It would be good to explore XFT on CDE too, as this can help - it can
> select glyphs from other fonts if a font you are using does not support
> a glyph, for example. Plus all that anti-aliasing goodness, and the
> generally better quality and completeness of TTF fonts.
>
> But, if anyone has suggestions for good fontsets we can configure CDE
> with (via cde's fonts.alias files), let us know.
>
> Since at least linux and the BSD's are using essentially the same X11
> environment and software, we should be able to come up with something
> that will work for most users out of the box.
>
>
> -
>
> Jon Trulson
>
> "Entropy. It isn't what it used to be."
> -- Sheldon
>
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION] make ksh build, update to ksh93v-beta

[Chase via cdesktopenv-devel]

 we don't want nmake or any of that other crap around either And we
> >  definitely do not want to be stuck with an old version of the 'new' ksh
> >  as a result.
> >
> > > As for us depending on meson, we do not, the branch I chose was one of 
> > > the last that functions with the old nmake build system, which only 
> > > depends on standard c as far as I am aware.
> >
> > With meson, at least temporarily, we could simply have the dtksh
> > Makefile call meson to build ksh first :)
> > I would vastly prefer that than to continuing to rely on old
> > unmaintained software (nmake, pax, etc - as well as the 'old' ksh tree
> > you decided to import instead of the latest stuff)...
> > -jon
> >
> > > Thank you for your time,
> > > -Chase
> > > ‐‐‐ Original Message ‐‐‐
> > > On Friday, November 15, 2019 6:05 PM, Jon Trulson j...@radscan.com wrote:
> > >
> > > > On 11/14/19 7:26 PM, Chase via cdesktopenv-devel wrote:
> > > >
> > > > > First off, massive apology for the commit size, I did not realize it 
> > > > > was
> > > > > going to be that big, and there really wasn't a good way to break it
> > > > > down that I saw.
> > > >
> > > > 38MB, yeah... that's pretty much impossible to review properly.
> > > > I probably would have done something like:
> > > > commit #1 - remove old ksh
> > > > #2 - add new ksh
> > > > #3 - fix this
> > > > #4 - fix that
> > > > ...
> > > > I'm not going to add this immediately to the autotools branch until I
> > > > know it builds and actually works. Even then, it might sit in it's own
> > > > branch for a bit (autotools-conversion-dtksh, for example).
> > > >
> > > > > A few things to consider before merging:
> > > > > I am not a lawyer, but it seems that the old ksh version that was
> > > > > provided with CDE was donated to the open group by at&t, to be
> > > > > distributed as their copyright work under the lgpl, with this patch, 
> > > > > the
> > > > > copyright will return to at&t, and thus the license control as well 
> > > > > (epl
> > > > > vs lgpl). It shouldn't be that big of an issue though, we can always
> > > > > fork, and I will gladly sacrifice license sovereignty for ~22 years of
> > > > > improvements.
> > > >
> > > > I don't expect it to be much of an issue, though I am not a lawyer 
> > > > either.
> > > >
> > > > > I tried to make this work with imake, but everything I tried ended up
> > > > > with an "error: recipe commences before first target", I did not seem 
> > > > > to
> > > > > get this error with automake, so into the automake branch it goes.
> > > > > This patch only works with linux, it needs to be built on the BSDs and
> > > > > solarises, shouldnt be that hard though.
> > > >
> > > > Does it actually build and work? I noticed that in theconfigure.ac,
> > > > you disabled generation of the relevant Makefiles (though I think the
> > > > way you did that is not actually valid WRT use of '#').
> > > > Will it actually build and work?
> > > > The fact you disabled those Makefiles implies that it does not...
> > > >
> > > > > Somewhere in the dtksh source, I commented out three lines, they
> > > > > reference tty_alt, editb and main, these symbols were found in a part 
> > > > > of
> > > > > the ksh source that didn't seem to get built into the libshell 
> > > > > archive,
> > > > > but doing so would have alleviated this issue, so I asked the ksh devs
> > > > > how I could get these to be added to the archive, to which they
> > > > > responded that they have no idea how nmake (the old ksh build system)
> > > > > works, only David korn himself knows, and they have switched to meson 
> > > > > in
> > > > > their builds.
> > > >
> > > > Yes, I am aware of their use of meson. So, would that have to be
> > > > installed as well in order for this ksh to build?
> > > > Also, it would be nice to know exactly what you changed and where... A
> > > > README.md is perfectly fine in programs/dtksh/ 
> >

Re: [cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION] make ksh build, update to ksh93v-beta

[Chase via cdesktopenv-devel]

Alright... I will see what I can do with the latest branch, but I still feel 
that it would be best to move from version to version a bit more slowly, after 
all, there are over 22 years of changes in ksh by now...


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Friday, November 15, 2019 6:32 PM, Jon Trulson  wrote:

> On 11/15/19 5:21 PM, Chase wrote:
>
> > I can see why those commented out makefiles could cause concern. I did this 
> > because in the build order from the imake file (not sure if this is 
> > actually important, in fact I am pretty sure it is not, as mentioned 
> > later), it was built after programs that we are still trying to make build. 
> > So what I did was I moved it to the very beggining of the programs list, 
> > and made sure to thoroughly test it to build, which it does... at the 
> > beginning of the programs directory. So an additional patch will be needed 
> > to move it to an appropriate location in the configure.ac file.
>
> Hmm Yes - it tries to build dtsession next - I'll work on that next
> when I get some time. But, it is still be possible to simply (after
> running .configure) to:
>
> cd programs/dtksh
> make
>
> In fact I just tried this, and it failed (full log attached):
>
> 
>
> -   /bin/cp
> 
> /home/jon/src/CDE/cde/programs/dtksh/ksh93/src/cmd/nmake/pkg-cobol-mfcobc.mk
> 
> /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64/lib/make/pkg-cobol-mfcobc.mk
>
> -   test '' '=' ppcc
>
> -   /usr/bin/cmp -s ppcc
> 
> /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64/lib/make/ppcc
>
> -   2> /dev/null
>
> -   /bin/mv
> 
> /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64/lib/make/ppcc
> 
> /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64/lib/make/ppcc.old
>
> -   2> /dev/null
>
> -   true
>
> -   /bin/cp ppcc
> 
> /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64/lib/make/ppcc
>
> -   nmake --base --compile
> 
> '--file=/home/jon/src/CDE/cde/programs/dtksh/ksh93/src/cmd/nmake/Makerules.mk'
> /usr/bin/ksh: line 4: nmake: not found
> mamake [cmd/nmake]: *** exit code 127 making Makerules.mo
> mamake: *** exit code 1 making cmd/nmake
> package: make: errors making
> /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64/bin/nmake
> package: make done at Fri Nov 15 17:21:14 MST 2019 in
> /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64
> Makefile:637: recipe for target 'ksh93' failed
> make[1]: *** [ksh93] Error 1
> ...
>
> Also, I think I would have preferred you use the latest meson branch, as
> we don't want nmake or any of that other crap around either And we
> definitely do not want to be stuck with an old version of the 'new' ksh
> as a result.
>
>
> > As for us depending on meson, we do not, the branch I chose was one of the 
> > last that functions with the old nmake build system, which only depends on 
> > standard c as far as I am aware.
>
> With meson, at least temporarily, we could simply have the dtksh
> Makefile call meson to build ksh first :)
>
> I would vastly prefer that than to continuing to rely on old
> unmaintained software (nmake, pax, etc - as well as the 'old' ksh tree
> you decided to import instead of the latest stuff)...
>
> -jon
>
> > Thank you for your time,
> > -Chase
> > ‐‐‐ Original Message ‐‐‐
> > On Friday, November 15, 2019 6:05 PM, Jon Trulson j...@radscan.com wrote:
> >
> > > On 11/14/19 7:26 PM, Chase via cdesktopenv-devel wrote:
> > >
> > > > First off, massive apology for the commit size, I did not realize it was
> > > > going to be that big, and there really wasn't a good way to break it
> > > > down that I saw.
> > >
> > > 38MB, yeah... that's pretty much impossible to review properly.
> > > I probably would have done something like:
> > > commit #1 - remove old ksh
> > > #2 - add new ksh
> > > #3 - fix this
> > > #4 - fix that
> > > ...
> > > I'm not going to add this immediately to the autotools branch until I
> > > know it builds and actually works. Even then, it might sit in it's own
> > > branch for a bit (autotools-conversion-dtksh, for example).
> > >
> > > > A few things to consider before merging:
> > > > I am not a lawyer, but it seems that the old ksh version that was
> > > > provided with CDE was donated to the open group 

Re: [cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION] make ksh build, update to ksh93v-beta

[Chase via cdesktopenv-devel]

I can see why those commented out makefiles could cause concern. I did this 
because in the build order from the imake file (not sure if this is actually 
important, in fact I am pretty sure it is not, as mentioned later), it was 
built after programs that we are still trying to make build. So what I did was 
I moved it to the very beggining of the programs list, and made sure to 
thoroughly test it to build, which it does... at the beginning of the programs 
directory. So an additional patch will be needed to move it to an appropriate 
location in the configure.ac file.

As for us depending on meson, we do not, the branch I chose was one of the last 
that functions with the old nmake build system, which only depends on standard 
c as far as I am aware.


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Friday, November 15, 2019 6:05 PM, Jon Trulson  wrote:

> On 11/14/19 7:26 PM, Chase via cdesktopenv-devel wrote:
>
> > First off, massive apology for the commit size, I did not realize it was
> > going to be that big, and there really wasn't a good way to break it
> > down that I saw.
>
> 38MB, yeah... that's pretty much impossible to review properly.
>
> I probably would have done something like:
>
> commit #1 - remove old ksh
> #2 - add new ksh
> #3 - fix this
> #4 - fix that
> ...
>
> I'm not going to add this immediately to the autotools branch until I
> know it builds and actually works. Even then, it might sit in it's own
> branch for a bit (autotools-conversion-dtksh, for example).
>
> > A few things to consider before merging:
> > I am not a lawyer, but it seems that the old ksh version that was
> > provided with CDE was donated to the open group by at&t, to be
> > distributed as their copyright work under the lgpl, with this patch, the
> > copyright will return to at&t, and thus the license control as well (epl
> > vs lgpl). It shouldn't be that big of an issue though, we can always
> > fork, and I will gladly sacrifice license sovereignty for ~22 years of
> > improvements.
>
> I don't expect it to be much of an issue, though I am not a lawyer either.
>
> > I tried to make this work with imake, but everything I tried ended up
> > with an "error: recipe commences before first target", I did not seem to
> > get this error with automake, so into the automake branch it goes.
> > This patch only works with linux, it needs to be built on the BSDs and
> > solarises, shouldnt be that hard though.
>
> Does it actually build and work? I noticed that in theconfigure.ac,
> you disabled generation of the relevant Makefiles (though I think the
> way you did that is not actually valid WRT use of '#').
>
> Will it actually build and work?
>
> The fact you disabled those Makefiles implies that it does not...
>
> > Somewhere in the dtksh source, I commented out three lines, they
> > reference tty_alt, editb and main, these symbols were found in a part of
> > the ksh source that didn't seem to get built into the libshell archive,
> > but doing so would have alleviated this issue, so I asked the ksh devs
> > how I could get these to be added to the archive, to which they
> > responded that they have no idea how nmake (the old ksh build system)
> > works, only David korn himself knows, and they have switched to meson in
> > their builds.
>
> Yes, I am aware of their use of meson. So, would that have to be
> installed as well in order for this ksh to build?
>
> Also, it would be nice to know exactly what you changed and where... A
> README.md is perfectly fine in programs/dtksh/ 
>
> > So I believe the best course of action would be to fork
> > from here and get automake files into the root to build it (this is why
> > I left the meson files in the source).
>
> Yes - we would probably need to do this, or require meson be installed
> too. Simply 'forking' would need to be done carefully to allow for
> future updates with minimal pain.
>
> The current ksh is undergoing a lot of development - no doubt we would
> need/want to upgrade it from time to time.
>
> > Marcin Ciezlak also jumped into
> > the dev conversation and said he was looking to make sort of a shared
> > library out of ksh (?, I'd have to ask more about it, but I want results
> > now, so I am making this commit).
>
> Well... It's usually better to do something right than quick... I know
> Marcin has talked about that for awhile now, and it would be ideal for
> dtksh to simply use an external libksh/libshell library. But yeah, I've
> heard that for years now :)
>
> > Sorry again about the commit size, i am going 

[cdesktopenv-devel] [PATCH] [AUTOTOOLS CONVERSION] move BuildNotes to doc

[Chase via cdesktopenv-devel]

I am assuming that admin is going to get nuked once Imake is gone, so lets move 
the BuildNotes to somewhere where they make more sense

Thank you for your time,
-ChaseFrom 724387065c23c546572f5175e0c0d517eb553ea1 Mon Sep 17 00:00:00 2001
From: Chase 
Date: Thu, 14 Nov 2019 21:25:33 -0600
Subject: [PATCH] Move BuildNotes to doc

---
 cde/{admin => doc}/BuildNotes/building_release_archive.txt | 0
 cde/{admin => doc}/BuildNotes/changing_version_number.txt  | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename cde/{admin => doc}/BuildNotes/building_release_archive.txt (100%)
 rename cde/{admin => doc}/BuildNotes/changing_version_number.txt (100%)

diff --git a/cde/admin/BuildNotes/building_release_archive.txt b/cde/doc/BuildNotes/building_release_archive.txt
similarity index 100%
rename from cde/admin/BuildNotes/building_release_archive.txt
rename to cde/doc/BuildNotes/building_release_archive.txt
diff --git a/cde/admin/BuildNotes/changing_version_number.txt b/cde/doc/BuildNotes/changing_version_number.txt
similarity index 100%
rename from cde/admin/BuildNotes/changing_version_number.txt
rename to cde/doc/BuildNotes/changing_version_number.txt
-- 
2.17.1

___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION] make ksh build, update to ksh93v-beta

[Chase via cdesktopenv-devel]

First off, massive apology for the commit size, I did not realize it was going 
to be that big, and there really wasn't a good way to break it down that I saw.

A few things to consider before merging:

I am not a lawyer, but it seems that the old ksh version that was provided with 
CDE was donated to the open group by at&t, to be distributed as their copyright 
work under the lgpl, with this patch, the copyright will return to at&t, and 
thus the license control as well (epl vs lgpl). It shouldn't be that big of an 
issue though, we can always fork, and I will gladly sacrifice license 
sovereignty for ~22 years of improvements.

I tried to make this work with imake, but everything I tried ended up with an 
"error: recipe commences before first target", I did not seem to get this error 
with automake, so into the automake branch it goes.

This patch only works with linux, it needs to be built on the BSDs and 
solarises, shouldnt be that hard though.

Somewhere in the dtksh source, I commented out three lines, they reference 
tty_alt, editb and main, these symbols were found in a part of the ksh source 
that didn't seem to get built into the libshell archive, but doing so would 
have alleviated this issue, so I asked the ksh devs how I could get these to be 
added to the archive, to which they responded that they have no idea how nmake 
(the old ksh build system) works, only David korn himself knows, and they have 
switched to meson in their builds. So I believe the best course of action would 
be to fork from here and get automake files into the root to build it (this is 
why I left the meson files in the source). Marcin Ciezlak also jumped into the 
dev conversation and said he was looking to make sort of a shared library out 
of ksh (?, I'd have to ask more about it, but I want results now, so I am 
making this commit).

Sorry again about the commit size, i am going to look for a tool to tell me how 
big my commits will be before I commit them.

Patch is here (my email provider wont send anything over 25M):
https://gofile.io/?c=yRFsFn

Thank you for your time,
-Chase___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] remove more internal jpeg headers

[Chase via cdesktopenv-devel]

Here's also another patch removing some deprecate files from il, they were all 
merged into files that we compile or their function was eliminated

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Monday, October 28, 2019 8:31 PM, Chase via cdesktopenv-devel 
 wrote:

> We only have one internal jpeg header left, and I cant seem to find a 
> suitable replacement builtin for it, but I'll keep looking
>
> Thank you for your time,
> -ChaseFrom 64d113e1d5325106a23605b4d46a309ac869e43e Mon Sep 17 00:00:00 2001
From: Chase 
Date: Mon, 28 Oct 2019 21:23:47 -0500
Subject: [PATCH] il: remove various deprecated files

---
 cde/lib/DtHelp/il/ilcompressfaxg31d.c  | 30 --
 cde/lib/DtHelp/il/ilcompresstiffg31d.c | 30 --
 cde/lib/DtHelp/il/ildecompfaxg31d.c| 30 --
 cde/lib/DtHelp/il/ildecompfaxg32d.c| 29 -
 cde/lib/DtHelp/il/ildecompfaxg4.c  | 25 -
 cde/lib/DtHelp/il/ildecompfaxg4.h  | 25 -
 cde/lib/DtHelp/il/ildecomptiffg31d.c   | 30 --
 cde/lib/DtHelp/il/what.c   | 25 -
 8 files changed, 224 deletions(-)
 delete mode 100644 cde/lib/DtHelp/il/ilcompressfaxg31d.c
 delete mode 100644 cde/lib/DtHelp/il/ilcompresstiffg31d.c
 delete mode 100644 cde/lib/DtHelp/il/ildecompfaxg31d.c
 delete mode 100644 cde/lib/DtHelp/il/ildecompfaxg32d.c
 delete mode 100644 cde/lib/DtHelp/il/ildecompfaxg4.c
 delete mode 100644 cde/lib/DtHelp/il/ildecompfaxg4.h
 delete mode 100644 cde/lib/DtHelp/il/ildecomptiffg31d.c
 delete mode 100644 cde/lib/DtHelp/il/what.c

diff --git a/cde/lib/DtHelp/il/ilcompressfaxg31d.c b/cde/lib/DtHelp/il/ilcompressfaxg31d.c
deleted file mode 100644
index 1f5b3223..
--- a/cde/lib/DtHelp/il/ilcompressfaxg31d.c
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * CDE - Common Desktop Environment
- *
- * Copyright (c) 1993-2012, The Open Group. All rights reserved.
- *
- * These libraries and programs are free software; you can
- * redistribute them and/or modify them under the terms of the GNU
- * Lesser General Public License as published by the Free Software
- * Foundation; either version 2 of the License, or (at your option)
- * any later version.
- *
- * These libraries and programs are distributed in the hope that
- * they will be useful, but WITHOUT ANY WARRANTY; without even the
- * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
- * PURPOSE. See the GNU Lesser General Public License for more
- * details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with these libraries and programs; if not, write
- * to the Free Software Foundation, Inc., 51 Franklin Street, Fifth
- * Floor, Boston, MA 02110-1301 USA
- */
-/* $XConsortium: ilcompressfaxg31d.c /main/3 1995/10/23 15:43:07 rswiston $ */
-/* 
-
-   The code functionality of this module was merged with /ilc/ilcompresstiffg31d.c
-   to form a new module /ilc/ilcompressg3.c
-
-    */
-
diff --git a/cde/lib/DtHelp/il/ilcompresstiffg31d.c b/cde/lib/DtHelp/il/ilcompresstiffg31d.c
deleted file mode 100644
index 15f6d7c9..
--- a/cde/lib/DtHelp/il/ilcompresstiffg31d.c
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * CDE - Common Desktop Environment
- *
- * Copyright (c) 1993-2012, The Open Group. All rights reserved.
- *
- * These libraries and programs are free software; you can
- * redistribute them and/or modify them under the terms of the GNU
- * Lesser General Public License as published by the Free Software
- * Foundation; either version 2 of the License, or (at your option)
- * any later version.
- *
- * These libraries and programs are distributed in the hope that
- * they will be useful, but WITHOUT ANY WARRANTY; without even the
- * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
- * PURPOSE. See the GNU Lesser General Public License for more
- * details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with these libraries and programs; if not, write
- * to the Free Software Foundation, Inc., 51 Franklin Street, Fifth
- * Floor, Boston, MA 02110-1301 USA
- */
-/* $XConsortium: ilcompresstiffg31d.c /main/3 1995/10/23 15:43:43 rswiston $ */
-/* 
-
-   The code functionality of this module was merged with /ilc/ilcompressfaxg31d.c
-   to form a new module /ilc/ilcompressg3.c
-
-    */
-
diff --git a/cde/lib/DtHelp/il/ildecompfaxg31d.c b/cde/lib/DtHelp/il/ildecompfaxg31d.c
deleted file mode 100644
index 65a3e230..
--- a/cde/lib/DtHelp/il/ildecompfaxg31d.c
+++ /dev/null
@@ 

[cdesktopenv-devel] [PATCH] remove more internal jpeg headers

[Chase via cdesktopenv-devel]

We only have one internal jpeg header left, and I cant seem to find a suitable 
replacement builtin for it, but I'll keep looking

Thank you for your time,
-ChaseFrom 302672b060a9e1cd619b527ff4962795855ecb2d Mon Sep 17 00:00:00 2001
From: Chase 
Date: Mon, 28 Oct 2019 20:27:35 -0500
Subject: [PATCH] remove more internal jpeg headers

---
 cde/lib/DtHelp/JpegUtils.c |  10 +--
 cde/lib/DtHelp/jpeg/cderror.h  | 155 -
 cde/lib/DtHelp/jpeg/cdjpeg.h   |   2 -
 cde/lib/DtHelp/jpeg/jinclude.h | 114 
 4 files changed, 5 insertions(+), 276 deletions(-)
 delete mode 100644 cde/lib/DtHelp/jpeg/cderror.h
 delete mode 100644 cde/lib/DtHelp/jpeg/jinclude.h

diff --git a/cde/lib/DtHelp/JpegUtils.c b/cde/lib/DtHelp/JpegUtils.c
index c7c004c9..977b3686 100644
--- a/cde/lib/DtHelp/JpegUtils.c
+++ b/cde/lib/DtHelp/JpegUtils.c
@@ -48,8 +48,8 @@
 #include 
 #include "GraphicsP.h"
 #include 
-#include "cdjpeg.h"
 #include "JpegUtilsI.h"
+#include "cdjpeg.h"
 
 /*
 ** Macro definitions
@@ -202,7 +202,7 @@ static boolean fill_input_buffer (
 nbytes = 0;
 src->buffer = (JOCTET *) (*cinfo->mem->alloc_small) (
   (j_common_ptr) cinfo, JPOOL_IMAGE,
-  2 * SIZEOF(JOCTET));
+  2 * sizeof(JOCTET));
 }
 else /* _DtGrFILE, read the next chunk of data */
 nbytes = _DtGrRead (src->buffer, 1, src->input_buf_size, src->stream);
@@ -294,7 +294,7 @@ static void jpeg_stream_src (
 */
 cinfo->src = (struct jpeg_source_mgr *) (*cinfo->mem->alloc_small) (
 (j_common_ptr) cinfo, JPOOL_IMAGE,
-SIZEOF(stream_source_mgr));
+sizeof(stream_source_mgr));
 src = (stream_src_ptr) cinfo->src;
 
 src->stream = stream;
@@ -311,7 +311,7 @@ static void jpeg_stream_src (
 {
 src->buffer = (JOCTET *) (*cinfo->mem->alloc_small) (
 (j_common_ptr) cinfo, JPOOL_IMAGE,
-INPUT_BUF_SIZE * SIZEOF(JOCTET));
+INPUT_BUF_SIZE * sizeof(JOCTET));
 src->input_buf_size = INPUT_BUF_SIZE;
 src->pub.bytes_in_buffer = 0;/* forces fill_input_buffer call */
 src->pub.next_input_byte = NULL; /* on first read */
@@ -410,7 +410,7 @@ djpeg_dest_ptr init_jpeg_dest_mgr (
 */
 dest = (ximg_dest_ptr) (*cinfo->mem->alloc_small) (
 (j_common_ptr) cinfo, JPOOL_IMAGE, 
-SIZEOF(ximg_dest_struct));
+sizeof(ximg_dest_struct));
 dest->pub.start_output = start_output_ximg;
 dest->pub.finish_output = finish_output_ximg;
 dest->pub.put_pixel_rows = copy_pixels;
diff --git a/cde/lib/DtHelp/jpeg/cderror.h b/cde/lib/DtHelp/jpeg/cderror.h
deleted file mode 100644
index ee251745..
--- a/cde/lib/DtHelp/jpeg/cderror.h
+++ /dev/null
@@ -1,155 +0,0 @@
-/*
- * CDE - Common Desktop Environment
- *
- * Copyright (c) 1993-2012, The Open Group. All rights reserved.
- *
- * These libraries and programs are free software; you can
- * redistribute them and/or modify them under the terms of the GNU
- * Lesser General Public License as published by the Free Software
- * Foundation; either version 2 of the License, or (at your option)
- * any later version.
- *
- * These libraries and programs are distributed in the hope that
- * they will be useful, but WITHOUT ANY WARRANTY; without even the
- * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
- * PURPOSE. See the GNU Lesser General Public License for more
- * details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with these libraries and programs; if not, write
- * to the Free Software Foundation, Inc., 51 Franklin Street, Fifth
- * Floor, Boston, MA 02110-1301 USA
- */
-/* $XConsortium: cderror.h /main/2 1996/05/09 03:45:18 drk $ */
-/*
- * cderror.h
- *
- * Copyright (C) 1994, Thomas G. Lane.
- * This file is part of the Independent JPEG Group's software.
- * For conditions of distribution and use, see the accompanying README file.
- *
- * This file defines the error and message codes for the cjpeg/djpeg
- * applications.  These strings are not needed as part of the JPEG library
- * proper.
- * Edit this file to add new codes, or to translate the message strings to
- * some other language.
- */
-
-/*
- * To define the enum list of message codes, include this file without
- * defining macro JMESSAGE.  To create a message string table, include it
- * again with a suitable JMESSAGE definition (see jerror.c for an example).
- */
-#ifndef JMESSAGE
-#ifndef CDERROR_H
-#define CDERROR_H
-/* First time through, define the enum list */
-#define JMAKE_ENUM_LIST
-#else
-/* Repeated inclusions of this file are no-ops unless JMESSAGE is defined */
-#define JMESSAGE(code,string)
-#endif /* CDERROR_H */
-#end

Re: [cdesktopenv-devel] [PATCH] [autotools-conversion]

[Chase via cdesktopenv-devel]

Most of it should work in theory™, but the most testing I did was to make sure 
that we could get past the configure.ac file, but I made some changes 
afterwards. I know what shouldn't work for sure is appbuilder, dthelp and 
dtinfo, they use some imake magic that is pretty complex, makedepend also 
doesnt work, not because i couldnt, but because I was thinking we would do it 
at the compiler level when it came time for a merge and it wouldn't be 
necessary. I seemed to have never written a Makefile for programs/utils/dttypes 
(I did this a while ago, Ive been spending recent efforts on trying to import a 
new version of ksh).


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Wednesday, October 23, 2019 5:02 PM, Jon Trulson  wrote:

> On 10/23/19 3:58 PM, Chase wrote:
>
> > I mimicked imake in this case, and put an include to a file that uses 
> > variables for a cpp command. There might be a better way to do this (this 
> > might not even work at all), but I was hoping to stick to what works for 
> > now and autotoolize the code as we go along, the configure.ac also mimicks 
> > imake in the sense that it uses os detection rather than feature detection.
>
> Yeah. I was thinking to use tradcpp - single source file, bsd licensed,
> that can act just like cpp and we can include it as part of the build.
> But that can wait for now.
>
> I've tried to build it and there are some missing pieces still in
> configure.ac, Makefile.am. I'm hacking on it now :)
>
> But - is any of this expected to work yet, or were you just filling in
> pieces first?
>
> It would help to know what is expected to work and what isn't at this
> stage. Again, thanks for the effort!
>
> -jon
>
> > Thank you for your time,
> > -Chase
> > ‐‐‐ Original Message ‐‐‐
> > On Wednesday, October 23, 2019 4:45 PM, Jon Trulson j...@radscan.com wrote:
> >
> > > On 10/23/19 2:56 PM, Chase via cdesktopenv-devel wrote:
> > >
> > > > I tried to make these patches as distinct as possible, this constitutes
> > > > an estimated 80% of the code covered
> > >
> > > Nice! I can see that took a long time.
> > > As discussed, I have applied these patches to the new
> > > autotools-conversion branch.
> > > Nice work Chase - this gives us a good start on an autotools building
> > > future :)
> > > I look forward to trying it out soon.
> > > How did you handle the cases where cpp is used to pre-process various
> > > files (doc, .ksh scripts, UDB, etc)? I haven't looked yet.
> > > [...]
> > >
> > > Jon Trulson
> > > "Nothing unreal exists."
> > > -- Kiri-kin-tha
> > > cdesktopenv-devel mailing list
> > > cdesktopenv-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
>
> Jon Trulson
>
> "Nothing unreal exists."
> -- Kiri-kin-tha




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] [autotools-conversion]

[Chase via cdesktopenv-devel]

I mimicked imake in this case, and put an include to a file that uses variables 
for a cpp command. There might be a better way to do this (this might not even 
work at all), but I was hoping to stick to what works for now and autotoolize 
the code as we go along, the configure.ac also mimicks imake in the sense that 
it uses os detection rather than feature detection.


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Wednesday, October 23, 2019 4:45 PM, Jon Trulson  wrote:

> On 10/23/19 2:56 PM, Chase via cdesktopenv-devel wrote:
>
> > I tried to make these patches as distinct as possible, this constitutes
> > an estimated 80% of the code covered
>
> Nice! I can see that took a long time.
>
> As discussed, I have applied these patches to the new
> autotools-conversion branch.
>
> Nice work Chase - this gives us a good start on an autotools building
> future :)
>
> I look forward to trying it out soon.
>
> How did you handle the cases where cpp is used to pre-process various
> files (doc, .ksh scripts, UDB, etc)? I haven't looked yet.
>
> [...]
>
>
> ---
>
> Jon Trulson
>
> "Nothing unreal exists."
> -- Kiri-kin-tha
>
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] merging programs/dthelp/parser/pass1, pass2 and canon1

[Chase via cdesktopenv-devel]

would there be any large consequences of merging these similar programs via 
ifdef? this has been holding up my autotools progress.

Thank you for your time,
-Chase___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] NetBSD build broken

[Chase via cdesktopenv-devel]

A while ago we started using system built in versions of tcl instead of the 
ancient copy we built, this was done on all platforms except netbsd, try 
writing a patch adding the location for tcl on netbsd and tell me if that 
changes anything:
[https://sourceforge.net/p/cdesktopenv/code/ci/master/tree/cde/programs/dtdocbook/instant/](https://sourceforge.net/p/cdesktopenv/code/ci/master/tree/cde/programs/dtdocbook/instant/Imakefile)Imakefile

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Friday, February 22, 2019 9:58 AM, Danilo Pecher 
 wrote:

> Hi all,
>
> At the time the CDE build on all NetBSD variants seems to be broken. The 
> programs build fine if one uses the ancient binary build of ast-ksh, but none 
> of the documentation builds. Build process stops without any meaningful error 
> message whatsoever :
>
> dtdocbook fatal error:
> Error processing book.out.sdl by 
> ../../../programs/dthelp/parser/pass2/htag2
>
> That happens for all languages != C
>
> I seem to remember that we had something like that in the past already..
>
> Cheers, Hippo___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Back in the flock

[Chase via cdesktopenv-devel]

I don't mean to sound discouraging or anything, but does the world really need 
a CDE linux distro? Would you be able to maintain such a custom distro? My 
primary goal in contributing to the project is to get CDE available in the 
debian repos and lay the groundwork for the other distros to package it into 
their repos, thus making the need for a custom distro with CDE preinstalled 
redundant. That also seems like a lot of work, I would much rather see DtMail 
fixed up than you splitting your free time between that and an entire distro. I 
would however also like to advise against a rewrite if possible for DtMail, as 
this is a historical project somewhat, I would like to see if we can 
use/improve it in any way first before we just discard it.

As for my autotools progress, I am about 80% done with the base Makefiles, I am 
going to test the build once I have one to one parity with our Imake build. On 
this issue, Once I have the linux version of the autotool build finished, I 
would like to upload it to a separate branch for the community to test, as I do 
not think that I would do justice testing it in VMs for operating systems other 
than linux, as I am not familiar with them. Ulrich, if you are reading, I think 
you should commit your experimental OSX code before I make the commit (should 
still be a month or two down the pipeline, but I'm pretty sure another dramatic 
shift in the code would require a rewrite). I also definitely know AIX and HPUX 
builds will be broken with this, but maybe David Cantrell could help getting 
hands on the former now that he's joined the dark side of big blue :) (too 
soon?). There's also a guy who seem to be running AIX on his pinebook with CDE 
built, I think he's posted to the discussions but I can't be sure.

I would very much like to see a new ksh in our build. I know Marcin Ciezlak 
(sorry if I butchered that) said he would look into it, and even stepped in to 
maintain ast-ksh on freebsd, but I'm sure that alone probably opened up a can 
of worms for him. They use meson, and I could see that being a problem (maybe 
CMake can integrate ninja and make files together? I am not going to do the 
research on this or contribute to such an effort anyhow, I have already learnt 
automake and such, and keeping make compatibility seems like the right choice).

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Thursday, February 21, 2019 5:27 AM, Danilo Pecher 
 wrote:

> Hi all,
>
> Thanks for the replies.
>
> I was expecting calls to bring back CDEbian, but I'm somewhat torn on that, 
> since Debian, like far too many distros has gone to the dark side and 
> switched to systemd, which turns a perfectly servicable Linux into Windows 9 
> Linux OS, so it's either a fork from debian or going the full mile and make a 
> distro based on LFS, which also has the added bonus of being tailor made for 
> the architecture.
>
> I have a test rig with a Ryzen 5 2500U octo-core, which has both Ubuntu 18.04 
> and my current nightly build of "CDELfs" on it. Ubuntu doesn't even boot 
> without deactivating half the processor's features by kernel command line. 
> The LFS instead takes about 4 hours to compile and install, which is 
> certainly a point to be made in its disfavour, but it boots cleanly and in 
> comparison to the generic code in the Ubuntu install, the optimized LFS 
> binaries are almost comically fast. for instance the build times for CDE:
>
> On Ubuntu 18.04: 6 minutes, 34 seconds
> On LFS: 2 minutes, 16 seconds.
>
> So I'm leaning towards LFS, but the lack of a package manager is a a severe 
> drawback. Currently I'm evaluating two possible candidates : pkgsrc and 
> portage-index, which might mitigate that.
>
> dtmail will most certainly get a hefty refresh, but it will have to be a 
> rewrite, as I know of no halfway up-to-date motif based email client that one 
> could start with. In a first step I'm planning on a plain-text only version 
> as I also don't know of any halfway decent motif-based web engine and 
> introducing masses of gome or kde dependencies would beat the purpose of CDE.
>
> Cheers,
> Hippo
>
> On Wed, 2019-02-20 at 23:27 -0600, Matthew R. Trower wrote:
>
>>> Additionally, ninja or meson would ‎severely restrict platform
>>> support. CMake could be alright.
>>>
>>> It would be great to see DtMail given new life.
>>>
>>> -mrt
>>>
>>> From: Christopher Turkel
>>> Sent: Wednesday, February 20, 2019 20:50
>>> To: CDE development
>>> Subject: Re: [cdesktopenv-devel] Back in the flock
>>>
>>> Bring back CDEbian, that would be great!
>>>
>>> CDE still builds on OpenBSD just fine, since that's what I use these
>>> days.
>>>
>>> On Wed, Feb 20, 2019 at 9:47 PM Jon Trulson  wrote:
>>
 > On 2/20/19 1:53 PM, Danilo Pecher wrote:
 > > Hi everybody,
 > >
 > > I've been away for quite a while from CDE related work, so long
 > in fact,
 > > I don't even have the same name anymore. Back then I was going by
 > the
 > 

Re: [cdesktopenv-devel] Problem with DtMmdb

[Chase via cdesktopenv-devel]

Maybe it wasn't the correct word, but in Imake, you can implement things like 
"LinkSourceFile()" which has Imake replace that and it's argument with the 
correct implementation of a symlink build instruction on make, autotools 
doesn't have that functionality as far as I've read.


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Monday, January 21, 2019 6:16 PM, Jon Trulson  wrote:

> On 1/21/19 4:22 PM, Chase wrote:
>
> > I did see this, but doesn't the preprocessor define instances of v_io_buf 
> > as it's ptr version? Or is that only
>
> Only if if C_API is defined. Otherwise v_io_buf is used.
>
>  the exported version of DtMmdb? I have no idea where to start there.
> C_API is defined during compilation (all I did was move DtMmdb to lib
> and disable building of mmdb.
>
> I don't know as I've never looked into the mmdb stuff.
>
> It's clear there are things going on that you do not quite understand
> yet -- for example why there are two mmdb libs where one symlinks to
> another.
>
> You should figure out why that was done first before changing anything...
>
> Maybe they are built with different defines so that the lib exports
> different behavior to different software components for some reason.
> C_API is a clue, there may be more - read the Imakefiles and look at the
> options passed when building them.
>
> You will have to figure out how this is all being built and used now
> before you can re-implement it properly...
>
> Also, I was puzzled by this comment earlier:
>
> > > > would take me a long time to write makefile.ams for due to the fact that
> > > > as far as I can tell, automake doesn't have an easy way to implement
> > > > macros, and thus I would have to write a plain Makefile direction for
>
> What do you mean that automake doesn't have an easy way to make macros?
> What macros?
>
> -jon
>
> > Thank you for your time,
> > -Chase
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, January 21, 2019 4:24 PM, Jon Trulson j...@radscan.com wrote:
> >
> > > On 1/21/19 2:07 PM, Chase via cdesktopenv-devel wrote:
> > >
> > > > Hi all,
> > > > The further and further I delve into the document building system in
> > > > CDE, the more of a trainwreck I see that it is.
> > >
> > > :)
> > >
> > > > I have been working on the autotools port, and one point of interest I
> > > > am running into continuously is the issue of downsizing duplicate code.
> > > > I have successfully done this with the replacement of nsgmls, however
> > > > due to the in progress replacement of the sgml docs with xml docs, this
> > > > patch was rejected. Matthew said he would do this, however due to real
> > > > life obligations and the size of the task, I don't believe that this
> > > > will be done soon. No matter, nsgmls was simple enough to make a
> > > > makefile.am for.
> > >
> > > Good - I think as you get this stuff building, it would be unwise to
> > > make other changes that affect behavior We can address that stuff 
> > > later.
> > >
> > > > However, what isn't simple is the make file for dtinfo/mmdb. To make it
> > > > short, this entire directory is just simlinks to dtinfo/DtMmdb, this
> > > > would take me a long time to write makefile.ams for due to the fact that
> > > > as far as I can tell, automake doesn't have an easy way to implement
> > > > macros, and thus I would have to write a plain Makefile direction for
> > > > each of the symlinked files. I tried to implement a merge of dtinfo/mmdb
> > > > and dtinfo/DtMmdb, but I have hit these two linker errors that I am
> > > > stumped on (log file attached). Could anyone help me with this?
> > >
> > > So do you know why these are two separate dirs for building? I don't,
> > > but usually there is a reason, like some sort of translation of symbols
> > > and the like.
> > > At any rate, if you look at programs/dtinfo/DtMmdb/object/pstring.h you
> > > will see that this member variable is not available if everything is
> > > built with C_API defined, which C_API should always be defined.
> > > So I am guessing that when /programs/dtinfo/dtinfo/src/Marks/Mark_mmdb.C
> > > was compiled, C_API was not defined as it should be. This would then
> > > cause pstring::v_io_buf_ptr to be used instead, which you should see if
> > > you run 'nm' on the program

Re: [cdesktopenv-devel] [PATCH] Use iconv in linux

[Chase via cdesktopenv-devel]

Was this pushed? I'm not seeing it in git log or on the sourceforge page


Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On Monday, January 14, 2019 12:11 PM, Jon Trulson  wrote:

> Applied to master, thanks!
> -jon
>
> On 1/12/19 4:08 PM, Chase via cdesktopenv-devel wrote:
>
> > Hi all,
> > Hope everyone had a good holiday. Work on converting the project to
> > autotools continues, however it is a long process, so here is a small
> > patch in the meantime.
> > Thank you for your time,
> > -Chase
> >
> > cdesktopenv-devel mailing list
> > cdesktopenv-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
>
> Jon Trulson
>
> "The Party told you to reject the evidence of your eyes and ears.
> It was their final, most essential command."
>
> -- 1984
>
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel




___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel