[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): F
From: |
Stefan Monnier |
Subject: |
bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully |
Date: |
Sat, 03 Sep 2022 22:02:07 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Eli Zaretskii [2022-09-03 22:28:20] wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: 57562@debbugs.gnu.org
>> Date: Sat, 03 Sep 2022 15:16:23 -0400
>>
>> > I guess that's enough for Emacs 28. (And I do wonder how come people
>> > come up with unwritable home directories.)
>>
>> In the discussion of that Debian bug#1017739, Russ Allbery mentions
>> a(n unrelated) problem which can lead to this:
>>
>> % su
>> # emacs
>>
>> If the user hasn't yet used Emacs (and depending on the details of which
>> version of `su` you use) this can create
>> a /home/<user>/.emacs.d/eln-cache that's owned by root because we create
>> that dir according to `~$USER` rather than according to `$HOME`.
>
> I didn't mean to say that I didn't understand how this could happen
> _technically_. What I don't get is how come people let this happen,
> and don't pay attention until Emacs complains? Isn't it crazy to have
> your home directory unwritable by your user??
I think in the above scenario, if you just upgraded to Emacs-28 and it's
hence the first time you run an Emacs with native compilation, you get
a home directory that's still perfectly writable, including `~/.emacs.d`
and it's only `~/.emacs.d/eln-cache` that's owned by root.
And since Emacs error(s|ed) out right away, the error message didn't let
you find the name of the directories that were searched to figure out
the origin of the problem.
Stefan
- bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully, Stefan Monnier, 2022/09/03
- bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully, Eli Zaretskii, 2022/09/03
- bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully, Stefan Monnier, 2022/09/03
- bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully, Eli Zaretskii, 2022/09/03
- bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully, Stefan Monnier, 2022/09/03
- bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully, Eli Zaretskii, 2022/09/03
- bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully, Stefan Monnier, 2022/09/03
- bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully, Eli Zaretskii, 2022/09/03
- bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully,
Stefan Monnier <=
- bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully, Eli Zaretskii, 2022/09/04
- bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully, Stefan Monnier, 2022/09/04
- bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully, Stefan Monnier, 2022/09/03
bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully, Stefan Monnier, 2022/09/03