| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 42 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:43:25 |
| Calls: | 220 |
| Calls today: | 1 |
| Files: | 824 |
| Messages: | 121,543 |
| Posted today: | 6 |
On 26/08/24 01:39, Lawrence D'Oliveiro wrote:
On Sun, 25 Aug 2024 14:21:08 +0200, MarioCCCP wrote:
On 25/08/24 05:58, Charlie Gibbs wrote:
I always include the -n (dry run) option when typing a command using
the delete option. If the output looks OK,
how would you evaluate if an 1'500'000 files output is OK ?
You don’t need to look at them all. There will be repetitive patterns, so >> you check a few occurrences of those.
If you had a bit more experience with the command line, this wouldn’t be >> new to you.
no, normally I import text output (generated by suitable
programs) into KATE and then I use RegEx to search and filter.
partially OT : programming taskI believe not.
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 ?
physical memory
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
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.
On 20/08/2024 14:09, MarioCCCP wrote:
I believe not.
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 ?
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
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 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.
Basically, yer GUI app either does, or does not, support cut-n-paste
and that's that.
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.
But don't forget the later gens allergy to command prompts ... they
just WON'T cope.
On 8/20/24 2:27 PM, The Natural Philosopher wrote:
On 20/08/2024 14:09, MarioCCCP wrote:
I believe not.
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 ?
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.
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 ?
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.
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.
bidimensional / graphical interfaces, touch and pointers, are
intrinsically easier and more intuitive for MOST humans (not saying
users, but unformatted future users).
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
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.
On 21/08/2024 05:11, 186282@ud0s4.net wrote:
On 8/20/24 2:27 PM, The Natural Philosopher wrote:Not /tmp oddly, but various other stuff like /run is, yes.
On 20/08/2024 14:09, MarioCCCP wrote:
I believe not.
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 ?
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.
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:Not /tmp oddly, but various other stuff like /run is, yes.
On 20/08/2024 14:09, MarioCCCP wrote:
I believe not.
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 ?
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.
Even if it's not a ramdisk by default, you could still easily set it up
as one in your fstab
On 21/08/2024 05:11, 186282@ud0s4.net wrote:
Not /tmp oddly, but various other stuff like /run is, yes.
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.
-- 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
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?
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).
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).
On 22/08/2024 21:10, candycanearter07 wrote:
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 ...
FreeFileSync is much faster in scanning and stat-ing millions of files,
not to say comparing timestamps.
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.
On Fri, 23 Aug 2024 19:35:26 +0200, MarioCCCP wrote:
FreeFileSync is much faster in scanning and stat-ing millions of files,
not to say comparing timestamps.
Faster than rsync?
On 24/08/24 01:00, Lawrence D'Oliveiro wrote:
On Fri, 23 Aug 2024 19:35:26 +0200, MarioCCCP wrote:
FreeFileSync is much faster in scanning and stat-ing millions of
files, not to say comparing timestamps.
Faster than rsync?
rsync does not fit my habits, simply said. I find it overly difficult to master, so I end up not trusting what it does (due to my inexperience).
Not even QRsync (a gui wrapper)
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).