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
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
2022年11月28日(月) 19:51 Koichi Murase :
> The fix for PATSCAN (C) is included in the second patch
> [r0037.patscan1.parse_subbracket.patch.txt], which solves "Repeat-By 1
> and 4" by using PARSE_SUBBRACKET of the first patch. [...]
Sorry, there was an oversight in the second patch
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 timing subshell commands
Thank you for
On 11/20/22 7:50 AM, Koichi Murase wrote:
This difference is caused because the slash after the backslash is
only checked after a matching character is found
(lib/glob/sm_loop.c:703). The same check should be applied also
before a matching character is found
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
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
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
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
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
2022年11月17日(木) 6:47 Chet Ramey :
> The cleverness is due to Russ Cox, a really smart guy who figured this
> stuff out first:
>
> https://research.swtch.com/glob
>
> (https://swtch.com/~rsc/regexp/ is a collection of his writing on regular
> expressions. It's well worth reading.)
Thank you for the
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
2022年11月1日(火) 0:59 Chet Ramey :
> If someone wanted to do this, I would take a look at incorporating the
> results, as long as it didn't add dependencies on, say, pcre or gnulib
> regex.
Instead of translating the pattern to a regular expression and
compiling it by regcomp (), I have
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 .
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 didn't
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
(possibly
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 has changed since you
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
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
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's no additional code
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 blissfully
On 10/30/22 3:25 PM, Martin D Kealey wrote:
How much faster do you think it can be made?
I don't know, irrelevant though.
The problem is not that individual steps are slow, but rather that it
takes at least a higher-order-polynomial number of steps, possibly
more (such as exponential or
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 when inversions are present;
> > (c)
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 negations (though
On Sat, 29 Oct 2022 at 22:15, Greg Wooledge wrote:
> On Sat, Oct 29, 2022 at 04:50:00PM +1100, 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
On Sat, Oct 29, 2022 at 04:50:00PM +1100, 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.
This isn't straightforward, because of the
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
##
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto
-ffat-lto-objects -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux EliteBook 5.19.0-23-generic
32 matches
Mail list logo
