On Tue, Sep 24, 2019 at 10:20 PM Daniel Colascione wrote:
>
> On Mon, Sep 23, 2019 at 6:36 AM Chet Ramey wrote:
> >
> > On 9/23/19 7:32 AM, Daniel Colascione wrote:
> > > On Wed, Jan 9, 2019 at 12:37 PM Chet Ramey wrote:
> > >>
> > >> On 1/9/19 2:39 PM, Daniel Colascione wrote:
> > >>> Any
On 1/8/20 2:34 AM, Mickael KENIKSSI wrote:
Hello,
I found a bug regarding how pathnames are processed during filename
expansion. The result for non-normalized path-patterns may get mangled in a
such a way that it becomes inconsistent and unpredictable, making it
useless for string comparison or
On 1/8/20 4:13 AM, Julien Palard wrote:
It can be reproduced on Debian bullseye with bash 5.0.11 on urxvt and xterm and
by a friend on MacOS with bash 3.2.57.
With this procedure I'm able to reproduce it consistently:
- Move ~/.bashrc elsewhere just to start clean
- Start a new terminal (in
It can be reproduced on Debian bullseye with bash 5.0.11 on urxvt and xterm and
by a friend on MacOS with bash 3.2.57.
With this procedure I'm able to reproduce it consistently:
- Move ~/.bashrc elsewhere just to start clean
- Start a new terminal (in my case tput cols tells it's 79 columns,
Hello,
I found a bug regarding how pathnames are processed during filename
expansion. The result for non-normalized path-patterns may get mangled in a
such a way that it becomes inconsistent and unpredictable, making it
useless for string comparison or any kind of string manipulation where
having
