[lug] Bash Scripting Ping
Jeffrey S. Haemer
jeffrey.haemer at gmail.com
Sun Nov 8 12:49:22 MST 2020
Thanks!
On Sun, Nov 8, 2020 at 12:44 PM D. Stimits <stimits at comcast.net> wrote:
>
> 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> wrote:
>
>
> > On 11/08/2020 12:18 PM Steve Sullivan < 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
> > ping 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> wrote:
> > > >
> > > > > >
> > > > >
> > > > > > > > On 11/08/2020 11:21 AM Jed S. Baer <
> 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: 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: 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: 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: irc.hackingsociety.org port=6667
> channel=#hackingsociety
> >
> >
> > --
> >
> > ========================================
> > Steve Sullivan 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: 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: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
>
>
> --
> Jeffrey Haemer < 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
>
> _______________________________________________
> 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
--
Jeffrey Haemer <jeffrey.haemer at gmail.com> 720-837-8908 [cell]
*פרייהייט? דאס איז יאַנג דינען וואָרט!*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20201108/e6bf83c6/attachment-0001.html>
More information about the LUG
mailing list