On 4/2/23 1:28 PM, Robert Elz wrote:
Date:Sun, 2 Apr 2023 17:48:24 +0200
From:Martin Schulte
Message-ID: <20230402174824.01db4d51fd4f0061fdba7...@schrader-schulte.de>
| in the following lines I consider dash's behaviour as correct
| an bash's as wrong:
All
On 4/2/23 12:54 PM, Oğuz wrote:
2 Nisan 2023 Pazar tarihinde Martin Schulte yazdı:
Hello,
in the following lines I consider dash's behaviour as correct an bash's as
wrong:
Bash expands `<()' as a process substitution. If you escape `<' or `(' it
works fine.
I am surprised that `<()' is no
On Mon, Apr 03, 2023 at 12:28:25AM +0700, Robert Elz wrote:
> bash is parsing the <() as a process substitution, producing nothing.
> The only chars in the bracket expression will then be . and [ which
> explains the result.
That does seem like a bug, to be fair.
> Try instead
>
> bash
Date:Sun, 2 Apr 2023 17:48:24 +0200
From:Martin Schulte
Message-ID: <20230402174824.01db4d51fd4f0061fdba7...@schrader-schulte.de>
| in the following lines I consider dash's behaviour as correct
| an bash's as wrong:
All other shells (even ksh93) not just dash.
I
2 Nisan 2023 Pazar tarihinde Martin Schulte yazdı:
> Hello,
>
> in the following lines I consider dash's behaviour as correct an bash's as
> wrong:
>
Bash expands `<()' as a process substitution. If you escape `<' or `(' it
works fine.
I am surprised that `<()' is not a syntax error when `()' i
Hello,
in the following lines I consider dash's behaviour as correct an bash's as
wrong:
$ uname -a
Linux martnix4 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64
GNU/Linux
$ bash--version | head -n 1
GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)
$ bash-5.2.15 --
