Re: How to test if stdin is empty, if not empty print to stdout, otherwise do something else.

[Peng Yu]

On Wed, Mar 25, 2020 at 10:23 AM Eli Schwartz <address@hidden>
wrote:

> On 3/25/20 10:08 AM, Peng Yu wrote:
> >> The problem with this thread, as with all of Peng Yu's threads, is that
> >> nobody knows what the actual GOAL is.  Peng Yu will never reveal the
> goal,
> >> either, no matter how many times you ask.
> >
> > I have emailed you before. The goal does not matter.
>
> There are some people who can get away with saying "the goal does not
> matter", but you are not one of them.
>
> The problem is that you keep on asking extremely stupid


Sorry. I don’t reply emails like this. Chet knows that I have discovered
several bugs related to bash.

questions that
> make no sense, which could be asking about several different things. Due
> to your inability to ASK GOOD QUESTIONS, we are left with the need (in
> every one of your threads) to know what your actual goal is, so that we
> can figure out what your real question was.
>
> This is actually not an uncommon issue. Many people aren't very talented
> at asking good questions. But most of those people have the good grace
> to fill in that gap by explaining their actual use case. This lets
> people like Greg analyze their issue, explain to them, "all you need to
> care about is XXX, and this is how you can do it", and everyone walks
> away happy.
>
> You, however, due to some surprising combination of paranoia and
> secretiveness, refuse to provide EITHER your goal, OR a complete example
> that serves as a mockup of your goal.
>
> >> I can think of at least two possible goals which might drive someone to
> >> ask how to test whether stdin has input available.
> >
> > Thanks for your suggestion. However, I only use stdin to take input
> > data whenever possible. And I don't want to add an additional switch
> > to tell the program whether the input contains data or not as it is
> > redundant to add such a switch when the information whether the input
> > is empty is contained in the input itself.
> >
> >> (1) "I want to write a utility that can either take data as an argument,
> >>     or read data from stdin.  I want it to do the correct thing
> >>     automatically, without having to pass a --stdin option or whatever."
> >>
> >>     In this case, the test is simply reversed.  Don't try to test
> whether
> >>     stdin has input available.  Test whether an argument was passed.
> >>
> >>     thing() {
> >>       if [[ $1 ]]; then
> >>         stuff "$1"
> >>       else
> >>         local in
> >>      in=$(cat; printf x)
> >>      in=${in%x}
> >>      # Or, in=$(cat) if you want to strip newlines.  Or, read -r in if
> >>      # you only want one line of input, with newline stripped.
> >>      stuff "$in"
> >>       fi
> >>     }
> >>
> >> (2) "I'm writing an keyboard-event-driven user interface that should
> handle
> >>     keyboard presses whenever they occur, but should not block to wait
> for
> >>     them."
> >
> > This is not relevant to my goal.
>
> Up above you falsely claimed that your goal does not matter. Now, here,
> you claim that a suggestion does not help because it isn't relevant to
> your goal.
>
> You cannot have it both ways: either your goal matters, or it doesn't
> matter.
>
> The only remaining question is whether you are maliciously lying, or
> simply a fool.
>
> ...
>
> Now, if you want to get help, tell us what your goal is. Provide an
> example use case where you'd use the input, which informs us of the
> constraints the data has.
>
> --
> Eli Schwartz
> Arch Linux Bug Wrangler and Trusted User
>
> --
Regards,
Peng