What would you suggest for reliable servers to ping for connectivity

[VPN user]

What would you suggest for reliable servers to ping for connectivity?

If the tunnel drops, the vpnstatus (aka vpnwatch) script kindly written
by Marek Novotny drops all sensitive apps, which lets me know that the
tunnel dropped.

However, if the tunnel is still up, but, for whatever reason, connectivity
is lost, then I don't find this out for minutes simply because the only
way I notice that there is no connectivity is that network commands fail
to run (e.g., a ping to anywhere would fail when the connectivity is lost).

So, I hacked out this "vpnping" script today, just to test connectivity
at random intervals to random servers, popping up a notification only
when connectivity is lost.

The current list of servers was taken from a list of public DNS servers
that I found on the net, but I would like to expand the list of potential
servers to test (to spread out the load).

My question is what *list* of reliable servers would you use to test
the connectivity to?

Here's the version 0.01 script that tests for connectivity.

#!/bin/bash
# vpnping.sh v0.01 pops up a notification if connectivity is lost

# Define variables:
maxDelay=10 # max seconds for random delay between pings
minDelay=2 # min secondsf or random delay between pings
timeout=2300 # fping timeout is in milliseconds (ping TTL is in seconds)

# Select a random server to ping for connectivity
# Code structure courtesy of Marek Novotny
# WIP: Need a better list of reliable servers to ping!
randomServer()
{
pingArray=(
"119.81.242.146" # Korea ns1.hk.dns.opennic.glue
"172.81.176.146" # ns1.tor.ca
"190.10.8.128" # ns1.cr
"192.99.240.129" # ns1.mtr.ca
"193.183.98.154" # Korea ns1.it.dns.opennic.glue
"195.46.39.39" # SafeDNS public dns server
"195.46.39.40" # SafeDNS public dns server
"208.67.220.220" # OpenDNS Home4 public dns server
"208.67.222.222" # OpenDNS Home4 public dns server
"209.244.0.3" # Level3 public dns server
"209.244.0.4" # Level3 public dns server
"216.146.35.35" # Dyn public dns server
"216.146.36.36" # Dyn public dns server
"37.235.1.174" # FreeDNS public dns server
"37.235.1.177" # FreeDNS public dns server
"4.2.2.1" # Verizon public dns server
"4.2.2.2" # Verizon public dns server
"4.2.2.3" # Verizon public dns server
"4.2.2.4" # Verizon public dns server
"4.2.2.5" # Verizon public dns server
"4.2.2.6" # Verizon public dns server
"50.116.23.211" # ns19.tx.us
"50.116.23.211" # OpenNIC dns server
"5.9.49.12" # Korea ns24.de.dns.opennic.glue
"79.133.43.124" # Korea ns3.vie.at.dns.opennic.glue
"8.20.247.20" # Comodo Secure DNS public dns server
"8.26.56.26" # Comodo Secure DNS public dns server
"8.8.4.4" # Google public dns server
"8.8.8.8" # Google public dns server
)
pingRange=$((${#pingArray[@]} - 1))
i=$RANDOM
let "i %= $pingRange"
pingIP=${pingArray[$i]}
# echo "pingIP set to $pingIP"
}

# Set up the display for the xmessage:
setupDisplay()
{
if [[ -z "$DISPLAY" ]]; then
DISPLAY=':0'
fi
}
setupDisplay

# Pop up a message if connectivity is lost:
# WIP: Do something with the buttons or remove them.
sendMessage()
{
ans=$(xmessage -display $DISPLAY -fg black -bg red \
-title "Connectivity lost!" -geom +60+30 \
-buttons yes,no -default yes "$1")
}

# Loop continuously testing random site connectivity at random intervals
while true; do # continue until a kill or Ctrl+C occurs
randomServer # select a random server to ping
sleep $[ ( $RANDOM % $maxDelay ) + $minDelay ]s # wait a random min-to-max second delay
fping -c1 -t${timeout} $pingIP 2>/dev/null 1>/dev/null # ping the server
if [ $? -ne 0 ]; then # if the ping failed within the timeout, then send a message
sendMessage "Ping $pingIP failed on $(date)"
fi
done

exit 0
## End ##

[Bit Twister]

On Sun, 17 Apr 2016 04:41:31 -0000 (UTC), VPN user wrote:
>


I suggest moving pingArray out from under the function and make it global.
That way it would be loaded just once instead of every time
randomServer is called.

Any special reason you are using fping? I saw no indication that the
special program/app was required by your script.

I would think this would work
ping -c1 -w${timeout} $pingIP > /dev/null 2>&1
and is easier to read than

fping -c1 -t${timeout} $pingIP 2>/dev/null 1>/dev/null

I think your code would be easier to read if you would put a blank
line after comment before code. Also would not hurt to break up long
lines that would not print on without having to go landscape.

I would have placed the sleep after ping just to speed up the first test.
So, if you were to implement my suggestions you code would look
something like this snippet of your code.

# Loop continuously testing random site connectivity at random intervals

while true; do # continue until a kill or Ctrl+C occurs
randomServer # select a random server to ping

ping -c1 -w${timeout} $pingIP > /dev/null 2>&1 # ping the server
if [ $? -ne 0 ]; then # ping failed within timeout, send a message

sendMessage "Ping $pingIP failed on $(date)"
fi

sleep $[ ( $RANDOM % $maxDelay ) + $minDelay ]s # wait random min-to-max delay
done

[Dan Purgert]

Bit Twister wrote:
>
> [snip]

}
> I would think this would work
> ping -c1 -w${timeout} $pingIP > /dev/null 2>&1
> and is easier to read than
> fping -c1 -t${timeout} $pingIP 2>/dev/null 1>/dev/null

I'm hardly a pro at bash scripts, but isn't the correct command
ping -c1 -w${timeout} $pingIP 2>&1 > /dev/null

[Bit Twister]

I would hardly call myself a pro but I have the habit of
any_app > some_fn and for any other redirects after it.

Whichever one is more correct is fine by me. Down side if I am wrong I
have to change
$ grep 'dev/null 2>&1' * | wc -l
411
lines of code. :(

[VPN user]

Bit Twister wrote:

> Any special reason you are using fping?
> I saw no indication that the
> special program/app was required by your script.

I'm working on the other suggestions, but, the main reason for
using fping was that it can handle milliseconds (I originally
had it set to 300 milliseconds) while ping's timeout is only
in seconds.

There are advantages to fping over ping:
- fping was specifically designed to be used in scripts
- fping can handle any number of targets on the command line
- fping can input a file containing the lists of targets
- fping will "round robin" the list of targets (unlike ping)

FPING(8)
-t n Initial target timeout in milliseconds (default 500). In the default
mode, this is the amount of time that fping waits for a response to its
first request. Successive timeouts are multiplied by the backoff
factor.

PING(8)
-t ttl ping only.
Set the IP Time to Live.

[VPN user]

Bit Twister wrote:

> I would think this would work
> ping -c1 -w${timeout} $pingIP > /dev/null 2>&1
> and is easier to read than
> fping -c1 -t${timeout} $pingIP 2>/dev/null 1>/dev/null

Thanks for that suggestion.

The whole file-descriptor syntax confuses me to no end.

Your suggestion of combining the output of both file descriptors
(1=STDOUT, 2=STDERR) into a single stream is what I've implemented.

I'm not sure *how* to perform your other suggestions, so, I'm working
on them and will reply if/when I'm successful.

Thanks for your advice.

NOTE: I tried to use your skeleton but it would have taken far more
work so I just copied an old script to use as my template. The
skeleton is good, but it has a very steep learning curve. :(

[Marek Novotny]

On 2016-04-17, VPN user <vpn...@example.com> wrote:
> Bit Twister wrote:
>
>> I would think this would work
>> ping -c1 -w${timeout} $pingIP > /dev/null 2>&1
>> and is easier to read than
>> fping -c1 -t${timeout} $pingIP 2>/dev/null 1>/dev/null
>
> Thanks for that suggestion.
>
> The whole file-descriptor syntax confuses me to no end.
>
> Your suggestion of combining the output of both file descriptors
> (1=STDOUT, 2=STDERR) into a single stream is what I've implemented.

try this:

$ cat hello > /dev/null
cat: hello: no such file or directory

answer: stdout is redirected to /dev/null but there is no output since
there is no file called, 'hello' to cat... so all we see is the error
and the error is sent to stderr

$ cat hello > /dev/null 2>&1

answer: we see nothing at all. again as above we send stdout to
/dev/null but this time we told stderr to go where stdout is going and
stdout is going to /dev/null. so the end result is that both stdout and
stderr are going to /dev/null

You can replace /dev/null with ~/results.txt for example and capture the
output so you can see it.

$ cat hello > ~/results.txt 2>&1

Now you'll get a file called results.txt which shows you the error.

You could just use &> /dev/null by the way. That will tell stdout and
stderr to go to /dev/null

cat hello &> /dev/null

> I'm not sure *how* to perform your other suggestions, so, I'm working
> on them and will reply if/when I'm successful.
>
> Thanks for your advice.
>
> NOTE: I tried to use your skeleton but it would have taken far more
> work so I just copied an old script to use as my template. The
> skeleton is good, but it has a very steep learning curve. :(

--
Marek Novotny
https://github.com/marek-novotny

[Bit Twister]

On Sun, 17 Apr 2016 15:15:41 -0000 (UTC), VPN user wrote:
> Bit Twister wrote:
>
>> Any special reason you are using fping?
>> I saw no indication that the
>> special program/app was required by your script.
>
> I'm working on the other suggestions, but, the main reason for
> using fping was that it can handle milliseconds (I originally
> had it set to 300 milliseconds) while ping's timeout is only
> in seconds.

Snipped all the fping reasons because your code is not really using
them when compared to using ping.

Your -t delay is 2.3 seconds and I would guess anything over 2 is too
slow anyway.

I suggest you need some verbiage in script header warning that fping
is required for script operation.

Based on what your script is doing I suggest to you there is no real
requirement for fping over ping.

If the ip delay is critical, then I suggest the array entry would be
ip max_time_allowed.

That way you can parse the rtt line from a ping -c1 -w2 -q $ip and check
against $max_time_allowed to indicate fault.

[VPN user]

Bit Twister wrote:

> Snipped all the fping reasons because your code is not really using
> them when compared to using ping.

I agree that I'm only using the one feature of fping, with is that
the -t is in milliseconds, while the -w of ping is in seconds.

Actually, to make matters worse, when I originally tested ping, I
used "ping -t" which didn't work for me.

So then I switched to "fping -t".

I only realized that I should have used "ping -w" when *you* showed
that command.

In short, I had tested "ping -t" against "fping -t", and I found that
"fping -t" did what I wanted but not "ping -t" (because it should have
been "ping -w" but I didn't realize that at the time.

> Your -t delay is 2.3 seconds and I would guess anything over 2 is too
> slow anyway.

I started at 300 milliseconds, and have been getting larger and larger.
:(

The bad news is that I'm up to five seconds, and *still* some of the
sites time out.

So I had to switch the popup from a permanent popup to a temporary
popup, because it happens about forty or fifty times an hour even
when I'm on a *good* VPN connection to vpngate.

Sigh. I never realized that a ping would time out so often, when
on a seemingly good (but slow) connection (slow bing 1MB to 5MB
download speeds with 200 or 300 ms ping times).

> I suggest you need some verbiage in script header warning that fping
> is required for script operation.

I think, as you noted, that "ping -w" would work just as well as
"fping -t" does, since I'm way above the less-than-a-second mark
by now.

> Based on what your script is doing I suggest to you there is no real
> requirement for fping over ping.

I don't disagree. I had tested the wrong ping option (-t instead of -w)
when I deprecated ping.

> If the ip delay is critical, then I suggest the array entry would be
> ip max_time_allowed.

I'm not sure what that sentence means.

> That way you can parse the rtt line from a ping -c1 -w2 -q $ip and check
> against $max_time_allowed to indicate fault.

I'll have to research that because I am unfamiliar with the terms but
I suspect it's from the ping manpage so I'll parse that suggestion
mentally.

[Bit Twister]

On Sun, 17 Apr 2016 19:56:05 -0000 (UTC), VPN user wrote:
> Bit Twister wrote:
>
>
> I'm not sure *how* to perform your other suggestions, so, I'm working
> on them and will reply if/when I'm successful.

Just move the ip array up under the delay arguments at top of code.

>
> NOTE: I tried to use your skeleton but it would have taken far more
> work so I just copied an old script to use as my template. The
> skeleton is good, but it has a very steep learning curve. :(

Nothing wrong with having a simple_bash_skeleton :)

#!/bin/bash
#*********************************************
#*
#*********************************************
export PATH="\
/usr/local/sbin:/usr/sbin:/sbin\
:/usr/local/bin:/usr/bin:/bin\
"
set -u

_exe=$0
_app=$(basename $0)

_usage=$(
cat <<-EOF

$_exe [OPTIONS]

-h usage help
-l LOG_FN File name for log output
-t will preform pre-install tests
EOF
)


function usage ()
{
echo " "
echo "Usage: $_usage"
echo " "
exit 0
} # end function usage

#******************************
#* command line argument check
#*******************************

#*******************************************
#* Main code starts here
#*******************************************


#***************end whatever ******************************

[Bit Twister]

On Sun, 17 Apr 2016 20:56:26 -0000 (UTC), VPN user wrote:
> Bit Twister wrote:
>

>> If the ip delay is critical, then I suggest the array entry would be
>> ip max_time_allowed.
>
> I'm not sure what that sentence means.

It means if you want a failure message for any given ip address when
the time exceeds a max time limit you would have a value with each ip
address.

>> That way you can parse the rtt line from a ping -c1 -w2 -q $ip and check
>> against $max_time_allowed to indicate fault.
>
> I'll have to research that because I am unfamiliar with the terms but
> I suspect it's from the ping manpage so I'll parse that suggestion
> mentally.

Just run
ping -c1 -w1 -q yahoo.com
ping -c1 -w1 -q yahoo.com | grep rtt

[VPN user]

Here is version 2 with some of the earlier updates
(but not all of them)...

a. I changed the fping to a ping (and upped it to 5 seconds)
b. I added a log file so I could tell which sites fail the most
c. I stamped the log file with the assumed VPN IP address
d. At the same time, I added vpnping to the list of sensitive apps
for Marek's vpnstatus script to kill if the tunnel goes down.
e. I changed the location of the popup and made it temporary
because it was (and is) popping up 50 times an hour.
f. I moved the pingarray so that it's outside the randomizer function

What needs to be done is:
A. Add all suggestions from this newsgroup
B. Create a better (more reliable) list of servers
C. Figure out why the ping fails so often while on VPN

#!/bin/bash
# vpnping.sh v02 pops up a temporary notification if connectivity is lost

# Define variables:
pingLog=/tmp/vpnping.log
maxDelay=20 # maximum random delay, in seconds
minDelay=2 # minimum random delay, in seconds
timeout=5 # fping "-t" timeout is in milliseconds (ping "-w" is in seconds)

# Stamp the log file with the VPN address without requiring an Internet connection:
vpnRoute=$(route -n \
| grep -v ^"0.0.0.0" \
| grep -v ^"10.211.1." \
| grep -v ^"192.168.1.0" \
| grep -v ^"128.0.0.0" \
| grep -v ^Kernel \
| grep -v ^Destination \
| awk '{print $1}')
echo $vpnRoute >> $pingLog
echo "Stamping log file for IP $vpnRoute"

# Select a random server to ping for connectivity

# WIP: Need a better reliable list of servers to ping
pingArray=(
"google.com" # google.com
"linksys.com" # linksys.com
"cisco.com" # cisco.com
"ubuntu.com" # ubuntu.com
"dictionary.com" # dictionary.com
"109.69.8.51" # puntCAT Public DNS Server
"119.81.242.146" # Korea ns1.hk.dns.opennic.glue
"156.154.71.1" # DNS Advantage Public DNS Server
"192.99.240.129" # OpenNIC Public DNS Server

"193.183.98.154" # Korea ns1.it.dns.opennic.glue
"195.46.39.39" # SafeDNS public dns server
"195.46.39.40" # SafeDNS public dns server

"199.85.127.10" # Norton ConnectSafe Public DNS Server

"208.67.220.220" # OpenDNS Home4 public dns server
"208.67.222.222" # OpenDNS Home4 public dns server

"208.76.51.51" # SmartViper Public DNS Server
"209.244.0.3" # Level 3 DNS Server
)

# Define a routing to select a random server from the list above:
randomServer()
{

pingRange=$((${#pingArray[@]} - 1))
i=$RANDOM
let "i %= $pingRange"
pingIP=${pingArray[$i]}
}

# Set up the display for the xmessage popup:

setupDisplay()
{
if [[ -z "$DISPLAY" ]]; then
DISPLAY=':0'
fi
}
setupDisplay

# Pop up a temporary message at bottom right if connectivity is lost:
sendMessage()
{
xmessage \

-display $DISPLAY \
-fg black \
-bg red \

-title "${title}" \
-geom -60-30 \
-timeout 4 \
-buttons OK:1 \
-default OK "$1"

}

# Loop continuously testing random site connectivity at random intervals
while true; do # continue until a kill or Ctrl+C occurs

randomServer # select a new random server to ping
sleep $[ ( $RANDOM % $maxDelay ) + $minDelay ]s # random min-to-max second delay
#fping -c1 -t${timeout} $pingIP > /dev/null 2>&1 # t is in ms
ping -c1 -w${timeout} $pingIP > /dev/null 2>&1 # w is in seconds

if [ $? -ne 0 ]; then

echo "$pingIP failed at $(date)" >> $pingLog
title="${0##*/} Ping Failed"
sendMessage "$pingIP failed at $(date)"
else
echo "$pingIP OK at $(date)"
echo "$pingIP OK at $(date)" >> $pingLog

[Bit Twister]

On Sun, 17 Apr 2016 21:13:30 -0000 (UTC), VPN user wrote:
>
> #!/bin/bash
> # vpnping.sh v02 pops up a temporary notification if connectivity is lost

Not all your users maybe running as root. Take for example
$ type route
route is /sbin/route

Normal users would not have that in their path.

I would suggest adding a PATH statement to your scripts as a matter of habit.

#!/bin/bash
#**********************************************
#*
#**********************************************

set -u

[VPN user]

Bit Twister wrote:

> Not all your users maybe running as root. Take for example
> $ type route
> route is /sbin/route
>
> Normal users would not have that in their path.
>
> I would suggest adding a PATH statement to your scripts as a matter of habit.
>
> #!/bin/bash
> #**********************************************
> #*
> #**********************************************
>
> set -u
> export PATH="\
> /usr/local/sbin:/usr/sbin:/sbin\
> :/usr/local/bin:/usr/bin:/bin\
> "

Interesting. I never thought of that, although I did see similar
path lines in your "skeleton" that I wondered how important they were.

I don't think I've ever consciously touched my path, so, it should be
as close to the default as possible (I don't know though).

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

I don't have a clue what's in "games", since I don't play them, so,
even my path is a bit too long.

But it makes sense to have the same path for all users in a script:

Here's your suggested path:

export PATH="\
/usr/local/sbin:\
/usr/sbin:\
/sbin:\
/usr/local/bin:\
/usr/bin:\
/bin\
"

I'm not sure how it's any different, functionally, than mine, but, if
I drop the gaming stuff, mine would become:

export PATH="\
/usr/local/sbin:\
/usr/local/bin:\
/usr/sbin:\
/usr/bin:\
/sbin:\
/bin:\
"

Clearly they're slightly different; but do you see any problem with the
order?

[VPN user]

Bit Twister wrote:

> Nothing wrong with having a simple_bash_skeleton

That's a *lot* easier to digest, for the first time coder!

Thanks.

[VPN user]

Marek Novotny wrote:

> try this:

That helped a lot.

I've added it to my bash help file (which I refer to constantly).

Thanks.

[Bit Twister]

On Mon, 18 Apr 2016 01:10:05 -0000 (UTC), VPN user wrote:
> Bit Twister wrote:
>
>> Not all your users maybe running as root. Take for example
>> $ type route
>> route is /sbin/route
>>
>> Normal users would not have that in their path.
>>
>> I would suggest adding a PATH statement to your scripts as a matter of habit.
>>
>> #!/bin/bash
>> #**********************************************
>> #*
>> #**********************************************
>>
>> set -u
>> export PATH="\
>> /usr/local/sbin:/usr/sbin:/sbin\
>> :/usr/local/bin:/usr/bin:/bin\
>> "
>
> Interesting. I never thought of that, although I did see similar
> path lines in your "skeleton" that I wondered how important they were.

Well, you get to decide how important it is to the operation of your script.

When the shell has to go looking for an application order matters
because it hunts in each directory in order the directory is declared
in $PATH.

> I don't think I've ever consciously touched my path, so, it should be
> as close to the default as possible (I don't know though).
>
> $ echo $PATH
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
>
> I don't have a clue what's in "games", since I don't play them, so,
> even my path is a bit too long.

But that is where "fortune" is located. :)

> But it makes sense to have the same path for all users in a script:

And better yet, checkout what PATH looks like in a cron job/script
grep PATH= /etc/crontab

> Here's your suggested path:
> export PATH="\
> /usr/local/sbin:\
> /usr/sbin:\
> /sbin:\
> /usr/local/bin:\
> /usr/bin:\
> /bin\
> "

Well, yes and no this is what I had

export PATH="\
/usr/local/sbin:/usr/sbin:/sbin\
:/usr/local/bin:/usr/bin:/bin\
"

Yes functionally, your format of my PATH is same as mine, but in mine
the first row was "root" stuff, and the second was "user" stuff. :)
That is why I wrote it that way. :-)

> I'm not sure how it's any different, functionally, than mine, but, if
> I drop the gaming stuff, mine would become:
>
> export PATH="\
> /usr/local/sbin:\
> /usr/local/bin:\
> /usr/sbin:\
> /usr/bin:\
> /sbin:\
> /bin:\
> "
>
> Clearly they're slightly different; but do you see any problem with the
> order?

Sine I have always seen root's path with *sbin before *bin I'll stick
with my suggested PATH.

As for the "skeleton" PATH, I want my "cron" PATH pretty close to my
"desktop/interactive" PATH.

The skeleton's kde and qt stuff lets me have hooks into the desktop
environment. My main use there is for running my switch_desktop script.

I have my desktop shorts switching to desired desktop just to keep the
clutter down. Current count of open terminals
$ ps aux | grep xterm | wc -l
13
spread across desktops
$ env | grep _desktop= | sort -V -t '=' --key=2
_login_desktop=1
_binaries_desktop=2
_usenet_desktop=3
_browsing_desktop=4
_root_desktop=5
_users_desktop=6
_bank_desktop=7
_mail_desktop=8

[Bit Twister]

But that is somewhat of a dis-service. That header should have all the
subsections as a guide for what should be in each script.

Take your script for instance. You header does not indicate what
special app(s) need to be installed, for instance xmessage.

Speaking of which, some controversy between using if [[ ...]] and [..].

That is why my skeleton had

if [ -z ${DISPLAY:-""} ] ; then # probably running in cron/batch.
export DISPLAY=:0 # set DISPLAY to allow xmessage pop ups
fi

[Dan Purgert]

VPN user wrote:
>
> [snip]

>
> I don't have a clue what's in "games", since I don't play them, so,
> even my path is a bit too long.

your fortune files for one - used by "fortune" and "cowsay", among other
things.

--
Registered Linux user #585947

[VPN user]

Dan Purgert wrote:

>> I don't have a clue what's in "games", since I don't play them, so,
>> even my path is a bit too long.
>
> your fortune files for one - used by "fortune" and "cowsay", among other
> things.

Looks like I have neither ... :)

$ cowsay
The program 'cowsay' is currently not installed. You can install it by typing:
sudo apt-get install cowsay

$ fortune
The program 'fortune' is currently not installed. You can install it by typing:
sudo apt-get install fortune-mod

But there is a lot of junk in there that I'll never use:

$ ls /usr/games/
adventure boggle dab hangman number quiz snake wargames
arithmetic caesar espdiff hunt phantasia rain snscore worm
atc canfield gnome-sudoku kpat pig random sol worms
backgammon cfscores go-fish mille pom robots teachgammon wtf
battlestar countmail gomoku monop ppt rot13 tetris-bsd wump
bcd cribbage hack morse primes sail trek

$ ls /usr/local/games
$

[VPN user]

Bit Twister wrote:

> Take your script for instance. You header does not indicate what
> special app(s) need to be installed, for instance xmessage.

I actually don't know what programs are "special" and which programs
are "default". I think I only have default programs on my system,
so I "think" that xmessage is normal, but I certainly do realize
that there are many flavors of linux out there, so I appreciate the
advice to list the programs needed.

The commands & default variables used by the script are (in order):
export
route -n
RANDOM
let
if ... else ... fi
xmessage
while
sleep
ping
exit

Is there a command that tells me which of these are installed by
default? (probably not).

> Speaking of which, some controversy between using if [[ ...]] and [..].

I had not even noticed the double square brackets until you mentioned that.

$ which [
/usr/bin/[

$ /usr/bin/[
/usr/bin/[: missing ']'

$ help '['
[: [ arg... ]
Evaluate conditional expression.
This is a synonym for the "test" builtin, but the last argument must
be a literal `]', to match the opening `['.

So it seems the first square bracket is actually an alias to the command
"test", while the second square bracket just ends the "test" command.

Googling further for the difference between [ and [[, I find:
https://serverfault.com/questions/52034/what-is-the-difference-between-double-and-single-square-brackets-in-bash

Apparently, from reading that article, the "[[" turns on "magic" which
makes it easier to use special characters, as in:
$ [ a < b ] # the "<" means redirect
$ [[ a < b ]] # the "<" means less than

> That is why my skeleton had
>
> if [ -z ${DISPLAY:-""} ] ; then # probably running in cron/batch.
> export DISPLAY=:0 # set DISPLAY to allow xmessage pop ups
> fi

I must admit I stole that section, verbatim, from Marek's scripts:

setupDisplay()
{
if [[ -z "$DISPLAY" ]]; then
DISPLAY=':0'
fi
}
setupDisplay

I only use a single desktop, but from Marek's context, I assume that people
with multiple desktops would want the xmessage to pop up on the current
desktop.

I assume, from your context, that you're allowing the program to run in
a crontab batch run (where there is no desktop).

If your syntax is more general than Marek's, I'm fine by that.
So I've swapped the two out to make the script more general.

[VPN user]

VPN user wrote:

> Apparently, from reading that article, the "[[" turns on "magic" which
> makes it easier to use special characters, as in:
> $ [ a < b ] # the "<" means redirect
> $ [[ a < b ]] # the "<" means less than

Reading further, I find that the [[ is only understood in bash & korn,
so, I see why it's probably better to use [ for portability.

Thanks for the advice.

[Bit Twister]

On Mon, 18 Apr 2016 12:04:07 -0000 (UTC), VPN user wrote:
> Bit Twister wrote:
>
>> Take your script for instance. You header does not indicate what
>> special app(s) need to be installed, for instance xmessage.
>
> I actually don't know what programs are "special" and which programs
> are "default". I think I only have default programs on my system,
> so I "think" that xmessage is normal,

I stand corrected. Just checked several distributions and they all had
xmessage installed. Guessing I was testing a Mandriva or Mageia
pre-release which did not have it installed by default.

> but I certainly do realize that there are many flavors of linux out
> there, so I appreciate the advice to list the programs needed.

I was not suggesting a list of programs needed, just any that you had
to install after a clean install.

[Marek Novotny]

On 2016-04-18, Bit Twister <BitTw...@mouse-potato.com> wrote:
> On Mon, 18 Apr 2016 12:04:07 -0000 (UTC), VPN user wrote:
>> Bit Twister wrote:
>>
>>> Take your script for instance. You header does not indicate what
>>> special app(s) need to be installed, for instance xmessage.
>>
>> I actually don't know what programs are "special" and which programs
>> are "default". I think I only have default programs on my system,
>> so I "think" that xmessage is normal,
>
> I stand corrected. Just checked several distributions and they all had
> xmessage installed. Guessing I was testing a Mandriva or Mageia
> pre-release which did not have it installed by default.

You were before. It is not always there. I don't remember which distro
didn't have it. Might have been rhel 6.x or 7.x. I have absolutely run
into distros that don't have it by default.

>> but I certainly do realize that there are many flavors of linux out
>> there, so I appreciate the advice to list the programs needed.
>
> I was not suggesting a list of programs needed, just any that you had
> to install after a clean install.
>

[VPN user]

Sn!pe wrote:

> May I ask, please, why you require a
> collection of free VPNs to access Usenet?

Oh geez. The stink is still following...

I know you from a.f.n to be a sock of the troll TOSEM,
where you ruin any thread you participate in and don't
believe *any* answer because of your wacko conspiracy
theories.

Then you morph and argue with yourself, as you will
almost certainly do here.

That you have absolutely no idea what the problem set
entails for the vpn servers we employ is obvious, yet
you persist with your trolling.

This is my last message to you in this ng because I will
plonk you now, as I've fed you far more than enough in
a.f.n on that very same question, yet you persist in your
wacko conspiracy theories. Besides, I don't wish to fall
into the trap of arguing that Mark Twain so aptly warned
against where you take the answer and turn it into a
Monty Python skit of your own creation.

Run along now.

[Jasen Betts]

On 2016-04-18, Marek Novotny <marek....@marspolar.com> wrote:
> On 2016-04-18, Bit Twister <BitTw...@mouse-potato.com> wrote:
>> On Mon, 18 Apr 2016 12:04:07 -0000 (UTC), VPN user wrote:
>>> Bit Twister wrote:
>>>
>>>> Take your script for instance. You header does not indicate what
>>>> special app(s) need to be installed, for instance xmessage.
>>>
>>> I actually don't know what programs are "special" and which programs
>>> are "default". I think I only have default programs on my system,
>>> so I "think" that xmessage is normal,
>>
>> I stand corrected. Just checked several distributions and they all had
>> xmessage installed. Guessing I was testing a Mandriva or Mageia
>> pre-release which did not have it installed by default.
>
> You were before. It is not always there. I don't remember which distro
> didn't have it. Might have been rhel 6.x or 7.x. I have absolutely run
> into distros that don't have it by default.

I've too have encountered installs without it, but on Debian 8 it's a
dependancy of "xorg"



--
\_(ツ)_

[Bit Twister]

On Tue, 19 Apr 2016 03:13:44 -0000 (UTC), VPN user wrote:
> Sn!pe wrote:
>
> Oh geez. The stink is still following...

Please do not feed the troll.

[VPN user]

Bit Twister wrote:

> Please do not feed the troll.

I apologize. My OCD kicked in and I felt I *had* to respond to the troll.

You are correct; I should have plonked the troll and moved on instead of
replying and then putting the troll in my killfile for this ng.

The troll has no clue the main issue we face with this free VPN server
which is designed explicitly to foil censors.

I will plonk this *entire* thread, so my OCD won't be tempted to kick
in again, so this is my *last* post to this thread forever.

[TOSEM]

Bit Twister <BitTw...@mouse-potato.com> wrote;

<nf5ipt$u2c$2...@news.mixmin.net>
you figure out yet _whom_
is trollin'.

frankly you puzzle a read with being troll'd so easily
given you posted an evaluation of VPNuser trollin'.

[Paul Derbyshire]

On 4/19/2016 5:39 PM, TOSEM wrote:
> frankly you puzzle a read
>

You have shit for brains.