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.
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.
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.
On 03/07/2024 04:42, Robert Riches wrote:
On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:Tell that to systemd...:-)
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.
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.
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.
On 03/07/2024 04:42, Robert Riches wrote:
Not on _MY_ machine, it doesn't. Long-standing tradition says it is aTell that to systemd...:-)
bug for a program to fail to clean up after itself in /tmp.
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..
On 03/07/2024 04:42, Robert Riches wrote:
On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:Tell that to systemd...:-)
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.
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:Tell that to systemd...:-)
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.
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.
If it becomes impractical to use Linux without systemd, one of the BSDs
will have to do.
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.
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 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:Tell that to systemd...:-)
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.
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
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:Tell that to systemd...:-)
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.
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.
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.
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.
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.
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.
I'm looking at you GTK with your /tmp/gtk_errs that might end up being
owned by root ...
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.
Exactly. **temporary** files are just that: temporary.
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.
When he got it back, he complained that important files he'dWell, it was his boss fault, for not making sure he was properly
been keeping in /tmp were gone.
trained. I don't understand why he laughed.
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?
How would you _not_ run gparted as root, Perfessor?
The interpretation of the "rules" is that the files can be deleted, or
maybe not.
On Sat, 6 Jul 2024 12:56:11 +0200, Carlos E. R. wrote:
The interpretation of the "rules" is that the files can be deleted, or
maybe not.
Given that many Linux systems are using tmpfs, which is entirely RAM-
based, for /tmp and other similar filesystems, that’s a guarantee that the files in there will *not* survive a reboot.
On 2024-07-07 03:33, Lawrence D'Oliveiro wrote:
On Sat, 6 Jul 2024 12:56:11 +0200, Carlos E. R. wrote:
The interpretation of the "rules" is that the files can be deleted, or
maybe not.
Given that many Linux systems are using tmpfs, which is entirely RAM-
based, for /tmp and other similar filesystems, that’s a guarantee that the >> files in there will *not* survive a reboot.
openSUSE is using hard disk for /tmp, and has currently no working
periodical job to clean it.
On Sat, 6 Jul 2024 22:58:05 -0000 (UTC), vallor wrote:
How would you _not_ run gparted as root, Perfessor?
From the OP:
m70t [jvs] /home/jvs > gparted
bash: /tmp/gtk_errs: Permission denied
That’s not running as root now, is it?
If you maintain a large uptime (say, even more than a few
hours), you really should, periodically, clean up the contents of /tmp
On 7 Jul 2024 03:25:47 GMT, vallor wrote:
On Sun, 7 Jul 2024 01:31:41 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <v6cr5s$1kfb$1@dont-email.me>:
That’s not running as root now, is it?
Yes, and that's the problem.
Maybe think of GParted as Nature’s way of telling you not to run GUI tools as root.
On Sun, 7 Jul 2024 01:31:41 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <v6cr5s$1kfb$1@dont-email.me>:
That’s not running as root now, is it?
Yes, and that's the problem.
openSUSE is using hard disk for /tmp, and has currently no working
periodical job to clean it.
On Sun, 7 Jul 2024 03:59:21 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <v6d3qp$6ida$1@dont-email.me>:
On 7 Jul 2024 03:25:47 GMT, vallor wrote:
On Sun, 7 Jul 2024 01:31:41 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <v6cr5s$1kfb$1@dont-email.me>:
That’s not running as root now, is it?
Yes, and that's the problem.
Maybe think of GParted as Nature’s way of telling you not to run GUI tools >> as root.
Okay, I'll bite -- how do you modify partition tables without running
as root?
# systemctl list-timers | grep tmp
# systemctl list-timers | grep tmp
I wonder if there is a “UUOG” to go with “UUOC”:
systemctl list-timers '*tmp*'
On 2024-07-07 at 04:10 Carlos E. R. wrote:
openSUSE is using hard disk for /tmp, and has currently no working
periodical job to clean it.
Yes it does, and it's even enabled by default, it just has to be tuned up
to your/sysadmin's liking. On my system (v15.4):
# systemctl list-timers | grep tmp
Mon 2024-07-08 05:38:18 CEST 17h left Fri 2024-07-05 12:10:56 CEST 1
day 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
see man systemd-tmpfiles, tmpfiles.d for details.
On 2024-07-07 12:17, marrgol wrote:
On 2024-07-07 at 04:10 Carlos E. R. wrote:
openSUSE is using hard disk for /tmp, and has currently no working
periodical job to clean it.
Yes it does, and it's even enabled by default, it just has to be tuned up
to your/sysadmin's liking. On my system (v15.4):
# systemctl list-timers | grep tmp
Mon 2024-07-08 05:38:18 CEST 17h left Fri 2024-07-05 12:10:56 CEST 1
day 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
see man systemd-tmpfiles, tmpfiles.d for details.
Doesn't work.
On Fri, 12 Jul 2024 21:12:05 +0200, Carlos E.R. wrote:
On 2024-07-07 12:17, marrgol wrote:
On 2024-07-07 at 04:10 Carlos E. R. wrote:
openSUSE is using hard disk for /tmp, and has currently no working
periodical job to clean it.
Yes it does, and it's even enabled by default, it just has to be tuned up >>> to your/sysadmin's liking. On my system (v15.4):
# systemctl list-timers | grep tmp
Mon 2024-07-08 05:38:18 CEST 17h left Fri 2024-07-05 12:10:56 CEST 1 >>> day 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
see man systemd-tmpfiles, tmpfiles.d for details.
Doesn't work.
Be careful; systemd-tmpfiles has been in the news recently,
(see https://www.theregister.com/2024/06/20/systemd_2561_data_wipe_fix/ ) because it can delete your home directory.
Specifically, with respect to systemd v256, The Register warns:
"If you invoke the systemd-tmpfiles --purge command without specifying
that very important config file which tells it which files to handle,
version 256 will merrily purge your entire home directory."
Apparently, systemd v256.1 makes some acknowledgement of this behaviour by documenting it in the systemd help files.
Stay safe out there.
Be careful; systemd-tmpfiles has been in the news recently,
(see https://www.theregister.com/2024/06/20/systemd_2561_data_wipe_fix/ ) because it can delete your home directory.
Be careful; systemd-tmpfiles has been in the news recently,
(see https://www.theregister.com/2024/06/20/systemd_2561_data_wipe_fix/
) because it can delete your home directory.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 497 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 11:17:07 |
| Calls: | 9,782 |
| Calls today: | 1 |
| Files: | 13,748 |
| Messages: | 6,187,342 |