Am 01.03.2017 um 22:14 schrieb Chet Ramey:
>> […]
>>
>> is still there.
>
> This was fixed back in November as part of the work prompted by this
> report:
>
> http://lists.gnu.org/archive/html/bug-bash/2016-11/msg00101.html
>
> I've attached a patch people can play around with.
Indeed, then
On 3/1/17 3:32 PM, Reuti wrote:
>
> Am 01.03.2017 um 21:24 schrieb Grisha Levit:
>
>> On Wed, Mar 1, 2017 at 3:08 PM, Reuti wrote:
>>> I would say not closed, as it's still happening in 4.4.12. And if it's
>>> closed, it should be reopened.
>>
>> Are you using the same example? I can reproduce
Am 01.03.2017 um 21:24 schrieb Grisha Levit:
> On Wed, Mar 1, 2017 at 3:08 PM, Reuti wrote:
>> I would say not closed, as it's still happening in 4.4.12. And if it's
>> closed, it should be reopened.
>
> Are you using the same example? I can reproduce Geoff's original test
> case with 4.3 but
On Wed, Mar 1, 2017 at 3:08 PM, Reuti wrote:
> I would say not closed, as it's still happening in 4.4.12. And if it's
> closed, it should be reopened.
Are you using the same example? I can reproduce Geoff's original test
case with 4.3 but not with 4.4..
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 01.03.2017 um 20:27 schrieb Geoff Hull:
> Aha! That's it. Case closed, I think.
I would say not closed, as it's still happening in 4.4.12. And if it's closed,
it should be reopened.
- -- Reuti
-BEGIN PGP SIGNATURE-
Comment: GPGTools - h
Aha! That's it. Case closed, I think.
Thanks,
Geoff
On 2 March 2017 at 05:07, Reuti wrote:
>
> > Am 01.03.2017 um 16:53 schrieb Grisha Levit :
> >
> > On Mar 1, 2017 1:04 AM, "Geoff Hull" wrote:
> > If I want to go back to the behaviour I first experienced then I put the
> default COMMAND_PROM
> Am 01.03.2017 um 16:53 schrieb Grisha Levit :
>
> On Mar 1, 2017 1:04 AM, "Geoff Hull" wrote:
> If I want to go back to the behaviour I first experienced then I put the
> default COMMAND_PROMPT back
>
> I reported the multi-line alias and PROMPT_COMMAND interaction last June. The
> behavior
On Mar 1, 2017 1:04 AM, "Geoff Hull" wrote:
If I want to go back to the behaviour I first experienced then I put the
default COMMAND_PROMPT back
I reported the multi-line alias and PROMPT_COMMAND interaction last June.
The behavior you note should be fixed in 4.4.
https://lists.gnu.org/archive
Hi,
> Am 01.03.2017 um 07:04 schrieb Geoff Hull :
>
> Hi Reuti, Andreas,
>
> Yes, forgot to mention the bash versions I have tried: 4.3.46 on Arch Linux
> and 4.1.2 on CentOS 6.8.
>
> This is getting weirder: I've found I can replicate the behaviour you are
> getting Reuti, if I first do this
Hi Reuti, Andreas,
Yes, forgot to mention the bash versions I have tried: 4.3.46 on Arch Linux
and 4.1.2 on CentOS 6.8.
This is getting weirder: I've found I can replicate the behaviour you are
getting Reuti, if I first do this command:
unset COMMAND_PROMPT
If I want to go back to the behaviour
> Am 28.02.2017 um 14:21 schrieb Reuti :
>
> Hi,
>
>> Am 28.02.2017 um 11:00 schrieb Andreas Schwab :
>>
>> On Feb 28 2017, Geoff Hull wrote:
>>
>>> If I "source" the attached file (i.e. ". test_aliases") in a bash session,
>>> then run the following:
>>>
>>> assemble_fam1
>>> assemble_fam2
Hi,
> Am 28.02.2017 um 11:00 schrieb Andreas Schwab :
>
> On Feb 28 2017, Geoff Hull wrote:
>
>> If I "source" the attached file (i.e. ". test_aliases") in a bash session,
>> then run the following:
>>
>> assemble_fam1
>> assemble_fam2
>> say_families
>>
>> I see the following output:
>>
>>
On Feb 28 2017, Geoff Hull wrote:
> If I "source" the attached file (i.e. ". test_aliases") in a bash session,
> then run the following:
>
> assemble_fam1
> assemble_fam2
> say_families
>
> I see the following output:
>
> Flintstones=wilma:bam-bam:fred
> Rubbles=barney
It seems like the shell is
I think the following is a bug, but I'm not really sure. I've checked the
documentation for differences between old-style command substitution (
`...` ) and new-style ( $(...) ), and couldn't see anything that related to
this problem.
*Background*
At my place of work, I use some loops with variab
14 matches
Mail list logo
