On 1/10/20 8:39 PM, Robert Elz wrote:
That said, I also see no particularly good reason why bash should
be the outlier here.
It's an artifact of the bash implementation.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Ch
On 1/9/20 6:09 AM, Mickael KENIKSSI wrote:
Thanks for your comment.
I understand this may not sound of primary importance for you since they
are canonically equivalent, but sometimes what we really all care about is
the path as a literal string (be it well- or ill-formed), and not the
filesys
Date:Thu, 9 Jan 2020 12:09:22 +0100
From:Mickael KENIKSSI
Message-ID:
| zsh (and ksh) provide the expected result:
As far as I can tell, all shells except bash preserve the
null components, regardless of whether or not pattern chars
appear in filenames to the rig
On Jan 09 2020, Mickael KENIKSSI wrote:
> I understand this may not sound of primary importance for you since they
> are canonically equivalent, but sometimes what we really all care about is
> the path as a literal string (be it well- or ill-formed), and not the
> filesystem object it points to.
Thanks for your comment.
I understand this may not sound of primary importance for you since they
are canonically equivalent, but sometimes what we really all care about is
the path as a literal string (be it well- or ill-formed), and not the
filesystem object it points to.
Normalization upon fil
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
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
2019-08-08 10:38:48 -0400, Greg Wooledge:
[...]
> > shopt -s failglob
> > command="echo xyz\(\)"
> > $command
> > ```
> >
> > And it was working fine. But somewhere between bash version 4 and 5 I
> > realized it generates an error:
> > no match: xyz\(\)
[...]
> And my personal response for this va
On Thu, Aug 08, 2019 at 04:33:16PM +0200, Janek Mi wrote:
> For some time in my scripts I was using something like this:
>
> ```shell
> #!/usr/bin/env bash
> shopt -s failglob
> command="echo xyz\(\)"
> $command
> ```
>
> And it was working fine. But somewhere between bash version 4 and 5 I
> rea
On 8/8/19 10:33 AM, Janek Mi wrote:
> For some time in my scripts I was using something like this:
>
> ```shell
> #!/usr/bin/env bash
> shopt -s failglob
> command="echo xyz\(\)"
> $command
> ```
>
> And it was working fine. But somewhere between bash version 4 and 5 I
> realized it generates an
For some time in my scripts I was using something like this:
```shell
#!/usr/bin/env bash
shopt -s failglob
command="echo xyz\(\)"
$command
```
And it was working fine. But somewhere between bash version 4 and 5 I
realized it generates an error:
no match: xyz\(\)
with exit code equal 1.
If I un
11 matches
Mail list logo
