I see that the mail-archive mangled my quotes
and lines a little, but you'll get what I mean.
On Sep 18, 2025, 13:55 Chet Ramey wrote:
> On 9/17/25 12:02 PM, Pourko wrote:
> > As a side question, wouldn't it make more sense if read -d"" -t 0
> > makes the read in raw mode?
>
> What would that do to change things? (I assume that you mean a non-
> blocking read; `raw mode' has historically m
On 9/17/25 11:31 AM, pou...@tutamail.com wrote:
Chet Ramey wrote:
> Why? If you're running the script from an interactive shell with job
> control enabled, the standard input and standard output will be the
> same as the parent shell.
I am kicking myself why I had to be so easily provoked by
On 9/17/25 12:02 PM, pou...@tutamail.com wrote:
As a side question, wouldn't it make more sense if read -d"" -t 0
makes the read in raw mode?
What would that do to change things? (I assume that you mean a non-
blocking read; `raw mode' has historically meant something different.)
Or is it car
Greg Wooledge wrote:
> Now, this is where I get confused about your goals. It sounds like
> you've written a program that interacts with a user via the terminal.
> If something else runs your program as a background command, then your
> program won't work. It'll be stopped when it tries to read t
Duncan Roe wrote:
> malloc: unknown:0: assertion botched
> free: underflow detected; magic8 corrupted
> Aborting...$
> [1]+ Aborted (core dumped) ./test1
>
> Maybe there is a bug in here somewhere after all.
Curiouser and curiouser! :-)
Thanks, Duncan!
As a side question, wouldn't it make more sense if read -d"" -t 0
makes the read in raw mode? Or is it carved in stone for historical
reasons? If so, then couldn't we maybe some time in the future get
a new "-T 0" option that could do a read in raw mode? Because, as
things are now, one has no way
On Wed, Sep 17, 2025 at 17:31:04 +0200, pourko--- via Bug reports for the GNU
Bourne Again SHell wrote:
> Nothing interactive in that. Now, if some other script,
> that calls my script, were to spin it off with an "&", that's when
> one of my functions gets stuck there forever. I am trying to fin
Chet Ramey wrote:
> Why? If you're running the script from an interactive shell with job
> control enabled, the standard input and standard output will be the
> same as the parent shell.
I am kicking myself why I had to be so easily provoked by some posts,
as to rewrite the examples as two separa
On 9/17/25 5:05 AM, pourko--- via Bug reports for the GNU Bourne Again
SHell wrote:
RESULTS:
./test0 finishes execution.
./test1 gets stuck after echo "RUNNING", and before echo "RETURNING".
You can look at the process status using ps and see what's going on. It's
already been covered in othe
I oversimplified my original post, so here is the CORRECTED version:
BTW, I am reproducing the problem with both bash-5.2.37 on Alpine,
and with bash-5.3.3 on Slackware.
cat <<'EOF' >./test0
#!/bin/bash
[ -t 0 ] && [ -t 1 ] || exit
echo " ==> NOTE: RUNNING."
read -d "" -t 0
echo " ==> NOTE: RETUR
11 matches
Mail list logo
