help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reading a job name from deallocated storage


From: G. Branden Robinson
Subject: Re: reading a job name from deallocated storage
Date: Fri, 4 Mar 2022 03:20:42 +1100
User-agent: NeoMutt/20180716

Hi Greg,

Thanks for the swift reply!

I'll rearrange your response.

At 2022-03-03T11:01:19-0500, Greg Wooledge wrote:
> Also, your script has a #!/bin/sh shebang.  Make sure you're actually
> running it in bash, not dash.

I thought I knew that, but I didn't.  dash inherts $SHELL from a parent
Bash, which deceived me.  Trying the "help" command uncovered the truth.

You probably have a FAQ about this.  >forehead slap<

And Bash, even the 5.0.3(1) version I have, in fact behaves precisely as
I expect--my script runs beautifully there, repeatedly.

> I'm not sure how to reproduce the issue you mentioned, but this part
> of your script stood out for a different reason.  You're running the
> assignment to 'output' as a background job, so the foreground part of
> the script is never going to see any content in the 'output' variable.

Ah, thank you.  I've always avoided job control in regression tests to
date, and try to minimize my use of it in noninteractive shells
generally.  I have therefore acquired little skill managing the many
issues that arise (lots of them race conditions).

> If you want the foreground part of a script to see the output of a
> background process, you need to redirect it to a file, or something
> equivalent.

Yes, I also generally try to avoid file creation in regression tests or
even utility scripts, because that gets me off the hook for having to
write a trap handler (which has to be done very carefully) to clean up
the files afterward in case my script is interrupted.

I know the tradition is to just say "screw it" and let temporary files
pile up, but I'm kind of non-traditional in some ways.

Thank you for the suggestions!

The script in question is very much a work in progress.  I'm rethinking
screwing with this /dev/tty stuff altogether; technically all I really
need for my regression test is a nonseekable stream that is literally
not named "-"[1], and "/dev/stdin" will do for that.

Anyway, if any dash enthusiasts are reading this, it looks like the bad
read is happening to your shell, not bash.  There are also problems, or
at least noteworthy differences, from Bash's job control, even when I
limit myself to POSIX 2018 features.

Regards,
Branden

[1] If somebody wants the background, it's at
    <https://savannah.gnu.org/bugs/?55334>.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]