partially OT : programming task
Scenario : Debian Bookworm, XFCE4
Very often GUI programs show their results in the form of
ListBoxes, whose content is mainly textual semantically, but
very often cannot be copied/pasted as text and neither is
easy to export as text. I have one case in FreeFileSync,
that shows lists of files upwards of 500'000 items, and
other deduplicators programs.
I am having a general curiosity about this problem in linux.
Can a root user access, in read only mode, to memory
associated to another (plain user mode) process ? Or the
outcome is invariably a seg_fault ? Has a root user the
right to inquire the memory of non root programs ? I am not
speaking about disk files, but specifically in physical memory
Those gui programs must be storing long list of strings in
memory somewhere.
The first question is : is it there any way to escalate
read-only access to memory assigned to other programs ?
If the answer is, YES, then the problems evolves to
is it there a way to query the system (X server ? Who else
?) what is the topmost (active desktop, foreground)
graphical element at given mouse coordinates ? Are list
boxes standard enough to be accessed in a fairly portable
way disregarding the many different graphic engines (QT, GTK
or else) and DM (I have XFCE, but there are plenty of), so
to locate the strings arrays ? I can guess many frameworks
could implement internally listboxes in different ways and
debugging would be hard ! But the first thing to be
clarified is : I need some handle to memory allocated to it
in read only mode. Only then I could think to attemptively
elucidate the internal structure of the object. I am
assuming to not have any source code of the program or of
the underlying framwork.
If I had the code itself, it would be much simpler to extend
it, obviously, and to add a menu item with an ExportList cmq.
Tnx for any suggestion about the memory management and
protection under linux kernel.

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 20/08/2024 14:09, MarioCCCP wrote:
>
> partially OT : programming task
> Scenario : Debian Bookworm, XFCE4
> Very often GUI programs show their results in the form of ListBoxes,
> whose content is mainly textual semantically, but very often cannot be
> copied/pasted as text and neither is easy to export as text. I have one
> case in FreeFileSync, that shows lists of files upwards of 500'000
> items, and other deduplicators programs.
> I am having a general curiosity about this problem in linux.
> Can a root user access, in read only mode, to memory associated to
> another (plain user mode) process ? Or the outcome is invariably a
> seg_fault ? Has a root user the right to inquire the memory of non root
> programs ?
I believe not.
In such cases it is usual to write a daemon to handle *all* requests.

I am not speaking about disk files, but specifically in
> physical memory

Well thereby hangs a tale. In fact i deliberately created a RAMDISK in
one application purely to handle communications between synchronous
processes.

One process writes it, others may read

--
"And if the blind lead the blind, both shall fall into the ditch".

Gospel of St. Mathew 15:14

MarioCCCP <NoliMihiFrangereMentulam@libero.it> writes:
> Can a root user access, in read only mode, to memory associated to
> another (plain user mode) process ? Or the outcome is invariably a
> seg_fault ? Has a root user the right to inquire the memory of non
> root programs ? I am not speaking about disk files, but specifically
> in physical memory

Yes, root can access the memory image of non-root processes, for example
by reading from /proc/<pid>/mem, or using the ptrace syscall.

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

On Tue, 20 Aug 2024 15:09:03 +0200, MarioCCCP wrote:

> partially OT : programming task Scenario : Debian Bookworm, XFCE4 Very
> often GUI programs show their results in the form of ListBoxes, whose
> content is mainly textual semantically, but very often cannot be
> copied/pasted as text and neither is easy to export as text. I have one
> case in FreeFileSync, that shows lists of files upwards of 500'000
> items, and other deduplicators programs.

Short answer: you are doing it wrong.

Remember, GUIs are not designed to be automated. If you want to extract a
large list of filenames as output from one program to feed into another,
you do it from the command line.

On 8/20/24 9:28 PM, Lawrence D'Oliveiro wrote:
> On Tue, 20 Aug 2024 15:09:03 +0200, MarioCCCP wrote:
>
>> partially OT : programming task Scenario : Debian Bookworm, XFCE4 Very
>> often GUI programs show their results in the form of ListBoxes, whose
>> content is mainly textual semantically, but very often cannot be
>> copied/pasted as text and neither is easy to export as text. I have one
>> case in FreeFileSync, that shows lists of files upwards of 500'000
>> items, and other deduplicators programs.
>
> Short answer: you are doing it wrong.
>
> Remember, GUIs are not designed to be automated. If you want to extract a
> large list of filenames as output from one program to feed into another,
> you do it from the command line.

But most users come from Win - and shriek and run
hide in the shower stall at the appearance of a
command prompt :-)

Basically, yer GUI app either does, or does not,
support cut-n-paste and that's that.

On 8/20/24 2:27 PM, The Natural Philosopher wrote:
> On 20/08/2024 14:09, MarioCCCP wrote:
>>
>> partially OT : programming task
>> Scenario : Debian Bookworm, XFCE4
>> Very often GUI programs show their results in the form of ListBoxes,
>> whose content is mainly textual semantically, but very often cannot be
>> copied/pasted as text and neither is easy to export as text. I have
>> one case in FreeFileSync, that shows lists of files upwards of 500'000
>> items, and other deduplicators programs.
>> I am having a general curiosity about this problem in linux.
>> Can a root user access, in read only mode, to memory associated to
>> another (plain user mode) process ? Or the outcome is invariably a
>> seg_fault ? Has a root user the right to inquire the memory of non
>> root programs ?
> I believe not.
> In such cases it is usual to write a daemon to handle *all* requests.
>
>  I am not speaking about disk files, but specifically in
>> physical memory
>
> Well thereby hangs a tale. In fact i deliberately created a RAMDISK in
> one application purely to handle communications between synchronous
> processes.
>
> One process writes it, others may read

In many Linux distros now, /tmp is a de-facto
ramdisk - all disappears on reboot. IF you have
the space in your / partition then you need not
specifically create a NEW ramdisk to achieve the
effect.

I've done it both ways over the years.

Also look into "pipes". They've been useful at
times (but a bit less flexible than the on-'disk'
file approach). Wrote a nice little bi-di multi-
user socket server using pipes (in Python and
then 'C') so the 'parent' could convey a few
important lists to the 'child' and vice-versa.

Pipes basically ARE temporary in-ram files, but
managed more automatically and systematically by
the language/system library routines.

In this case the server COULD actually send commands
and info autonomously to the client so, I guess,
in a sense they were both clients AND servers.
Still have the code - might be interesting to refine
it a little more. Pushing "status" info to the clients
as needed is the best use IMHO ... "User X is sending
you a 'friend' request ..."

There are lots of client/server demos on the net,
from the stupidest blocking send-wait kind to the
high-traffic pre-forked/threaded variety. NOT hard
to expand them into something good. Great fun.

At current, I think "pre-threaded" holds the speed
record ... the server creates like a dozen images
of its important stuff at start-up so they're ready
and waiting and can then increase from there as needed.
It's maybe the most 'complicated', but not to the point
of being incomprehensible levitating-guru-only.

On Tue, 20 Aug 2024 23:46:07 -0400, 186282@ud0s4.net wrote:

> Basically, yer GUI app either does, or does not, support cut-n-paste
> and that's that.

GUI apps do not typically support copy/paste of GUI actions or widget
settings.

On 8/21/24 1:17 AM, Lawrence D'Oliveiro wrote:
> On Tue, 20 Aug 2024 23:46:07 -0400, 186282@ud0s4.net wrote:
>
>> Basically, yer GUI app either does, or does not, support cut-n-paste
>> and that's that.
>
> GUI apps do not typically support copy/paste of GUI actions or widget
> settings.

Quite correct.

Supporting that requires a LOT more effort.

Few bother.

But don't forget the later gens allergy to
command prompts ... they just WON'T cope.
Linux/Unix/Whatever will NOT be in their
future - which is tragic.

Hmmmm ... a GUI solution to common GUI issues ?

At least for some 'common apps' what the GUI
shows CAN be kinda parsed-out or even just
brute-force img-2-text ...

On Wed, 21 Aug 2024 01:46:04 -0400, 186282@ud0s4.net wrote:

> On 8/21/24 1:17 AM, Lawrence D'Oliveiro wrote:
>
>> On Tue, 20 Aug 2024 23:46:07 -0400, 186282@ud0s4.net wrote:
>>
>>> Basically, yer GUI app either does, or does not, support cut-n-paste
>>> and that's that.
>>
>> GUI apps do not typically support copy/paste of GUI actions or widget
>> settings.
>
> Supporting that requires a LOT more effort.

It can never be made to work efficiently or reliably.

> But don't forget the later gens allergy to command prompts ... they
> just WON'T cope.

Microsoft and Apple have spent years, decades, conditioning their users to
be allergic to the command line.

Gee, that’s too bad.

On 21/08/2024 05:11, 186282@ud0s4.net wrote:
> On 8/20/24 2:27 PM, The Natural Philosopher wrote:
>> On 20/08/2024 14:09, MarioCCCP wrote:
>>>
>>> partially OT : programming task
>>> Scenario : Debian Bookworm, XFCE4
>>> Very often GUI programs show their results in the form of ListBoxes,
>>> whose content is mainly textual semantically, but very often cannot
>>> be copied/pasted as text and neither is easy to export as text. I
>>> have one case in FreeFileSync, that shows lists of files upwards of
>>> 500'000 items, and other deduplicators programs.
>>> I am having a general curiosity about this problem in linux.
>>> Can a root user access, in read only mode, to memory associated to
>>> another (plain user mode) process ? Or the outcome is invariably a
>>> seg_fault ? Has a root user the right to inquire the memory of non
>>> root programs ?
>> I believe not.
>> In such cases it is usual to write a daemon to handle *all* requests.
>>
>>   I am not speaking about disk files, but specifically in
>>> physical memory
>>
>> Well thereby hangs a tale. In fact i deliberately created a RAMDISK in
>> one application purely to handle communications between synchronous
>> processes.
>>
>> One process writes it, others may read
>
>   In many Linux distros now, /tmp is a de-facto
>   ramdisk - all disappears on reboot. IF you have
>   the space in your / partition then you need not
>   specifically create a NEW ramdisk to achieve the
>   effect.
>
Not /tmp oddly, but various other stuff like /run is, yes.

--
For every complex problem there is an answer that is clear, simple, and
wrong.

H.L.Mencken

MarioCCCP <NoliMihiFrangereMentulam@libero.it> writes:
> If the answer is, YES, then the problems evolves to
> is it there a way to query the system (X server ? Who else ?) what is
> the topmost (active desktop, foreground) graphical element at given
> mouse coordinates ? Are list boxes standard enough to be accessed in a
> fairly portable way disregarding the many different graphic engines
> (QT, GTK or else) and DM (I have XFCE, but there are plenty of), so to
> locate the strings arrays ?

In terms of in-memory representation, no, they are totally different.

One way to programmatically interact with a GUI application from
‘outside’ is via Accesibility APIs.
https://fedoramagazine.org/automation-through-accessibility/ is an
example. I’ve no idea how standardized this is between different GUI
toolkits.

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

On 20/08/24 22:53, Richard Kettlewell wrote:
> MarioCCCP <NoliMihiFrangereMentulam@libero.it> writes:
>> Can a root user access, in read only mode, to memory associated to
>> another (plain user mode) process ? Or the outcome is invariably a
>> seg_fault ? Has a root user the right to inquire the memory of non
>> root programs ? I am not speaking about disk files, but specifically
>> in physical memory
>
> Yes, root can access the memory image of non-root processes, for example
> by reading from /proc/<pid>/mem, or using the ptrace syscall.
>

tnx a lot, I will make research about these suggestions

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 21/08/24 08:48, Lawrence D'Oliveiro wrote:
> On Wed, 21 Aug 2024 01:46:04 -0400, 186282@ud0s4.net wrote:
>
>> On 8/21/24 1:17 AM, Lawrence D'Oliveiro wrote:
>>
>>> On Tue, 20 Aug 2024 23:46:07 -0400, 186282@ud0s4.net wrote:
>>>
>>>> Basically, yer GUI app either does, or does not, support cut-n-paste
>>>> and that's that.
>>>
>>> GUI apps do not typically support copy/paste of GUI actions or widget
>>> settings.
>>
>> Supporting that requires a LOT more effort.
>
> It can never be made to work efficiently or reliably.
>
>> But don't forget the later gens allergy to command prompts ... they
>> just WON'T cope.
>
> Microsoft and Apple have spent years, decades, conditioning their users to
> be allergic to the command line.
I don't agree with this point of view.
bidimensional / graphical interfaces, touch and pointers,
are intrinsically easier and more intuitive for MOST humans
(not saying users, but unformatted future users).
We are evolutionary projected to work like that. Some firms
have chosen to follow the users preference in this case.
Amiga had one of the first gui interface, and is universally
considered a precursor
>
> Gee, that’s too bad.
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 21/08/24 20:00, Richard Kettlewell wrote:
> MarioCCCP <NoliMihiFrangereMentulam@libero.it> writes:
>> If the answer is, YES, then the problems evolves to
>> is it there a way to query the system (X server ? Who else ?) what is
>> the topmost (active desktop, foreground) graphical element at given
>> mouse coordinates ? Are list boxes standard enough to be accessed in a
>> fairly portable way disregarding the many different graphic engines
>> (QT, GTK or else) and DM (I have XFCE, but there are plenty of), so to
>> locate the strings arrays ?
>
> In terms of in-memory representation, no, they are totally different.
>
> One way to programmatically interact with a GUI application from
> ‘outside’ is via Accesibility APIs.
> https://fedoramagazine.org/automation-through-accessibility/ is an
> example. I’ve no idea how standardized this is between different GUI
> toolkits.
>
Tnx again !!!
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 8/21/24 18:15, MarioCCCP wrote:
> On 21/08/24 08:48, Lawrence D'Oliveiro wrote:
>> On Wed, 21 Aug 2024 01:46:04 -0400, 186282@ud0s4.net wrote:
>>
>>> On 8/21/24 1:17 AM, Lawrence D'Oliveiro wrote:
>>>
>>>> On Tue, 20 Aug 2024 23:46:07 -0400, 186282@ud0s4.net wrote:
>>>>
>>>>> Basically, yer GUI app either does, or does not, support cut-n-paste
>>>>> and that's that.
>>>>
>>>> GUI apps do not typically support copy/paste of GUI actions or widget
>>>> settings.
>>>
>>> Supporting that requires a LOT more effort.
>>
>> It can never be made to work efficiently or reliably.
>>
>>> But don't forget the later gens allergy to command prompts ... they
>>> just WON'T cope.
>>
>> Microsoft and Apple have spent years, decades, conditioning their
>> users to
>> be allergic to the command line.
>
> I don't agree with this point of view.
> bidimensional / graphical interfaces, touch and pointers, are
> intrinsically easier and more intuitive for MOST humans (not saying
> users, but unformatted future users).
> We are evolutionary projected to work like that. Some firms have chosen
> to follow the users preference in this case.
> Amiga had one of the first gui interface, and is universally considered
> a precursor
>
>>
>> Gee, that’s too bad.
>
I dunno why you figure it is bad. I had several Amigas computers at
one time or another and AmigaOS not only had a
GUI bur a Cli much like bash. I learned to use both and
used to format and copy multiple floppies from the Comand Line
interface. I used to run a system before I got my 2nd hard
drive from a Ram disk. First hard drive was a functional so
I paid in 1998 or so $346 US for my first working SCSI drive.
Took it up to 3.4 GB SCSI with a 68060 at a whole,
screaming but not overheaing, 50 MHz ub nt Amiga 2000b wutg
a video card and a scan doubler sho that i could work in
VGA.
Now AmigaOS lacked Memory Management because it had
been dropped in favor of the 68000 cpu which made the
machine much cheaper to produce.

Now I do not like the terminal but I spent 40 minutes
in it yesterday and finally got my audio back working.

bliss- Dell Precision 7730- PCLOS 2024.08- Linux 6.6.47- Plasma 5.27.11
now at 87 YOA as never before.
--
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

On Thu, 22 Aug 2024 03:15:55 +0200, MarioCCCP wrote:

> bidimensional / graphical interfaces, touch and pointers, are
> intrinsically easier and more intuitive for MOST humans (not saying
> users, but unformatted future users).

Sure they are. But they won’t do what you want to do in this case.

On 8/21/24 9:15 PM, MarioCCCP wrote:
> On 21/08/24 08:48, Lawrence D'Oliveiro wrote:
>> On Wed, 21 Aug 2024 01:46:04 -0400, 186282@ud0s4.net wrote:
>>
>>> On 8/21/24 1:17 AM, Lawrence D'Oliveiro wrote:
>>>
>>>> On Tue, 20 Aug 2024 23:46:07 -0400, 186282@ud0s4.net wrote:
>>>>
>>>>> Basically, yer GUI app either does, or does not, support cut-n-paste
>>>>> and that's that.
>>>>
>>>> GUI apps do not typically support copy/paste of GUI actions or widget
>>>> settings.
>>>
>>> Supporting that requires a LOT more effort.
>>
>> It can never be made to work efficiently or reliably.
>>
>>> But don't forget the later gens allergy to command prompts ... they
>>> just WON'T cope.
>>
>> Microsoft and Apple have spent years, decades, conditioning their
>> users to
>> be allergic to the command line.
>
> I don't agree with this point of view.
> bidimensional / graphical interfaces, touch and pointers, are
> intrinsically easier and more intuitive for MOST humans (not saying
> users, but unformatted future users).
> We are evolutionary projected to work like that. Some firms have chosen
> to follow the users preference in this case.
> Amiga had one of the first gui interface, and is universally considered
> a precursor

Hey, I don't disagree that GUIs are very NICE interfaces.
They're a LOT easier than the 'terminal' stuff I so
keenly remember. That's why they exist. It's why we
have telephones and TV rather than just Morse code.

But there are just some things they don't DO well.

Also, GUIs just can't provide the level of detailed
control you can get from most command-line utils.

M$, when absolutely needed, will provide cut-n-paste
stuff to enter in a command terminal. Otherwise ...

Joe/Jane User don't WANT to be "computer experts",
maybe just CAN'T. They just want stuff that's easy
to use and attractive.

There's an old joke about the professor who writes
some ten-line leader of super-complex math on the
old chalk-board and then says "So, OBVIOUSLY ..."

THAT is kinda how it is for 99 percent of computer
users. They can't/won't GET it - ever.

I can see this both ways. The 'real users' are in a
much better position, but they will always be the
very significant minority. Both factions 'deserve'
and need to use PCs. HOW to make it work for the
other 99 percent ???

GUIs for 'system stuff' need to be vastly IMPROVED.
GOTTA be able to get at the low-level stuff in a
way Joe/Jane can cope with.

SO far - even with Win - NOT EVEN CLOSE.

MarioCCCP <NoliMihiFrangereMentulam@libero.it> writes:

> partially OT : programming task
> Scenario : Debian Bookworm, XFCE4
> Very often GUI programs show their results in the form of ListBoxes,
> whose content is mainly textual semantically, but very often cannot be
> copied/pasted as text and neither is easy to export as text. I have
> one case in FreeFileSync, that shows lists of files upwards of 500'000
> items, and other deduplicators programs.

I'm not sure what exactly is the problem you're having. You want to copy
500,000 file names out of FreeFileSync? But why?

The Natural Philosopher <tnp@invalid.invalid> wrote at 09:56 this Wednesday (GMT):
> On 21/08/2024 05:11, 186282@ud0s4.net wrote:
>> On 8/20/24 2:27 PM, The Natural Philosopher wrote:
>>> On 20/08/2024 14:09, MarioCCCP wrote:
>>>>
>>>> partially OT : programming task
>>>> Scenario : Debian Bookworm, XFCE4
>>>> Very often GUI programs show their results in the form of ListBoxes,
>>>> whose content is mainly textual semantically, but very often cannot
>>>> be copied/pasted as text and neither is easy to export as text. I
>>>> have one case in FreeFileSync, that shows lists of files upwards of
>>>> 500'000 items, and other deduplicators programs.
>>>> I am having a general curiosity about this problem in linux.
>>>> Can a root user access, in read only mode, to memory associated to
>>>> another (plain user mode) process ? Or the outcome is invariably a
>>>> seg_fault ? Has a root user the right to inquire the memory of non
>>>> root programs ?
>>> I believe not.
>>> In such cases it is usual to write a daemon to handle *all* requests.
>>>
>>>   I am not speaking about disk files, but specifically in
>>>> physical memory
>>>
>>> Well thereby hangs a tale. In fact i deliberately created a RAMDISK in
>>> one application purely to handle communications between synchronous
>>> processes.
>>>
>>> One process writes it, others may read
>>
>>   In many Linux distros now, /tmp is a de-facto
>>   ramdisk - all disappears on reboot. IF you have
>>   the space in your / partition then you need not
>>   specifically create a NEW ramdisk to achieve the
>>   effect.
>>
> Not /tmp oddly, but various other stuff like /run is, yes.

Even if it's not a ramdisk by default, you could still easily set it up
as one in your fstab
--
user <candycane> is generated from /dev/urandom

On 22/08/2024 21:10, candycanearter07 wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote at 09:56 this Wednesday (GMT):
>> On 21/08/2024 05:11, 186282@ud0s4.net wrote:
>>> On 8/20/24 2:27 PM, The Natural Philosopher wrote:
>>>> On 20/08/2024 14:09, MarioCCCP wrote:
>>>>>
>>>>> partially OT : programming task
>>>>> Scenario : Debian Bookworm, XFCE4
>>>>> Very often GUI programs show their results in the form of ListBoxes,
>>>>> whose content is mainly textual semantically, but very often cannot
>>>>> be copied/pasted as text and neither is easy to export as text. I
>>>>> have one case in FreeFileSync, that shows lists of files upwards of
>>>>> 500'000 items, and other deduplicators programs.
>>>>> I am having a general curiosity about this problem in linux.
>>>>> Can a root user access, in read only mode, to memory associated to
>>>>> another (plain user mode) process ? Or the outcome is invariably a
>>>>> seg_fault ? Has a root user the right to inquire the memory of non
>>>>> root programs ?
>>>> I believe not.
>>>> In such cases it is usual to write a daemon to handle *all* requests.
>>>>
>>>>   I am not speaking about disk files, but specifically in
>>>>> physical memory
>>>>
>>>> Well thereby hangs a tale. In fact i deliberately created a RAMDISK in
>>>> one application purely to handle communications between synchronous
>>>> processes.
>>>>
>>>> One process writes it, others may read
>>>
>>>   In many Linux distros now, /tmp is a de-facto
>>>   ramdisk - all disappears on reboot. IF you have
>>>   the space in your / partition then you need not
>>>   specifically create a NEW ramdisk to achieve the
>>>   effect.
>>>
>> Not /tmp oddly, but various other stuff like /run is, yes.
>
>
> Even if it's not a ramdisk by default, you could still easily set it up
> as one in your fstab

Indeed. But unwilling to disturb stuff that already was working fine, I
created mine under /volatile, to remind me it would vanish on reboot.

--
"Nature does not give up the winter because people dislike the cold."

― Confucius

On 21/08/2024 10:56, The Natural Philosopher wrote:
> On 21/08/2024 05:11, 186282@ud0s4.net wrote:
>>
>>    In many Linux distros now, /tmp is a de-facto
>>    ramdisk - all disappears on reboot. IF you have
>>    the space in your / partition then you need not
>>    specifically create a NEW ramdisk to achieve the
>>    effect.
>>
> Not /tmp oddly, but various other stuff like /run is, yes.
>

Well, currently just varies distro to distro what the defaults are. e.g.

Debian 12 stable ("bookworm") and various Debian downstreams are still
on-disk /tmp by default (of course you can already put it in ram if you
want to).

However, was recentish (May/Jun 2024) news that future Debian 13
("trixie") will move to tmpfs (ram) /tmp by default [1][2]. Can expect
it to propagate to Debian downstream Ubuntu etc. too [3].

It's already been changed to use the systemd tmp.mount [4] for tmpfs
(ram) /tmp in debian unstable ("sid") [5]

[1] https://lwn.net/Articles/975565/
[2]
https://www.reddit.com/r/debian/comments/1d8swux/debian_13_is_changing_the_tmp_behavior/
[3] https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1870585
[4] https://github.com/systemd/systemd/blob/main/units/tmp.mount

[5]
https://metadata.ftp-master.debian.org/changelogs//main/s/systemd/systemd_256.5-1_changelog

> -- Luca Boccassi <bluca@debian.org> Tue, 28 May 2024 12:11:36 +0100
>
> systemd (256~rc3-3) unstable; urgency=medium
> [...]
> * Make /tmp/ a tmpfs by default. Restore the upstream default
> and make /tmp/ a tmpfs. Can be overridden with: touch
> /etc/systemd/system/tmp.mount or: systemctl mask tmp.mount
>

On 23/08/24 11:11, The Natural Philosopher wrote:
> On 22/08/2024 21:10, candycanearter07 wrote:
>> The Natural Philosopher <tnp@invalid.invalid> wrote at
>> 09:56 this Wednesday (GMT):
>>> On 21/08/2024 05:11, 186282@ud0s4.net wrote:
>>>> On 8/20/24 2:27 PM, The Natural Philosopher wrote:
>>>>> On 20/08/2024 14:09, MarioCCCP wrote:
>>>>>>

the thread proceded on its own, but I was not asking about
how to chose a way to share anything at my will : I was
asking about how to "spy" upon AN EXISTING SW that very
likely uses RAM (whether or not it uses also disk caching I
dunno, even it is possible). I'd like to read its RAM, not
to search for cached info (named whatsoever).

>>>>>> partially OT : programming task
>>>>>> Scenario : Debian Bookworm, XFCE4
>>>>>> Very often GUI programs show their results in the form
>>>>>> of ListBoxes,
>>>>>> whose content is mainly textual semantically, but very
>>>>>> often cannot
>>>>>> be copied/pasted as text and neither is easy to export
>>>>>> as text. I
>>>>>> have one case in FreeFileSync, that shows lists of
>>>>>> files upwards of
>>>>>> 500'000 items, and other deduplicators programs.
>>>>>> I am having a general curiosity about this problem in
>>>>>> linux.
>>>>>> Can a root user access, in read only mode, to memory
>>>>>> associated to
>>>>>> another (plain user mode) process ? Or the outcome is
>>>>>> invariably a
>>>>>> seg_fault ? Has a root user the right to inquire the
>>>>>> memory of non
>>>>>> root programs ?
>>>>> I believe not.
>>>>> In such cases it is usual to write a daemon to handle
>>>>> *all* requests.
>>>>>
>>>>>    I am not speaking about disk files, but specifically in
>>>>>> physical memory
>>>>>
>>>>> Well thereby hangs a tale. In fact i deliberately
>>>>> created a RAMDISK in
>>>>> one application purely to handle communications between
>>>>> synchronous
>>>>> processes.
>>>>>
>>>>> One process writes it, others may read
>>>>
>>>>     In many Linux distros now, /tmp is a de-facto
>>>>     ramdisk - all disappears on reboot. IF you have
>>>>     the space in your / partition then you need not
>>>>     specifically create a NEW ramdisk to achieve the
>>>>     effect.
>>>>
>>> Not /tmp oddly, but various other stuff like /run is, yes.
>>
>>
>> Even if it's not a ramdisk by default, you could still
>> easily set it up
>> as one in your fstab
>
> Indeed. But unwilling to disturb stuff that already was
> working fine, I created mine under /volatile, to remind me
> it would vanish on reboot.
>
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 22/08/24 09:19, 186282@ud0s4.net wrote:
> On 8/21/24 9:15 PM, MarioCCCP wrote:
>> On 21/08/24 08:48, Lawrence D'Oliveiro wrote:
>>> On Wed, 21 Aug 2024 01:46:04 -0400, 186282@ud0s4.net wrote:
>>>
>>>> On 8/21/24 1:17 AM, Lawrence D'Oliveiro wrote:
>>>>
>>>>> On Tue, 20 Aug 2024 23:46:07 -0400, 186282@ud0s4.net
>>>>> wrote:
>>>>>
>>>>>> Basically, yer GUI app either does, or does not,
>>>>>> support cut-n-paste
>>>>>> and that's that.
>>>>>
>>>>> GUI apps do not typically support copy/paste of GUI
>>>>> actions or widget
>>>>> settings.
>>>>
>>>> Supporting that requires a LOT more effort.
>>>
>>> It can never be made to work efficiently or reliably.
>>>
>>>> But don't forget the later gens allergy to command
>>>> prompts ... they
>>>> just WON'T cope.
>>>
>>> Microsoft and Apple have spent years, decades,
>>> conditioning their users to
>>> be allergic to the command line.
>>
>> I don't agree with this point of view.
>> bidimensional / graphical interfaces, touch and pointers,
>> are intrinsically easier and more intuitive for MOST
>> humans (not saying users, but unformatted future users).
>> We are evolutionary projected to work like that. Some
>> firms have chosen to follow the users preference in this
>> case.
>> Amiga had one of the first gui interface, and is
>> universally considered a precursor
>
>   Hey, I don't disagree that GUIs are very NICE interfaces.
>   They're a LOT easier than the 'terminal' stuff I so
>   keenly remember. That's why they exist. It's why we
>   have telephones and TV rather than just Morse code.
>
>   But there are just some things they don't DO well.
FreeFileSync is a GUI program that does so well what it does
that I am willing to attach some extern piece of SW to
"extend" it further, in this case.
Meanwhile I am also writing from scratch some SW in Gambas
that would do what I lack in FreeFileSync (without the
ambition of being as much as general and versatile).
Gambas is, by chance, a GUI IDE :D
FreeFileSync is much faster in scanning and stat-ing
millions of files, not to say comparing timestamps.

>
>   Also, GUIs just can't provide the level of detailed
>   control you can get from most command-line utils.
that is surely true, but such level of control is out of my
capacity. If I absolutely need to control bits, I put hands
at Gambas or QT creator, bottom up.
Bash is really difficult to me. I have tried many times to
understand it, but I failed. So it's useless to complain
about this : i try more familiar approaches (I am well
accustomed with C and Basic, but in this case, requiring
unusual features, I lack the knowledge of the SYSTEM in itself).
>
>   M$, when absolutely needed, will provide cut-n-paste
>   stuff to enter in a command terminal. Otherwise ...
>
>   Joe/Jane User don't WANT to be "computer experts",
>   maybe just CAN'T. They just want stuff that's easy
>   to use and attractive.
>
>   There's an old joke about the professor who writes
>   some ten-line leader of super-complex math on the
>   old chalk-board and then says "So, OBVIOUSLY ..."
>
>   THAT is kinda how it is for 99 percent of computer
>   users. They can't/won't GET it - ever.
>
>   I can see this both ways. The 'real users' are in a
>   much better position, but they will always be the
>   very significant minority. Both factions 'deserve'
>   and need to use PCs. HOW to make it work for the
>   other 99 percent ???
>
>   GUIs for 'system stuff' need to be vastly IMPROVED.
>   GOTTA be able to get at the low-level stuff in a
>   way Joe/Jane can cope with.
>
>   SO far - even with Win - NOT EVEN CLOSE.
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 22/08/24 10:16, Anssi Saari wrote:
> MarioCCCP <NoliMihiFrangereMentulam@libero.it> writes:
>
>> partially OT : programming task
>> Scenario : Debian Bookworm, XFCE4
>> Very often GUI programs show their results in the form of ListBoxes,
>> whose content is mainly textual semantically, but very often cannot be
>> copied/pasted as text and neither is easy to export as text. I have
>> one case in FreeFileSync, that shows lists of files upwards of 500'000
>> items, and other deduplicators programs.
>
> I'm not sure what exactly is the problem you're having. You want to copy
> 500,000 file names out of FreeFileSync? But why?

to revise / analyze the results externally, also to save log
of errors and mangle them to compile scripts that would try
to resolve such errors (i.g. with higher privileges).

Also from deduplicators, very smart in finding duplicates,
I'd prefer to import the lists of candidates in extern
software written by myself (extending the options : ig.
instead to delete the copies, enable MOVING them elsewhere,
renaming with criteria, compressing, hardlinking and so).

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

MarioCCCP <NoliMihiFrangereMentulam@libero.it> wrote:
> On 23/08/24 11:11, The Natural Philosopher wrote:
>> On 22/08/2024 21:10, candycanearter07 wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> wrote at
>>> 09:56 this Wednesday (GMT):
>>>> On 21/08/2024 05:11, 186282@ud0s4.net wrote:
>>>>> On 8/20/24 2:27 PM, The Natural Philosopher wrote:
>>>>>> On 20/08/2024 14:09, MarioCCCP wrote:
>>>>>>>
>
> the thread proceded on its own, but I was not asking about
> how to chose a way to share anything at my will : I was
> asking about how to "spy" upon AN EXISTING SW that very
> likely uses RAM (whether or not it uses also disk caching I
> dunno, even it is possible). I'd like to read its RAM, not
> to search for cached info (named whatsoever).

We certianly can't stop you, but as at least one commenter indicated,
you are trying go at it the "wrong way". If you want a list of files,
use a proper tool (i.e., the 'find' command) to get a list of files.

But if you want to continue, feel free to do so, but you'll be falling
down a very deep rabbit hole within which you'll find multiple mazes of
twisty passages.