Re: Is this a bug by any chance?

2019-10-05 Thread
On Sat, 5 Oct 2019 18:48:35 + (UTC)
George R Goffe via Bug reports for the GNU Bourne Again SHell 
 wrote:

> Hi,
> 
> I just built the latest bash in an effort to determine if thie script shows a 
> bug or a ufu. Can you help me please?
> 
> I was expecting to see:
> 12345
> 
> Best regards AND thanks for your help,
> 
> George...
> 
> #!./bash -xv
>  x="1 2 3 4 5"
> + x='1 2 3 4 5'
>  for z in "$x"
>     do
>    echo "$z"
>     done
> + for z in "$x"
> + echo '1 2 3 4 5'
>  1 2 3 4 5
>  exit 0
> + exit 0
> 
> 

It's definitely not a bug. Quoting the expansion inhibits word splitting. Your 
loop iterates once over a single word. Said word is conveyed to echo as a 
single argument. In this case, said argument is printed by echo, with the 
addition of a newline character. If your ultimate intent is to store an 
arbitrary list of strings in a variable prior to iterating over them, you 
should use an array variable instead. As such, this would be a topic better 
suited to the help-bash list.

-- 
Kerin Millar



Is this a bug by any chance?

2019-10-05 Thread George R Goffe via Bug reports for the GNU Bourne Again SHell
Hi,

I just built the latest bash in an effort to determine if thie script shows a 
bug or a ufu. Can you help me please?

I was expecting to see:
12345

Best regards AND thanks for your help,

George...

#!./bash -xv
 x="1 2 3 4 5"
+ x='1 2 3 4 5'
 for z in "$x"
    do
   echo "$z"
    done
+ for z in "$x"
+ echo '1 2 3 4 5'
 1 2 3 4 5
 exit 0
+ exit 0




Forgets color when resizing with newline in prompt

2019-10-05 Thread ao2
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-parentheses -Wno-format-security
uname output: Linux jcn 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-09-26) 
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.0
Patch Level: 3
Release Status: release

Description:

I noticed that when there is a newline in the prompt bash "forgets"
about ANSI color sequences when the window is resized. I am not sure
f this is general for other kinds of ANSI escape codes.

Repeat-By:

1. Set the prompt to something like:

 PS1='\[\033[36m\]cyan\ncyan\[\033[0m\]\$ '

   or equivalently to:

 PS1='\[$(tput setaf 6)\]cyan\ncyan\[$(tput sgr0)\]\$ '

2. Resize the terminal window and see the second line of the prompt
   loosing the color.


I experience the problem with both gnome-terminal and xterm, so I don't think
it's the terminal emulator.

The issue can be worked around by specifying again the escape sequence after
the newline, e.g.:

 PS1='\[\033[36m\]cyan\n\[\033[36m\]cyan\[\033[0m\]\$ '

But that should not be needed, right?


The problem does not occur in zsh with neither with gnome-terminal or xterm,
with the following equivalent prompt:

  PROMPT=$'%{\e[36m%}cyan\ncyan%{\e[0m%}\$ '

or

  PROMPT=$'%F{cyan}cyan\ncyan%f\$ '

so I thought it might be a bash specific issue.


Thank you,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?



Color forgotten after newline in prompt when resizing window

2019-10-05 Thread ao2
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-parentheses -Wno-format-security
uname output: Linux jcn 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-09-26) 
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.0
Patch Level: 3
Release Status: release

Description:

I noticed that when there is a newline in the prompt bash "forgets"
the ANSI color sequences when the window is resized. I am not sure if
this is general for other kinds of ANSI escape codes.

Repeat-By:

1. Set the prompt to something like:

 PS1='\[\033[36m\]cyan\ncyan\[\033[0m\]\$ '

   or equivalently to:

 PS1='\[$(tput setaf 6)\]cyan\ncyan\[$(tput sgr0)\]\$ '

2. Resize the terminal window and see the second line of the prompt
   loosing the color.


I experience the problem with both gnome-terminal and xterm, so I don't think
it's the terminal emulator.

The issue can be worked around by specifying again the escape sequence after
the newline, e.g.:

 PS1='\[\033[36m\]cyan\n\[\033[36m\]cyan\[\033[0m\]\$ '

But that should not be needed, right?


The problem does not occur in zsh with neither gnome-terminal or xterm, using
the following equivalent prompt:

  PROMPT=$'%{\e[36m%}cyan\ncyan%{\e[0m%}\$ '

or

  PROMPT=$'%F{cyan}cyan\ncyan%f\$ '

So I thought it might be a bash specific issue.


Thank you,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?



the gdb does not displays tui properly

2019-10-05 Thread Kartikey Tewari
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-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/build/bash-N2nMjo/bash-4.4.18=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux inspiron-5370 4.4.0-18362-Microsoft #1-Microsoft Mon
Mar 18 12:02:00 PST 2019 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu


Bash Version: 4.4
Patch Level: 20
Release Status: release

Description:
I am using Microsoft Windows-10 -wsl ubuntu.
when dubugging c++ codes having extension .cpp via gdb debugger, I observe
that TUI does not get rendered properly.
But when I use the same code and binary in ubuntu-18.04 LTS, that I have
dual booted alongwith win10 in the system
the TUI works flawlessly. Please correct the same.

Repeat-By:
1. write a code say, main.cpp
2. compile using g++
open cmd
wsl
g++ -g -o main.out main.cpp
gdb
tui enable
file main.out
l
set breakpoints using b main.cpp:
r (run the programme)
n
info local (tui breaks at this point)



Fix:
Using ctrl+l after every command works always.So, I tried hooking majour
commands like next,continue, and info local
to refresh command, but that does not works, always.

Regards
Kartikey Tewari
Undergraduate
CSE Department
NIT, Hamirpur