At Wed, 20 Aug 2025 07:57:52 +0100, BC HABS <[email protected]> wrote:
Subject: Re: CTWM and XDM
>
> Further to my earlier post above ... (and I should have tried before
> posting), despite the AI results I mentioned, it does not look like
> from testing that the -f /dev/null uses the internal cfg.  It does
> indeed seem to just start ctwm with no workspaces (or menus or basic
> setup etc that the internal cfg indicates).  My error ... sorry.

Indeed, specifying an empty config file causes no extra config to be
used, internally or externally.

There is one case where you can be fooled if you specify an empty file
that happens to have the same basename as a non-empty file with the
screen number as an extension -- that's why I specified /dev/null as
there's not supposed to be any "/dev/null.0", etc. on any system.

Oh, and the last sentence in the '-f filename' description in the manual
page omits mention of the system-wide default fallback config file,
though of course that's only tried if there's no '-f' option _and_ none
of the other default files are found.

The internal config is only used if there's no '-f' given _and_ no
default files _and_ no system-wide file.

Also '--dumpcfg' as you said only dumps the default internal config, and
it does do whether that config would be used or not -- it does not dump
the live configuration after reading any config files, which is probably
why it's not documented in the manual page.


> I am not sure then, when I keep getting the 'crashes' as originally
> reported when not using a workspaces entry ... perhaps other settings
> in the cfg file rely on a workspaces entry somewhere in the code.

Ah, yes indeed -- sorry I meant to mention this possibility in my
earlier reply.

It very well could be that your config file does turn on something that
relies on workspaces but the code for that feature isn't protected by
the internal boolean flag ("workSpaceManagerActive") that's set IFF when
the first workspace is defined (it keeps getting "set" to true over and
over again for every additional workspace too, and that's kinda silly).

If the crashes you experience do cause a core dump, perhaps you could
try running a debugger on it to get a stack trace.  Or maybe you could
post your config file and someone (maybe even me) could try this test.


As an aside I find all the logic in ctwm for handling workspaces kind of
convoluted -- no doubt because it was grafted onto twm after the fact.

For example that boolean "workSpaceManagerActive" is unnecessary --
there's also a "workSpaceMgr.count" variable that keeps track of how
many workspaces are defined and it could be checked if it is non-zero
instead.

Also does it really make sense to support the "no workspaces are defined
case"?  Surely there could be a single default workspace always defined,
but with the manager window left hidden in that case, and then all the
checking to see if a workspace is defined or not could simply be
eliminated none of the code would have to worry about the case of "no
workspaces are defined", and there would be no risk of dereferencing a
null or wild pointer or running of the end of an array, etc.


Another aside:  I find the behaviour with an empty config file to be
somewhat disturbing -- the only way out of that setup is to kill the
process as there's no menu of any kind defined, and I don't think any
key bindings are set either.  Only the titlebar buttons have functions
defined by default.  Perhaps starting with no menu defined should define
a default menu with at least an "exit" button.


BTW, never believe anything a so-called LLM/GPT chat-bot "AI" tells you!
They don't actually store verbatim copies of their training material and
unless the bot reaches out and queries a real fact source to provide the
answer (e.g. by quoting from the actual manual page, and providing a URL
to reference the source it got it from) then the bot is just making shit
up.  Sometimes that shit matches reality, sometimes it is actually
useful, but it's still always just rambling and spewing out whatever the
model predicts should be output.  Maybe the next iteration of it will be
trained with this email thread as well and it might stand a chance of
spewing out the right answer all on its own, but I wouldn't count on it.

--
                                        Greg A. Woods <[email protected]>

Kelowna, BC     +1 250 762-7675           RoboHack <[email protected]>
Planix, Inc. <[email protected]>     Avoncote Farms <[email protected]>

Attachment: pgplKwwL5RLLT.pgp
Description: OpenPGP Digital Signature

Reply via email to