On Fri, 23 Aug 2024 10:11:44 +0100, The Natural Philosopher wrote:

> 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 ...

What I do, when I start modifying a file in /etc, say “/etc/«file»”, I
first make a backup copy under the name “/etc/«file»-orig”. That way, I
can easily go back if it doesn’t work right. And also I can quickly find
all the places I’ve customized things with a simple search like

find /etc -name \*-orig

On Fri, 23 Aug 2024 19:27:05 +0200, 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 already explained why that’s a bad idea.

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 23/08/24 23:35, Rich wrote:
> 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,

no, the post was not about getting a list of files in
whatever other way, it was about extracting information from
listboxes of (some) GUI software.

> use a proper tool (i.e., the 'find' command) to get a list of files.

I just use it to perform other tasks (like backups)

>
> 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.

in fact I am also following a path B : recreating from
scratch the functions I want with Gambas or QT creator.

>

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

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)

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

On Sat, 24 Aug 2024 01:26:16 +0200, MarioCCCP wrote:

> 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)

Given all the time spent so far fruitlessly discussing alternatives, if I
were you, I would be thinking of reviewing my life choices about now.

On 8/23/24 1:35 PM, MarioCCCP wrote:
> 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).

BASH and friends ARE 'cryptic'. They basically evolved
organically over time - more and more options kinda
rudely squeezed in. There IS extreme power there, but
how best to USE that power is oft insanely obscure.

THESE days, I'd strongly rec Python instead of Bash.
Much more comprehensible, capable and better documented.

I still write some Bash scripts - but if they're gonna
be more than a few lines, need some logic, then I'll
just use them to evoke a small Python pgm. It's good
to kinda KNOW how to use Bash - but, frankly, I always
wind up researching the net to see the ultra-fine details
of how to do stuff. NOT as difficult/obscure with Python.

Hmm ... "pysh" ? As is it's ALMOST there ...

Knowledge of "the System" ... again I'd rec Python
instead of Bash/Ksh/etc. The docs and libraries are
MUCH better documented. Bash, hell, a mere inobvious
SPACE can trash the whole script. Python DOES use up
more CPU/mem ... but these days, does that matter
so much ??? We're past 8088's and 64k. Being SURE
of what you're writing can usually be MUCH more
important.

MarioCCCP <NoliMihiFrangereMentulam@libero.it> wrote:
> 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)

You'd experience a more fruitful use of your time in learning rsync
instead of trying to dig around inside the memory of a running program
trying to extract the data from a list box on screen.

Trying to trawl around in the memory of another program to extract a
list box contents will cost you by far (as in something like 10x to
100x the cost in time and effort) than you'd use simply learning to use
rsync.

On 8/24/24 12:03 PM, Rich wrote:
> MarioCCCP <NoliMihiFrangereMentulam@libero.it> wrote:
>> 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)
>
> You'd experience a more fruitful use of your time in learning rsync
> instead of trying to dig around inside the memory of a running program
> trying to extract the data from a list box on screen.
>
> Trying to trawl around in the memory of another program to extract a
> list box contents will cost you by far (as in something like 10x to
> 100x the cost in time and effort) than you'd use simply learning to use
> rsync.

I will join in praise of rsync ... it is immensely
capable and can even be used client/server if needed.
The last few company backup programs I wrote were
all smart front-ends for rsync.

Getting the EXACT params CAN be a bit tricky sometimes,
but once you've got 'em you've got 'em. Many examples
can be found on the net.

But DO be cautious with the 'delete' option :-)

On Sat, 24 Aug 2024 20:53:21 -0400, 186282@ud0s4.net wrote:

> I will join in praise of rsync ...
>
> But DO be cautious with the 'delete' option :-)

Just for fun, there is also “--delete-before” and “--delete-after”. ;)

One nice thing is, if it hits an error during the transfer, any “delete”
options you specify, that haven’t already been acted on, get ignored.

On 2024-08-25, 186282@ud0s4.net <186283@ud0s4.net> wrote:

> I will join in praise of rsync ... it is immensely
> capable and can even be used client/server if needed.
> The last few company backup programs I wrote were
> all smart front-ends for rsync.
>
> Getting the EXACT params CAN be a bit tricky sometimes,
> but once you've got 'em you've got 'em. Many examples
> can be found on the net.

It took me a long time to get into rsync, and even now
I know I'm only using a fraction of its capabilities.
For instance, I still have to work out how to skip all
those browser caches when doing a backup. Maybe someday...

> But DO be cautious with the 'delete' option :-)

I always include the -n (dry run) option when typing a
command using the delete option. If the output looks OK,
I then recall the command and remove the -n.

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

On Sun, 25 Aug 2024 03:58:23 GMT, Charlie Gibbs wrote:

> It took me a long time to get into rsync, and even now I know I'm only
> using a fraction of its capabilities.
> For instance, I still have to work out how to skip all those browser
> caches when doing a backup.

Use the “--exclude” option.

> I always include the -n (dry run) option when typing a command using the
> delete option. If the output looks OK, I then recall the command and
> remove the -n.

Very wise. Same here.

I also like to do something similar with the “rm” command.

On 8/25/24 12:29 AM, Lawrence D'Oliveiro wrote:
> On Sun, 25 Aug 2024 03:58:23 GMT, Charlie Gibbs wrote:
>
>> It took me a long time to get into rsync, and even now I know I'm only
>> using a fraction of its capabilities.
>> For instance, I still have to work out how to skip all those browser
>> caches when doing a backup.
>
> Use the “--exclude” option.
>
>> I always include the -n (dry run) option when typing a command using the
>> delete option. If the output looks OK, I then recall the command and
>> remove the -n.
>
> Very wise. Same here.
>
> I also like to do something similar with the “rm” command.

The 'delete' option CAN be VERY useful for managing
company-scale backups. If it disappears or is moved
in the source dir then it's deleted in the dest dir.
This is very good for keeping Old Crap from building
up until it takes over the universe.

There IS a danger though - if for some reason the source
dir gets unmounted/etc then rsync will assume you removed
*everything* ... and will dutifully delete ALL of your
backups. Had to add some extra IQ, a bullshit test, to
some backup pgms I wrote just to deal with that. If
the source dir was suddenly under half its old size
then you DID NOT run rsync delete, but instead flagged
the user to look at what's going on there.

On 25/08/24 05:58, Charlie Gibbs wrote:
> On 2024-08-25, 186282@ud0s4.net <186283@ud0s4.net> wrote:
>
>> I will join in praise of rsync ... it is immensely
>> capable and can even be used client/server if needed.
>> The last few company backup programs I wrote were
>> all smart front-ends for rsync.
>>
>> Getting the EXACT params CAN be a bit tricky sometimes,
>> but once you've got 'em you've got 'em. Many examples
>> can be found on the net.
>
> It took me a long time to get into rsync, and even now
> I know I'm only using a fraction of its capabilities.
> For instance, I still have to work out how to skip all
> those browser caches when doing a backup. Maybe someday...
>
>> But DO be cautious with the 'delete' option :-)
>
> 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 ?

> I then recall the command and remove the -n.
>

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

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.

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.
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On Mon, 26 Aug 2024 18:42:54 +0200, MarioCCCP wrote:

> 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.

Have you tried that with 1.5 million lines?

On 26/08/24 23:36, Lawrence D'Oliveiro wrote:
> On Mon, 26 Aug 2024 18:42:54 +0200, MarioCCCP wrote:
>
>> 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.
>
> Have you tried that with 1.5 million lines?
yes, and Kate is surprisingly robust (I have 64 GB physical
RAM though and a swap partition as much as large). The files
is some hundred MB large.
Strangely enough, with regex I don't manage to remove the
rows, it leavs an empty row, so I later use a cleanup small
prog. to remove empty rows.

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