Re: regex string ">(...)" in [[ ]] command recognize as process substitution

2022-10-31 Thread Chet Ramey
On 10/31/22 1:31 AM, Hyunho Cho wrote: # this is an error # [[ ]] command recognizes ">(.*)" as process substitution. bash$ [[ $val =~ ((.*)<[^>]*>(.*)) ]] && echo yes # Error ! bash$ .*: command not found Yes, process substitution is one of the word expansions the pattern undergoes (all

Re: Function declarations produce no trace nor trigger debug trap while having side effects

2022-10-31 Thread Chet Ramey
On 10/28/22 12:09 PM, Erik Adelbert wrote: Hello Chet and other bash maintainers, Thanks for your time. On 27 Oct 2022, at 23:26, Chet Ramey > wrote: we believe the current semantic to be at least unclear and would like to see either: 0 the DEBUG trap called

Re: local/typeset/declare -p - outputs invalid declare -- -

2022-10-31 Thread Alex fxmbsw7 Ratchev
On Mon, Oct 31, 2022, 18:31 Greg Wooledge wrote: > On Mon, Oct 31, 2022 at 06:12:14PM +0100, Alex fxmbsw7 Ratchev wrote: > > hi , sorry.. whats the purpose of local - > > informational question > > a. Since there is no `declare -' equivalent of `local -', make sure to use >`local -' in the

Re: local/typeset/declare -p - outputs invalid declare -- -

2022-10-31 Thread Greg Wooledge
On Mon, Oct 31, 2022 at 06:12:14PM +0100, Alex fxmbsw7 Ratchev wrote: > hi , sorry.. whats the purpose of local - > informational question a. Since there is no `declare -' equivalent of `local -', make sure to use `local -' in the output of `local -p'. - s. The `local' builtin takes a

Re: Multiline editing breaks if the previous output doesn't end in newline

2022-10-31 Thread Alex fxmbsw7 Ratchev
where the cursor is ? some tput ansi code returns it .. but i guess u mean bigger compatibility problems does, readline, export its cursor assumptations ? like for dev'ing On Mon, Oct 31, 2022, 16:46 Chet Ramey wrote: > On 10/30/22 9:40 PM, Oğuz wrote: > > > Yeah, or add a new prompt sequence

Re: local/typeset/declare -p - outputs invalid declare -- -

2022-10-31 Thread Alex fxmbsw7 Ratchev
hi , sorry.. whats the purpose of local - informational question On Mon, Oct 31, 2022, 17:45 Emanuele Torre wrote: > Since bash 5.2, local/typeset/declare -p without argument no longer > outputs "declare -- -" when local - is used. > > But local/typeset/declare -p - still outputs "declare

local/typeset/declare -p - outputs invalid declare -- -

2022-10-31 Thread Emanuele Torre
Since bash 5.2, local/typeset/declare -p without argument no longer outputs "declare -- -" when local - is used. But local/typeset/declare -p - still outputs "declare -- -" instead of "local -". bash-5.1$ a () { local -; local -p; declare -p -; typeset -p -; local -p - ;} bash-5.1$

Re: bash "extglob" needs to upgrade at least like zsh "kshglob"

2022-10-31 Thread Chet Ramey
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

Re: bash "extglob" needs to upgrade at least like zsh "kshglob"

2022-10-31 Thread Chet Ramey
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

Re: bash "extglob" needs to upgrade at least like zsh "kshglob"

2022-10-31 Thread Chet Ramey
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

Re: bash "extglob" needs to upgrade at least like zsh "kshglob"

2022-10-31 Thread Chet Ramey
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

Re: Multiline editing breaks if the previous output doesn't end in newline

2022-10-31 Thread Chet Ramey
On 10/30/22 9:40 PM, Oğuz wrote: Yeah, or add a new prompt sequence (e.g. \N) that prints a newline only if the cursor is not at column 0. There is no portable way to determine this. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' -

Re: Multiline editing breaks if the previous output doesn't end in newline

2022-10-31 Thread Chet Ramey
On 10/28/22 8:21 AM, Albert Vaca Cintora wrote: Machine: All archs OS: All OSes Bash Version: All versions since I have memory Description: When there's leftover output before the prompt (ie: when the previous command output doesn't end in a new line), editing a multi-line command from

Re: Subsequent Here Doc/String Never Evaluated in Process Substitution

2022-10-31 Thread Chet Ramey
On 10/28/22 6:37 AM, ad...@nosuck.org wrote: Thank you for the awesome shell.  I noticed the following after upgrading from 5.1.16-3 to 5.2.2-2 on Fedora.  It actually resulted in a minor amount of data loss. Thanks for the report. I believe this was fixed a couple of weeks ago as the result

Re: bash "extglob" needs to upgrade at least like zsh "kshglob"

2022-10-31 Thread Oğuz İsmail Uysal
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

Re: bash "extglob" needs to upgrade at least like zsh "kshglob"

2022-10-31 Thread Greg Wooledge
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