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

2022-10-30 Thread Hyunho Cho
## 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 #2

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

2022-10-30 Thread Oğuz
31 Ekim 2022 Pazartesi tarihinde Greg Wooledge yazdı: > > There's no 100% portable way to determine where the cursor is. Pity > Shells like zsh that show a special symbol in these cases use a hack > to do so. There's a good explanation in this answer: > > https://unix.stackexchange.com/questi

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

2022-10-30 Thread Oğuz
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 to

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

2022-10-30 Thread Martin D Kealey
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

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

2022-10-30 Thread Greg Wooledge
On Mon, Oct 31, 2022 at 03:40:34AM +0200, Oğuz wrote: > > Option B: Fix the line editor to take into account when the > > prompt doesn't start at column 0. > > > > > Yeah, or add a new prompt sequence (e.g. \N) that prints a newline only if > the cursor is not at column 0. There's no 100%

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

2022-10-30 Thread Oğuz
28 Ekim 2022 Cuma tarihinde Albert Vaca Cintora yazdı: > > Option A: If the previous command doesn't end in a newline, > add a newline manually. This is what most shells do. This sounds wrong. How are you going to know if the previous command ends in a newline or not then? > Op

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

2022-10-30 Thread Alex fxmbsw7 Ratchev
On Sun, Oct 30, 2022, 23:01 Dennis Williamson wrote: > > > On Sun, Oct 30, 2022 at 4:41 PM Alex fxmbsw7 Ratchev > wrote: > >> >> >> i coded a files tree to bash code via gawk reading and printing bash code >> i did noeol no newline at end >> logically , cause , who wants var='from file\n' >> >>

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

2022-10-30 Thread Dennis Williamson
On Sun, Oct 30, 2022 at 4:41 PM Alex fxmbsw7 Ratchev wrote: > > > i coded a files tree to bash code via gawk reading and printing bash code > i did noeol no newline at end > logically , cause , who wants var='from file\n' > > > > Because command substitution strips trailing newlines? $ echo -e

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

2022-10-30 Thread Alex fxmbsw7 Ratchev
On Sun, Oct 30, 2022, 21:21 Albert Vaca Cintora wrote: > On Sun, Oct 30, 2022 at 7:54 AM Martin D Kealey > wrote: > > > > This sounds like a bug in whatever is producing the output. POSIX text > files have a newline terminating every line; that description includes > streams going through pipes

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

2022-10-30 Thread Albert Vaca Cintora
On Sun, Oct 30, 2022 at 7:54 AM Martin D Kealey wrote: > > This sounds like a bug in whatever is producing the output. POSIX text files > have a newline terminating every line; that description includes streams > going through pipes and tty devices if they purport to be text. > There are many r

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

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

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

2022-10-30 Thread Alex fxmbsw7 Ratchev
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) use

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

2022-10-30 Thread Oğuz
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 n

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

2022-10-30 Thread Martin D Kealey
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 parallel