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
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
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
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
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
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
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
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
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.
>
> [...]
>
>
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
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..
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
-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 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
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 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
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
> 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
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
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
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
25 matches
Mail list logo
