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

[Eli Schwartz]

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 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

signature.asc
Description: OpenPGP digital signature