On 9/26/23 2:01 AM, Grisha Levit wrote:
This was an oversight when changing quote_string_for_globbing to
only quote chars when they need it.
Thanks for the report.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Rame
This was an oversight when changing quote_string_for_globbing to
only quote chars when they need it.
---
pathexp.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/pathexp.c b/pathexp.c
index a849ec76..2eed8310 100644
--- a/pathexp.c
+++ b/pathexp.c
@@ -175,6 +175,
2022年12月2日(金) 0:59 Chet Ramey :
> > Thank you for the discussion and for applying the changes. Besides, I
> > am sorry that I still have a discussion on the behavior of BRACKMATCH,
> > so it was not the last set of changes. After the above fix, I moved
> > to check the behavior related to PATSCAN
On 11/28/22 5:51 AM, Koichi Murase wrote:
2022年11月23日(水) 5:24 Chet Ramey :
I attached the latest patch against bash-5.2.9.
commit 3c9dd4565792bc53de3a94ec38a65a1989f3fe2f (upstream/devel)
associative array elements; last set of changes to globbing
bracket expressions; fix for
On 11/28/22 5:51 AM, Koichi Murase wrote:
2022年11月23日(水) 5:24 Chet Ramey :
I attached the latest patch against bash-5.2.9.
commit 3c9dd4565792bc53de3a94ec38a65a1989f3fe2f (upstream/devel)
associative array elements; last set of changes to globbing
bracket expressions; fix for
se = pp + strlen (pp); /* end of pattern string */
- pe = glob_patscan (pp, se, 0); /* end of extglob pattern */
+ pe = glob_patscan (pp, se, 0, 0);/* end of extglob pattern */
/* if pe == 0, this is an invalid extglob pattern */
if (pe == 0)
@@ -234,7 +234,7 @@ ext
`matched' label in BRACKMATCH: This handles
sub-expressions of the bracket expression after a matching
sub-expression is found.
- (C) PATSCAN: This skips bracket expressions to determine the end of
the extglob constructs of the form @(...), ?(...), +(...), etc.
- (D) MATCHLEN (lib/g
). I
attach a patch for this [r0037.brackmatch6.remaining-slash.patch].
I agree with this; it was an inadvertent omission.
There is another related inconsistency. I just modified my new
extglob engine to follow Bash's choice described above, but then the
behavior became different from
lied also
before a matching character is found (lib/glob/sm_loop.c:573). I
attach a patch for this [r0037.brackmatch6.remaining-slash.patch].
--
There is another related inconsistency. I just modified my new
extglob engine to follow Bash's choice described above, but then the
behav
2022年11月18日(金) 2:11 Chet Ramey :
> "If a pattern ends with an unescaped , it is unspecified whether
> the pattern does not match anything or the pattern is treated as invalid."
>
> Bash uses the former interpretation. If "the pattern is treated as invalid"
> means trying to literally match the open
2022年11月18日(金) 6:29 Chet Ramey :
> The same is true for ranges. If either the first character or the second
> character in the range is a slash it should cause the bracket to be matched
> literally.
>
> Incidentally, I made an additional change so that an incomplete range
> expression causes the br
On 11/17/22 6:05 AM, Koichi Murase wrote:
Thank you for the patch. I applied it locally and tried it. I attach
a test script that I used: [bracket-slash.sh]. Now I switched to a
loadable builtin that directly calls strmatch instead of hacking
GLOBIGNORE. Here are the results:
---Tests fo
On 11/17/22 6:05 AM, Koichi Murase wrote:
Also, I have a suggestion of changes for more consistent handling of
incomplete bracket expressions. Currently, incomplete bracket
expressions sometimes fail unconditionally (#26..#31) and sometimes
fall back to a literal `[' plus remaining pattern (#18
ubmit the version ready
for review.
[1] https://gitlab.com/akinomyoga/bash/-/merge_requests/1; If some of
you want to try it, you can clone it by
$ git clone https://gitlab.com/akinomyoga/bash.git -b extglob
but be careful that this is now a moving target occasionally squashed
and force-pushed.
[
2022年11月17日(木) 6:47 Chet Ramey :
> fnmatch with FNM_PATHNAME only has to avoid matching the slash with a
> bracket expression. The shell has an additional constraint: a slash that
> appears in a bracket expression renders the bracket expression void and
> requires the `[' to be matched explicitly.
On 11/14/22 6:06 AM, Koichi Murase wrote:
However, I noticed two strange behaviors of the current engine.
Before adjusting the behavior of the new engine and submitting it for
review, I would like to confirm the (expected) behavior of the current
engine in the current devel.
These two behaviors
omp (), I have experimentally implemented
a new extglob engine based on a naive DFA and was comparing the
behavior and the performance with the current implementations of
devel. [Note: In this report hereafter, ``the current
implementation/engine'' always means the implementation of strmatch
(l
On 10/29/22 1:50 AM, Martin D Kealey wrote:
PS: While we're about it, can we please fix the expansion of « a/*/b/c/d/*
» so it only calls readdir on a/ and each dir matching a/*/b/c/d/ and NOT
call readdir on dirs matching a/*/, a/*/b/, or a/*/b/c/.
It already does this.
Given
$ find . -prin
On 10/30/22 9:59 PM, Martin D Kealey wrote:
With the exception of the !(LIST) negation, there's a direct correspondence
between extglob and any other regex format. Translating between them is
trivial.
As I said before, I would gladly look at incorporating such a change, as
long as it d
On 10/30/22 6:32 AM, Oğuz wrote:
Or
(g) make the existing extglob code faster and avoid introducing more
complexity into the shell.
The extglob code has reasonable performance when it's asked to do the most
common thing: check whether a given null-terminated string matches a given
(pos
On 10/29/22 1:50 AM, Martin D Kealey wrote:
This seems like a good reason to simply translate extglobs into regexes,
which should run in linear time, rather than put effort into building and
debugging a parallel implementation.
If someone wanted to do this, I would take a look at incorporating
On 10/28/22 2:44 AM, Hyunho Cho wrote:
Bash Version: 5.2
Patch Level: 2
Release Status: release
##
bash "extglob" almost unusable except with very tiny string.
there is no such problems in zsh "kshglob".
Nothing h
On 10/31/22 2:20 PM, Greg Wooledge wrote:
Bash already uses the POSIX regex functions (regcomp(3) et al.) to do
[[ =~ ]] using POSIX ERE.
Yeah, and offers no more than what your libc's regex engine has. For
example, you can't tell what `[[ x =~ .{256} ]]' (or even `[[ x =~ ""
]]') would return
On Mon, Oct 31, 2022 at 05:00:40AM +0200, Oğuz wrote:
> 31 Ekim 2022 Pazartesi tarihinde Martin D Kealey
> yazdı:
> > If we use the standard POSIX BRE or ERE, then there's no additional code to
> > ship; it's included as part of the OS. The hard part is what to do with
> > (!LIST), which was the p
31 Ekim 2022 Pazartesi tarihinde Martin D Kealey
yazdı:
>
> With the exception of the !(LIST) negation, there's a direct
> correspondence between extglob and any other regex format. Translating
> between them is trivial.
>
If we use the standard POSIX BRE or ERE, then there&
I'm top-quoting this because the entire response below seems to be
predicated on a misconception, or perhaps several misconceptions.
Exactly NONE of my suggestions involves expanding the Shell language.
Users would continue to write extglob exactly as they do now, and they
would remain bliss
tions was to /minimize/ the complexity that
becomes part of Bash's codebase, while leaving as few pathological
cases as possible - preferably none.
I meant complexity of the language, not the codebase.
In my opinion "make the existing extglob code faster" is a wasted
effort if it do
On Sun, Oct 30, 2022, 11:33 Oğuz wrote:
> 30 Ekim 2022 Pazar tarihinde Martin D Kealey
> yazdı:
> >
> > So the options would seem to be:
> > (a) prohibit inversions (you get to pick EITHER extglob or rexglob, not
> > both);
> > (b) bypass convert-to-regex
30 Ekim 2022 Pazar tarihinde Martin D Kealey
yazdı:
>
> So the options would seem to be:
> (a) prohibit inversions (you get to pick EITHER extglob or rexglob, not
> both);
> (b) bypass convert-to-regex when inversions are present;
> (c) use PCRE or Vim RE, which already support
> > debugging a parallel implementation.
>
> This isn't straightforward, because of the !(list) feature of extglob.
> There's no analogous construct for that in standard regexes.
>
That's true. and my "simply" is understating the complexity of the task,
but it&#
because of the !(list) feature of extglob.
There's no analogous construct for that in standard regexes.
This seems like a good reason to simply translate extglobs into regexes,
which should run in linear time, rather than put effort into building and
debugging a parallel implementation.
-Martin
PS: While we're about it, can we please fix the expansion of « a/*/b/c/d/*
» so it only calls readdir on
On Fri, Oct 28, 2022 at 03:44:34PM +0900, Hyunho Cho wrote:
> # this is just for testing purposes.
> $ foo=$( gcc -v --help 2> /dev/null | sed -En 's/^\s*(-[^ ]+).*/\1/p' )
The last time this issue was reported, we mentioned that "gcc --help"
is not a standard document that appears the same on eve
#24-Ubuntu SMP
PREEMPT_DYNAMIC Fri Oct 14 15:39:57 UTC 2022 x86_64 x86_64 x86_64
GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: 2
Release Status: release
##
bash "extglob" almost unusable except with very t
On 10/13/22 2:50 PM, Justin Wood (Callek) wrote:
Bash Version: 5.2
Patch Level: 2
Release Status: release
Description:
Bash segfaults when using extglob on an empty var. Regression in 5.2.2
compared to 5.1.16
Thanks for the report. This will be fixed in the next devel branch push.
Chet
x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 5.2
Patch Level: 2
Release Status: release
Description:
Bash segfaults when using extglob on an empty var. Regression in 5.2.2
compared to 5.1.16
#0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S
On 10/6/22 7:58 PM, Kerin Millar wrote:
Thanks for the report. I've attached the patch I applied to fix this.
Thanks for the patch. It is probably sufficient for the downstream bug report to
be closed. Unfortunately, it remains the case that the >=5.2-rc3 parser is
buggy.
Thanks for the ad
On Thu, 6 Oct 2022 15:49:26 -0400
Chet Ramey wrote:
> On 10/2/22 4:51 AM, Kerin Millar wrote:
>
> > $ declare -p BASH_VERSION
> > declare -- BASH_VERSION="5.2.0(1)-release"
> > $ BASH_COMPAT=50; shopt extglob; : $(: $(: $(:))); shopt extglob
> > ex
On 10/2/22 4:51 AM, Kerin Millar wrote:
$ declare -p BASH_VERSION
declare -- BASH_VERSION="5.2.0(1)-release"
$ BASH_COMPAT=50; shopt extglob; : $(: $(: $(:))); shopt extglob
extglob off
extglob on
Thanks for the report. I've attached the patch I applied to fix
extglob shell option to be switched on, without having
instructed bash to do so.
$ declare -p BASH_VERSION
declare -- BASH_VERSION="5.2.0(1)-release"
$ BASH_COMPAT=50; shopt extglob; : $(: $(: $(:))); shopt extglob
extglob off
extglob on
When the bug occurs, all levels ar
On 7/25/21 5:01 PM, Andreas Schwab wrote:
On Jul 25 2021, Chet Ramey wrote:
In the bash build directory, for instance, it fails right away, as it
should: there aren't any files ending in `y'.
It doesn't matter whether the file name contains `y', just how long it
is.
That's not what I mean
On Jul 25 2021, Chet Ramey wrote:
> In the bash build directory, for instance, it fails right away, as it
> should: there aren't any files ending in `y'.
It doesn't matter whether the file name contains `y', just how long it
is. Try creating a file with a name of 30 or more characters. Each
add
On 7/25/21 1:09 PM, andrej--- via Bug reports for the GNU Bourne Again
SHell wrote:
Bash Version: 5.1
Patch Level: 8
Release Status: release
Description:
An extglob like +(!(x))y causes Bash to freeze with a 100% CPU
utilization.
At the first glance the freeze doesn't se
On Jul 25 2021, Greg Wooledge wrote:
> On Sun, Jul 25, 2021 at 07:09:50PM +0200, andrej--- via Bug reports for the
> GNU Bourne Again SHell wrote:
>> Description:
>> An extglob like +(!(x))y causes Bash to freeze with a 100% CPU
>> utilization.
>>
On Sun, Jul 25, 2021 at 07:09:50PM +0200, andrej--- via Bug reports for the GNU
Bourne Again SHell wrote:
> Description:
> An extglob like +(!(x))y causes Bash to freeze with a 100% CPU
> utilization.
> At the first glance the freeze doesn't seem to depend on the
rsion: 5.1
Patch Level: 8
Release Status: release
Description:
An extglob like +(!(x))y causes Bash to freeze with a 100% CPU
utilization.
At the first glance the freeze doesn't seem to depend on the
(non-)existence of matching paths.
Repeat-By:
echo +(!(x))y # This fr
#x27;. Making `@()' work differently
>> from `*' would be surprising.
>
> However, ?(aa).foo matches the file .foo in Bash 4.4 and 5.0 (and also
> in Ksh and Zsh), so extglob already breaks the above mentioned rule.
Yes. That was part of the overhaul of this code that I re
t;.") which
starts with a '.' character.
For the same reason `*.' doesn't match `.'. Making `@()' work differently
from `*' would be surprising.
However, ?(aa).foo matches the file .foo in Bash 4.4 and 5.0 (and
also in Ksh and Zsh), so extglob already
On Jan 13 2019, Robert Elz wrote:
> The pattern
> ./$null"$dir"/
>
> is expanded (parameter expansion) to
>
> ./@()./
>
> which does not have a "." immediately after the / and
> tus cannot match any filename (incoludeing ".") which
> starts with a '.' character.
For the same reason `
7; if
>> `.' is the first character in the pattern. A pattern that begins with a
>> null extglob pattern (especially one that is defined to perform at least
>> one match) followed by a dot, quoted or unquoted, does not fulfill that
>> criterion.
>
> I don't foll
Date:Sat, 12 Jan 2019 17:58:12 -0600
From:Peng Yu
Message-ID:
| I don't think it is a good idea to introduce such kind of special
| cases. If @() should match an empty string, the least surprising
| definition is that it should match empty string everywhere.
filename that starts with a `.' if
> `.' is the first character in the pattern. A pattern that begins with a
> null extglob pattern (especially one that is defined to perform at least
> one match) followed by a dot, quoted or unquoted, does not fulfill that
> criterion.
I don&
me that starts with a `.' if
`.' is the first character in the pattern. A pattern that begins with a
null extglob pattern (especially one that is defined to perform at least
one match) followed by a dot, quoted or unquoted, does not fulfill that
criterion.
>
> How was this bug intro
)"
declare -- dir="."
shopt -s extglob
set +f
matched_paths=(./$null"$dir"/main_debug.sh)
declare -p matched_paths
$ ./main_debug.sh
4.4.23(1)-release
declare -a matched_paths=([0]="././main_debug.sh")
$ ./main_debug.sh
5.0.0(1)-release
declare -a matched_paths=([0]="./@()./main_debug.sh")
--
Regards,
Peng
On 8/22/18 3:19 PM, Michal Pesa wrote:
> My bad, sorry for not searching properly before asking. Thank you for your
> time.
No problem, you should always report against the latest version you have.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa,
My bad, sorry for not searching properly before asking. Thank you for
your time.
On 8/22/2018 3:16 PM, Chet Ramey wrote:
On 8/22/18 3:57 AM, Michal Pesa wrote:
Hello, I have encountered a strange behavior of nested extended globs:
$ echo *
.txt 000.txt 00.txt 0.txt a.txt b.txt c.txt
$ ec
On 8/22/18 3:57 AM, Michal Pesa wrote:
> Hello, I have encountered a strange behavior of nested extended globs:
>
> $ echo *
> .txt 000.txt 00.txt 0.txt a.txt b.txt c.txt
> $ echo !(0.txt)
> .txt 000.txt 00.txt a.txt b.txt c.txt
> $ echo !(+(0).txt)
> . .. a.txt b.txt c.txt
>
> The last e
On Wed, Aug 22, 2018 at 09:57:19AM +0200, Michal Pesa wrote:
> Hello, I have encountered a strange behavior of nested extended globs:
>
> $ echo *
> .txt 000.txt 00.txt 0.txt a.txt b.txt c.txt
> $ echo !(0.txt)
> .txt 000.txt 00.txt a.txt b.txt c.txt
> $ echo !(+(0).txt)
> . .. a.txt b.txt
Hello, I have encountered a strange behavior of nested extended globs:
$ echo *
.txt 000.txt 00.txt 0.txt a.txt b.txt c.txt
$ echo !(0.txt)
.txt 000.txt 00.txt a.txt b.txt c.txt
$ echo !(+(0).txt)
. .. a.txt b.txt c.txt
The last example correctly excludes the files but why are "." ".." b
On 8/12/18 12:26 AM, Mark Polyakov wrote:
>Bash Version: 4.3
>Patch Level: 46
>Release Status: release
>A
>Description:
> A A A An extglob pattern such as `*?(anything)something_else` will
>match any string, even though it should only match strin
On Sat, Aug 11, 2018 at 09:26:56PM -0700, Mark Polyakov wrote:
>Bash Version: 4.3
>Patch Level: 46
>A A A An extglob pattern such as `*?(anything)something_else` will
>match any string, even though it should only match strings that end
>with something_else.
put: Linux hullabaloo 2.6.32-042stab127.2 #1 SMP Thu Jan 4
16:41:44 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
A
Bash Version: 4.3
Patch Level: 46
Release Status: release
A
Description:
A A A An extglob pattern such as `*?(anything)some
> If you apply that rule, you can figure out the answer: extglob changes the
> behavior of the parser, so it must be enabled before a command is parsed.
> The complete line of input is read before any of it is parsed, and the
> complete line is parsed before any of it is executed. As a
On 5/27/18 7:38 PM, marcelpa...@gmail.com wrote:
> Bash Version: 4.4
> Patch Level: 19
> Release Status: release
>
> Description:
> extglob patterns are not expanded in -c command-strings, even if extglob is
> set within the command-string. For instance, running:
>
>
> bash -c 'shopt -s extglob; echo @(foo*|bar*)'
I've just discovered that this works as expected:
bash -O extglob -c 'echo @(foo*|bar*)'
However, the puzzle lingers on, since running this:
bash -c 'shopt -s extglob; shopt extglob'
results in:
extglo
-Wall
-Wno-parentheses -Wno-format-security
uname output: Linux monk 4.15.0-22-generic #24-Ubuntu SMP Wed May 16 12:15:17
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4
Patch Level: 19
Release Status: release
Description:
extglob patterns are not expa
On 01/02/2018 10:30 AM, Chet Ramey wrote:
> On 12/31/17 10:36 PM, Eric Cook wrote:
>
>> So to make my request more specific, i don't think the extglob !() should
>> match dotfiles when one of the patterns in the list is preceded with an
>> period.
>> to be mo
On 12/31/17 10:36 PM, Eric Cook wrote:
> So to make my request more specific, i don't think the extglob !() should
> match dotfiles when one of the patterns in the list is preceded with an
> period.
> to be more ksh93-like.
Let's see if we can be more precise: if a fil
On 12/31/2017 01:47 PM, Chet Ramey wrote:
> On 12/29/17 6:55 PM, Eric Cook wrote:
>> When using an pattern that begin with an period in pattern-list, bash will
>> include dotfiles in the results.
>> This doesn't seem to be the case with the various korn shells that i ha
On 12/29/17 6:55 PM, Eric Cook wrote:
> When using an pattern that begin with an period in pattern-list, bash will
> include dotfiles in the results.
> This doesn't seem to be the case with the various korn shells that i have
> seen. Since extglob is based on
> ksh's ex
When using an pattern that begin with an period in pattern-list, bash will
include dotfiles in the results.
This doesn't seem to be the case with the various korn shells that i have seen.
Since extglob is based on
ksh's extension to globbing, this appears to be an bug.
$ shopt
On 3/31/17 12:00 AM, Clark Wang wrote:
> There is a post on stackoverflow:
> http://stackoverflow.com/questions/43117707/bashs-strange-behavior-on-a-function-named/
> So when |extglob| is on, |@()| is handled as a glob pattern which makes
> sense. But the behavior after |shopt
On Fri, Mar 31, 2017 at 7:00 AM, Clark Wang wrote:
> There is a post on stackoverflow: http://stackoverflow.com/
> questions/43117707/bashs-strange-behavior-on-a-function-named/
>
> The *problem*:
>
> bash-4.4# shopt -s extglob
> bash-4.4# function @() { echo foo; }
> ba
There is a post on stackoverflow:
http://stackoverflow.com/questions/43117707/bashs-strange-behavior-on-a-function-named/
The *problem*:
bash-4.4# shopt -s extglob
bash-4.4# function @() { echo foo; }
bash-4.4# @()
foo
bash-4.4# declare -f
@() ()
{
echo foo
}
bash-4.4#
bash-4.4# unset -f
On 1/15/17 2:55 PM, Grisha Levit wrote:
> Is it expected that ** work with extended pattern matching?
No, it never has worked as in your example, nor was it intended to. That's
not how it works with ksh93, either. The `**' is basically a pathname
component.
Chet
--
``The lyf so short, the craft
On 1/15/17 2:46 PM, Grisha Levit wrote:
>> On 3/23/16 6:15 PM, Isabella Parakiss wrote:
>>> Just wanted to report a couple of problems in 4.3.42 and the latest
>>> devel version:
>>
>> Thanks for the report. These were both easy fixes, and the fixes will
>> be in bash-4.4.
>
> Using Isabella's ex
On Sun, Jan 15, 2017 at 2:46 PM, Grisha Levit wrote:
> Using Isabella's examples and the latest devel snapshot, there still
seems to be something off when dotglob is enabled:
Also the following case doesn't seem right (this time without dotglob):
$ echo !(f)
a b c
$ echo !(f)!(f)
. .. .x .y .z a
Is it expected that ** work with extended pattern matching?
$ shopt -s extglob globstar
$ echo **
d1 d1/f d2 d2/f f
$ echo @(**)
d1 d2 f
t devel snapshot, there still seems
to be something off when dotglob is enabled:
$ touch a b c .x .y .z
$ shopt -s extglob dotglob
$ echo @(*|@(f))
. .. .x .y .z a b c
$ echo @(*|@(ff))
.x .y .z a b c
On 3/23/16 6:15 PM, Isabella Parakiss wrote:
> Just wanted to report a couple of problems in 4.3.42 and the latest
> devel version:
Thanks for the report. These were both easy fixes, and the fixes will
be in bash-4.4.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Just wanted to report a couple of problems in 4.3.42 and the latest
devel version:
*?(/) followed by something makes it ignore the rest:
$ [[ a = a*?(/)b ]] && echo match
match
@(*|extglob) matches everything(?) but not always:
$ touch a b c .x .y .z
$ echo .!(|.) #
the shell works. The shell always parses a
complete command before executing any of it. A shell function definition
is a compound command, so the shell parses the entire function definition
at definition time rather than parsing it piece-by-piece on the fly at
execution time. Since extglob change
On Wed, Oct 07, 2015 at 10:44:20PM -0500, Eduardo A. Bustamante López wrote:
> > Repeat-By:
> > shopt -u extglob
> > isnum () ( shopt -s extglob; case "$1" in [1-9]*([0-9])) return 0 ;;
> > *) return 1 ;; esac; )
>
> Remember that bash parses an
> Repeat-By:
> shopt -u extglob
> isnum () ( shopt -s extglob; case "$1" in [1-9]*([0-9])) return 0 ;;
> *) return 1 ;; esac; )
Remember that bash parses and interprets the script line-by-line. If you want
to change the parser's operation (for example, ha
i Jul 4 21:40:53
UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 30
Release Status: release
Description:
The shell gives a syntax error when defining a function that uses the
extended pattern matching operators.
The man p
a 2.6.39.3-v11 #9 SMP PREEMPT Tue Dec 13 11:07:11 HST
> 2011 i686 GNU/Linux
> Machine Type: i686-pc-linux-gnu
>
> Bash Version: 3.2
> Patch Level: 17
> Release Status: release
>
> Description:
> My interactive environment contains some shell functions that are
>
e: i686-pc-linux-gnu
Bash Version: 3.2
Patch Level: 17
Release Status: release
Description:
My interactive environment contains some shell functions that are
cleaner making use of "extglob on" of the interactive shell. But
as soon as any other shell script is run
The pathexp-globignore-delim.patch seems to work as advertised.
> If *a matches scratch/a, for
> example, that's a bug in the matching code I will have to identify and fix.
Yes, this is the case. Based on your reply, the examples I showed are
definitely a bug.
Thank you so much.
On 6/19/14, 6:47 PM, Ian Kelling wrote:
> The doc says "When matching a pathname, the slash character
> must always be matched explicitly." Shortly thereafter, in the next
> paragraph of the same section, GLOBIGNORE is described, which does not
> treat / as special, but this is not mentioned, and
Chet Ramey writes:
> On 6/9/14, 3:42 PM, Ian Kelling wrote:
> Yes, it's an interesting question: what exactly does pattern negation
> include? You can match all filenames beginning with a `.' by using `.'
> as the first character of the pattern, so should a negated pattern
> beginning with a `.'
On 6/9/14, 3:42 PM, Ian Kelling wrote:
>
> Running this script with your own bash path demonstrates the bug.
>
> #!/home/ian/opt/bash/bash --norc
> shopt -s extglob
> shopt -s dotglob
> cd $(mktemp -d)
> mkdir a
> touch a/.b
> touch a/c
> echo a/!(.b)
>
Running this script with your own bash path demonstrates the bug.
#!/home/ian/opt/bash/bash --norc
shopt -s extglob
shopt -s dotglob
cd $(mktemp -d)
mkdir a
touch a/.b
touch a/c
echo a/!(.b)
output:
a/. a/.. a/c
this happens with all bash versions 4.3+ (latest is patch 18).
before that, the
> shows the help for (( ... )), so I casually threw some asterisks
> around it ... and got a segfault. This also happens in bash
> 4.2.45 and 4.2.25, but not 3.2.48. It only segfaults when
> extglob is enabled; probably because it's an incomplete extglob.
Thanks for the report. T
sion: 4.2
Patch Level: 45
Release Status: release
Description:
One of the side-effects of the latest changes of the help
builtin in the devel release is that ''help "(("'' no longer
shows the help for (( ... )), so I casually threw some asterisks
around it ... and got a s
#1 SMP Sat Apr 21
> 12:43:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-unknown-linux-gnu
>
> Bash Version: 4.2
> Patch Level: 28
> Release Status: release
>
> Description:
> A leading dot in extglob pattern fails to expand as expected.
Thanks for the
64-unknown-linux-gnu
Bash Version: 4.2
Patch Level: 28
Release Status: release
Description:
A leading dot in extglob pattern fails to expand as expected.
Repeat-By:
cd $(mktemp -d)
touch .Xdefaults
shopt -s extglob
echo @(.Xdefaults)
should print .Xdefaults
but it prints @(.Xdefaults)
works in ksh93 Version JM 93u+ 2011-06-22
On 4/21/12 3:27 PM, Andreas Schwab wrote:
> Mike Frysinger writes:
>
>> first set your locale to something unicode based:
>> export LC_ALL=en_US.UTF-8
>>
>> then try the simple script (from Ulrich Müller):
>> $ cat test.sh
>> shopt -s extglob
>> te
Mike Frysinger writes:
> first set your locale to something unicode based:
> export LC_ALL=en_US.UTF-8
>
> then try the simple script (from Ulrich Müller):
> $ cat test.sh
> shopt -s extglob
> text="aaaäöü"
> echo "${text} ${text//?aa} ${text//\aaa}"
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/21/12 12:43 PM, Mike Frysinger wrote:
> first set your locale to something unicode based:
> export LC_ALL=en_US.UTF-8
>
> then try the simple script (from Ulrich Müller):
> $ cat test.sh
> shopt -s extglob
> text="aaaä
first set your locale to something unicode based:
export LC_ALL=en_US.UTF-8
then try the simple script (from Ulrich Müller):
$ cat test.sh
shopt -s extglob
text="aaaäöü"
echo "${text} ${text//?aa} ${text//\aaa}"
with bash-4.1_p2, i get:
aaaäöü äöü äöü
but with bash-4.2_p8 ..
1 - 100 of 136 matches
Mail list logo
