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
2017-02-28 16:18:05 -0500, Chet Ramey:
[...]
> > Just my personal opinion, but I think I'd rather the spec had
> > been updated to accomodate the bash (and many other shells)
> > behaviour rather than bash breaking its backward compatibility
> > to comply to a requirement that is not particularly u
On 3/1/17 7:43 AM, Stephane Chazelas wrote:
> 2017-02-28 16:18:05 -0500, Chet Ramey:
> [...]
>>> Just my personal opinion, but I think I'd rather the spec had
>>> been updated to accomodate the bash (and many other shells)
>>> behaviour rather than bash breaking its backward compatibility
>>> to co
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
> 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
Chet Ramey wrote:
On 3/1/17 7:43 AM, Stephane Chazelas wrote:
It's not clear what combining several
compat options could do. For instance with shopt -s compat31
compat43 would not be compatible with bash-4.3 in that the [[ =~
]] operator would work the bash-3.1 way. That could cause
confusion
On Wed, Mar 01, 2017 at 08:48:20AM -0800, L A Walsh wrote:
> Chet Ramey wrote:
> >Compatibiity options are all mutually exclusive, last one wins.
> ---
> But the way it is now -- if someone is using a compat option
> for an earlier version, and now needs another compat option
> for some other incom
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
On 3/1/17 11:48 AM, L A Walsh wrote:
> But the way it is now -- if someone is using a compat option
> for an earlier version, and now needs another compat option
> for some other incompat, then they have a problem. I'm
> fairly sure that wasn't by design, as the compat options seem
> to have been
-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
On 3/1/17 12:06 PM, Greg Wooledge wrote:
> The purpose of the compat options is that you, as the script writer,
> right now, can write and test and deploy your script on a specific
> version of bash. Once you know that your script works on this version
> of bash (say, 4.4) you can set the compat
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..
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 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 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
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale
El mié., mar. 1, 2017 3:46 PM, Eduardo Bustamante
escribió:
>
>
> El mié., mar. 1, 2017 3:38 PM, Lfabbro
> escribió:
>
> [...]
>
> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
>
> Description:
> Bash rewrites on the same line if I exeed line terminal width lenght.
>
> [...]
>
>
2017-03-01 09:49:52 -0500, Chet Ramey:
[...]
> > Would you recommend people start adding:
> >
> > shopt -s compat44 2> /dev/null || true
> >
> > at the start of their script that they develop for bash-4.4 now
> > so that it still works even when bash-6.0 makes a non-backward
> > compatible change
On Wed, Mar 01, 2017 at 09:48:08PM +, Eduardo Bustamante wrote:
> El mié., mar. 1, 2017 3:46 PM, Eduardo Bustamante
> escribió:
> > Description:
> > Bash rewrites on the same line if I exeed line terminal width lenght.
> >
> Do you have an exotic PS1 or PROMPT_COMMAND ?
That was one of my ini
There:
>echo $TERM
xterm-256color
> echo $PS1
\[\033[01;32m\][\u@\h\[\033[01;37m\] \W$(__git_ps1 "
(\033[31m%s\033[37m)")\033[32m]\$\[\033[00m\]
>uname -a
Linux time-travel 4.4.48-1-MANJARO #1 SMP PREEMPT Thu Feb 9 22:17:50 UTC 2017
x86_64 GNU/Linux
>infocmp
# Reconstructed via infocmp from f
Oh! And thanks for your fast reply!
Sent with [ProtonMail](https://protonmail.com) Secure Email.
Original Message
Subject: Re: Broken Termcaps
Local Time: March 1, 2017 11:02 PM
UTC Time: March 1, 2017 10:02 PM
From: lfabbr...@protonmail.com
To: Greg Wooledge
Eduardo Bustama
On Wed, Mar 01, 2017 at 05:02:32PM -0500, Lfabbro wrote:
> > echo $PS1
> \[\033[01;32m\][\u@\h\[\033[01;37m\] \W$(__git_ps1 "
> (\033[31m%s\033[37m)")\033[32m]\$\[\033[00m\]
There are some unprotected escape sequences inside the $(...) but I have
absolutely no idea what that command substitution
Greg, I'm not sure what you mean by termcaps are legacy...
I mean, I personally use curses.h, term.h and termios.h
aren't them termcaps?
Why are them legacy and should not be used?
We must use them for our shell project...
The prompt actually use escapes for colors and to print branch name if I am
Yes you were right the error comes from PS1...
I'm sad I have no more the git branch on the prompt... :(
Now I use:
ps1="\[\033[01;32m\][\u@\h\[\033[01;37m\] \W\[\033[01;32m\]]\$\[\033[00m\]"
Sent with [ProtonMail](https://protonmail.com) Secure Email.
Original Message
Subjec
On Wed, Mar 01, 2017 at 05:15:51PM -0500, Lfabbro wrote:
> Greg, I'm not sure what you mean by termcaps are legacy...
> I mean, I personally use curses.h, term.h and termios.h
> aren't them termcaps?
No. Those are terminfo. Be grateful.
If you want a brief overview, you can start with "man term
25 matches
Mail list logo
