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

Re: non-blocking stdin from bash



On Mon, Aug 13, 2018 at 10:34:40AM -0400, Jim Popovitch wrote:
> On Mon, 2018-08-13 at 08:59 -0400, Greg Wooledge wrote:
> > On Sat, Aug 11, 2018 at 06:08:34PM -0400, Jim Popovitch wrote:
> > > What's the best way to grab anything that's in stdin into a
> > > variable inside a bash script, but won't block if stdin is null?
> > 
> > On Sun, Aug 12, 2018 at 01:57:09PM -0400, Jim Popovitch wrote:
> > > Interesting.  I'm using it via a cron script like so:
> > > 
> > > * * * * *  grep "unusual" /opt/logs/* | /opt/notify.sh `hostname`;
> > 
> > On Sun, Aug 12, 2018 at 06:45:23PM -0400, Jim Popovitch wrote:
> > > That was just an example of what I'm doing.  In reality logtail's
> > > in there, but it made the example line too long.
> > 
> > https://mywiki.wooledge.org/XyProblem
> > https://mywiki.wooledge.org/BashFAQ/064
> 
> Come on, that's not warranted.... or you just like posting links to you
> own site.  smh.

It's absolutely warranted.  You changed the question, and then you changed
the question AGAIN.

The original question was about testing whether stdin has input characters
AVAILABLE, for which the feature "read -t 0" was added in bash version 4.0.

But then the question mutated, and there was no longer any need to probe
for input characters to avoid blocking, because you were simply reading
from a piped grep.

But then the question mutated AGAIN, and in this THIRD version of the
question, there is something called "logtail" involved, and I have no
idea what that even IS, or how it affects the pipeline.  One may speculate
that it works something like "tail -f" or "tail -F", in which case we
are BACK TO THE ORIGINAL QUESTION.  Maybe.  But we can't be sure, since
not only is this a nonstandard tool, but you didn't show or describe
how it's being used.

So, yeah.  It's warranted.  Idiot.


Reply to: