unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Albinus <michael.albinus@gmx.de>
To: Augusto Stoffel <arstoffel@gmail.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Buffer-local process environments
Date: Sat, 08 May 2021 19:51:18 +0200	[thread overview]
Message-ID: <87wns9glm1.fsf@gmx.de> (raw)
In-Reply-To: <874kflmzn3.fsf@gmail.com> (Augusto Stoffel's message of "Sun, 02 May 2021 08:13:36 +0200")

Augusto Stoffel <arstoffel@gmail.com> writes:

> Hi Michael,

Hi Augusto,

> I can only think of two alternatives:
>
> 1. Introduce a whitelist of variables that can be exported to a remote.
>    Then drop entirely the current hack and just check whether
>    `process-environment' contains any exportable variables.  For
>    flexibility, you can allow whitelisting a variable name (any value),
>    or a specific VAR=VALUE pair.
>
>    The whitelist can be set globally or dynamically.  So, for instance,
>    the vc files could just append "BZR_LOG", "HGPLAIN" and whatnot
>    globally to this list and never worry again.
>
>    Obviously, this will break third-party code, but the fix is quite
>    easy.  Nobody could bash you for that.

We have already a white list, which is tramp-remote-process-environment.
I'm reluctant to add package specific entries there by default, it would
be an endless story. PAGER is included as being a general purpose
environment variable, BZR_LOG and HGPLAIN are not. If packages believe
they shall be added, this could be done in vc-bzr.el or vc-hg.el. Tramp
is a stupid library, it shouldn't try to be clever.

> 2. Introduce a blacklist of variables that are never exported to a
>    remote.  This can be done by extending
>    `tramp-remote-process-environment' to follow the same convention of
>    `process-environment' that an entry of the form VAR, without the
>    =VALUE, means removing the variable.

There are already such variables to be unset. These are the variables
without any value, like "HISTORY="

>    So, for instance, entries "PATH" and "TERM" should be added to the
>    default value of `tramp-remote-process-environment'.  This would
>    solve the unintuitive (if not buggy) behavior I pointed out a few
>    messages back in this thread.

TERM is handled special. All Tramp connections add "TERM=dumb",
hard-coded. Since this shall not be changed by a user, it isn't
configurable here.

PATH is handled by tramp-remote-path. This is a variable on its own,
because just setting a simple string "PATH=/abc:/def" isn't sufficient,
often.

>    As another example, python.el would append "PYTHONPATH" and
>    "PYTHONHOME" globally to `tramp-remote-process-environment', since
>    these variables hold directory names.

Yes, if python.el developers prefer that. However, I doubt, that this
value is always the same for all different remote hosts, the value might
differ depending on the OS the remote host is running.

>    This option is fully backwards compatible, but keeps the hack you
>    said you don't like anyway.

So in fact, this solution is almost the current implementation.

> It's also conceivable do to both things, but instead of enforcing 1.,
> just give a warning.  Then eventually you could get rid of the hack
> without breaking other packages.

As said, variant 1. isn't applicable in my eyes.

Best regards, Michael.



  reply	other threads:[~2021-05-08 17:51 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-29 10:56 Buffer-local process environments Augusto Stoffel
2021-04-29 12:30 ` Eli Zaretskii
2021-04-29 12:40   ` Augusto Stoffel
2021-04-29 12:52     ` Eli Zaretskii
2021-04-29 13:06       ` Augusto Stoffel
2021-04-29 14:02 ` Stefan Monnier
2021-04-29 17:26   ` Augusto Stoffel
2021-04-29 17:34     ` Michael Albinus
2021-04-30  7:29       ` Augusto Stoffel
2021-04-30  7:48         ` Michael Albinus
2021-04-30 15:19           ` Augusto Stoffel
2021-04-30 15:51             ` Michael Albinus
2021-05-02  6:13               ` Augusto Stoffel
2021-05-08 17:51                 ` Michael Albinus [this message]
2021-05-09  5:06                   ` Augusto Stoffel
2021-05-09 16:38                     ` Michael Albinus
2021-08-28 12:28                       ` [PATCH] " Augusto Stoffel
2021-08-28 12:37                         ` Eli Zaretskii
2021-08-28 12:55                           ` Augusto Stoffel
2021-09-01 10:42                             ` Stephen Leake
2021-09-01 10:56                               ` Augusto Stoffel
2021-09-01 22:38                                 ` Stephen Leake
2021-09-02  7:14                                   ` Augusto Stoffel
2021-09-06 15:17                                     ` Stephen Leake
2021-08-28 14:06                           ` Arthur Miller
2021-08-28 14:33                             ` Eli Zaretskii
2021-08-28 15:27                               ` Arthur Miller
2021-08-28 15:38                                 ` Eli Zaretskii
2021-08-28 16:48                                   ` Arthur Miller
2021-08-28 15:39                                 ` Augusto Stoffel
2021-08-28 16:43                                   ` Arthur Miller
2021-08-28 12:47                         ` Michael Albinus
2021-08-28 12:59                           ` Augusto Stoffel
2021-08-28 13:18                             ` Michael Albinus
2021-08-28 13:54                               ` Augusto Stoffel
2021-08-28 14:05                               ` Stefan Monnier
2021-08-28 15:19                                 ` Augusto Stoffel
2021-04-30 15:32           ` Augusto Stoffel
2021-04-30 15:55             ` Michael Albinus
2021-04-29 15:37 ` Michael Albinus
2021-04-29 17:31   ` Augusto Stoffel
2021-04-29 17:44     ` Michael Albinus
2021-04-30  7:00       ` Augusto Stoffel
2021-04-30  7:25         ` Michael Albinus
2021-05-02 13:45 ` Stephen Leake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wns9glm1.fsf@gmx.de \
    --to=michael.albinus@gmx.de \
    --cc=arstoffel@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).