On Sun, 13 Oct 2024, 17:15 Oğuz, wrote:
> On Sun, Oct 13, 2024 at 3:18 AM Chet Ramey wrote:
> > You have two processes fighting over stdin.
>
> Why though? Can't bash just close the procsub's stdin when `:' returns?
>
Of course not. The operating system won't let processes meddle with each
othe
On Okt 13 2024, Oğuz wrote:
> Why though? Can't bash just close the procsub's stdin when `:' returns?
bash has no handle on the command's stdin.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely di
On Sun, Oct 13, 2024 at 3:18 AM Chet Ramey wrote:
> You have two processes fighting over stdin.
Why though? Can't bash just close the procsub's stdin when `:' returns?
On 10/9/24 2:01 PM, Oğuz wrote:
The first letter I type after running this command won't show up on
the terminal:
: < <(cat)
This is reproducible on 5.3 beta too.
It's cat and the scheduler. You have two processes fighting over stdin.
cat inherits stdin, and successfully reads one charac
On Wed, Oct 9, 2024 at 8:02 PM Oğuz wrote:
> The first letter I type after running this command won't show up on
> the terminal:
>
> : < <(cat)
>
> This is reproducible on 5.3 beta too.
>
> Oğuz
>
>
May be your 1st char is eaten by the dangling cat(1)
>From /dev/pts/0
===
┌─none
The first letter I type after running this command won't show up on
the terminal:
: < <(cat)
This is reproducible on 5.3 beta too.
Oğuz
