[lug] Bash Scripting Ping

D. Stimits stimits at comcast.net
Sun Nov 8 12:44:11 MST 2020


>     On 11/08/2020 12:34 PM Jeffrey S. Haemer <jeffrey.haemer at gmail.com> wrote:
> 
> 
>     D.,
> 
>     I absolutely get this. It's what entertains me, too.
> 
>     I am, however, still looking for a way to reproduce the problem so I can answer for real instead of making stuff up that I'm "sure will work." I am pathetically good at fooling myself. :-)
> 
Perhaps you are my long lost twin (I'm probably the "evil" one)...

>     I just googled for ping options and can't find "-D" or "-O" in Linux, either. Can you give me a different, concrete command to illustrate the problem, which I can think about and play with instead?
> 
You can just use ping without any options. The "D" adds a time, the "O" just guarantees no two pings will be outstanding at the same time. A sample ping might be:
[1604863335.214753] 64 bytes from 127.0.0.1: icmp_seq=8932 ttl=254 time=7.54 ms

Note that "[1604863335.214753]" is just a time in microseconds. Actual time can be found via:
date --date='@1604863335.214753'
...which replies with:
Sun Nov 8 12:22:15 MST 2020

The example would be just as good even without the extra date stamp, the "-D" option. You can entirely ignore the "-O" option as it will not change output...it merely implies a second ping won't go out until the fate of the first ping is known (and most of the time this is not going to occur anyway).

>     [1604863335.214753] 64 bytes from 96.120.12.233: icmp_seq=8932 ttl=254 time=7.54 msAlso, what ping are you working with that has these options? You have me curious.
> 
>     On Sun, Nov 8, 2020 at 12:26 PM D. Stimits < stimits at comcast.net mailto:stimits at comcast.net > wrote:
> 
>         > >         > On 11/08/2020 12:18 PM Steve Sullivan < steve.sullivan at mathcom.com mailto:steve.sullivan at mathcom.com > wrote:
> >         >
> >         > 
> >         > This would be easy in python3 ... or many other languages.
> >         > Is bash the only possible route?
> > 
> >         Yes, I am interested in the "bash" way to do this. I can do this in other languages, but it just seems to stick to my brain that I want to know how to tokenize a text stream in bash without waiting for the infinite text stream to end. I just thought that if I understood doing this in bash I might have found something interesting about the language after years of boredom with it. I guess I'm still trying to entertain myself with things most people are not entertained by.
> > 
> >         > For example ...
> >         >
> >         > === testa.py ===
> >         > #!/usr/bin/env python3
> >         >
> >         > import subprocess, sys
> >         >
> >         > fin = sys.stdin
> >         > line = ''
> >         > while True:
> >         >   chr = fin.read(1)
> >         >   if chr == '\n':
> >         >     subprocess.run('echo The line is: \'' + line + '\'', shell=True)
> >         >     line = ''
> >         >   else: line += chr
> >         >
> >         >
> >         >
> >         > === Test it:
> >         > chmod u+x testa.py
> >         > seq 101 103 | ./testa.py
> >         > pinghttp://google.com | ./testa.py
> >         >
> >         >
> >         > Steve
> >         >
> >         >
> >         > On Sun, Nov 08, 2020 at 11:50:18AM -0700, D. Stimits wrote:
> >         > >
> >         > > >
> >         > > >     How's Jed's suggestion different from what you need?
> >         > > >
> >         > > A single ping is a single line of text, followed by termination of the process providing the text. I am interested in parsing sections of a continuous, never ending string of text whenever a newline is found. Each newline providing a "token" to process, but the text stream never ending.
> >         > >
> >         > > How do I trigger something to occur on a subset of a continuous string of text delimited by newlines without actually ending that continuous source of a text stream? That is the brain teaser, to arbitrarily pick and process subsets of a continuous stream of characters in bash. It does not need to be "ping", that is just the case that is puzzling me.
> >         > >
> >         > > Perhaps an updated pseudo code:
> >         > > stream = `ping` # ping never ends, but embeds newlines.
> >         > > while (stream.subset_token_via_newline); do
> >         > > do stuff with newline delimited token, not interrupting the stream;
> >         > > done
> >         > >
> >         > > Versus:
> >         > > while (true); do
> >         > > token = something_generating_a_single_token;
> >         > > do something with token;
> >         > > done
> >         > >
> >         > > >     Best regards,
> >         > > >     kh
> >         > > >
> >         > > >
> >         > > >     On 9 November 2020 02:27:21 GMT+08:00, "D. Stimits" < stimits at comcast.net mailto:stimits at comcast.net > wrote:
> >         > > >
> >         > > >         > >
> >         > > > >
> >         > > > >             > > > On 11/08/2020 11:21 AM Jed S. Baer < blug at jbaer.cotse.net mailto:blug at jbaer.cotse.net > wrote:
> >         > > > > >
> >         > > > > >
> >         > > > > >             On Sun, 8 Nov 2020 10:53:09 -0700 (MST)
> >         > > > > >             D. Stimits wrote:
> >         > > > > >
> >         > > > > >
> >         > > > > >                 > > > > I am curious about something in bash scripting which does not seem to be
> >         > > > > > >                 particularly easy. I wanted to script "ping -O -D address" such that each
> >         > > > > > >                 line gets processed by some logic if the ping fails. Redirecting ping to
> >         > > > > > >                 a variable does not work because it only "returns" when the ping exits
> >         > > > > > >                 (each line is not an exit). Even if I were to fork and exec, the forked
> >         > > > > > >                 process would itself have the same problem.
> >         > > > > > >
> >         > > > > > >                 Is there some simple/clever way to process each line of a ping in bash
> >         > > > > > >                 without killing off the ping itself? My goal was to send it through some
> >         > > > > > >                 database and statistics type processing as success/failure lines occur.
> >         > > > > > >
> >         > > > > > >             > > > I'm not sure of quite what you want. Is it necessary to process this in
> >         > > > > >             real time? And you say "...if ping fails", but then "... as success/failure
> >         > > > > >             lines occur."
> >         > > > > >
> >         > > > > >         > >
> >         > > > >
> >         > > > >         I'd like to know if there is a way to pipe the output of ping such that each line is equivalent to a loop iteration. Pseudo code:
> >         > > > >            while (ping text line); do
> >         > > > >               line | edit line; # e.g., substituting microseconds for date.
> >         > > > >               print edit line if conditions are met; # e.g., a few lines of fail prior to print.
> >         > > > >            done
> >         > > > >
> >         > > > >         I'm not actually concerned that this is ping so much as I am trying to figure out how a newline from a continuous command can be used to trigger a loop iteration. It has become something of a "brain teaser" for me. It is easy if the ping itself ends with a single ping. It is also easy if you run ping all day and only then process the results upon exit of ping. I am now just really curious how the newline delimited continuous output of ping can be used to trigger something else despite the continuous output itself not stopping.
> >         > > > >
> >         > > > >         >
> >         > > > >
> >         > > > >             > > > The super simple thing is a bash read loop. But you won't know the exit
> >         > > > > >             status until the ping finishes.
> >         > > > > >
> >         > > > > >             $ ping -c 3 -D -O n.n.n.n | while read LINE;
> >         > > > > >
> >         > > > > >                 > > > > do
> >         > > > > > >                 echo $LINE
> >         > > > > > >                 done
> >         > > > > > >
> >         > > > > > >             > > > Bash read will do token separation using IFS, so you could do
> >         > > > > >             | while read FIELD1 FIELD2 etc
> >         > > > > >
> >         > > > > >             Offhand, if the exit status of ping must be known before processing, then
> >         > > > > >             redirect ping output to a file, check status, then you can still do a bash
> >         > > > > >             read loop to process the file. If needed, the bash mktemp command will
> >         > > > > >             generate a unique tmp filename for your ping output.
> >         > > > > >
> >         > > > > >             --
> >         > > > > >             All operating systems suck, but Linux just sucks less
> >         > > > > >             - Linus Torvalds
> >         > > > > >             ---------------------------------------------
> >         > > > > >             Web Page: http://lug.boulder.co.us
> >         > > > > >             Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >         > > > > >             Join us on IRC:http://irc.hackingsociety.org port=6667 channel=#hackingsociety
> >         > > > > >
> >         > > > > >         > >         ---------------------------------------------
> >         > > > >
> >         > > > >         Web Page:  http://lug.boulder.co.us
> >         > > > >         Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >         > > > >         Join us on IRC:http://irc.hackingsociety.org port=6667 channel=#hackingsociety
> >         > > > >
> >         > > > >     >     _______________________________________________
> >         > > >     Web Page: http://lug.boulder.co.us
> >         > > >     Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >         > > >     Join us on IRC:http://irc.hackingsociety.org port=6667 channel=#hackingsociety
> >         > > >
> >         >
> >         > > _______________________________________________
> >         > > Web Page:  http://lug.boulder.co.us
> >         > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >         > > Join us on IRC:http://irc.hackingsociety.org port=6667 channel=#hackingsociety
> >         >
> >         >
> >         > --
> >         >
> >         > ========================================
> >         > Steve Sullivan      steve.sullivan at mathcom.com mailto:steve.sullivan at mathcom.com
> >         > 720-587-7498        http://www.mathcom.com
> >         > ========================================
> >         > _______________________________________________
> >         > Web Page:  http://lug.boulder.co.us
> >         > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >         > Join us on IRC:http://irc.hackingsociety.org port=6667 channel=#hackingsociety
> >         _______________________________________________
> >         Web Page:  http://lug.boulder.co.us
> >         Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >         Join us on IRC:http://irc.hackingsociety.org port=6667 channel=#hackingsociety
> > 
> >     > 
> 
>     --
>     Jeffrey Haemer < jeffrey.haemer at gmail.com mailto:jeffrey.haemer at gmail.com >   720-837-8908 [cell]
> 
> 
>      פרייהייט? דאס איז יאַנג דינען וואָרט!
> 
>     _______________________________________________
>     Web Page: http://lug.boulder.co.us
>     Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>     Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20201108/6aa091bd/attachment.html>


More information about the LUG mailing list