bash: how to discard unwanted stdin?
 

Hello :)

Often in bash we read lines from stdin in a loop and implicitly discard the remaining stdin by terminating the loop. Is it possible to discard it without terminating the loop? It could lead to smaller code.

Here's an example which uses two loops and below is the same algorithm assuming unwanted stdin can be discarded

If I get what you meant, perhaps that can be done this way:
or the other way around
What input from route are you trying to discard by the way?

Thanks konsolebox, the second method using unit/fd numbers is elegant :)

It works without the "exec"s in the process substitution subshells too, as in done 4< <(arp) instead of done 4< <(exec arp)

EDIT: I'm only interested in the default gateway line from route output; once that is found the rest is irrelevant.

It's really just optional. I just prefer not to summon another subprocess.
You might also find this pattern helpful (just in case):

Ah, I get you; with the bare (arp) a shell will be forked into the subshell and will then fork+exec to run arp, whereas using (exec arp), a shell will be forked into the subshell and will then exec arp thus saving a fork call. One more word in the code, one less (relatively expensive) system call in the execution. Nice.

Very helpful -- experimenting with it I found my OP was solving a problem that didn't exist; bash is smart enough to save and restore "here strings" :)

First the experimental/demonstration script:The output is Thus showing that bash saved the outer "here string" when it started the inner loop and restored it when it exited the inner loop.

Taking advantage of this feature, a better version of the get_default_gateway_MAC.sh script (better = simpler and does not need process substitution so more portable):

With larger outputs we should also be careful with this method since bash will most probably (as I've found out with other shells as well) allocate all the output of route first then store it in memory. It always depends on the implementation but it doesn't hurt to be more careful.

So try not to smack me about too much, but as opposed to the question asked about discarding stdin I thought I would just give an alternative for the script:

Thanks for the perspective -- so better to use process substitution when the command output is large.

Hello grail, nice to see you passing by the thread and thanks for the alternative :)

Is that alternative functionally equivalent, though? The intention is to get the default gateway's hardware address, not its IP address. Does it handle the case where there is no "default" in the routing table? Does it set $found to indicate the validity of the address?

The default gateway's hardware address will be used by a netbook's boot script as a "good enough" way of identifying the LAN so it can do LAN-specific initialisation. Being boot script code, performance is significant so the sweet spot between coding complexity and the fork+exec count is more towards the coding side.

Your alternative is tighter and easier to maintain than mine (natch!) but will take more resources to run, which matters when booting an Atom-based system!

hmmmm ... I am guessing there must be a lot more to the code that I have not seen as my output is the same, except I have output the word found instead
of yes and not attached to a variable which I know you would have no trouble in doing.

I would be curious, and I will premiss this by saying I am no guru, about using more resources in mine than yours.
Are we saying that the use of awk is a bigger hit than the 2 while loops being iterated over?

And in answer to your questions, again from the original script presented:
I see the hardware address being obtained but not used, hence I only returned the true statement 'found'
To be honest, in its current state there is obviously no control structure, but again, a simple if can handle this.
Also I would point out that if your script hits a route with no 'default' it will exit and do nothing.
Again back to my original statement that supplying the last line as an assignment to a variable, or better yet a control, perhaps 'if', can take care of all that.

I guess my initial point was that maybe instead of discarding values we can maybe be smarter about what values we are getting?

I hope I am being constructive as I always value your opinions :) and very happy to learn

cheers
grail

Here it is in contextEDIT: the above code fails if the default gateway IP address is resolved to a name that is longer than the column width provided by the route command. The following modification solves this problem by not resolving names

Code:

---

    # Get the default gateway hardware address
    found=
    while read destination gateway _
    do
        if [[ $destination = '0.0.0.0' ]]; then
            ping -c 1 -q $gateway >/dev/null # populate ARP cache
            while read address _ hw_address _
            do
                [[ $address = $gateway ]] && found=yes && break
            done <<< "$( exec arp -n )"
        fi
    done <<< "$( exec route -n )"

---

Yes :)

fork+exec is "expensive" and bash runs fast when processing small (say < 5 kB) strings. To be sure (and to get a feel for where awk's faster processing of large amounts of text begins to outweigh the fork+exec cost) testing would be necessary. The ping would have to be removed (very slow compared to the rest of the code) and to be measurable the code would have to be put in a loop; in the case of this code I don't think there are any buffering effects that would affect the results (as there would be when doing file I/O).

All true! You ave me bang to rights guvnor, an no mistake!

Doing nothing when the routing table has no default route is intended -- this is a "convenience" facility so it's not worth analysing rc.inet1.conf to see if there should be a default route or re-running DHCP client as might be appropriate on a mission-critical, robust system.

If there was a lot of data to search then I would go with being smarter about getting the values but for the small amount of data output by the route command (on a personal netbook) I believe that trawling through it line by line until getting what is needed is faster without requiring overly complex code.

Always a pleasure to debate with you; debate is a great way to learn different ways, to see other perspectives, to increase the breadth and depth of understanding and thus become better at what we do. Just so long as you remember that I'm always right! :D :D :D

I was talking to a network guy here at work (i am still learning) and he has said that to the best of his knowledge the 'default' will never not be in the routing table
(just passing on what was said :) )

So to this end, this might help for later testing, this is the same with the changes:
Assuming my friend here is correct your last echo would never get executed, so I have left it off.

For now ... lol

That is not correct as shown by this terminal sessionThat is slightly artificial but could happen by accident. More realistically, we have had several examples here on LQ in which questioner's troubles were traced to a missing default gateway.

Regards the case statement -- yes, more cases are envisaged.