[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6401:
From: |
Glenn Morris |
Subject: |
bug#6401: |
Date: |
Tue, 22 Nov 2011 02:49:30 -0500 |
User-agent: |
Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) |
Eli Zaretskii wrote:
>> http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00432.html
>>
>> I don't know if a solution was ever found for that.
>
> No solution was found, because I, like you, don't know what to do
> about it. Emacs has no way of knowing whether EMACSDATA etc. is set
> for it or for some other Emacs. So it cannot remove it from the
> environment when running subprocesses. Maybe someone could come up
> with some clever idea.
If all else fails, we can at least write a PROBLEMS entry.
Why does a --with-ns build actually need to set these env-vars for child
processes?
Could they specifically be unset in spawned M-x shells?
Similar to the suggestion in emacs-devel, could configure unset
$EMACSDATA if $EMACS is set (which indicates it is running from an Emacs
shell)? Under what circusmtances would one want to set EMACSDATA when
building Emacs? Or could we replace the env-var with a --with-emacsdata
argument to configure instead? Then people who need the functionality
can still access it, and people who don't won't inadvertently get
affected by it.
- bug#6401:, Tim Daly Jr., 2011/11/21
- bug#6401:, Glenn Morris, 2011/11/21
- bug#6401:, Eli Zaretskii, 2011/11/22
- bug#6401:,
Glenn Morris <=
- bug#6401:, Eli Zaretskii, 2011/11/22
- bug#6401:, Glenn Morris, 2011/11/22
- bug#6401:, Tim Daly Jr., 2011/11/22
- bug#6401:, Glenn Morris, 2011/11/22
- bug#6401:, Glenn Morris, 2011/11/22
- bug#6401:, Eli Zaretskii, 2011/11/22
- bug#6401:, Glenn Morris, 2011/11/22
- bug#6401:, Eli Zaretskii, 2011/11/22