* Re: EMACS=t Joy and Happiness
2018-05-24 20:46 EMACS=t Joy and Happiness Phillip Lord
@ 2018-05-24 20:52 ` Stefan Monnier
2018-05-24 20:52 ` bug#20202: " Stefan Monnier
` (6 subsequent siblings)
7 siblings, 0 replies; 56+ messages in thread
From: Stefan Monnier @ 2018-05-24 20:52 UTC (permalink / raw
To: Phillip Lord; +Cc: 20202, Paul Eggert, 20484, Emacs-Devel devel
> I worry that "Bash 4.4 or later is common" is rather indeterminate; my
At least Debian's stable (stretch) is on bash-4.4 (but still at 4.3 in
oldstable (jessie)).
> desktop is now 4.4.19. but another machine I am using has bash
> 4.2.46. Given that Emacs-26 is now destined to come out with
> EMACS=26.1.0, I would like to propose that we now remove this on master,
> i.e. make it happen for Emacs-27 which should be in about 2020.
Sounds good to me: by the time Emacs-27 comes out, Debian's oldstable
will be stretch (hence at 4.4).
Stefan
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-24 20:46 EMACS=t Joy and Happiness Phillip Lord
2018-05-24 20:52 ` Stefan Monnier
@ 2018-05-24 20:52 ` Stefan Monnier
2018-05-24 22:03 ` Paul Eggert
` (5 subsequent siblings)
7 siblings, 0 replies; 56+ messages in thread
From: Stefan Monnier @ 2018-05-24 20:52 UTC (permalink / raw
To: Phillip Lord; +Cc: Paul Eggert, Emacs-Devel devel, 20202, 20484
> I worry that "Bash 4.4 or later is common" is rather indeterminate; my
At least Debian's stable (stretch) is on bash-4.4 (but still at 4.3 in
oldstable (jessie)).
> desktop is now 4.4.19. but another machine I am using has bash
> 4.2.46. Given that Emacs-26 is now destined to come out with
> EMACS=26.1.0, I would like to propose that we now remove this on master,
> i.e. make it happen for Emacs-27 which should be in about 2020.
Sounds good to me: by the time Emacs-27 comes out, Debian's oldstable
will be stretch (hence at 4.4).
Stefan
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-24 20:46 EMACS=t Joy and Happiness Phillip Lord
2018-05-24 20:52 ` Stefan Monnier
2018-05-24 20:52 ` bug#20202: " Stefan Monnier
@ 2018-05-24 22:03 ` Paul Eggert
2018-05-25 2:25 ` bug#20202: " Van L
` (4 more replies)
2018-05-24 22:03 ` Paul Eggert
` (4 subsequent siblings)
7 siblings, 5 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-24 22:03 UTC (permalink / raw
To: Phillip Lord, Emacs-Devel devel; +Cc: 20202, Stefan Monnier, 20484
Bash 4.4 came out only in September 2016, and it's too soon to assume
it. For example, my students regularly use Emacs on a server running
RHEL 7, which ships Bash 4.2.46, and as I understand it, this is the
most recent RHEL available.
How about this idea: At Emacs build time, we check whether Bash is 4.4
or later, and if so we use a term.el that assumes bash 4.4 or later.
Otherwise, we use a term.el that interrogates the shell dynamically for
whether it is shell and if so what its version number is, the first time
that Emacs runs a process under a shell.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-24 22:03 ` Paul Eggert
@ 2018-05-25 2:25 ` Van L
2018-05-25 6:11 ` bug#20484: " Ricardo Wurmus
` (5 more replies)
2018-05-25 6:16 ` Eli Zaretskii
` (3 subsequent siblings)
4 siblings, 6 replies; 56+ messages in thread
From: Van L @ 2018-05-25 2:25 UTC (permalink / raw
To: Paul Eggert; +Cc: 20202, Phillip Lord, 20484, Stefan Monnier, Emacs-Devel devel
> Paul Eggert writes:
>
> this is the most recent RHEL available
You could have your sclerotic institution’s IT manager provide Enterprise RHEL for students studying topics as old as the hills and mountains (and they won’t change) and request them to “think" about the latest unstable Fedora or Debian or Ubuntu releases for research oriented experimental AI & CS “work” which are hot career topics and ought not to be held back by bureaucratically convenient RHEL IT hell. Ask them for what Tesla or Uber or Facebook or Google use to keep up with “innovation” before it is "too late" on RHEL.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-25 2:25 ` bug#20202: " Van L
@ 2018-05-25 6:11 ` Ricardo Wurmus
2018-05-25 6:11 ` bug#20202: " Ricardo Wurmus
` (4 subsequent siblings)
5 siblings, 0 replies; 56+ messages in thread
From: Ricardo Wurmus @ 2018-05-25 6:11 UTC (permalink / raw
To: Van L
Cc: Paul Eggert, Emacs-Devel devel, 20202, 20484, Stefan Monnier,
Phillip Lord
Van L <van@scratch.space> writes:
>> Paul Eggert writes:
>>
>> this is the most recent RHEL available
>
> You could have your sclerotic institution’s IT manager provide
> Enterprise RHEL for students studying topics as old as the hills and
> mountains (and they won’t change) and request them to “think" about
> the latest unstable Fedora or Debian or Ubuntu releases for research
> oriented experimental AI & CS “work” which are hot career topics and
> ought not to be held back by bureaucratically convenient RHEL IT
> hell. Ask them for what Tesla or Uber or Facebook or Google use to
> keep up with “innovation” before it is "too late" on RHEL.
This is not constructive.
There are even RHEL 6 deployments out there, because it’s still
supported until 2020. There are people who pay for the privilege of not
having to upgrade.
--
Ricardo
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-25 2:25 ` bug#20202: " Van L
2018-05-25 6:11 ` bug#20484: " Ricardo Wurmus
@ 2018-05-25 6:11 ` Ricardo Wurmus
2018-05-25 6:11 ` Ricardo Wurmus
` (3 subsequent siblings)
5 siblings, 0 replies; 56+ messages in thread
From: Ricardo Wurmus @ 2018-05-25 6:11 UTC (permalink / raw
To: Van L
Cc: Paul Eggert, Emacs-Devel devel, 20202, 20484, Stefan Monnier,
Phillip Lord
Van L <van@scratch.space> writes:
>> Paul Eggert writes:
>>
>> this is the most recent RHEL available
>
> You could have your sclerotic institution’s IT manager provide
> Enterprise RHEL for students studying topics as old as the hills and
> mountains (and they won’t change) and request them to “think" about
> the latest unstable Fedora or Debian or Ubuntu releases for research
> oriented experimental AI & CS “work” which are hot career topics and
> ought not to be held back by bureaucratically convenient RHEL IT
> hell. Ask them for what Tesla or Uber or Facebook or Google use to
> keep up with “innovation” before it is "too late" on RHEL.
This is not constructive.
There are even RHEL 6 deployments out there, because it’s still
supported until 2020. There are people who pay for the privilege of not
having to upgrade.
--
Ricardo
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-25 2:25 ` bug#20202: " Van L
2018-05-25 6:11 ` bug#20484: " Ricardo Wurmus
2018-05-25 6:11 ` bug#20202: " Ricardo Wurmus
@ 2018-05-25 6:11 ` Ricardo Wurmus
2018-05-25 7:12 ` Van L
2018-05-25 17:59 ` Paul Eggert
` (2 subsequent siblings)
5 siblings, 1 reply; 56+ messages in thread
From: Ricardo Wurmus @ 2018-05-25 6:11 UTC (permalink / raw
To: Van L
Cc: Paul Eggert, Emacs-Devel devel, 20202, 20484, Stefan Monnier,
Phillip Lord
Van L <van@scratch.space> writes:
>> Paul Eggert writes:
>>
>> this is the most recent RHEL available
>
> You could have your sclerotic institution’s IT manager provide
> Enterprise RHEL for students studying topics as old as the hills and
> mountains (and they won’t change) and request them to “think" about
> the latest unstable Fedora or Debian or Ubuntu releases for research
> oriented experimental AI & CS “work” which are hot career topics and
> ought not to be held back by bureaucratically convenient RHEL IT
> hell. Ask them for what Tesla or Uber or Facebook or Google use to
> keep up with “innovation” before it is "too late" on RHEL.
This is not constructive.
There are even RHEL 6 deployments out there, because it’s still
supported until 2020. There are people who pay for the privilege of not
having to upgrade.
--
Ricardo
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-25 2:25 ` bug#20202: " Van L
` (2 preceding siblings ...)
2018-05-25 6:11 ` Ricardo Wurmus
@ 2018-05-25 17:59 ` Paul Eggert
2018-05-26 0:17 ` Van L
2018-05-26 0:43 ` Van L
2018-05-25 17:59 ` bug#20484: " Paul Eggert
2018-05-25 17:59 ` bug#20202: " Paul Eggert
5 siblings, 2 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-25 17:59 UTC (permalink / raw
To: Van L; +Cc: 20484, Emacs-Devel devel, 20202, Stefan Monnier, Phillip Lord
On 05/24/2018 07:25 PM, Van L wrote:
> Ask them for what Tesla or Uber or Facebook or Google use
I just checked the first company mentioned on your list (Tesla) and it
is posting want-ads that ask for Red Hat expertise. Unfortunately I
can't disclose what I privately know about Tesla, but suffice it to say
that like most other successful companies they use a wide variety of
systems in their work, and not all of these systems are the very latest
version of everything.
> I can understand the excuse for long-term-support system contracts but not for the poster’s student environment.
>
> You refer to lazy privileged people
I'm afraid there's a misunderstanding here. At UCLA we have a wide
variety of systems running many different OSes. Servers at UCLA run many
operating systems; it's quite a gamut, as we have a lot of departments
and research groups, most of which focus on areas other than computer
science and who have a lot of software of varying quality that they
don't necessarily have time or budget to upgrade or maintain
extensively. The courses I teach are assigned to a batch of RHEL 7
servers that support many different courses, not just mine. I do not
specify or maintain the server OSes; that's a responsibility of the
operations staff of the School of Engineering, and they're busy people
who do not report to me.
To help keep my course material up-to-date I install copies of the
latest released versions of Emacs (currently 25.3), Bash (currently
4.4.19), and many other free software programs. (I don't overwrite
/usr/bin of course; I install into a separate directory that students
put into their PATH settings.) So it'll be little trouble to me or my
students if Emacs requires Bash 4.4 or later. When I mentioned RHEL 7, I
wasn't simply talking about my personal situation; I was observing that
requiring Bash 4.4 would be a hassle for people installing newer Emacs
versions onto Red Hat servers, as it would require these people to also
install newer Bash versions. If it's important for Emacs to require Bash
4.4 of course Emacs can do so; still, I expect that the overall hassle
to Emacs users of requiring Bash 4.4 still outweighs the relatively
minor technical benefit in question. Sorry, but that's how things often
work in production software.
With all this in mind you might want to rethink your comments that among
other things seem to imply that the staff at UCLA consists of "lazy
privileged people".
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-25 17:59 ` Paul Eggert
@ 2018-05-26 0:17 ` Van L
2018-05-26 7:41 ` Eli Zaretskii
2018-05-26 0:43 ` Van L
1 sibling, 1 reply; 56+ messages in thread
From: Van L @ 2018-05-26 0:17 UTC (permalink / raw
To: Paul Eggert; +Cc: Emacs-Devel devel
> the operations staff of the School of Engineering, and they're busy people who do not report to me.
There are new tricks at Digital Ocean, Google and what RHEL learns from their CoreOS catch.
My point is Enterprise RHEL will have to upgrade constantly, report a breach within 72-hours or pay 4% of revenue.
> With all this in mind you might want to rethink your comments that among other things seem to imply that the staff at UCLA consists of "lazy privileged people”.
You misunderstand.
I was upset by the idea of paying more to not upgrade.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-26 0:17 ` Van L
@ 2018-05-26 7:41 ` Eli Zaretskii
2018-05-26 10:07 ` Van L
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2018-05-26 7:41 UTC (permalink / raw
To: Van L; +Cc: eggert, emacs-devel
> From: Van L <van@scratch.space>
> Date: Sat, 26 May 2018 10:17:02 +1000
> Cc: Emacs-Devel devel <emacs-devel@gnu.org>
>
> I was upset by the idea of paying more to not upgrade.
I guess you never had the experience of upgrading a system in a
production-type environments, with a large number of users, each of
whom has their specific requirements and packages that need to
continue running smoothly.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-26 7:41 ` Eli Zaretskii
@ 2018-05-26 10:07 ` Van L
2018-05-26 10:57 ` Eli Zaretskii
0 siblings, 1 reply; 56+ messages in thread
From: Van L @ 2018-05-26 10:07 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Emacs-Devel devel
> On 26 May 2018, at 17:41, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> From: Van L <van@scratch.space>
>> Date: Sat, 26 May 2018 10:17:02 +1000
>> Cc: Emacs-Devel devel <emacs-devel@gnu.org>
>>
>> I was upset by the idea of paying more to not upgrade.
>
> I guess you never had the experience of upgrading a system in a
> production-type environments, with a large number of users, each of
> whom has their specific requirements and packages that need to
> continue running smoothly.
Let’s not get personal.
This is about the system and upgrades.
Anyway, it is now the law to report a breach within 72-hours or pay 4% of revenue.
Your are skating over a concept large installations use orchestration toolchains for devopsproding.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-26 10:07 ` Van L
@ 2018-05-26 10:57 ` Eli Zaretskii
0 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2018-05-26 10:57 UTC (permalink / raw
To: Van L; +Cc: emacs-devel
> From: Van L <van@scratch.space>
> Date: Sat, 26 May 2018 20:07:42 +1000
> Cc: Emacs-Devel devel <emacs-devel@gnu.org>
>
> > I guess you never had the experience of upgrading a system in a
> > production-type environments, with a large number of users, each of
> > whom has their specific requirements and packages that need to
> > continue running smoothly.
>
> Let’s not get personal.
I wasn't.
> This is about the system and upgrades.
Yes, it is. And the experience one has with systems and their
upgrades affects one's views on the existence and importance of
Enterprise distributions. Which is why I mentioned that experience.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-25 17:59 ` Paul Eggert
2018-05-26 0:17 ` Van L
@ 2018-05-26 0:43 ` Van L
1 sibling, 0 replies; 56+ messages in thread
From: Van L @ 2018-05-26 0:43 UTC (permalink / raw
To: Paul Eggert; +Cc: Emacs-Devel devel
> Paul Eggert writes:
>
> we have a lot of departments and research groups, most of which focus on areas other than computer science and who have a lot of software of varying quality that they don't necessarily have time or budget to upgrade or maintain extensively. The courses I teach are assigned to a batch of RHEL 7 servers that support many different courses, not just mine. I do not specify or maintain the server OSes; that's a responsibility of the operations staff
How can the industrial processes at Amazon, Digital Ocean, Google help them? unless deep in their own bowels they are no different.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-25 2:25 ` bug#20202: " Van L
` (3 preceding siblings ...)
2018-05-25 17:59 ` Paul Eggert
@ 2018-05-25 17:59 ` Paul Eggert
2018-05-25 17:59 ` bug#20202: " Paul Eggert
5 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-25 17:59 UTC (permalink / raw
To: Van L; +Cc: 20202, Phillip Lord, 20484, Stefan Monnier, Emacs-Devel devel
On 05/24/2018 07:25 PM, Van L wrote:
> Ask them for what Tesla or Uber or Facebook or Google use
I just checked the first company mentioned on your list (Tesla) and it
is posting want-ads that ask for Red Hat expertise. Unfortunately I
can't disclose what I privately know about Tesla, but suffice it to say
that like most other successful companies they use a wide variety of
systems in their work, and not all of these systems are the very latest
version of everything.
> I can understand the excuse for long-term-support system contracts but not for the poster’s student environment.
>
> You refer to lazy privileged people
I'm afraid there's a misunderstanding here. At UCLA we have a wide
variety of systems running many different OSes. Servers at UCLA run many
operating systems; it's quite a gamut, as we have a lot of departments
and research groups, most of which focus on areas other than computer
science and who have a lot of software of varying quality that they
don't necessarily have time or budget to upgrade or maintain
extensively. The courses I teach are assigned to a batch of RHEL 7
servers that support many different courses, not just mine. I do not
specify or maintain the server OSes; that's a responsibility of the
operations staff of the School of Engineering, and they're busy people
who do not report to me.
To help keep my course material up-to-date I install copies of the
latest released versions of Emacs (currently 25.3), Bash (currently
4.4.19), and many other free software programs. (I don't overwrite
/usr/bin of course; I install into a separate directory that students
put into their PATH settings.) So it'll be little trouble to me or my
students if Emacs requires Bash 4.4 or later. When I mentioned RHEL 7, I
wasn't simply talking about my personal situation; I was observing that
requiring Bash 4.4 would be a hassle for people installing newer Emacs
versions onto Red Hat servers, as it would require these people to also
install newer Bash versions. If it's important for Emacs to require Bash
4.4 of course Emacs can do so; still, I expect that the overall hassle
to Emacs users of requiring Bash 4.4 still outweighs the relatively
minor technical benefit in question. Sorry, but that's how things often
work in production software.
With all this in mind you might want to rethink your comments that among
other things seem to imply that the staff at UCLA consists of "lazy
privileged people".
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-25 2:25 ` bug#20202: " Van L
` (4 preceding siblings ...)
2018-05-25 17:59 ` bug#20484: " Paul Eggert
@ 2018-05-25 17:59 ` Paul Eggert
5 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-25 17:59 UTC (permalink / raw
To: Van L; +Cc: 20202, Phillip Lord, 20484, Stefan Monnier, Emacs-Devel devel
On 05/24/2018 07:25 PM, Van L wrote:
> Ask them for what Tesla or Uber or Facebook or Google use
I just checked the first company mentioned on your list (Tesla) and it
is posting want-ads that ask for Red Hat expertise. Unfortunately I
can't disclose what I privately know about Tesla, but suffice it to say
that like most other successful companies they use a wide variety of
systems in their work, and not all of these systems are the very latest
version of everything.
> I can understand the excuse for long-term-support system contracts but not for the poster’s student environment.
>
> You refer to lazy privileged people
I'm afraid there's a misunderstanding here. At UCLA we have a wide
variety of systems running many different OSes. Servers at UCLA run many
operating systems; it's quite a gamut, as we have a lot of departments
and research groups, most of which focus on areas other than computer
science and who have a lot of software of varying quality that they
don't necessarily have time or budget to upgrade or maintain
extensively. The courses I teach are assigned to a batch of RHEL 7
servers that support many different courses, not just mine. I do not
specify or maintain the server OSes; that's a responsibility of the
operations staff of the School of Engineering, and they're busy people
who do not report to me.
To help keep my course material up-to-date I install copies of the
latest released versions of Emacs (currently 25.3), Bash (currently
4.4.19), and many other free software programs. (I don't overwrite
/usr/bin of course; I install into a separate directory that students
put into their PATH settings.) So it'll be little trouble to me or my
students if Emacs requires Bash 4.4 or later. When I mentioned RHEL 7, I
wasn't simply talking about my personal situation; I was observing that
requiring Bash 4.4 would be a hassle for people installing newer Emacs
versions onto Red Hat servers, as it would require these people to also
install newer Bash versions. If it's important for Emacs to require Bash
4.4 of course Emacs can do so; still, I expect that the overall hassle
to Emacs users of requiring Bash 4.4 still outweighs the relatively
minor technical benefit in question. Sorry, but that's how things often
work in production software.
With all this in mind you might want to rethink your comments that among
other things seem to imply that the staff at UCLA consists of "lazy
privileged people".
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-24 22:03 ` Paul Eggert
2018-05-25 2:25 ` bug#20202: " Van L
@ 2018-05-25 6:16 ` Eli Zaretskii
2018-05-25 7:28 ` bug#20484: " Van L
` (3 more replies)
2018-05-25 6:16 ` bug#20202: " Eli Zaretskii
` (2 subsequent siblings)
4 siblings, 4 replies; 56+ messages in thread
From: Eli Zaretskii @ 2018-05-25 6:16 UTC (permalink / raw
To: Paul Eggert; +Cc: 20484, emacs-devel, 20202, monnier, phillip.lord
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 24 May 2018 15:03:56 -0700
> Cc: 20202@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
> 20484@debbugs.gnu.org
>
> Bash 4.4 came out only in September 2016, and it's too soon to assume
> it.
I agree, 1.5 years is too soon. I think we need 5 years at least.
> How about this idea: At Emacs build time, we check whether Bash is 4.4
> or later, and if so we use a term.el that assumes bash 4.4 or later.
> Otherwise, we use a term.el that interrogates the shell dynamically for
> whether it is shell and if so what its version number is, the first time
> that Emacs runs a process under a shell.
The first part will only work if Emacs is used on the same system
where it is built, right? Is that a good assumption, given all the
binary distributions?
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-25 6:16 ` Eli Zaretskii
@ 2018-05-25 7:28 ` Van L
2018-05-25 7:28 ` bug#20202: " Van L
` (2 subsequent siblings)
3 siblings, 0 replies; 56+ messages in thread
From: Van L @ 2018-05-25 7:28 UTC (permalink / raw
To: Eli Zaretskii
Cc: Paul Eggert, emacs-devel, 20202, 20484, monnier, phillip.lord
> Eli Zaretskii writes:
>
>> Bash 4.4 came out only in September 2016, and it's too soon to assume
>> it.
>
> I agree, 1.5 years is too soon. I think we need 5 years at least.
How about applying the 5-multiplier to 9-month cycles?
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-25 6:16 ` Eli Zaretskii
2018-05-25 7:28 ` bug#20484: " Van L
@ 2018-05-25 7:28 ` Van L
2018-05-25 7:28 ` Van L
2018-05-25 17:50 ` Paul Eggert
3 siblings, 0 replies; 56+ messages in thread
From: Van L @ 2018-05-25 7:28 UTC (permalink / raw
To: Eli Zaretskii
Cc: Paul Eggert, emacs-devel, 20202, 20484, monnier, phillip.lord
> Eli Zaretskii writes:
>
>> Bash 4.4 came out only in September 2016, and it's too soon to assume
>> it.
>
> I agree, 1.5 years is too soon. I think we need 5 years at least.
How about applying the 5-multiplier to 9-month cycles?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-25 6:16 ` Eli Zaretskii
2018-05-25 7:28 ` bug#20484: " Van L
2018-05-25 7:28 ` bug#20202: " Van L
@ 2018-05-25 7:28 ` Van L
2018-05-25 8:02 ` bug#20202: " Eli Zaretskii
` (2 more replies)
2018-05-25 17:50 ` Paul Eggert
3 siblings, 3 replies; 56+ messages in thread
From: Van L @ 2018-05-25 7:28 UTC (permalink / raw
To: Eli Zaretskii
Cc: Paul Eggert, emacs-devel, 20202, 20484, monnier, phillip.lord
> Eli Zaretskii writes:
>
>> Bash 4.4 came out only in September 2016, and it's too soon to assume
>> it.
>
> I agree, 1.5 years is too soon. I think we need 5 years at least.
How about applying the 5-multiplier to 9-month cycles?
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-25 7:28 ` Van L
@ 2018-05-25 8:02 ` Eli Zaretskii
2018-05-25 8:02 ` Eli Zaretskii
2018-05-25 8:02 ` bug#20484: " Eli Zaretskii
2 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2018-05-25 8:02 UTC (permalink / raw
To: Van L; +Cc: eggert, emacs-devel, 20202, 20484, monnier, phillip.lord
> From: Van L <van@scratch.space>
> Date: Fri, 25 May 2018 17:28:31 +1000
> Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel@gnu.org,
> 20202@debbugs.gnu.org, 20484@debbugs.gnu.org,
> monnier@iro.umontreal.ca, phillip.lord@russet.org.uk
>
> > I agree, 1.5 years is too soon. I think we need 5 years at least.
>
> How about applying the 5-multiplier to 9-month cycles?
I think you are confusing this with an entirely different domain.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-25 7:28 ` Van L
2018-05-25 8:02 ` bug#20202: " Eli Zaretskii
@ 2018-05-25 8:02 ` Eli Zaretskii
2018-05-26 0:01 ` Van L
2018-05-25 8:02 ` bug#20484: " Eli Zaretskii
2 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2018-05-25 8:02 UTC (permalink / raw
To: Van L; +Cc: eggert, emacs-devel, 20202, 20484, monnier, phillip.lord
> From: Van L <van@scratch.space>
> Date: Fri, 25 May 2018 17:28:31 +1000
> Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel@gnu.org,
> 20202@debbugs.gnu.org, 20484@debbugs.gnu.org,
> monnier@iro.umontreal.ca, phillip.lord@russet.org.uk
>
> > I agree, 1.5 years is too soon. I think we need 5 years at least.
>
> How about applying the 5-multiplier to 9-month cycles?
I think you are confusing this with an entirely different domain.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-25 7:28 ` Van L
2018-05-25 8:02 ` bug#20202: " Eli Zaretskii
2018-05-25 8:02 ` Eli Zaretskii
@ 2018-05-25 8:02 ` Eli Zaretskii
2 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2018-05-25 8:02 UTC (permalink / raw
To: Van L; +Cc: eggert, emacs-devel, 20202, 20484, monnier, phillip.lord
> From: Van L <van@scratch.space>
> Date: Fri, 25 May 2018 17:28:31 +1000
> Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel@gnu.org,
> 20202@debbugs.gnu.org, 20484@debbugs.gnu.org,
> monnier@iro.umontreal.ca, phillip.lord@russet.org.uk
>
> > I agree, 1.5 years is too soon. I think we need 5 years at least.
>
> How about applying the 5-multiplier to 9-month cycles?
I think you are confusing this with an entirely different domain.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-25 6:16 ` Eli Zaretskii
` (2 preceding siblings ...)
2018-05-25 7:28 ` Van L
@ 2018-05-25 17:50 ` Paul Eggert
3 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-25 17:50 UTC (permalink / raw
To: emacs-devel
On 05/24/2018 11:16 PM, Eli Zaretskii wrote:
>> How about this idea: At Emacs build time, we check whether Bash is 4.4
>> or later, and if so we use a term.el that assumes bash 4.4 or later.
>> Otherwise, we use a term.el that interrogates the shell dynamically for
>> whether it is shell and if so what its version number is, the first time
>> that Emacs runs a process under a shell.
> The first part will only work if Emacs is used on the same system
> where it is built, right
No, it merely assumes that the build Bash version is not greater than
the production Bash version. Although this is the typical situation,
you're correct that it might not be true in general; if that's a problem
(which I doubt), we can easily provide a configure-time option to
override the default assumption.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-24 22:03 ` Paul Eggert
2018-05-25 2:25 ` bug#20202: " Van L
2018-05-25 6:16 ` Eli Zaretskii
@ 2018-05-25 6:16 ` Eli Zaretskii
2018-05-25 6:16 ` bug#20484: " Eli Zaretskii
2018-05-25 22:34 ` Phillip Lord
4 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2018-05-25 6:16 UTC (permalink / raw
To: Paul Eggert; +Cc: 20202, phillip.lord, 20484, monnier, emacs-devel
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 24 May 2018 15:03:56 -0700
> Cc: 20202@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
> 20484@debbugs.gnu.org
>
> Bash 4.4 came out only in September 2016, and it's too soon to assume
> it.
I agree, 1.5 years is too soon. I think we need 5 years at least.
> How about this idea: At Emacs build time, we check whether Bash is 4.4
> or later, and if so we use a term.el that assumes bash 4.4 or later.
> Otherwise, we use a term.el that interrogates the shell dynamically for
> whether it is shell and if so what its version number is, the first time
> that Emacs runs a process under a shell.
The first part will only work if Emacs is used on the same system
where it is built, right? Is that a good assumption, given all the
binary distributions?
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-24 22:03 ` Paul Eggert
` (2 preceding siblings ...)
2018-05-25 6:16 ` bug#20202: " Eli Zaretskii
@ 2018-05-25 6:16 ` Eli Zaretskii
2018-05-25 22:34 ` Phillip Lord
4 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2018-05-25 6:16 UTC (permalink / raw
To: Paul Eggert; +Cc: 20202, phillip.lord, 20484, monnier, emacs-devel
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 24 May 2018 15:03:56 -0700
> Cc: 20202@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
> 20484@debbugs.gnu.org
>
> Bash 4.4 came out only in September 2016, and it's too soon to assume
> it.
I agree, 1.5 years is too soon. I think we need 5 years at least.
> How about this idea: At Emacs build time, we check whether Bash is 4.4
> or later, and if so we use a term.el that assumes bash 4.4 or later.
> Otherwise, we use a term.el that interrogates the shell dynamically for
> whether it is shell and if so what its version number is, the first time
> that Emacs runs a process under a shell.
The first part will only work if Emacs is used on the same system
where it is built, right? Is that a good assumption, given all the
binary distributions?
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-24 22:03 ` Paul Eggert
` (3 preceding siblings ...)
2018-05-25 6:16 ` bug#20484: " Eli Zaretskii
@ 2018-05-25 22:34 ` Phillip Lord
4 siblings, 0 replies; 56+ messages in thread
From: Phillip Lord @ 2018-05-25 22:34 UTC (permalink / raw
To: Paul Eggert; +Cc: Emacs-Devel devel, 20484, Stefan Monnier, 20202
Paul Eggert <eggert@cs.ucla.edu> writes:
> Bash 4.4 came out only in September 2016, and it's too soon to assume
> it. For example, my students regularly use Emacs on a server running
> RHEL 7, which ships Bash 4.2.46, and as I understand it, this is the
> most recent RHEL available.
Well, Emacs-27 will come out in 2020, so that's 4 years lead time. And
the most recent of RHEL also ships with Emacs-24. So, by the time RHEL
ships Emacs-27, good chance it will ship Bash 4.4.
> How about this idea: At Emacs build time, we check whether Bash is 4.4
> or later, and if so we use a term.el that assumes bash 4.4 or
> later. Otherwise, we use a term.el that interrogates the shell
> dynamically for whether it is shell and if so what its version number
> is, the first time that Emacs runs a process under a shell.
Well, the latter half we could do (I don't think the build idea makes
sense). But I was hoping to make life simpler, not more complex.
Phil
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-24 20:46 EMACS=t Joy and Happiness Phillip Lord
` (2 preceding siblings ...)
2018-05-24 22:03 ` Paul Eggert
@ 2018-05-24 22:03 ` Paul Eggert
2018-05-24 22:03 ` bug#20202: " Paul Eggert
` (3 subsequent siblings)
7 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-24 22:03 UTC (permalink / raw
To: Phillip Lord, Emacs-Devel devel; +Cc: 20484, 20202, Stefan Monnier
Bash 4.4 came out only in September 2016, and it's too soon to assume
it. For example, my students regularly use Emacs on a server running
RHEL 7, which ships Bash 4.2.46, and as I understand it, this is the
most recent RHEL available.
How about this idea: At Emacs build time, we check whether Bash is 4.4
or later, and if so we use a term.el that assumes bash 4.4 or later.
Otherwise, we use a term.el that interrogates the shell dynamically for
whether it is shell and if so what its version number is, the first time
that Emacs runs a process under a shell.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-24 20:46 EMACS=t Joy and Happiness Phillip Lord
` (3 preceding siblings ...)
2018-05-24 22:03 ` Paul Eggert
@ 2018-05-24 22:03 ` Paul Eggert
2018-05-25 20:36 ` bug#20484: " Paul Eggert
` (2 subsequent siblings)
7 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-24 22:03 UTC (permalink / raw
To: Phillip Lord, Emacs-Devel devel; +Cc: 20484, 20202, Stefan Monnier
Bash 4.4 came out only in September 2016, and it's too soon to assume
it. For example, my students regularly use Emacs on a server running
RHEL 7, which ships Bash 4.2.46, and as I understand it, this is the
most recent RHEL available.
How about this idea: At Emacs build time, we check whether Bash is 4.4
or later, and if so we use a term.el that assumes bash 4.4 or later.
Otherwise, we use a term.el that interrogates the shell dynamically for
whether it is shell and if so what its version number is, the first time
that Emacs runs a process under a shell.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-24 20:46 EMACS=t Joy and Happiness Phillip Lord
` (4 preceding siblings ...)
2018-05-24 22:03 ` bug#20202: " Paul Eggert
@ 2018-05-25 20:36 ` Paul Eggert
2018-05-25 20:36 ` Paul Eggert
2018-05-25 20:36 ` Paul Eggert
7 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-25 20:36 UTC (permalink / raw
To: Phillip Lord, Emacs-Devel devel; +Cc: 20484, 20202, Stefan Monnier
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
On 05/24/2018 01:46 PM, Phillip Lord wrote:
> I would like to propose that we now remove this on master,
>
Given the compatibility concerns expressed, how about the attached patch
instead? The idea is to remove the need to setenv EMACS with newer
Bashes, while still setting EMACS for older Bashes, for backward
compatibility.
[-- Attachment #2: 0001-Don-t-set-EMACS-t-if-Bash-is-4.4-or-newer.txt --]
[-- Type: text/plain, Size: 3015 bytes --]
From f7efdc4d21c22a81398b06cdc58144ec2f9c7697 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 25 May 2018 13:25:51 -0700
Subject: [PROPOSED] =?UTF-8?q?Don=E2=80=99t=20set=20EMACS=3Dt=20if=20Bash?=
=?UTF-8?q?=20is=204.4=20or=20newer?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* lisp/term.el (term--bash-needs-EMACS-status): New var.
(term--bash-needs-EMACSp): New function.
(term-exec-1): Use it instead of always setting EMACS.
---
lisp/term.el | 31 +++++++++++++++++++++++++------
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/lisp/term.el b/lisp/term.el
index 017b0221ec..fa43774ae8 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1489,6 +1489,26 @@ term-termcap-format
;; don't define :te=\\E[2J\\E[?47l\\E8:ti=\\E7\\E[?47h\
"Termcap capabilities supported.")
+;; This is for backwards compatibility with Bash 4.3 and earlier.
+;; Remove this hack once Bash 4.4-or-later is reasonably universal, because
+;; it slows down execution slightly, just before the first subshell.
+(defvar term--bash-needs-EMACS-status nil
+ "43 if Bash is so old that it needs EMACS set.
+Some other integer if Bash is new or not in use.
+Nil if unknown.")
+(defun term--bash-needs-EMACSp ()
+ "t if Bash is old, nil if it is new or not in use."
+ (unless term--bash-needs-EMACS-status
+ (let ((process-environment (copy-sequence process-environment)))
+ (setenv "BASH_ENV")
+ (setq term--bash-needs-EMACS-status
+ (condition-case nil
+ (call-process
+ "bash" nil nil nil "-c"
+ "case $BASH_VERSION in [0123].*|4.[0123].*) exit 43;; esac")
+ (error 0)))))
+ (eq 43 term--bash-needs-EMACS-status))
+
;; This auxiliary function cranks up the process for term-exec in
;; the appropriate environment.
@@ -1506,12 +1526,6 @@ term-exec-1
(format term-termcap-format "TERMCAP="
term-term-name term-height term-width)
- ;; This is for backwards compatibility with Bash 4.3 and earlier.
- ;; Remove this hack once Bash 4.4-or-later is common, because
- ;; it breaks './configure' of some packages that expect it to
- ;; say where to find EMACS.
- (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
-
(format "INSIDE_EMACS=%s,term:%s" emacs-version term-protocol-version)
(format "LINES=%d" term-height)
(format "COLUMNS=%d" term-width))
@@ -1523,6 +1537,11 @@ term-exec-1
;; escape codes, so we need to see the raw output. We will have to
;; do the decoding by hand on the parts that are made of chars.
(coding-system-for-read 'binary))
+ (when (term--bash-needs-EMACSp)
+ (setq process-environment
+ (cons
+ (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
+ process-environment)))
(apply 'start-process name buffer
"/bin/sh" "-c"
(format "stty -nl echo rows %d columns %d sane 2>/dev/null;\
--
2.17.0
^ permalink raw reply related [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-24 20:46 EMACS=t Joy and Happiness Phillip Lord
` (5 preceding siblings ...)
2018-05-25 20:36 ` bug#20484: " Paul Eggert
@ 2018-05-25 20:36 ` Paul Eggert
2018-05-25 22:49 ` bug#20202: " Phillip Lord
2018-05-26 7:20 ` bug#20484: " Eli Zaretskii
2018-05-25 20:36 ` Paul Eggert
7 siblings, 2 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-25 20:36 UTC (permalink / raw
To: Phillip Lord, Emacs-Devel devel; +Cc: 20202, Stefan Monnier, 20484
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
On 05/24/2018 01:46 PM, Phillip Lord wrote:
> I would like to propose that we now remove this on master,
>
Given the compatibility concerns expressed, how about the attached patch
instead? The idea is to remove the need to setenv EMACS with newer
Bashes, while still setting EMACS for older Bashes, for backward
compatibility.
[-- Attachment #2: 0001-Don-t-set-EMACS-t-if-Bash-is-4.4-or-newer.txt --]
[-- Type: text/plain, Size: 3015 bytes --]
From f7efdc4d21c22a81398b06cdc58144ec2f9c7697 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 25 May 2018 13:25:51 -0700
Subject: [PROPOSED] =?UTF-8?q?Don=E2=80=99t=20set=20EMACS=3Dt=20if=20Bash?=
=?UTF-8?q?=20is=204.4=20or=20newer?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* lisp/term.el (term--bash-needs-EMACS-status): New var.
(term--bash-needs-EMACSp): New function.
(term-exec-1): Use it instead of always setting EMACS.
---
lisp/term.el | 31 +++++++++++++++++++++++++------
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/lisp/term.el b/lisp/term.el
index 017b0221ec..fa43774ae8 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1489,6 +1489,26 @@ term-termcap-format
;; don't define :te=\\E[2J\\E[?47l\\E8:ti=\\E7\\E[?47h\
"Termcap capabilities supported.")
+;; This is for backwards compatibility with Bash 4.3 and earlier.
+;; Remove this hack once Bash 4.4-or-later is reasonably universal, because
+;; it slows down execution slightly, just before the first subshell.
+(defvar term--bash-needs-EMACS-status nil
+ "43 if Bash is so old that it needs EMACS set.
+Some other integer if Bash is new or not in use.
+Nil if unknown.")
+(defun term--bash-needs-EMACSp ()
+ "t if Bash is old, nil if it is new or not in use."
+ (unless term--bash-needs-EMACS-status
+ (let ((process-environment (copy-sequence process-environment)))
+ (setenv "BASH_ENV")
+ (setq term--bash-needs-EMACS-status
+ (condition-case nil
+ (call-process
+ "bash" nil nil nil "-c"
+ "case $BASH_VERSION in [0123].*|4.[0123].*) exit 43;; esac")
+ (error 0)))))
+ (eq 43 term--bash-needs-EMACS-status))
+
;; This auxiliary function cranks up the process for term-exec in
;; the appropriate environment.
@@ -1506,12 +1526,6 @@ term-exec-1
(format term-termcap-format "TERMCAP="
term-term-name term-height term-width)
- ;; This is for backwards compatibility with Bash 4.3 and earlier.
- ;; Remove this hack once Bash 4.4-or-later is common, because
- ;; it breaks './configure' of some packages that expect it to
- ;; say where to find EMACS.
- (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
-
(format "INSIDE_EMACS=%s,term:%s" emacs-version term-protocol-version)
(format "LINES=%d" term-height)
(format "COLUMNS=%d" term-width))
@@ -1523,6 +1537,11 @@ term-exec-1
;; escape codes, so we need to see the raw output. We will have to
;; do the decoding by hand on the parts that are made of chars.
(coding-system-for-read 'binary))
+ (when (term--bash-needs-EMACSp)
+ (setq process-environment
+ (cons
+ (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
+ process-environment)))
(apply 'start-process name buffer
"/bin/sh" "-c"
(format "stty -nl echo rows %d columns %d sane 2>/dev/null;\
--
2.17.0
^ permalink raw reply related [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-25 20:36 ` Paul Eggert
@ 2018-05-25 22:49 ` Phillip Lord
2018-05-26 7:20 ` bug#20484: " Eli Zaretskii
1 sibling, 0 replies; 56+ messages in thread
From: Phillip Lord @ 2018-05-25 22:49 UTC (permalink / raw
To: Paul Eggert; +Cc: Emacs-Devel devel, 20484, Stefan Monnier, 20202
Paul Eggert <eggert@cs.ucla.edu> writes:
> On 05/24/2018 01:46 PM, Phillip Lord wrote:
>> I would like to propose that we now remove this on master,
>>
>
> Given the compatibility concerns expressed, how about the attached
> patch instead? The idea is to remove the need to setenv EMACS with
> newer Bashes, while still setting EMACS for older Bashes, for backward
> compatibility.
>
> From f7efdc4d21c22a81398b06cdc58144ec2f9c7697 Mon Sep 17 00:00:00 2001
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 25 May 2018 13:25:51 -0700
> Subject: [PROPOSED] =?UTF-8?q?Don=E2=80=99t=20set=20EMACS=3Dt=20if=20Bash?=
> =?UTF-8?q?=20is=204.4=20or=20newer?=
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> * lisp/term.el (term--bash-needs-EMACS-status): New var.
> (term--bash-needs-EMACSp): New function.
> (term-exec-1): Use it instead of always setting EMACS.
> ---
> lisp/term.el | 31 +++++++++++++++++++++++++------
> 1 file changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/lisp/term.el b/lisp/term.el
> index 017b0221ec..fa43774ae8 100644
> --- a/lisp/term.el
> +++ b/lisp/term.el
> @@ -1489,6 +1489,26 @@ term-termcap-format
> ;; don't define :te=\\E[2J\\E[?47l\\E8:ti=\\E7\\E[?47h\
> "Termcap capabilities supported.")
>
> +;; This is for backwards compatibility with Bash 4.3 and earlier.
> +;; Remove this hack once Bash 4.4-or-later is reasonably universal, because
> +;; it slows down execution slightly, just before the first subshell.
> +(defvar term--bash-needs-EMACS-status nil
> + "43 if Bash is so old that it needs EMACS set.
> +Some other integer if Bash is new or not in use.
> +Nil if unknown.")
> +(defun term--bash-needs-EMACSp ()
> + "t if Bash is old, nil if it is new or not in use."
> + (unless term--bash-needs-EMACS-status
> + (let ((process-environment (copy-sequence process-environment)))
> + (setenv "BASH_ENV")
> + (setq term--bash-needs-EMACS-status
> + (condition-case nil
> + (call-process
> + "bash" nil nil nil "-c"
> + "case $BASH_VERSION in [0123].*|4.[0123].*) exit 43;; esac")
> + (error 0)))))
> + (eq 43 term--bash-needs-EMACS-status))
> +
> ;; This auxiliary function cranks up the process for term-exec in
> ;; the appropriate environment.
>
> @@ -1506,12 +1526,6 @@ term-exec-1
> (format term-termcap-format "TERMCAP="
> term-term-name term-height term-width)
>
> - ;; This is for backwards compatibility with Bash 4.3 and earlier.
> - ;; Remove this hack once Bash 4.4-or-later is common, because
> - ;; it breaks './configure' of some packages that expect it to
> - ;; say where to find EMACS.
> - (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
> -
> (format "INSIDE_EMACS=%s,term:%s" emacs-version term-protocol-version)
> (format "LINES=%d" term-height)
> (format "COLUMNS=%d" term-width))
> @@ -1523,6 +1537,11 @@ term-exec-1
> ;; escape codes, so we need to see the raw output. We will have to
> ;; do the decoding by hand on the parts that are made of chars.
> (coding-system-for-read 'binary))
> + (when (term--bash-needs-EMACSp)
> + (setq process-environment
> + (cons
> + (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
> + process-environment)))
> (apply 'start-process name buffer
> "/bin/sh" "-c"
> (format "stty -nl echo rows %d columns %d sane 2>/dev/null;\
It's a solution, afaict. However, one which is more complex than we
already have. The problem with RHEL probably only effects weird people
like you (and me!) who use a stock bash on an old RHEL, then compile the
latest Emacs. And us weird people could probably circumvent the problem
with term anyway.
You, Stefan and Eli have far more experience here clearly. Happy with
what ever you decide.
Phil
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-25 20:36 ` Paul Eggert
2018-05-25 22:49 ` bug#20202: " Phillip Lord
@ 2018-05-26 7:20 ` Eli Zaretskii
2018-05-26 20:54 ` Paul Eggert
` (2 more replies)
1 sibling, 3 replies; 56+ messages in thread
From: Eli Zaretskii @ 2018-05-26 7:20 UTC (permalink / raw
To: Paul Eggert; +Cc: 20202, phillip.lord, 20484, monnier, emacs-devel
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 25 May 2018 13:36:03 -0700
> Cc: 20202@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
> 20484@debbugs.gnu.org
>
> Given the compatibility concerns expressed, how about the attached patch
> instead?
I like it because it is future proof, and makes our burden of
remembering this issue easier.
Thanks.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-26 7:20 ` bug#20484: " Eli Zaretskii
@ 2018-05-26 20:54 ` Paul Eggert
2018-05-31 21:07 ` bug#20202: " Phillip Lord
2018-05-26 20:54 ` bug#20484: " Paul Eggert
2018-05-26 20:54 ` bug#20202: " Paul Eggert
2 siblings, 1 reply; 56+ messages in thread
From: Paul Eggert @ 2018-05-26 20:54 UTC (permalink / raw
To: Eli Zaretskii
Cc: Eli Barzilay, emacs-devel, monnier, 20202-done, 20484,
phillip.lord
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
Eli Zaretskii wrote:
> I like it because it is future proof, and makes our burden of
> remembering this issue easier.
>
> Thanks.
You're welcome. Stefan privately emailed me some helpful comments that improved
the patch (thanks!), and I installed the attached into master. In the hope that
this has laid Bug#20202 to rest (at least on modern GNU systems running Bash 4.4
or later), I'm boldly closing the bug report.
[-- Attachment #2: 0001-Don-t-set-EMACS-t-if-Bash-is-4.4-or-newer.txt --]
[-- Type: text/plain, Size: 3257 bytes --]
From 6fcab83600317e94ea7b915da7730a8c7e50226d Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 26 May 2018 13:29:06 -0700
Subject: [PATCH] =?UTF-8?q?Don=E2=80=99t=20set=20EMACS=3Dt=20if=20Bash=20i?=
=?UTF-8?q?s=204.4=20or=20newer?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
(Thanks to Stefan Monnier for improvements to this patch.)
* lisp/term.el (term--bash-needs-EMACS-status): New var.
(term--bash-needs-EMACSp): New function.
(term-exec-1): Use it instead of always setting EMACS.
---
lisp/term.el | 34 ++++++++++++++++++++++++++++------
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/lisp/term.el b/lisp/term.el
index 017b022..19e68dd 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1489,6 +1489,31 @@ term-termcap-format
;; don't define :te=\\E[2J\\E[?47l\\E8:ti=\\E7\\E[?47h\
"Termcap capabilities supported.")
+;; This private hack is for backwards compatibility with Bash 4.3 and earlier.
+;; It can be useful even when running a program other than Bash, as the
+;; program might invoke Bash as an interactive subshell. See this thread:
+;; https://lists.gnu.org/r/emacs-devel/2018-05/msg00670.html
+;; Remove this hack and its uses once Bash 4.4-or-later is reasonably
+;; universal, because it slows down execution slightly when
+;; term--bash-needs-EMACSp is first called.
+(defvar term--bash-needs-EMACS-status nil
+ "43 if Bash is so old that it needs EMACS set.
+Some other integer if Bash is new or not in use.
+Nil if unknown.")
+(defun term--bash-needs-EMACSp ()
+ "t if Bash is old, nil if it is new or not in use."
+ (eq 43
+ (or term--bash-needs-EMACS-status
+ (setf
+ term--bash-needs-EMACS-status
+ (let ((process-environment
+ (cons "BASH_ENV" process-environment)))
+ (condition-case nil
+ (call-process
+ "bash" nil nil nil "-c"
+ "case $BASH_VERSION in [0123].*|4.[0123].*) exit 43;; esac")
+ (error 0)))))))
+
;; This auxiliary function cranks up the process for term-exec in
;; the appropriate environment.
@@ -1506,12 +1531,6 @@ term-exec-1
(format term-termcap-format "TERMCAP="
term-term-name term-height term-width)
- ;; This is for backwards compatibility with Bash 4.3 and earlier.
- ;; Remove this hack once Bash 4.4-or-later is common, because
- ;; it breaks './configure' of some packages that expect it to
- ;; say where to find EMACS.
- (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
-
(format "INSIDE_EMACS=%s,term:%s" emacs-version term-protocol-version)
(format "LINES=%d" term-height)
(format "COLUMNS=%d" term-width))
@@ -1523,6 +1542,9 @@ term-exec-1
;; escape codes, so we need to see the raw output. We will have to
;; do the decoding by hand on the parts that are made of chars.
(coding-system-for-read 'binary))
+ (when (term--bash-needs-EMACSp)
+ (push (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
+ process-environment))
(apply 'start-process name buffer
"/bin/sh" "-c"
(format "stty -nl echo rows %d columns %d sane 2>/dev/null;\
--
2.7.4
^ permalink raw reply related [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-26 20:54 ` Paul Eggert
@ 2018-05-31 21:07 ` Phillip Lord
2018-05-31 23:45 ` Paul Eggert
` (2 more replies)
0 siblings, 3 replies; 56+ messages in thread
From: Phillip Lord @ 2018-05-31 21:07 UTC (permalink / raw
To: Paul Eggert; +Cc: Eli Barzilay, emacs-devel, monnier, 20484, 20202-done
Paul Eggert <eggert@cs.ucla.edu> writes:
> Eli Zaretskii wrote:
>
>> I like it because it is future proof, and makes our burden of
>> remembering this issue easier.
>>
>> Thanks.
>
> You're welcome. Stefan privately emailed me some helpful comments that
> improved the patch (thanks!), and I installed the attached into
> master. In the hope that this has laid Bug#20202 to rest (at least on
> modern GNU systems running Bash 4.4 or later), I'm boldly closing the
> bug report.
Not wishing to reopen the bug report that you have so boldly closed,
given that this would appear to be a conservative change rather than the
breaking one I was suggesting, any reason why this can't be installed
on emacs-26?
Phil
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-31 21:07 ` bug#20202: " Phillip Lord
@ 2018-05-31 23:45 ` Paul Eggert
2018-06-01 1:56 ` Stefan Monnier
` (5 more replies)
2018-05-31 23:45 ` bug#20484: " Paul Eggert
2018-05-31 23:45 ` bug#20202: " Paul Eggert
2 siblings, 6 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-31 23:45 UTC (permalink / raw
To: Phillip Lord
Cc: Eli Barzilay, emacs-devel, monnier, Eli Zaretskii, 20484,
20202-done
On 05/31/2018 02:07 PM, Phillip Lord wrote:
> any reason why this can't be installed
> on emacs-26?
None that I know of. Will there be a 26.2, though?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-31 23:45 ` Paul Eggert
@ 2018-06-01 1:56 ` Stefan Monnier
2018-06-01 1:56 ` bug#20202: " Stefan Monnier
` (4 subsequent siblings)
5 siblings, 0 replies; 56+ messages in thread
From: Stefan Monnier @ 2018-06-01 1:56 UTC (permalink / raw
To: Paul Eggert
Cc: Eli Barzilay, emacs-devel, Eli Zaretskii, Phillip Lord, 20484,
20202-done
> None that I know of. Will there be a 26.2, though?
I'd be surprised if we don't need to make a 26.2 before 27.1.
Stefan
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-31 23:45 ` Paul Eggert
2018-06-01 1:56 ` Stefan Monnier
@ 2018-06-01 1:56 ` Stefan Monnier
2018-06-01 1:56 ` bug#20484: " Stefan Monnier
` (3 subsequent siblings)
5 siblings, 0 replies; 56+ messages in thread
From: Stefan Monnier @ 2018-06-01 1:56 UTC (permalink / raw
To: Paul Eggert; +Cc: Eli Barzilay, emacs-devel, 20202-done, 20484, Phillip Lord
> None that I know of. Will there be a 26.2, though?
I'd be surprised if we don't need to make a 26.2 before 27.1.
Stefan
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-31 23:45 ` Paul Eggert
2018-06-01 1:56 ` Stefan Monnier
2018-06-01 1:56 ` bug#20202: " Stefan Monnier
@ 2018-06-01 1:56 ` Stefan Monnier
2018-06-01 7:04 ` Eli Zaretskii
` (2 subsequent siblings)
5 siblings, 0 replies; 56+ messages in thread
From: Stefan Monnier @ 2018-06-01 1:56 UTC (permalink / raw
To: Paul Eggert; +Cc: Eli Barzilay, emacs-devel, 20202-done, 20484, Phillip Lord
> None that I know of. Will there be a 26.2, though?
I'd be surprised if we don't need to make a 26.2 before 27.1.
Stefan
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-31 23:45 ` Paul Eggert
` (2 preceding siblings ...)
2018-06-01 1:56 ` bug#20484: " Stefan Monnier
@ 2018-06-01 7:04 ` Eli Zaretskii
2018-06-01 7:04 ` bug#20202: " Eli Zaretskii
2018-06-01 7:04 ` Eli Zaretskii
5 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2018-06-01 7:04 UTC (permalink / raw
To: Paul Eggert; +Cc: eli, emacs-devel, 20202, 20484, monnier, phillip.lord
> Cc: Eli Zaretskii <eliz@gnu.org>, 20484@debbugs.gnu.org, emacs-devel@gnu.org,
> 20202-done@debbugs.gnu.org, monnier@iro.umontreal.ca,
> Eli Barzilay <eli@barzilay.org>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 31 May 2018 16:45:59 -0700
>
> On 05/31/2018 02:07 PM, Phillip Lord wrote:
> > any reason why this can't be installed
> > on emacs-26?
>
> None that I know of. Will there be a 26.2, though?
Yes, I'm quite sure it will be. So if we want this change backported
to Emacs 26.2, we can do that now.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-31 23:45 ` Paul Eggert
` (3 preceding siblings ...)
2018-06-01 7:04 ` Eli Zaretskii
@ 2018-06-01 7:04 ` Eli Zaretskii
2018-06-01 7:04 ` Eli Zaretskii
5 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2018-06-01 7:04 UTC (permalink / raw
To: Paul Eggert; +Cc: eli, emacs-devel, 20202, 20484, monnier, phillip.lord
> Cc: Eli Zaretskii <eliz@gnu.org>, 20484@debbugs.gnu.org, emacs-devel@gnu.org,
> 20202-done@debbugs.gnu.org, monnier@iro.umontreal.ca,
> Eli Barzilay <eli@barzilay.org>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 31 May 2018 16:45:59 -0700
>
> On 05/31/2018 02:07 PM, Phillip Lord wrote:
> > any reason why this can't be installed
> > on emacs-26?
>
> None that I know of. Will there be a 26.2, though?
Yes, I'm quite sure it will be. So if we want this change backported
to Emacs 26.2, we can do that now.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-05-31 23:45 ` Paul Eggert
` (4 preceding siblings ...)
2018-06-01 7:04 ` bug#20202: " Eli Zaretskii
@ 2018-06-01 7:04 ` Eli Zaretskii
2018-06-01 14:08 ` bug#20202: " Paul Eggert
` (2 more replies)
5 siblings, 3 replies; 56+ messages in thread
From: Eli Zaretskii @ 2018-06-01 7:04 UTC (permalink / raw
To: Paul Eggert; +Cc: eli, emacs-devel, 20202, phillip.lord, 20484, monnier
> Cc: Eli Zaretskii <eliz@gnu.org>, 20484@debbugs.gnu.org, emacs-devel@gnu.org,
> 20202-done@debbugs.gnu.org, monnier@iro.umontreal.ca,
> Eli Barzilay <eli@barzilay.org>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 31 May 2018 16:45:59 -0700
>
> On 05/31/2018 02:07 PM, Phillip Lord wrote:
> > any reason why this can't be installed
> > on emacs-26?
>
> None that I know of. Will there be a 26.2, though?
Yes, I'm quite sure it will be. So if we want this change backported
to Emacs 26.2, we can do that now.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-06-01 7:04 ` Eli Zaretskii
@ 2018-06-01 14:08 ` Paul Eggert
2018-06-01 14:08 ` bug#20484: " Paul Eggert
2018-06-01 14:08 ` Paul Eggert
2 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-06-01 14:08 UTC (permalink / raw
To: Eli Zaretskii; +Cc: eli, emacs-devel, 20202, 20484, monnier, phillip.lord
Eli Zaretskii wrote:
> if we want this change backported to Emacs 26.2, we can do that now.
Phillip prefers that, and I do too. Any objections?
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-06-01 7:04 ` Eli Zaretskii
2018-06-01 14:08 ` bug#20202: " Paul Eggert
@ 2018-06-01 14:08 ` Paul Eggert
2018-06-01 14:08 ` Paul Eggert
2 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-06-01 14:08 UTC (permalink / raw
To: Eli Zaretskii; +Cc: eli, emacs-devel, 20202, 20484, monnier, phillip.lord
Eli Zaretskii wrote:
> if we want this change backported to Emacs 26.2, we can do that now.
Phillip prefers that, and I do too. Any objections?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-06-01 7:04 ` Eli Zaretskii
2018-06-01 14:08 ` bug#20202: " Paul Eggert
2018-06-01 14:08 ` bug#20484: " Paul Eggert
@ 2018-06-01 14:08 ` Paul Eggert
2018-06-01 14:14 ` bug#20484: " Eli Zaretskii
2 siblings, 1 reply; 56+ messages in thread
From: Paul Eggert @ 2018-06-01 14:08 UTC (permalink / raw
To: Eli Zaretskii; +Cc: eli, emacs-devel, 20202, 20484, monnier, phillip.lord
Eli Zaretskii wrote:
> if we want this change backported to Emacs 26.2, we can do that now.
Phillip prefers that, and I do too. Any objections?
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-06-01 14:08 ` Paul Eggert
@ 2018-06-01 14:14 ` Eli Zaretskii
2018-06-14 20:54 ` Paul Eggert
` (2 more replies)
0 siblings, 3 replies; 56+ messages in thread
From: Eli Zaretskii @ 2018-06-01 14:14 UTC (permalink / raw
To: Paul Eggert; +Cc: eli, emacs-devel, 20202, 20484, monnier, phillip.lord
> Cc: eli@barzilay.org, emacs-devel@gnu.org, 20202@debbugs.gnu.org,
> phillip.lord@russet.org.uk, 20484@debbugs.gnu.org, monnier@iro.umontreal.ca
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 1 Jun 2018 07:08:56 -0700
>
> Eli Zaretskii wrote:
> > if we want this change backported to Emacs 26.2, we can do that now.
>
> Phillip prefers that, and I do too. Any objections?
Not from me.
Thanks.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: EMACS=t Joy and Happiness
2018-06-01 14:14 ` bug#20484: " Eli Zaretskii
@ 2018-06-14 20:54 ` Paul Eggert
2018-06-14 20:54 ` bug#20484: " Paul Eggert
2018-06-14 20:54 ` bug#20202: " Paul Eggert
2 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-06-14 20:54 UTC (permalink / raw
To: Eli Zaretskii; +Cc: eli, emacs-devel, 20202, 20484, monnier, phillip.lord
On 06/01/2018 07:14 AM, Eli Zaretskii wrote:
>> Eli Zaretskii wrote:
>>> if we want this change backported to Emacs 26.2, we can do that now.
>> Phillip prefers that, and I do too. Any objections?
> Not from me.
>
> Thanks.
You're welcome. I installed that patch into the emacs-26 branch.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-06-01 14:14 ` bug#20484: " Eli Zaretskii
2018-06-14 20:54 ` Paul Eggert
@ 2018-06-14 20:54 ` Paul Eggert
2018-06-14 20:54 ` bug#20202: " Paul Eggert
2 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-06-14 20:54 UTC (permalink / raw
To: Eli Zaretskii; +Cc: eli, emacs-devel, 20202, 20484, monnier, phillip.lord
On 06/01/2018 07:14 AM, Eli Zaretskii wrote:
>> Eli Zaretskii wrote:
>>> if we want this change backported to Emacs 26.2, we can do that now.
>> Phillip prefers that, and I do too. Any objections?
> Not from me.
>
> Thanks.
You're welcome. I installed that patch into the emacs-26 branch.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-06-01 14:14 ` bug#20484: " Eli Zaretskii
2018-06-14 20:54 ` Paul Eggert
2018-06-14 20:54 ` bug#20484: " Paul Eggert
@ 2018-06-14 20:54 ` Paul Eggert
2 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-06-14 20:54 UTC (permalink / raw
To: Eli Zaretskii; +Cc: eli, emacs-devel, 20202, 20484, monnier, phillip.lord
On 06/01/2018 07:14 AM, Eli Zaretskii wrote:
>> Eli Zaretskii wrote:
>>> if we want this change backported to Emacs 26.2, we can do that now.
>> Phillip prefers that, and I do too. Any objections?
> Not from me.
>
> Thanks.
You're welcome. I installed that patch into the emacs-26 branch.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-31 21:07 ` bug#20202: " Phillip Lord
2018-05-31 23:45 ` Paul Eggert
@ 2018-05-31 23:45 ` Paul Eggert
2018-05-31 23:45 ` bug#20202: " Paul Eggert
2 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-31 23:45 UTC (permalink / raw
To: Phillip Lord; +Cc: Eli Barzilay, emacs-devel, monnier, 20484, 20202-done
On 05/31/2018 02:07 PM, Phillip Lord wrote:
> any reason why this can't be installed
> on emacs-26?
None that I know of. Will there be a 26.2, though?
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-31 21:07 ` bug#20202: " Phillip Lord
2018-05-31 23:45 ` Paul Eggert
2018-05-31 23:45 ` bug#20484: " Paul Eggert
@ 2018-05-31 23:45 ` Paul Eggert
2 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-31 23:45 UTC (permalink / raw
To: Phillip Lord; +Cc: Eli Barzilay, emacs-devel, monnier, 20484, 20202-done
On 05/31/2018 02:07 PM, Phillip Lord wrote:
> any reason why this can't be installed
> on emacs-26?
None that I know of. Will there be a 26.2, though?
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#20484: EMACS=t Joy and Happiness
2018-05-26 7:20 ` bug#20484: " Eli Zaretskii
2018-05-26 20:54 ` Paul Eggert
@ 2018-05-26 20:54 ` Paul Eggert
2018-05-26 20:54 ` bug#20202: " Paul Eggert
2 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-26 20:54 UTC (permalink / raw
To: Eli Zaretskii
Cc: Eli Barzilay, emacs-devel, monnier, 20202-done, 20484,
phillip.lord
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
Eli Zaretskii wrote:
> I like it because it is future proof, and makes our burden of
> remembering this issue easier.
>
> Thanks.
You're welcome. Stefan privately emailed me some helpful comments that improved
the patch (thanks!), and I installed the attached into master. In the hope that
this has laid Bug#20202 to rest (at least on modern GNU systems running Bash 4.4
or later), I'm boldly closing the bug report.
[-- Attachment #2: 0001-Don-t-set-EMACS-t-if-Bash-is-4.4-or-newer.txt --]
[-- Type: text/plain, Size: 3257 bytes --]
From 6fcab83600317e94ea7b915da7730a8c7e50226d Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 26 May 2018 13:29:06 -0700
Subject: [PATCH] =?UTF-8?q?Don=E2=80=99t=20set=20EMACS=3Dt=20if=20Bash=20i?=
=?UTF-8?q?s=204.4=20or=20newer?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
(Thanks to Stefan Monnier for improvements to this patch.)
* lisp/term.el (term--bash-needs-EMACS-status): New var.
(term--bash-needs-EMACSp): New function.
(term-exec-1): Use it instead of always setting EMACS.
---
lisp/term.el | 34 ++++++++++++++++++++++++++++------
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/lisp/term.el b/lisp/term.el
index 017b022..19e68dd 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1489,6 +1489,31 @@ term-termcap-format
;; don't define :te=\\E[2J\\E[?47l\\E8:ti=\\E7\\E[?47h\
"Termcap capabilities supported.")
+;; This private hack is for backwards compatibility with Bash 4.3 and earlier.
+;; It can be useful even when running a program other than Bash, as the
+;; program might invoke Bash as an interactive subshell. See this thread:
+;; https://lists.gnu.org/r/emacs-devel/2018-05/msg00670.html
+;; Remove this hack and its uses once Bash 4.4-or-later is reasonably
+;; universal, because it slows down execution slightly when
+;; term--bash-needs-EMACSp is first called.
+(defvar term--bash-needs-EMACS-status nil
+ "43 if Bash is so old that it needs EMACS set.
+Some other integer if Bash is new or not in use.
+Nil if unknown.")
+(defun term--bash-needs-EMACSp ()
+ "t if Bash is old, nil if it is new or not in use."
+ (eq 43
+ (or term--bash-needs-EMACS-status
+ (setf
+ term--bash-needs-EMACS-status
+ (let ((process-environment
+ (cons "BASH_ENV" process-environment)))
+ (condition-case nil
+ (call-process
+ "bash" nil nil nil "-c"
+ "case $BASH_VERSION in [0123].*|4.[0123].*) exit 43;; esac")
+ (error 0)))))))
+
;; This auxiliary function cranks up the process for term-exec in
;; the appropriate environment.
@@ -1506,12 +1531,6 @@ term-exec-1
(format term-termcap-format "TERMCAP="
term-term-name term-height term-width)
- ;; This is for backwards compatibility with Bash 4.3 and earlier.
- ;; Remove this hack once Bash 4.4-or-later is common, because
- ;; it breaks './configure' of some packages that expect it to
- ;; say where to find EMACS.
- (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
-
(format "INSIDE_EMACS=%s,term:%s" emacs-version term-protocol-version)
(format "LINES=%d" term-height)
(format "COLUMNS=%d" term-width))
@@ -1523,6 +1542,9 @@ term-exec-1
;; escape codes, so we need to see the raw output. We will have to
;; do the decoding by hand on the parts that are made of chars.
(coding-system-for-read 'binary))
+ (when (term--bash-needs-EMACSp)
+ (push (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
+ process-environment))
(apply 'start-process name buffer
"/bin/sh" "-c"
(format "stty -nl echo rows %d columns %d sane 2>/dev/null;\
--
2.7.4
^ permalink raw reply related [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-26 7:20 ` bug#20484: " Eli Zaretskii
2018-05-26 20:54 ` Paul Eggert
2018-05-26 20:54 ` bug#20484: " Paul Eggert
@ 2018-05-26 20:54 ` Paul Eggert
2 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-26 20:54 UTC (permalink / raw
To: Eli Zaretskii
Cc: Eli Barzilay, emacs-devel, monnier, 20202-done, 20484,
phillip.lord
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
Eli Zaretskii wrote:
> I like it because it is future proof, and makes our burden of
> remembering this issue easier.
>
> Thanks.
You're welcome. Stefan privately emailed me some helpful comments that improved
the patch (thanks!), and I installed the attached into master. In the hope that
this has laid Bug#20202 to rest (at least on modern GNU systems running Bash 4.4
or later), I'm boldly closing the bug report.
[-- Attachment #2: 0001-Don-t-set-EMACS-t-if-Bash-is-4.4-or-newer.txt --]
[-- Type: text/plain, Size: 3257 bytes --]
From 6fcab83600317e94ea7b915da7730a8c7e50226d Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 26 May 2018 13:29:06 -0700
Subject: [PATCH] =?UTF-8?q?Don=E2=80=99t=20set=20EMACS=3Dt=20if=20Bash=20i?=
=?UTF-8?q?s=204.4=20or=20newer?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
(Thanks to Stefan Monnier for improvements to this patch.)
* lisp/term.el (term--bash-needs-EMACS-status): New var.
(term--bash-needs-EMACSp): New function.
(term-exec-1): Use it instead of always setting EMACS.
---
lisp/term.el | 34 ++++++++++++++++++++++++++++------
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/lisp/term.el b/lisp/term.el
index 017b022..19e68dd 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1489,6 +1489,31 @@ term-termcap-format
;; don't define :te=\\E[2J\\E[?47l\\E8:ti=\\E7\\E[?47h\
"Termcap capabilities supported.")
+;; This private hack is for backwards compatibility with Bash 4.3 and earlier.
+;; It can be useful even when running a program other than Bash, as the
+;; program might invoke Bash as an interactive subshell. See this thread:
+;; https://lists.gnu.org/r/emacs-devel/2018-05/msg00670.html
+;; Remove this hack and its uses once Bash 4.4-or-later is reasonably
+;; universal, because it slows down execution slightly when
+;; term--bash-needs-EMACSp is first called.
+(defvar term--bash-needs-EMACS-status nil
+ "43 if Bash is so old that it needs EMACS set.
+Some other integer if Bash is new or not in use.
+Nil if unknown.")
+(defun term--bash-needs-EMACSp ()
+ "t if Bash is old, nil if it is new or not in use."
+ (eq 43
+ (or term--bash-needs-EMACS-status
+ (setf
+ term--bash-needs-EMACS-status
+ (let ((process-environment
+ (cons "BASH_ENV" process-environment)))
+ (condition-case nil
+ (call-process
+ "bash" nil nil nil "-c"
+ "case $BASH_VERSION in [0123].*|4.[0123].*) exit 43;; esac")
+ (error 0)))))))
+
;; This auxiliary function cranks up the process for term-exec in
;; the appropriate environment.
@@ -1506,12 +1531,6 @@ term-exec-1
(format term-termcap-format "TERMCAP="
term-term-name term-height term-width)
- ;; This is for backwards compatibility with Bash 4.3 and earlier.
- ;; Remove this hack once Bash 4.4-or-later is common, because
- ;; it breaks './configure' of some packages that expect it to
- ;; say where to find EMACS.
- (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
-
(format "INSIDE_EMACS=%s,term:%s" emacs-version term-protocol-version)
(format "LINES=%d" term-height)
(format "COLUMNS=%d" term-width))
@@ -1523,6 +1542,9 @@ term-exec-1
;; escape codes, so we need to see the raw output. We will have to
;; do the decoding by hand on the parts that are made of chars.
(coding-system-for-read 'binary))
+ (when (term--bash-needs-EMACSp)
+ (push (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
+ process-environment))
(apply 'start-process name buffer
"/bin/sh" "-c"
(format "stty -nl echo rows %d columns %d sane 2>/dev/null;\
--
2.7.4
^ permalink raw reply related [flat|nested] 56+ messages in thread
* bug#20202: EMACS=t Joy and Happiness
2018-05-24 20:46 EMACS=t Joy and Happiness Phillip Lord
` (6 preceding siblings ...)
2018-05-25 20:36 ` Paul Eggert
@ 2018-05-25 20:36 ` Paul Eggert
7 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2018-05-25 20:36 UTC (permalink / raw
To: Phillip Lord, Emacs-Devel devel; +Cc: 20484, 20202, Stefan Monnier
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
On 05/24/2018 01:46 PM, Phillip Lord wrote:
> I would like to propose that we now remove this on master,
>
Given the compatibility concerns expressed, how about the attached patch
instead? The idea is to remove the need to setenv EMACS with newer
Bashes, while still setting EMACS for older Bashes, for backward
compatibility.
[-- Attachment #2: 0001-Don-t-set-EMACS-t-if-Bash-is-4.4-or-newer.txt --]
[-- Type: text/plain, Size: 3015 bytes --]
From f7efdc4d21c22a81398b06cdc58144ec2f9c7697 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 25 May 2018 13:25:51 -0700
Subject: [PROPOSED] =?UTF-8?q?Don=E2=80=99t=20set=20EMACS=3Dt=20if=20Bash?=
=?UTF-8?q?=20is=204.4=20or=20newer?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* lisp/term.el (term--bash-needs-EMACS-status): New var.
(term--bash-needs-EMACSp): New function.
(term-exec-1): Use it instead of always setting EMACS.
---
lisp/term.el | 31 +++++++++++++++++++++++++------
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/lisp/term.el b/lisp/term.el
index 017b0221ec..fa43774ae8 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1489,6 +1489,26 @@ term-termcap-format
;; don't define :te=\\E[2J\\E[?47l\\E8:ti=\\E7\\E[?47h\
"Termcap capabilities supported.")
+;; This is for backwards compatibility with Bash 4.3 and earlier.
+;; Remove this hack once Bash 4.4-or-later is reasonably universal, because
+;; it slows down execution slightly, just before the first subshell.
+(defvar term--bash-needs-EMACS-status nil
+ "43 if Bash is so old that it needs EMACS set.
+Some other integer if Bash is new or not in use.
+Nil if unknown.")
+(defun term--bash-needs-EMACSp ()
+ "t if Bash is old, nil if it is new or not in use."
+ (unless term--bash-needs-EMACS-status
+ (let ((process-environment (copy-sequence process-environment)))
+ (setenv "BASH_ENV")
+ (setq term--bash-needs-EMACS-status
+ (condition-case nil
+ (call-process
+ "bash" nil nil nil "-c"
+ "case $BASH_VERSION in [0123].*|4.[0123].*) exit 43;; esac")
+ (error 0)))))
+ (eq 43 term--bash-needs-EMACS-status))
+
;; This auxiliary function cranks up the process for term-exec in
;; the appropriate environment.
@@ -1506,12 +1526,6 @@ term-exec-1
(format term-termcap-format "TERMCAP="
term-term-name term-height term-width)
- ;; This is for backwards compatibility with Bash 4.3 and earlier.
- ;; Remove this hack once Bash 4.4-or-later is common, because
- ;; it breaks './configure' of some packages that expect it to
- ;; say where to find EMACS.
- (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
-
(format "INSIDE_EMACS=%s,term:%s" emacs-version term-protocol-version)
(format "LINES=%d" term-height)
(format "COLUMNS=%d" term-width))
@@ -1523,6 +1537,11 @@ term-exec-1
;; escape codes, so we need to see the raw output. We will have to
;; do the decoding by hand on the parts that are made of chars.
(coding-system-for-read 'binary))
+ (when (term--bash-needs-EMACSp)
+ (setq process-environment
+ (cons
+ (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
+ process-environment)))
(apply 'start-process name buffer
"/bin/sh" "-c"
(format "stty -nl echo rows %d columns %d sane 2>/dev/null;\
--
2.17.0
^ permalink raw reply related [flat|nested] 56+ messages in thread