Is there any practical way to completely disable Emacs' eln-cache
while using Devuan Daedalus binary packages, versions in the
1.28.2 neighborhood? Even better would be to entirely disable
native compilation.

The cached files cause noise in Tripwire output and make messes
in directories Emacs should not be leaving messes in. Recently,
I saw .el files being left in /tmp.

Web searching found several ways to try to direct the cache to a
different directory path, but that's not what I want. (Also,
most of those methods failed to work as advertised.) Making the
default directory a symlink to /dev/null simply moved the cached
files to another directory.

Thanks.

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

On 2024-07-02 06:19, Robert Riches wrote:
> Is there any practical way to completely disable Emacs' eln-cache
> while using Devuan Daedalus binary packages, versions in the
> 1.28.2 neighborhood? Even better would be to entirely disable
> native compilation.
>
> The cached files cause noise in Tripwire output and make messes
> in directories Emacs should not be leaving messes in. Recently,
> I saw .el files being left in /tmp.

emacs has all the right to leave any file it wishes in /tmp.

>
> Web searching found several ways to try to direct the cache to a
> different directory path, but that's not what I want. (Also,
> most of those methods failed to work as advertised.) Making the
> default directory a symlink to /dev/null simply moved the cached
> files to another directory.
>
> Thanks.
>

--
Cheers, Carlos.

On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:
> On 2024-07-02 06:19, Robert Riches wrote:
>> Is there any practical way to completely disable Emacs' eln-cache
>> while using Devuan Daedalus binary packages, versions in the
>> 1.28.2 neighborhood? Even better would be to entirely disable
>> native compilation.
>>
>> The cached files cause noise in Tripwire output and make messes
>> in directories Emacs should not be leaving messes in. Recently,
>> I saw .el files being left in /tmp.
>
> emacs has all the right to leave any file it wishes in /tmp.

Not on _MY_ machine, it doesn't. Long-standing tradition says it
is a bug for a program to fail to clean up after itself in /tmp.

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

On 03/07/2024 04:42, Robert Riches wrote:
> On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:
>> On 2024-07-02 06:19, Robert Riches wrote:
>>> Is there any practical way to completely disable Emacs' eln-cache
>>> while using Devuan Daedalus binary packages, versions in the
>>> 1.28.2 neighborhood? Even better would be to entirely disable
>>> native compilation.
>>>
>>> The cached files cause noise in Tripwire output and make messes
>>> in directories Emacs should not be leaving messes in. Recently,
>>> I saw .el files being left in /tmp.
>>
>> emacs has all the right to leave any file it wishes in /tmp.
>
> Not on _MY_ machine, it doesn't. Long-standing tradition says it
> is a bug for a program to fail to clean up after itself in /tmp.
>
Tell that to systemd...:-)

--
“The urge to save humanity is almost always only a false face for the
urge to rule it.”
– H. L. Mencken

On 2024-07-03 11:35, The Natural Philosopher wrote:
> On 03/07/2024 04:42, Robert Riches wrote:
>> On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:
>>> On 2024-07-02 06:19, Robert Riches wrote:
>>>> Is there any practical way to completely disable Emacs' eln-cache
>>>> while using Devuan Daedalus binary packages, versions in the
>>>> 1.28.2 neighborhood?  Even better would be to entirely disable
>>>> native compilation.
>>>>
>>>> The cached files cause noise in Tripwire output and make messes
>>>> in directories Emacs should not be leaving messes in.  Recently,
>>>> I saw .el files being left in /tmp.
>>>
>>> emacs has all the right to leave any file it wishes in /tmp.
>>
>> Not on _MY_ machine, it doesn't.  Long-standing tradition says it
>> is a bug for a program to fail to clean up after itself in /tmp.
>>
> Tell that to systemd...:-)

:-D

--
Cheers, Carlos.

On Wed, 03 Jul 2024 03:42:52 +0000, Robert Riches wrote:

> On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:
>> On 2024-07-02 06:19, Robert Riches wrote:
>>> Is there any practical way to completely disable Emacs' eln-cache
>>> while using Devuan Daedalus binary packages, versions in the
>>> 1.28.2 neighborhood? Even better would be to entirely disable
>>> native compilation.
>>>
>>> The cached files cause noise in Tripwire output and make messes
>>> in directories Emacs should not be leaving messes in. Recently,
>>> I saw .el files being left in /tmp.
>>
>> emacs has all the right to leave any file it wishes in /tmp.
>
> Not on _MY_ machine, it doesn't. Long-standing tradition says it
> is a bug for a program to fail to clean up after itself in /tmp.

Longer standing Unix tradition has a periodically-scheduled job
(often known as "skulker" or "tmpwatch") that cleans out the various
tmp directories (/tmp, /var/tmp, etc) of old, discarded temporary
files.

--
Lew Pitcher
"In Skills We Trust"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote at 13:33 this Wednesday (GMT):
> On Wed, 03 Jul 2024 03:42:52 +0000, Robert Riches wrote:
>
>> On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:
>>> On 2024-07-02 06:19, Robert Riches wrote:
>>>> Is there any practical way to completely disable Emacs' eln-cache
>>>> while using Devuan Daedalus binary packages, versions in the
>>>> 1.28.2 neighborhood? Even better would be to entirely disable
>>>> native compilation.
>>>>
>>>> The cached files cause noise in Tripwire output and make messes
>>>> in directories Emacs should not be leaving messes in. Recently,
>>>> I saw .el files being left in /tmp.
>>>
>>> emacs has all the right to leave any file it wishes in /tmp.
>>
>> Not on _MY_ machine, it doesn't. Long-standing tradition says it
>> is a bug for a program to fail to clean up after itself in /tmp.
>
> Longer standing Unix tradition has a periodically-scheduled job
> (often known as "skulker" or "tmpwatch") that cleans out the various
> tmp directories (/tmp, /var/tmp, etc) of old, discarded temporary
> files.

Wait, really? I've been storing random files in /var/tmp..
--
user <candycane> is generated from /dev/urandom

On Wed, 3 Jul 2024 10:35:48 +0100, The Natural Philosopher wrote:
On Wed, 3 Jul 2024 10:35:48 +0100, The Natural Philosopher wrote:

> On 03/07/2024 04:42, Robert Riches wrote:
> On 03/07/2024 04:42, Robert Riches wrote:
>
>
>> Not on _MY_ machine, it doesn't. Long-standing tradition says it is a
>> Not on _MY_ machine, it doesn't. Long-standing tradition says it is a
>> bug for a program to fail to clean up after itself in /tmp.
>> bug for a program to fail to clean up after itself in /tmp.
>>
>>
> Tell that to systemd...:-)
> Tell that to systemd...:-)

systemd has a whole mechanism for dealing with temporary files, including
systemd has a whole mechanism for dealing with temporary files, including
isolating processes with their own temporary directories, that
isolating processes with their own temporary directories, that
automatically disappear when the service terminates.
automatically disappear when the service terminates.

You are not going to see junk left around with systemd. It takes full
You are not going to see junk left around with systemd. It takes full
advantage of tmpfs to ensure that.
advantage of tmpfs to ensure that.
.

On 2024-07-03 16:30, candycanearter07 wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote at 13:33 this Wednesday (GMT):
>> On Wed, 03 Jul 2024 03:42:52 +0000, Robert Riches wrote:
>>
>>> On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:
>>>> On 2024-07-02 06:19, Robert Riches wrote:
>>>>> Is there any practical way to completely disable Emacs' eln-cache
>>>>> while using Devuan Daedalus binary packages, versions in the
>>>>> 1.28.2 neighborhood? Even better would be to entirely disable
>>>>> native compilation.
>>>>>
>>>>> The cached files cause noise in Tripwire output and make messes
>>>>> in directories Emacs should not be leaving messes in. Recently,
>>>>> I saw .el files being left in /tmp.
>>>>
>>>> emacs has all the right to leave any file it wishes in /tmp.
>>>
>>> Not on _MY_ machine, it doesn't. Long-standing tradition says it
>>> is a bug for a program to fail to clean up after itself in /tmp.
>>
>> Longer standing Unix tradition has a periodically-scheduled job
>> (often known as "skulker" or "tmpwatch") that cleans out the various
>> tmp directories (/tmp, /var/tmp, etc) of old, discarded temporary
>> files.
>
>
> Wait, really? I've been storing random files in /var/tmp..

Distributions have various policies and implementations of that.

--
Cheers,
Carlos E.R.

On 2024-07-03, The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 03/07/2024 04:42, Robert Riches wrote:
>> On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:
>>> On 2024-07-02 06:19, Robert Riches wrote:
>>>> Is there any practical way to completely disable Emacs' eln-cache
>>>> while using Devuan Daedalus binary packages, versions in the
>>>> 1.28.2 neighborhood? Even better would be to entirely disable
>>>> native compilation.
>>>>
>>>> The cached files cause noise in Tripwire output and make messes
>>>> in directories Emacs should not be leaving messes in. Recently,
>>>> I saw .el files being left in /tmp.
>>>
>>> emacs has all the right to leave any file it wishes in /tmp.
>>
>> Not on _MY_ machine, it doesn't. Long-standing tradition says it
>> is a bug for a program to fail to clean up after itself in /tmp.
>>
> Tell that to systemd...:-)

systemd? Not on this machine!!!!!

A test VM installation of the first Mageia release with systemd
appeared to install okay. However, on first boot, the boot
process got hung up, waited several minutes, reported some
timeouts, and came up with a severely crippled system. IIRC,
not all of the RAIDs were composed, and not all of the
filesystems were mounted. The tools to analyze the binary
registry^H^H^H^H^H^H^H^Hjournal weren't installed.

Determined to be one of the last people on the planet to use an
init system other than systemd, I switched to Slackware, then to
Debian, and now to Devuan (Beowulf, Chimaera, and now Daedalus).
If it becomes impractical to use Linux without systemd, one of
the BSDs will have to do.

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

On 7/3/24 20:29, Robert Riches wrote:
> On 2024-07-03, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 03/07/2024 04:42, Robert Riches wrote:
>>> On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:
>>>> On 2024-07-02 06:19, Robert Riches wrote:
>>>>> Is there any practical way to completely disable Emacs' eln-cache
>>>>> while using Devuan Daedalus binary packages, versions in the
>>>>> 1.28.2 neighborhood? Even better would be to entirely disable
>>>>> native compilation.
>>>>>
>>>>> The cached files cause noise in Tripwire output and make messes
>>>>> in directories Emacs should not be leaving messes in. Recently,
>>>>> I saw .el files being left in /tmp.
>>>>
>>>> emacs has all the right to leave any file it wishes in /tmp.
>>>
>>> Not on _MY_ machine, it doesn't. Long-standing tradition says it
>>> is a bug for a program to fail to clean up after itself in /tmp.
>>>
>> Tell that to systemd...:-)
>
> systemd? Not on this machine!!!!!
>
> A test VM installation of the first Mageia release with systemd
> appeared to install okay. However, on first boot, the boot
> process got hung up, waited several minutes, reported some
> timeouts, and came up with a severely crippled system. IIRC,
> not all of the RAIDs were composed, and not all of the
> filesystems were mounted. The tools to analyze the binary
> registry^H^H^H^H^H^H^H^Hjournal weren't installed.
>
> Determined to be one of the last people on the planet to use an
> init system other than systemd, I switched to Slackware, then to
> Debian, and now to Devuan (Beowulf, Chimaera, and now Daedalus).
> If it becomes impractical to use Linux without systemd, one of
> the BSDs will have to do.
>

Have you ever considered PCLinuxOS 64 bit only X86 as
here V and a friendly Forum that helps resolve issues.
<https://www.pclinuxos.com/forum/index.php>
A Rolling Release...
bliss- Dell Precision 7730-PCLOS 2024.07-Linux 6.6.36-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

On 4 Jul 2024 03:29:50 GMT, Robert Riches wrote:

> If it becomes impractical to use Linux without systemd, one of the BSDs
> will have to do.

Did you know some in the BSD world have been working on their own systemd-
lookalike? It’s called “InitWare”.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On 4 Jul 2024 03:29:50 GMT, Robert Riches wrote:
>> If it becomes impractical to use Linux without systemd, one of the
>> BSDs will have to do.
>
> Did you know some in the BSD world have been working on their own
> systemd- lookalike? It’s called “InitWare”.

In fact it seems to be a (by now quite divergent?) fork of systemd, not
just a lookalike.

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

On Thu, 04 Jul 2024 08:36:32 +0100, Richard Kettlewell wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On 4 Jul 2024 03:29:50 GMT, Robert Riches wrote:
>>
>>> If it becomes impractical to use Linux without systemd, one of the
>>> BSDs will have to do.
>>
>> Did you know some in the BSD world have been working on their own
>> systemd- lookalike? It’s called “InitWare”.
>
> In fact it seems to be a (by now quite divergent?) fork of systemd, not
> just a lookalike.

They do seem to measure themselves closely against systemd as a yardstick,
to how how they are different and how they are the same.

<https://github.com/InitWare/InitWare/wiki/Dropped-components>

On 2024-07-04, Bobbie Sellers <blissInSanFrancisco@mouse-potato.com> wrote:
> On 7/3/24 20:29, Robert Riches wrote:
>> On 2024-07-03, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> On 03/07/2024 04:42, Robert Riches wrote:
>>>> On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:
>>>>> On 2024-07-02 06:19, Robert Riches wrote:
>>>>>> Is there any practical way to completely disable Emacs' eln-cache
>>>>>> while using Devuan Daedalus binary packages, versions in the
>>>>>> 1.28.2 neighborhood? Even better would be to entirely disable
>>>>>> native compilation.
>>>>>>
>>>>>> The cached files cause noise in Tripwire output and make messes
>>>>>> in directories Emacs should not be leaving messes in. Recently,
>>>>>> I saw .el files being left in /tmp.
>>>>>
>>>>> emacs has all the right to leave any file it wishes in /tmp.
>>>>
>>>> Not on _MY_ machine, it doesn't. Long-standing tradition says it
>>>> is a bug for a program to fail to clean up after itself in /tmp.
>>>>
>>> Tell that to systemd...:-)
>>
>> systemd? Not on this machine!!!!!
>>
>> A test VM installation of the first Mageia release with systemd
>> appeared to install okay. However, on first boot, the boot
>> process got hung up, waited several minutes, reported some
>> timeouts, and came up with a severely crippled system. IIRC,
>> not all of the RAIDs were composed, and not all of the
>> filesystems were mounted. The tools to analyze the binary
>> registry^H^H^H^H^H^H^H^Hjournal weren't installed.
>>
>> Determined to be one of the last people on the planet to use an
>> init system other than systemd, I switched to Slackware, then to
>> Debian, and now to Devuan (Beowulf, Chimaera, and now Daedalus).
>> If it becomes impractical to use Linux without systemd, one of
>> the BSDs will have to do.
>>
>
> Have you ever considered PCLinuxOS 64 bit only X86 as
> here V and a friendly Forum that helps resolve issues.
><https://www.pclinuxos.com/forum/index.php>
> A Rolling Release...
> bliss- Dell Precision 7730-PCLOS 2024.07-Linux 6.6.36-Plasma 5.27.11

Thank you for the suggestion. PCLinuxOS was on my list of
options in May of 2016. At the time, it did not appear to have
csh.

Thanks.

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

On 2024-07-04, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 04 Jul 2024 08:36:32 +0100, Richard Kettlewell wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On 4 Jul 2024 03:29:50 GMT, Robert Riches wrote:
>>>
>>>> If it becomes impractical to use Linux without systemd, one of the
>>>> BSDs will have to do.
>>>
>>> Did you know some in the BSD world have been working on their own
>>> systemd- lookalike? It’s called “InitWare”.
>>
>> In fact it seems to be a (by now quite divergent?) fork of systemd, not
>> just a lookalike.
>
> They do seem to measure themselves closely against systemd as a yardstick,
> to how how they are different and how they are the same.
>
><https://github.com/InitWare/InitWare/wiki/Dropped-components>

Thanks for the heads-up.

Thanks.

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

On 7/4/24 20:36, Robert Riches wrote:
> On 2024-07-04, Bobbie Sellers <blissInSanFrancisco@mouse-potato.com> wrote:
>> On 7/3/24 20:29, Robert Riches wrote:
>>> On 2024-07-03, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> On 03/07/2024 04:42, Robert Riches wrote:
>>>>> On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:
>>>>>> On 2024-07-02 06:19, Robert Riches wrote:
>>>>>>> Is there any practical way to completely disable Emacs' eln-cache
>>>>>>> while using Devuan Daedalus binary packages, versions in the
>>>>>>> 1.28.2 neighborhood? Even better would be to entirely disable
>>>>>>> native compilation.
>>>>>>>
>>>>>>> The cached files cause noise in Tripwire output and make messes
>>>>>>> in directories Emacs should not be leaving messes in. Recently,
>>>>>>> I saw .el files being left in /tmp.
>>>>>>
>>>>>> emacs has all the right to leave any file it wishes in /tmp.
>>>>>
>>>>> Not on _MY_ machine, it doesn't. Long-standing tradition says it
>>>>> is a bug for a program to fail to clean up after itself in /tmp.
>>>>>
>>>> Tell that to systemd...:-)
>>>
>>> systemd? Not on this machine!!!!!
>>>
>>> A test VM installation of the first Mageia release with systemd
>>> appeared to install okay. However, on first boot, the boot
>>> process got hung up, waited several minutes, reported some
>>> timeouts, and came up with a severely crippled system. IIRC,
>>> not all of the RAIDs were composed, and not all of the
>>> filesystems were mounted. The tools to analyze the binary
>>> registry^H^H^H^H^H^H^H^Hjournal weren't installed.
>>>
>>> Determined to be one of the last people on the planet to use an
>>> init system other than systemd, I switched to Slackware, then to
>>> Debian, and now to Devuan (Beowulf, Chimaera, and now Daedalus).
>>> If it becomes impractical to use Linux without systemd, one of
>>> the BSDs will have to do.
>>>
>>
>> Have you ever considered PCLinuxOS 64 bit only X86 as
>> here V and a friendly Forum that helps resolve issues.
>> <https://www.pclinuxos.com/forum/index.php>
>> A Rolling Release...
>> bliss- Dell Precision 7730-PCLOS 2024.07-Linux 6.6.36-Plasma 5.27.11
>
> Thank you for the suggestion. PCLinuxOS was on my list of
> options in May of 2016. At the time, it did not appear to have
> csh.
>
> Thanks.
>

How about tcsh?

> An enhanced version of csh, the C shell
> Tcsh is an enhanced but completely compatible version of csh, the C
> shell. Tcsh is a command language interpreter which can be used both
> as an interactive login shell and as a shell script command processor.
> Tcsh includes a command line editor, programmable word completion,
> spelling correction, a history mechanism, job control and a C language
> like syntax.

If that variation is not too far out then you have
no excuse to not experiment with PCLinuxOS 64.
<http://www.pclinuxos.com>

bliss the satisfied user.
bliss- Dell Precision 7730- PCLOS 2024.07- Linux 6.6.36- 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

On Thu, 04 Jul 2024 02:46:14 +0200, Carlos E. R. wrote:

> On 2024-07-03 16:30, candycanearter07 wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote at 13:33 this Wednesday (GMT):
>>> On Wed, 03 Jul 2024 03:42:52 +0000, Robert Riches wrote:
>>>
>>>> On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:
>>>>> On 2024-07-02 06:19, Robert Riches wrote:
>>>>>> Is there any practical way to completely disable Emacs' eln-cache
>>>>>> while using Devuan Daedalus binary packages, versions in the
>>>>>> 1.28.2 neighborhood? Even better would be to entirely disable
>>>>>> native compilation.
>>>>>>
>>>>>> The cached files cause noise in Tripwire output and make messes
>>>>>> in directories Emacs should not be leaving messes in. Recently,
>>>>>> I saw .el files being left in /tmp.
>>>>>
>>>>> emacs has all the right to leave any file it wishes in /tmp.
>>>>
>>>> Not on _MY_ machine, it doesn't. Long-standing tradition says it
>>>> is a bug for a program to fail to clean up after itself in /tmp.
>>>
>>> Longer standing Unix tradition has a periodically-scheduled job
>>> (often known as "skulker" or "tmpwatch") that cleans out the various
>>> tmp directories (/tmp, /var/tmp, etc) of old, discarded temporary
>>> files.
>>
>>
>> Wait, really? I've been storing random files in /var/tmp..
>
> Distributions have various policies and implementations of that.

True dat. The requirements of the Linux Filesystem Hierarchy Standard
(https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html) seem to
have been sidelined by many distros and developers. But, AFAICT, they
still are the recommended standards.

For /var/tmp, the FHS says:
5.15. /var/tmp : Temporary files preserved between system reboots
5.15.1. Purpose

The /var/tmp directory is made available for programs that require
temporary files or directories that are preserved between system
reboots. Therefore, data stored in /var/tmp is more persistent than
data in /tmp.

Files and directories located in /var/tmp must not be deleted when
the system is booted. Although data stored in /var/tmp is typically
deleted in a site-specific manner, it is recommended that deletions
occur at a less frequent interval than /tmp

As for /tmp, the FHS says:
3.18. /tmp : Temporary files
3.18.1. Purpose

The /tmp directory must be made available for programs that require
temporary files.

Programs must not assume that any files or directories in /tmp are
preserved between invocations of the program.

Rationale
IEEE standard POSIX.1-2008 lists requirements similar to the above
section.

Although data stored in /tmp may be deleted in a site-specific
manner, it is recommended that files and directories located in
/tmp be deleted whenever the system is booted.

FHS added this recommendation on the basis of historical precedent
and common practice, but did not make it a requirement because system
administration is not within the scope of this standard.

--
Lew Pitcher
"In Skills We Trust"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>
> The /tmp directory must be made available for programs that require
> temporary files.
>
> Programs must not assume that any files or directories in /tmp are
> preserved between invocations of the program.

Exactly. **temporary** files are just that: temporary.

You don't expect them to be there after a reboot, or the next time your
program runs, or whatever.

If you want files to remain somewhere, you put them somewhere specific that is
**not** one of the tmp directories. And you name it such that there can be
multiple instances of it, such as
'/some-permanent-directory/my_program_errors-[PID-NUMBER]'

Any well-behaved program should destroy all of its temporary files after it
has finished with them.

That doesn't always happen. I'm looking at you GTK with your /tmp/gtk_errs
that might end up being owned by root, unable to be removed by non-root
users, and which causes GTK programs not owned by root to crash:

m70t [jvs] /home/jvs > gparted
bash: /tmp/gtk_errs: Permission denied
m70t [jvs] /home/jvs >

Regards.

Jack

--
She came late to bed at 3AM. "You're drunk" I said.
She asked "How do you know?"
"You live next door." I replied.

On Fri, 5 Jul 2024 19:52:28 -0000 (UTC), Lew Pitcher wrote:

> The /var/tmp directory is made available for programs that require
> temporary files or directories that are preserved between system
> reboots. Therefore, data stored in /var/tmp is more persistent than
> data in /tmp.

What about /var/cache?

On Sat, 6 Jul 2024 05:22:33 -0000 (UTC), Jack Strangio wrote:

> I'm looking at you GTK with your /tmp/gtk_errs that might end up being
> owned by root ...

How can that happen, unless you’ve been running GUI programs as root?

On 2024-07-06 07:22, Jack Strangio wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>
>> The /tmp directory must be made available for programs that require
>> temporary files.
>>
>> Programs must not assume that any files or directories in /tmp are
>> preserved between invocations of the program.
>
> Exactly. **temporary** files are just that: temporary.
>
> You don't expect them to be there after a reboot, or the next time your
> program runs, or whatever.

Not fully correct :-)

The interpretation of the "rules" is that the files can be deleted, or
maybe not. You can not expect assurance that they will be there, but
neither there is assurance that they will be deleted.

The application can not be sure that the file will be there on next
boot. But it may be.

--
Cheers,
Carlos E.R.

In article <sG6s8v.B6nB@yahoo.com>, jackstrangio@yahoo.com (Jack Strangio)
wrote:

> Exactly. **temporary** files are just that: temporary.

A record for Unix ignorance I encountered, 20-odd years ago. A chap at
work turned in his Solaris workstation to be sorted out after it began
misbehaving. When he got it back, he complained that important files he'd
been keeping in /tmp were gone. The sysadmins were sarcastic, as was his
boss, and everyone else.

John

On 2024-07-06 15:10, John Dallman wrote:
> In article <sG6s8v.B6nB@yahoo.com>, jackstrangio@yahoo.com (Jack Strangio)
> wrote:
>
>> Exactly. **temporary** files are just that: temporary.
>
> A record for Unix ignorance I encountered, 20-odd years ago. A chap at
> work turned in his Solaris workstation to be sorted out after it began
> misbehaving. When he got it back, he complained that important files he'd
> been keeping in /tmp were gone. The sysadmins were sarcastic, as was his
> boss, and everyone else.

Well, it was his boss fault, for not making sure he was properly
trained. I don¡t understand why he laughed.

--
Cheers,
Carlos E.R.

In article <let304FasraU1@mid.individual.net>, robin_listas@es.invalid
(Carlos E. R.) wrote:

> > When he got it back, he complained that important files he'd
> > been keeping in /tmp were gone.
> Well, it was his boss fault, for not making sure he was properly
> trained. I don't understand why he laughed.

The chap had been told. He didn't think it applied to him.

John