On 2024-07-14, candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
> Borax Man <rotflol2@hotmail.com> wrote at 07:09 this Sunday (GMT):
>> On 2024-07-14, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Sat, 13 Jul 2024 16:00:09 -0000 (UTC), candycanearter07 wrote:
>>>
>>>> I prefer a GUI for email specifically, bc of all the html emails that
>>>> break in something like mutt
>>>
>>> I see lack of HTML rendering for email to be a feature, not a bug.
>>
>> You can hook 'w3m' to display HTML emails in mutt. Isn't as good as
>> viewing it in a graphical client, but works well enough to render the
>> text OK without all yht HTML markup.
>
>
> Interesting. I might try mutt again at some point..

The magic is using a mailcap file. The contents of mine is

# auto view using w3m
text/html; w3m -F -I %{charset} -T text/html; copiousoutput;
text/plain; most ; copiousoutput

Then in your .muttrc, include this line, to use the .mailcap file.

set mailcap_path="~/.mailcap"

Borax Man <rotflol2@hotmail.com> wrote at 11:36 this Tuesday (GMT):
> On 2024-07-14, candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
>> Borax Man <rotflol2@hotmail.com> wrote at 07:16 this Sunday (GMT):
[snip]
>>> FVWM has this thing called "pipe menus", where you can construct a menu
>>> dynamically from the output of a program. I'm sure other window
>>> managers have this, but this means you can call xlock to list all the
>>> screensaver types, then construct a menu which launches the locker from
>>> that.
>>
>>
>> Neat! I know you can implement that relatively easily with something
>> like dmenu.
>
> dmenu is prety good in that respect. I did use it for another window
> manager where the piperead dynamic menus were not available, to solve
> the same problem. The advantage though of FVWM is that the menu is
> equal to other menus, operate the same, same fonts, appearance, etc,
> whereas with dmenu, its a different look, feel and operation.
>
> That said, dmenu is part of my standard install.

Right, the suckless programs do have some nice scriptability. I
personally have a keybinding to surf for an online dictionary thing.
--
user <candycane> is generated from /dev/urandom

Borax Man <rotflol2@hotmail.com> writes:
> On 2024-07-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sun, 14 Jul 2024 22:38 +0100 (BST), John Dallman wrote:
>>> ldo@nz.invalid (Lawrence D'Oliveiro) wrote:

>>>> But it is fundamental in Windows, is it not, that every process has
>>>> a GUI. Unless it is a _service_, which runs in the background, and
>>>> is managed separately.
>>>
>>> No, it is not. "Console applications" run with stdin, stdout & stderr,
>>> rather like traditional Unix programs. They can also have character
>>> graphics UIs, in terminal windows.
>>
>> So why do Python scripts, for example, have to come in two varieties on
>> Windows, with different extensions “.PY” versus “.PYW”?
>
> Windows definately does do "console" applications. What is missing, is
> the ability to run a console application without the GUI running itself,
> but the standard C "Hello world" program does run on Windows

I’m not sure what you mean by “the GUI running itself”. Windows
executables either use the CUI (console) or GUI subsystem, and this is
represented by a field in the PE file header, rather than being a
behavior of the application after it starts.

CUI subsystem applications always run within a console, either inherited
from the parent process, or created automatically if there isn’t one to
inherit. GUI subsystem applications don’t normally get one (but can
create one). Presumably a GUI subsystem application doesn’t have to open
any Window at all if it doesn’t want to.

In Python the .py vs .pyw distinction presumably allows file
associations to a CUI subsystem version of the interpreter and a GUI
subsystem version of the interpreter.

References:
* https://devblogs.microsoft.com/oldnewthing/20090101-00/?p=19643
* https://learn.microsoft.com/en-us/windows/console/creation-of-a-console
* https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_optional_header32

--
https://www.greenend.org.uk/rjk/

On Tue, 16 Jul 2024 21:09:52 +0100, Richard Kettlewell wrote:

> Windows executables either use the CUI (console) or GUI subsystem, and
> this is represented by a field in the PE file header, rather than being
> a behavior of the application after it starts.

Which is a pretty dumb way of doing it, don’t you think? But it was all a
part of the 1990s trend of building the GUI inextricably into the OS
kernel. A trend which *nix-type systems never succumbed to.

Borax Man <rotflol2@hotmail.com> writes:
>
> Just wondering what programs (aside from the coreutils/X11 and other
> elements that make up a basic install), do you consider to be a vital
> part of YOUR Linux install? What are the little additional tools that
> you can't live without, or just consider to be necessary that maybe
> others wouldn't?
>
> For me, its
A whole pile of shit!

There's all the server stuff and development stuff to begin with.

In no particular order:

mysql server
mysql client
mysql client-dev

apache2

virtualbox (So I can run Win7 solely for my HP Scanner software)

samba

I use a separate (different) browser for emails, so Brave-browser as well as
Chromium. (Firefox isn't quite right for me somehow, these days.)

Galculator - I like it better

Calibre

Synaptic

xterm and xtermcontrol

joe (for its WordStar persona)

A specific driver for my WiFi USB

cpmtools

ftp server

dosemu

peazip

VNC-viewer

During nightly backup I extract a list of all my installed packages - there
are literally hundreds of those. Let me have a quick squizz to see if there's
anything outstanding amongst those ...

dosbox

gparted of course, I use it a lot.

qpdfview

Some runners-up:

Brasero
Audacity
Soundconverter

Jack
--
I used to see a Life Coach quite frequently.

Back then they were called bartenders.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 16 Jul 2024 21:09:52 +0100, Richard Kettlewell wrote:
>> Windows executables either use the CUI (console) or GUI subsystem, and
>> this is represented by a field in the PE file header, rather than being
>> a behavior of the application after it starts.
>
> Which is a pretty dumb way of doing it, don’t you think?

It’s not necessarily how I’d have done it, but in the big picture, it
doesn’t seem very different from any other way that an application
declares its dependencies and the system arranges for them to be
satisfied.

> But it was all a part of the 1990s trend of building the GUI
> inextricably into the OS kernel. A trend which *nix-type systems never
> succumbed to.

AFAIK the only graphical component of Windows that was ever in the
kernel was GDI, which is a low-level drawing AP and isn’t relevant
here. So, I don’t think it was part of such a trend, to the extent that
the supposed trend ever existed in the first place.

--
https://www.greenend.org.uk/rjk/

On Wed, 17 Jul 2024 08:13:26 +0100, Richard Kettlewell wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Tue, 16 Jul 2024 21:09:52 +0100, Richard Kettlewell wrote:
>>
>>> Windows executables either use the CUI (console) or GUI subsystem, and
>>> this is represented by a field in the PE file header, rather than
>>> being a behavior of the application after it starts.
>>
>> Which is a pretty dumb way of doing it, don’t you think?
>
> It’s not necessarily how I’d have done it, but in the big picture, it
> doesn’t seem very different from any other way that an application
> declares its dependencies and the system arranges for them to be
> satisfied.

It is the reason you need two different versions of the Python interpreter
on Windows. Or of any other language interpreter that wants to offer the
option of running with a GUI or without.

>> But it was all a part of the 1990s trend of building the GUI
>> inextricably into the OS kernel. A trend which *nix-type systems never
>> succumbed to.
>
> AFAIK the only graphical component of Windows that was ever in the
> kernel was GDI, which is a low-level drawing AP and isn’t relevant here.

It is the reason why the use of a GUI has to be declared within the
executable, before it can even start executing. So that the part of the
kernel that is responsible for launching executables can decide whether to
set up the process to use a GUI or not.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 17 Jul 2024 08:13:26 +0100, Richard Kettlewell wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:

>>> But it was all a part of the 1990s trend of building the GUI
>>> inextricably into the OS kernel. A trend which *nix-type systems never
>>> succumbed to.
>>
>> AFAIK the only graphical component of Windows that was ever in the
>> kernel was GDI, which is a low-level drawing AP and isn’t relevant here.
>
> It is the reason why the use of a GUI has to be declared within the
> executable, before it can even start executing. So that the part of
> the kernel that is responsible for launching executables can decide
> whether to set up the process to use a GUI or not.

No, you have it exactly backwards. The distinction in the executable
determines whether it is attached to a console (see the references
posted earlier). Either type of excecutable can create GUI windows.

--
https://www.greenend.org.uk/rjk/

candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> writes:
>
> To be fair, having Linux as your first OS would be very rare.

Hey, look, guys! I'm a rarity!!
(Most people would deinitely consider that a GOOD THING!)

Well, almost. I went from MSDOS to UNIX and then Linux. Never had Windows as
my personal 'daily-driver'.

(Aually, I was using X11 desktops on UNIX, and had heard 'Wonderful Things'
about this new 'Windows thing'. So I tried it and was aghast at just how
**bad** and primitive it was, compared to what I was already using.)

Jack
--
I used to see a Life Coach quite frequently.

Back then they were called bartenders.

Jack Strangio <jackstrangio@yahoo.com> wrote at 08:48 this Wednesday (GMT):
> candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> writes:
>>
>> To be fair, having Linux as your first OS would be very rare.
>
> Hey, look, guys! I'm a rarity!!
> (Most people would deinitely consider that a GOOD THING!)
>
> Well, almost. I went from MSDOS to UNIX and then Linux. Never had Windows as
> my personal 'daily-driver'.
>
> (Aually, I was using X11 desktops on UNIX, and had heard 'Wonderful Things'
> about this new 'Windows thing'. So I tried it and was aghast at just how
> **bad** and primitive it was, compared to what I was already using.)
>
> Jack

Oh, cool! I personally started using linux some 10 years ago?
--
user <candycane> is generated from /dev/urandom

On Wed, 17 Jul 2024 08:48:06 -0000 (UTC), Jack Strangio wrote:

> (Aually, I was using X11 desktops on UNIX, and had heard 'Wonderful
> Things'
> about this new 'Windows thing'. So I tried it and was aghast at just
> how **bad** and primitive it was, compared to what I was already using.)

Athena and Motif aren't exactly the height of sophistication :)

Jack Strangio <jackstrangio@yahoo.com> writes:

> Well, almost. I went from MSDOS to UNIX and then Linux. Never had
> Windows as my personal 'daily-driver'.

Only my privately used OSes:

TRS-DOS, NewDos and siblings, CP/M, TOS (Atari-ST), (DOS[1],)
Minix1/386[2], Linux & BSD.

____________

1: For a not really private DOS project I added a 286 to the Atari-ST
and it took a while until Fidonet software was good enough on the
Atari-ST, so I did bite the sour apple and got a complete 80286
system for only that purpose. So I don't count DOS as personal daily
driver, as it only was the Fido boot-loader for me.

2: There was a big patch set to free Minix1/8086 from the fixed 64k
segment limit.

--
I do not bite, I just want to play.

On 7/17/24 09:44, yeti wrote:
> Jack Strangio <jackstrangio@yahoo.com> writes:
>
>> Well, almost. I went from MSDOS to UNIX and then Linux. Never had
>> Windows as my personal 'daily-driver'.
>
> Only my privately used OSes:
>
> TRS-DOS, NewDos and siblings, CP/M, TOS (Atari-ST), (DOS[1],)
> Minix1/386[2], Linux & BSD.
>
> ____________
>
> 1: For a not really private DOS project I added a 286 to the Atari-ST
> and it took a while until Fidonet software was good enough on the
> Atari-ST, so I did bite the sour apple and got a complete 80286
> system for only that purpose. So I don't count DOS as personal daily
> driver, as it only was the Fido boot-loader for me.
>
> 2: There was a big patch set to free Minix1/8086 from the fixed 64k
> segment limit.
>

You poor devils. I took one look at a MS-DOS clone, returned it
after only using my C=64. I ran CP/M on a C=128 as well as the
the native OS and GUI that had been devised for Apple originally.
The new user of today will never understand "fdloppy disk bound" then
I went to Amiga OS 1.3 and finished with 3.9 with a 3.9 GB hard disk.I
got Windows XP on a laptop and shortly had a dual-boot with Mandriva
2006. Each was a learning experience for a hobbyist like myself.

bliss- Dell Precision 7730- PCLOS 2024.07- Linux 6.6.40- Plasma 5.27.11
--
b l i s s - S F 4 e v e r at D S L E x t r e m e dot com

Borax Man <rotflol2@hotmail.com> writes:
> Just wondering what programs (aside from the coreutils/X11 and other
> elements that make up a basic install), do you consider to be a vital
> part of YOUR Linux install? What are the little additional tools that
> you can't live without, or just consider to be necessary that maybe
> others wouldn't?

gcc, clang, git, valgrind, strace, gdb, VS Code, emacs, make,
autoconf, automake, etckeeper, gimp, inkscape, LyX, openssh, openssl,
pwgen, unicode, tcpdump, vlc, monitor, tmux.

--
https://www.greenend.org.uk/rjk/

On Wed, 17 Jul 2024 09:34:40 +0100, Richard Kettlewell wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> It is the reason why the use of a GUI has to be declared within the
>> executable, before it can even start executing. So that the part of the
>> kernel that is responsible for launching executables can decide whether
>> to set up the process to use a GUI or not.
>
> No, you have it exactly backwards. The distinction in the executable
> determines whether it is attached to a console ...

You mean a GUI console?

Again, this distinction does not exist on *nix systems.

On 17 Jul 2024 15:59:09 GMT, rbowman wrote:

> On Wed, 17 Jul 2024 08:48:06 -0000 (UTC), Jack Strangio wrote:
>
>> (Aually, I was using X11 desktops on UNIX, and had heard 'Wonderful
>> Things' about this new 'Windows thing'. So I tried it and was aghast
>> at just how **bad** and primitive it was, compared to what I was
>> already using.)
>
> Athena and Motif aren't exactly the height of sophistication :)

MOTIF/CDE pioneered multiple desktops. Something that Windows still can’t
get right.

On Tue, 16 Jul 2024 21:09:52 +0100, Richard Kettlewell wrote:

> CUI subsystem applications always run within a console, either inherited
> from the parent process, or created automatically if there isn’t one to
> inherit. GUI subsystem applications don’t normally get one (but can
> create one). Presumably a GUI subsystem application doesn’t have to open
> any Window at all if it doesn’t want to.

Another weird distinction: non-console applications don’t get any
standard input/output/error streams, and will abort if they try to
access them
<https://stackoverflow.com/questions/9705982/pythonw-exe-or-python-exe/30313091#30313091>.

Again, this is a completely unnecessary distinction, that *nix systems
do not insist on.

Note also the additional fine-print clarifications in the above Stack
Overflow item. There’s a lot of them ...

On Wed, 17 Jul 2024 22:03:58 -0000 (UTC), Lawrence D'Oliveiro wrote:

> MOTIF/CDE pioneered multiple desktops. Something that Windows still
> can’t get right.

The multiple desktops aren't that bad. The deskktop manager is a little
quirky but it's no worse that Ubuntu/GNOME.

One thing X/Motif was good at was filling your bookshelf. After you work
your way through xmFoo and xtBar, sooner or later you'll wind up at gems
like XButtonEvent from XLib. For added fun we made extensive use of UILs
and Mrm.

Mrm actually works quite nicely. Every site wanted their GUIs configured a
little differently so you just build a bunch of UIDs and you're good to
go. I *think* you might do something like that with xaml in native Windows
but I never pursued it.

On Wed, 17 Jul 2024 22:48:39 -0000 (UTC), Lawrence D'Oliveiro wrote:

> Another weird distinction: non-console applications don’t get any
> standard input/output/error streams, and will abort if they try to
> access them

I can't address what goes on in pythonw but in a straight service

[DllImport("kernel32.dll")]
static extern bool AttachConsole(int dwProcessId);
private const int ATTACH_PARENT_PROCESS = -1;
static void Main()
{
string[] args = Environment.GetCommandLineArgs();
foreach (string arg in args)
{
if (arg == "-v")
{
AttachConsole(ATTACH_PARENT_PROCESS);
Console.WriteLine("{0} version {1}",
Assembly.GetExecutingAssembly().GetName().Name,
Assembly.GetExecutingAssembly().GetName().Version);
return;
}
}

works nicely if you want to print the version and exit rather than running
the service.

On Wed, 17 Jul 2024 19:26:22 +0100, Richard Kettlewell wrote:

> gcc, clang, git, valgrind, strace, gdb, VS Code, emacs, make, autoconf,
> automake, etckeeper, gimp, inkscape, LyX, openssh, openssl,
> pwgen, unicode, tcpdump, vlc, monitor, tmux.

Ah, valgrind... That's the reason I prefer to debug in Linux. Windows has
memory debuggers like the rather expensive Purify that are painful. It's a
little more work since you have to link the library but I also like
Electric Fence. That dumps you right out into gdb rather than allowing a
memory corruption time bomb that will bite you in some unrelated section
of code.

On 17 Jul 2024 23:22:02 GMT, rbowman wrote:

> On Wed, 17 Jul 2024 22:03:58 -0000 (UTC), Lawrence D'Oliveiro wrote:
>
>> MOTIF/CDE pioneered multiple desktops. Something that Windows still
>> can’t get right.
>
> The multiple desktops aren't that bad.

In Windows? They need application support for them to work properly. On
*nix, this Just Works™.

On 17 Jul 2024 23:31:22 GMT, rbowman wrote:

> AttachConsole(ATTACH_PARENT_PROCESS);

And where does that go?

On Wed, 17 Jul 2024 23:49:54 -0000 (UTC), Lawrence D'Oliveiro wrote:

> On 17 Jul 2024 23:22:02 GMT, rbowman wrote:
>
>> On Wed, 17 Jul 2024 22:03:58 -0000 (UTC), Lawrence D'Oliveiro wrote:
>>
>>> MOTIF/CDE pioneered multiple desktops. Something that Windows still
>>> can’t get right.
>>
>> The multiple desktops aren't that bad.
>
> In Windows? They need application support for them to work properly. On
> *nix, this Just Works™.

Exactly what are you talking about?

On Wed, 17 Jul 2024 23:51:10 -0000 (UTC), Lawrence D'Oliveiro wrote:

> On 17 Jul 2024 23:31:22 GMT, rbowman wrote:
>
>> AttachConsole(ATTACH_PARENT_PROCESS);
>
> And where does that go?

To the console where you are running the program from the command line. In
this case the program is a Windows Service and would typically be started
from the Service Manager, automatically, or 'net start ...' and would not
have access to the Windows Terminal console.

No, it's not Linux. otoh with Linux you can run a program like vim from
Konsole and lose that console, you can run 'vim &' to background it, then
you can screw around with bg, and fg.

Or with Ubuntu I can click on the Tor icon and it comes up with no
console, or I can start it from Konsole and see all the logging.

One way is not inherently better than the other.

On 18 Jul 2024 04:09:16 GMT, rbowman wrote:

> On Wed, 17 Jul 2024 23:51:10 -0000 (UTC), Lawrence D'Oliveiro wrote:
>
>> On 17 Jul 2024 23:31:22 GMT, rbowman wrote:
>>
>>> AttachConsole(ATTACH_PARENT_PROCESS);
>>
>> And where does that go?
>
> To the console where you are running the program from the command line. In
> this case the program is a Windows Service and would typically be started
> from the Service Manager, automatically, or 'net start ...' and would not
> have access to the Windows Terminal console.

So where would it go in that case?