Re: My script almost works but spams the terminal its launched from if useing dash.

[David Wright]

On Fri 22 Apr 2016 at 14:19:11 (+1000), Andrew McGlashan wrote:
> On 17/04/2016 3:11 AM, Aero Maxx wrote:
> >> bin/mailwatcher > /dev/null 2>&1 &
> 
> Perhaps better still...
>   bin/mailwatcher >& /dev/null &

... or even

bin/mailwatcher &> /dev/null &

which is generally safer.

> Without specifying STDOUT or STDERR you get both.
> 
> ;-)

Cheers,
David.

Re: Re: My script almost works but spams the terminal its launched from if useing dash.

[Clive Standbridge]

> > Perhaps better still...
> >   bin/mailwatcher >& /dev/null &
> > 
> I hadn't thought about that particular incantation. It is one of the
> strengths of bash (and some other shells) that there are several
> different incantations that achieve similar or same results. You get
> to speak the dialect you feel most comfortable with!!:-)

You get to write unportable scripts.


-- 
Cheers,
Clive

Re: My script almost works but spams the terminal its launched from if useing dash.

[Gene Heskett]

On Friday 22 April 2016 00:19:11 Andrew McGlashan wrote:

> On 17/04/2016 3:11 AM, Aero Maxx wrote:
> >> bin/mailwatcher > /dev/null 2>&1 &
>
> Perhaps better still...
>   bin/mailwatcher >& /dev/null &
>
> Without specifying STDOUT or STDERR you get both.
>
> ;-)
>
> AndrewM

I'll try that come next reboot Andrew, which likely won't be until a new 
kernel is made available from the linuxcnc servers. The reversed order
   bin/mailwatcher >/dev/null 2>&1 &
has been working well for several days now.  No unwanted newlines have 
been rx'd by the terminal that started it.

And the third and last of its elseif's was tested yesterday evening when 
a niece up in NYS sent me a message.  It worked correctly.  That was the 
target action. :)

Thank you AndrewM

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: My script almost works but spams the terminal its launched from if useing dash.

[Michael Milliman]

On 04/21/2016 11:19 PM, Andrew McGlashan wrote:


On 17/04/2016 3:11 AM, Aero Maxx wrote:

bin/mailwatcher > /dev/null 2>&1 &

Perhaps better still...
   bin/mailwatcher >& /dev/null &
I hadn't thought about that particular incantation.  It is one of the 
strengths of bash (and some other shells) that there are several 
different incantations that achieve similar or same results.  You get to 
speak the dialect you feel most comfortable with!!:-)



Without specifying STDOUT or STDERR you get both.

;-)

AndrewM




--
Mike

Re: My script almost works but spams the terminal its launched from if useing dash.

[Andrew McGlashan]

On 17/04/2016 3:11 AM, Aero Maxx wrote:
>> bin/mailwatcher > /dev/null 2>&1 &

Perhaps better still...
  bin/mailwatcher >& /dev/null &

Without specifying STDOUT or STDERR you get both.

;-)

AndrewM




signature.asc
Description: OpenPGP digital signature

Re: My script almost works but spams the terminal its launched from if useing dash.

[Gene Heskett]

On Monday 18 April 2016 09:49:29 David Wright wrote:

> On Sun 17 Apr 2016 at 00:41:03 (-0400), Gene Heskett wrote:
> > On Saturday 16 April 2016 22:18:34 David Wright wrote:
> > > On Sat 16 Apr 2016 at 19:06:42 (-0400), Gene Heskett wrote:
> > > > On Saturday 16 April 2016 14:02:16 Thomas Schmitt wrote:
> > > > > Gene Heskett wrote:
> > > > > > There are too many places where a conditional would be
> > > > > > needed
> > > > >
> > > > > The classic way is to use only gestures which are supported by
> > > > > the Bourne shell and to avoid certain peculiarities of some
> > > > > shells. In ./configure scripts of source packages one can see
> > > > > gestures like
> > > > >
> > > > >   if test "x${InMail}" = xgene
> > > > >
> > > > > which avoids to compare empty variable content.
> > > >
> > > > In normal everyday operation, the variable ${InMail} will not be
> > > > empty.
> > >
> > > That may or may not be a useful observation. However, sod's law
> > > dictates that when it *is* empty, it'll be in five years time when
> > > you've forgotten how and why you converted your script, and you
> > > desparately need it to work _now_.
> >
> > Each new incoming  email is another pass thru the loop. There are 3
> > possible names for the mailfile itself as procmail determines that.
>
> Which nicely illustrates the point of defensive programming.
> It's not *your* script that will necessarily make the first mistake,
> but you don't want procmail's unexpected input to derail your script
> and produce a cascade of errors. Let's face it, shell error messages
> are not the easiest to decode: that was the reason for your OP.
>
> And pointing out how your procmail system can't get it wrong is no
> defence. If you're using an unsafe test in one place, it's likely
> there are other ones in your scripts (assuming this isn't the only
> script you have).
>
> Cheers,
> David.

Observant, David.  Its not the only one but the others are cron jobs, and 
re-arranging the 2>&1 to be the last argument has truly shut this one 
up. 18+ hours and a hundred or more incoming emails later, and I am 
still looking at the shell prompt in the window I restarted it in.  Life 
is good, its truly backgrounded for good.

Thank you.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: My script almost works but spams the terminal its launched from if useing dash.

[David Wright]

On Sun 17 Apr 2016 at 00:41:03 (-0400), Gene Heskett wrote:
> On Saturday 16 April 2016 22:18:34 David Wright wrote:
> > On Sat 16 Apr 2016 at 19:06:42 (-0400), Gene Heskett wrote:
> > > On Saturday 16 April 2016 14:02:16 Thomas Schmitt wrote:
> > > > Gene Heskett wrote:
> > > > > There are too many places where a conditional would be needed
> > > >
> > > > The classic way is to use only gestures which are supported by the
> > > > Bourne shell and to avoid certain peculiarities of some shells.
> > > > In ./configure scripts of source packages one can see gestures
> > > > like
> > > >
> > > >   if test "x${InMail}" = xgene
> > > >
> > > > which avoids to compare empty variable content.
> > >
> > > In normal everyday operation, the variable ${InMail} will not be
> > > empty.
> >
> > That may or may not be a useful observation. However, sod's law
> > dictates that when it *is* empty, it'll be in five years time when
> > you've forgotten how and why you converted your script, and you
> > desparately need it to work _now_.
> 
> Each new incoming  email is another pass thru the loop. There are 3 
> possible names for the mailfile itself as procmail determines that.

Which nicely illustrates the point of defensive programming.
It's not *your* script that will necessarily make the first mistake,
but you don't want procmail's unexpected input to derail your script
and produce a cascade of errors. Let's face it, shell error messages
are not the easiest to decode: that was the reason for your OP.

And pointing out how your procmail system can't get it wrong is no
defence. If you're using an unsafe test in one place, it's likely
there are other ones in your scripts (assuming this isn't the only
script you have).

Cheers,
David.

Re: My script almost works but spams the terminal its launched from if useing dash.

[Jeremy Nicoll]

On Sun, 17 Apr 2016, at 14:28, Thomas Schmitt wrote:

> Let's assume a subordinate script ...

Thank-you!  That's devious.

-- 
Jeremy Nicoll - my opinions are my own.

Re: My script almost works but spams the terminal its launched from if useing dash.

[Thomas Schmitt]

Hi,

Gene Heskett wrote:
> they do not have enough voltage 
> across the oxide film to keep it "formed" so the oxide slowly reverts as 
> its in an oxygen free environment

I always preferred math over chemistry.


> So I should change my single quotes to double-quotes.

Rather not. At least not as general advise. Beware.


The single '-quotes enclose constants (with special meaning of $'...',
in bash but not in dash).
Their use case is to keep whitespace or special characters from being
converted.
'gene' does not really need them, because it is only one word.
But 'Gene Heskett' or ';(|[$' would need them to be handled as a single
argument to some program run or to avoid shell parser complaints.

  $ echo ;(|[$
  bash: syntax error near unexpected token `|'
  $ echo ';(|[$'
  ;(|[$

In bash only:

  $ echo $'xyz\010abc'
  xyabc

(octal 010 = decimal 8 = ASCII BS backspace did eat the "z")


The double "-quotes should often be put around variable evaluations in
order to make the variable content a single argument to some program
run. These quotation marks protect whitespace and some special
characters. But they do not prevent variable evaluation and similar
text conversions.

man bash says:

  Enclosing  characters  in  double quotes preserves the literal value of
  all characters within the quotes, with the exception of $, `,  \,  and,
  when  history  expansion  is enabled, !.  The characters $ and ` retain
  their special meaning within double quotes.  The backslash retains  its
  special  meaning only when followed by one of the following characters:
  $, `, ", \, or .  A double quote may be quoted  within  double
  quotes by preceding it with a backslash.  If enabled, history expansion
  will be performed unless an !  appearing in double  quotes  is  escaped
  using a backslash.  The backslash preceding the !  is not removed.

One may put each variable into its own "-pair or one may mix constant
text and variable evaluation inside a one pair of "-quotes.

I use the for-loop to demonstrate content and number of perceived
program arguments. Any program or sub script will see the words
between "in" and the first ";" as the argument list which is printed
here by the for-loops.
The appended echo commands produce spacer lines for better readbility.

  $ for i in a b c ; do echo "$i" ; done ; echo
  a
  b
  c

  $ x='X  Y  Z'
  $ for i in a $x c ; do echo "$i" ; done ; echo
  a
  X
  Y
  Z
  c

  $ for i in a "$x" c ; do echo "$i" ; done ; echo
  a
  X  Y  Z
  c

  $ for i in "a $x c" ; do echo "$i" ; done ; echo
  a X  Y  Z b

  $ for i in "a${x}c" ; do echo "$i" ; done ; echo
  aX  Y  Zb

Single quotes and double quotes can protect each other from the
shell parser:

  $ echo '"'"$x"'"'
  "X  Y  Z"
  $ echo "'"'"'"$x"'"'"'"
  '"X  Y  Z"'

(It can become as inflationary as Lisp brackets ...)


Have a nice day :)

Thomas

Re: My script almost works but spams the terminal its launched from if useing dash.

[Michael Milliman]

On 04/17/2016 08:28 AM, Thomas Schmitt wrote:

Hi,

Jeremy Nicoll wrote:

would anyone ever code:
  bin/mailwatcher 2>&1 >/dev/null
when surely all they need is
  bin/mailwatcher >/dev/null

Interesting question. (Like what is the use case of cat(1) ?)
Surely this is one of the less useful variations of the rules
for redirection.


Let's assume a subordinate script which expects to get started
with stdout redirected to some non-vanilla target.
For some reason it could decide to direct the stderr of one of
its own sub-subordinate scripts to stdout as prepared by its
superior script and to direct the sub-subordinate stdout to /dev/null.

Superior:

   subordinate | result_consumer

Subordinate

   ...
 echo "Note: Switching to diagnostic output mode"
 subsubordinate 2>&1 >/dev/null
   ...

Subsubordinate:

   ... some (in this case) invalid output to stdout ...
   echo "Failed because ..." >&2
   ...


Have a nice day :)

Thomas

Wow, that's pretty arcane, but pretty cool as well. While understanding 
how redirection works, I had never considered such a case.  It does 
point out the power of the redirection options available, though.


--
Mike

Re: My script almost works but spams the terminal its launched from if useing dash.

[Thomas Schmitt]

Hi,

Jeremy Nicoll wrote:
> would anyone ever code:
>  bin/mailwatcher 2>&1 >/dev/null
> when surely all they need is
>  bin/mailwatcher >/dev/null

Interesting question. (Like what is the use case of cat(1) ?)
Surely this is one of the less useful variations of the rules
for redirection.


Let's assume a subordinate script which expects to get started
with stdout redirected to some non-vanilla target.
For some reason it could decide to direct the stderr of one of
its own sub-subordinate scripts to stdout as prepared by its
superior script and to direct the sub-subordinate stdout to /dev/null.

Superior:

  subordinate | result_consumer

Subordinate

  ...
echo "Note: Switching to diagnostic output mode"
subsubordinate 2>&1 >/dev/null
  ...

Subsubordinate:

  ... some (in this case) invalid output to stdout ...
  echo "Failed because ..." >&2
  ...


Have a nice day :)

Thomas

Re: My script almost works but spams the terminal its launched from if useing dash.

[Michael Milliman]

On 04/17/2016 03:21 AM, Jeremy Nicoll wrote:

On Sun, 17 Apr 2016, at 07:25, Michael Milliman wrote:


Yes, this is the correct incantation.  The difference is very subtle.
With ... 2>&1 >/dev/null, the error output is redirected to be the same
as the standard output, and then the standard output is redirected to
/dev/null -- leaving the error output still going to the original
standard output (terminal).

Why is the "2>&1" part needed?   Wouldn't stderr go to the terminal by
default?

stderr goes to terminal by default, yes.  And in the first, incorrect 
incantation ...2>&1 >/dev/null, the redirection of the stderr to the 
same as stdout has basically no effect, though it does in theory 
redirect the stderr to the same place as stdout. In the second 
incantation ...>/dev/null 2>&1 the stdout is first redirected where you 
want the ouput to go, then the stderr is sent to the same place as 
stdout.  This has the effect of redirecting both outputs to /dev/null, 
whereas the incorrect syntax leaves the stderr going to the terminal 
while stdout is properly redirected this is the same effect as if the 
2>&1 portion was not present because it was processed before the 
redirection of stdout to /dev/null.  Bash processes the redirections in 
order as it reads them on the command line, and acts appropriately.


--
Mike

Re: My script almost works but spams the terminal its launched from if useing dash.

[Gene Heskett]

On Sunday 17 April 2016 08:06:13 Thomas Schmitt wrote:

> Hi,
>
> [Second try to send this mail. Looks like lists.debian.org had a
>  few minutes of inconsciousness. No reply on ping or https.]
>
> Gene Heskett wrote:
> > In normal everyday operation, the variable ${InMail} will not be
> > empty.
>
> Well, normally the 10 uF capacitors suffice for the projected
> life time of the dishwasher. :))
>
No.  The fact that it even ran 5 years amazes me.  The use of 16 volt 
electrolytic caps in a 5 volt circuit is an extreme miss-use of that 
type of capacitor because at 5 volts, they do not have enough voltage 
across the oxide film to keep it "formed" so the oxide slowly reverts as 
its in an oxygen free environment since the electrolyte is an extremely 
pure, called technical grade, ethylene glycol. The net result is that 
the 10 uf goes away, often in less than 5 years.  These were down to 
about what they would have been had they been even bigger paper caps, or 
in the .02uf to .03uf range.

The higher voltage stuff was fine although my meter overflows at 1000 uf 
and up. I need to buy my own ESR meter.

Possibly interesting story about the capacitor shortage back in the 70's 
when OPEC rationed the oil.  As the tx supervisor at KXNE-TV-19 for the 
Nebraska ETV folks at the time, it was coming toward the first frost of 
the fall, and I needed to convert the tx coolant to about 30% 
antifreeze.  That antifreeze cannot be contaminated with the usual 
automotive rust and corrosion inhibitors as they would make it 
conductive, whereas pure water, distilled or de-ionized is a great 
insulator. Since that conversion takes a 55 gallon drum of the pure 
stuff, I got on the horn and started trying to run a barrel of it down, 
calling all over the country till I finally found a barrel of technical 
grade, even purer stuff, sitting on the Mobil Oil dock 150 miles away in 
Omaha NE.  Pricy but I bought it, no choice.  That barrel had been 
earmarked for a JIT shipment to Cornel-Dubilair some weeks later.  My 
buying the last barrel in captivity caused much of that capacitor 
shortage.  And until we sorted the OPEC embargo, no petroleum could be 
spared to make any more of it.  It doesn't take much in each cap so that 
barrel was about a years supply for C-D.  Aerovox, Sangamo, Sprague, 
were all in the same boat.

> The bashism "[[ ${InMail} = 'gene' ]]" hides the pitfall that
> whitespace in a variable will normally yield more than word. (That's
> quite unexpected from the general view of shell programming, but
> documented in man bash.)
>
> With conservative shell gestures one should enclose variable
> evaluation in " quotation marks in order to get the content as exactly
> one word:
>
>   $ InMail="a b"
>   $ if [[ ${InMail} = 'gene' ]] ; then echo yes ; else echo no ; fi
>   no
>   $ if test ${InMail} = 'gene'; then echo yes ; else echo no ; fi
>   bash: test: too many arguments
>   no
>   $ if test "${InMail}" = 'gene'; then echo yes ; else echo no ; fi
>   no
>
> With empty text and no "-marks you get the contrary complaint about
> 0 words as evaluation result:
>
>   $ InMail=""
>   $ if test ${InMail} = 'gene'; then echo yes ; else echo no ; fi
>   bash: test: =: unary operator expected
>   no
>
>
> Google "portable shell" tells me that the gesture
>
>   test "x$variable" = xconstant
>
> does not really target empty variable content but rather reserved
> words as variable content.
> The command test(1) (bash builtin or /usr/bin/test) seems to be quite
> tolerant with syntax errors caused by reserved words where operants
> are expected.
> I fail to make it complain about content like
>   $ InMail="("
>   $ InMail="-f"
> if i use proper "-marks.
>
So I should change my single quotes to double-quotes.  And use test. And 
dump the doubled brackets.

Changes made, test run underway. Fetchmail says one incoming, 3 secs 
later kmail beeps.  I think its working. :)  The second possible name 
won't be tested unless a niece in NYS sends me an email, but amanda will 
test the third option in the early morning hours tomorrow.

And I learned a bit more, so the day will not be a total loss.
>
> Have a nice day :)
>
You too, Thomas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: My script almost works but spams the terminal its launched from if useing dash.

[Jeremy Nicoll]

On Sun, 17 Apr 2016, at 12:46, Thomas Schmitt wrote:
> Jeremy Nicoll wrote:
> > Why is the "2>&1" part needed?   Wouldn't stderr go to the terminal by
> > default.
> 
> Goal is to redirect both to /dev/null.
> 
> So these would do:
> 
>   bin/mailwatcher 2>/dev/null >/dev/null &
> 
>   bin/mailwatcher >/dev/null 2>&1 &

Yes, I understand that.

 
> But as Michael Milliman pointed out,
> 
>   bin/mailwatcher 2>&1 >/dev/null &
> 
> redirects only stdout to /dev/null and leaves stderr directed to where
> stdout was pointing before.

And I understand that too.  But I was asking from a different
perspective.  What I meant
was, if someone is trying to redirect stdout to /dev/null and leave
stderr directed to the
terminal (which seems to be the default), would anyone ever code:

  bin/mailwatcher 2>&1 >/dev/null

when surely all they need is

  bin/mailwatcher >/dev/null


-- 
Jeremy Nicoll - my opinions are my own.

Re: My script almost works but spams the terminal its launched from if useing dash.

[Thomas Schmitt]

Hi,

Gene Heskett wrote:
> In normal everyday operation, the variable ${InMail} will not be empty.

Well, normally the 10 uF capacitors suffice for the projected
life time of the dishwasher. :))


The bashism "[[ ${InMail} = 'gene' ]]" hides the pitfall that whitespace
in a variable will normally yield more than word. (That's quite unexpected
from the general view of shell programming, but documented in man bash.)

With conservative shell gestures one should enclose variable evaluation
in " quotation marks in order to get the content as exactly one word:

  $ InMail="a b"
  $ if [[ ${InMail} = 'gene' ]] ; then echo yes ; else echo no ; fi
  no
  $ if test ${InMail} = 'gene'; then echo yes ; else echo no ; fi
  bash: test: too many arguments
  no
  $ if test "${InMail}" = 'gene'; then echo yes ; else echo no ; fi
  no

With empty text and no "-marks you get the contrary complaint about
0 words as evaluation result:

  $ InMail=""
  $ if test ${InMail} = 'gene'; then echo yes ; else echo no ; fi
  bash: test: =: unary operator expected
  no


Google "portable shell" tells me that the gesture

  test "x$variable" = xconstant

does not really target empty variable content but rather reserved
words as variable content.
The command test(1) (bash builtin or /usr/bin/test) seems to be quite
tolerant with syntax errors caused by reserved words where operants
are expected.
I fail to make it complain about content like
  $ InMail="("
  $ InMail="-f"
if i use proper "-marks.  


Have a nice day :)

Thomas

Re: My script almost works but spams the terminal its launched from if useing dash.

[Thomas Schmitt]

Hi,

[Second try to send this mail. Looks like lists.debian.org had a
 few minutes of inconsciousness. No reply on ping or https.]

Gene Heskett wrote:
> In normal everyday operation, the variable ${InMail} will not be empty.

Well, normally the 10 uF capacitors suffice for the projected
life time of the dishwasher. :))


The bashism "[[ ${InMail} = 'gene' ]]" hides the pitfall that whitespace
in a variable will normally yield more than word. (That's quite unexpected
from the general view of shell programming, but documented in man bash.)

With conservative shell gestures one should enclose variable evaluation
in " quotation marks in order to get the content as exactly one word:

  $ InMail="a b"
  $ if [[ ${InMail} = 'gene' ]] ; then echo yes ; else echo no ; fi
  no
  $ if test ${InMail} = 'gene'; then echo yes ; else echo no ; fi
  bash: test: too many arguments
  no
  $ if test "${InMail}" = 'gene'; then echo yes ; else echo no ; fi
  no

With empty text and no "-marks you get the contrary complaint about
0 words as evaluation result:

  $ InMail=""
  $ if test ${InMail} = 'gene'; then echo yes ; else echo no ; fi
  bash: test: =: unary operator expected
  no


Google "portable shell" tells me that the gesture

  test "x$variable" = xconstant

does not really target empty variable content but rather reserved
words as variable content.
The command test(1) (bash builtin or /usr/bin/test) seems to be quite
tolerant with syntax errors caused by reserved words where operants
are expected.
I fail to make it complain about content like
  $ InMail="("
  $ InMail="-f"
if i use proper "-marks.  


Have a nice day :)

Thomas

Re: My script almost works but spams the terminal its launched from if useing dash.

[Thomas Schmitt]

Hi,

Jeremy Nicoll wrote:
> Why is the "2>&1" part needed?   Wouldn't stderr go to the terminal by
> default.

Goal is to redirect both to /dev/null.

So these would do:

  bin/mailwatcher 2>/dev/null >/dev/null &

  bin/mailwatcher >/dev/null 2>&1 &


But as Michael Milliman pointed out,

  bin/mailwatcher 2>&1 >/dev/null &

redirects only stdout to /dev/null and leaves stderr directed to where
stdout was pointing before.


Have a nice day :)

Thomas

Re: My script almost works but spams the terminal its launched from if useing dash.

[Gene Heskett]

On Sunday 17 April 2016 02:25:01 Michael Milliman wrote:

> On 04/16/2016 12:11 PM, Aero Maxx wrote:
> > On 16/04/2016 17:45, Gene Heskett wrote:
> >> On Saturday 16 April 2016 12:01:28 Aero Maxx wrote:
> >>> On 16/04/2016 16:23, Gene Heskett wrote:
>  But when I run it with dash, it doesn't seem to work right, and
>  spams the terminal with its error messages.  One that appears to
>  kill its function is the bashism of using [[ ]] to surround
>  string variables, reported like this:
>  bin/mailwatcher: 64: bin/mailwatcher: [[: not found
>  bin/mailwatcher: 70: bin/mailwatcher: [[: not found
>  bin/mailwatcher: 77: bin/mailwatcher: [[: not found
> >>>
> >>> dash isn't the same as bash, as it has a limited set of
> >>> instructions or commands it can do.
> >>>
> >>> But I too would be interested to know if it is possible to get it
> >>> to work in dash, I don't believe it is, but I am happy to be
> >>> corrected or proved wrong.
> >>>
>  And finally, once its working with either shell, how do I shut it
>  up totally?  Even the above command line launch fails as it
>  outputs to that shell, a newline for every incoming mail which
>  gradually scrolls any output that was on-screen, offscreen
>  without leaving a prompt until I tap the return key to restore
>  it.
> >>>
> >>> Also isn't the command you are running supposed to be as follows ?
> >>>
>  bin/mailwatcher 2>&1 > /dev/null &
> >>
> >> Is the space you inserted into my line between the > and the
> >> /dev/null a game changer? In either bash or dash?  Its been a while
> >> since I last read the bash docs, but I don't recall there was any
> >> emphasis on that.
> >
> > I'm sorry I was a bit too eager to reply and neglected to change
> > what I had pasted in.
> >
> > I meant to say could you try this
> >
> >> bin/mailwatcher > /dev/null 2>&1 &
>
> Yes, this is the correct incantation.  The difference is very subtle.

And not very well noted in the bash .pdf or the man page.

> With ... 2>&1 >/dev/null, the error output is redirected to be the
> same as the standard output, and then the standard output is
> redirected to /dev/null -- leaving the error output still going to the
> original standard output (terminal).  With ... >/dev/null 2>&1 The
> standard output is redirected first, and the the error output is sent
> to the same place as the standard output, resulting in both going to
> /dev/null.  The order of redirection is important to the end results
> in this case.

Good to know, and thank you.

> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: My script almost works but spams the terminal its launched from if useing dash.

[Jeremy Nicoll]

On Sun, 17 Apr 2016, at 07:25, Michael Milliman wrote:

> Yes, this is the correct incantation.  The difference is very subtle.  
> With ... 2>&1 >/dev/null, the error output is redirected to be the same 
> as the standard output, and then the standard output is redirected to 
> /dev/null -- leaving the error output still going to the original 
> standard output (terminal). 

Why is the "2>&1" part needed?   Wouldn't stderr go to the terminal by 
default?

-- 
Jeremy Nicoll - my opinions are my own.

Re: My script almost works but spams the terminal its launched from if useing dash.

[Michael Milliman]

On 04/16/2016 12:11 PM, Aero Maxx wrote:

On 16/04/2016 17:45, Gene Heskett wrote:

On Saturday 16 April 2016 12:01:28 Aero Maxx wrote:


On 16/04/2016 16:23, Gene Heskett wrote:

But when I run it with dash, it doesn't seem to work right, and
spams the terminal with its error messages.  One that appears to
kill its function is the bashism of using [[ ]] to surround string
variables, reported like this:
bin/mailwatcher: 64: bin/mailwatcher: [[: not found
bin/mailwatcher: 70: bin/mailwatcher: [[: not found
bin/mailwatcher: 77: bin/mailwatcher: [[: not found

dash isn't the same as bash, as it has a limited set of instructions
or commands it can do.

But I too would be interested to know if it is possible to get it to
work in dash, I don't believe it is, but I am happy to be corrected
or proved wrong.


And finally, once its working with either shell, how do I shut it up
totally?  Even the above command line launch fails as it outputs to
that shell, a newline for every incoming mail which gradually
scrolls any output that was on-screen, offscreen without leaving a
prompt until I tap the return key to restore it.

Also isn't the command you are running supposed to be as follows ?


bin/mailwatcher 2>&1 > /dev/null &


Is the space you inserted into my line between the > and the /dev/null a
game changer? In either bash or dash?  Its been a while since I last
read the bash docs, but I don't recall there was any emphasis on that.

I'm sorry I was a bit too eager to reply and neglected to change what 
I had pasted in.


I meant to say could you try this


bin/mailwatcher > /dev/null 2>&1 &


Yes, this is the correct incantation.  The difference is very subtle.  
With ... 2>&1 >/dev/null, the error output is redirected to be the same 
as the standard output, and then the standard output is redirected to 
/dev/null -- leaving the error output still going to the original 
standard output (terminal).  With ... >/dev/null 2>&1 The standard 
output is redirected first, and the the error output is sent to the same 
place as the standard output, resulting in both going to /dev/null.  The 
order of redirection is important to the end results in this case.

This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



--
Mike

Re: My script almost works but spams the terminal its launched from if useing dash.

[Gene Heskett]

On Saturday 16 April 2016 22:18:34 David Wright wrote:

> On Sat 16 Apr 2016 at 19:06:42 (-0400), Gene Heskett wrote:
> > On Saturday 16 April 2016 14:02:16 Thomas Schmitt wrote:
> > > Gene Heskett wrote:
> > > > There are too many places where a conditional would be needed
> > >
> > > The classic way is to use only gestures which are supported by the
> > > Bourne shell and to avoid certain peculiarities of some shells.
> > > In ./configure scripts of source packages one can see gestures
> > > like
> > >
> > >   if test "x${InMail}" = xgene
> > >
> > > which avoids to compare empty variable content.
> >
> > In normal everyday operation, the variable ${InMail} will not be
> > empty.
>
> That may or may not be a useful observation. However, sod's law
> dictates that when it *is* empty, it'll be in five years time when
> you've forgotten how and why you converted your script, and you
> desparately need it to work _now_.

Each new incoming  email is another pass thru the loop. There are 3 
possible names for the mailfile itself as procmail determines that.

This script launches an inotifywait instance with directions to return 
the name of the modified by being written to mailfile. So unless I kill 
it from a terminal, the inotifywait will define that name. If I kill it, 
all 3 IF's fail, and a new instance of inotifywait is launched to 
replace that one.  Not that big a script, but it helps to make my email 
handling fully automatic here. Pulling the mail is fetchmails job and 
ity hands the incoming off to procmail, which filters it thru spamd, 
clamav and thence to the correct mailfile in /var/spool/mail. 

This script, by noticing the change in the mailfile, sends kmail a go get 
mail from ${InMail} via dbus/dcop or whatever interprocess comm flavor 
is in the distro, which gets it/them and sorts it to the correct 
mailedir folder.  No manual intervention by me other than running this 
at bootup time.

All I have to do is tap the + key to read that email, and if I can 
contribute to the thread, click the correct answering format and start 
typing. When I am done, a ctrl+return sends it smtp style to the 
selected mail server, defined on a per folder basis.

I suspect that if I kill the inotifywait, that ${InMail} actually remains 
unchanged from the previous instance, and kmail likely gets sent to read 
an empty mailfile in that event, a few milliseconds wasted but kmail 
doesn't seem to mind. I did have some tracing echo's in there at one 
time, but they don't last long as that spams the terminal it was 
launched from.

> Going back a step or two:
>
> "This bash script has lived in ~/bin for years, but the mention of
>  dash as a replacement for bash made me want to test it with dash by
>  changing the bang line to #!/bin/sh, which is of course (this is
>  wheezy) a softlink to /bin/dash."
>
> Debian took a decision long ago to make dash the default shell for
> *system* scripts. In that sense only, dash replaced bash, and the
> replacement took a while because all the bashisms had first to be
> removed from those scripts headed by #!/bin/sh. Water under the
> bridge now.
>
> Grepping /var/lib/dpkg/info/*.p* can be a quick way of finding
> examples of dash's ways and means. However, you're probably wasting
> your time converting your own scripts unless you need the efficiency.

Efficiency of the present method seems adequate so that would not drive 
the change, but losing bash completely would upset the applecart long 
before it got to the cider press.
>
> And this statement:
>
> "However, I'll go on record as opposing any motions to remove bash,
>  the old man on the mountain of cli shells still gets the job done."
>
> is an unfounded fear. The default login shell is bash, as usual.

So it is not likely to go away before I do.  At 81, I know my time is 
limited. How much is probably up to a higher authority.

This discussion has been fruitfull and I thank you, David, as well as the 
other respondents who tried to make sense out of my scribbling's.

> Cheers,
> David.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: My script almost works but spams the terminal its launched from if useing dash.

[David Wright]

On Sat 16 Apr 2016 at 19:06:42 (-0400), Gene Heskett wrote:
> On Saturday 16 April 2016 14:02:16 Thomas Schmitt wrote:
> > Gene Heskett wrote:
> > > There are too many places where a conditional would be needed
> >
> > The classic way is to use only gestures which are supported by the
> > Bourne shell and to avoid certain peculiarities of some shells.
> > In ./configure scripts of source packages one can see gestures
> > like
> >
> >   if test "x${InMail}" = xgene
> >
> > which avoids to compare empty variable content.
> 
> In normal everyday operation, the variable ${InMail} will not be empty.

That may or may not be a useful observation. However, sod's law
dictates that when it *is* empty, it'll be in five years time when
you've forgotten how and why you converted your script, and you
desparately need it to work _now_.

Going back a step or two:

"This bash script has lived in ~/bin for years, but the mention of
 dash as a replacement for bash made me want to test it with dash by
 changing the bang line to #!/bin/sh, which is of course (this is
 wheezy) a softlink to /bin/dash."

Debian took a decision long ago to make dash the default shell for
*system* scripts. In that sense only, dash replaced bash, and the
replacement took a while because all the bashisms had first to be
removed from those scripts headed by #!/bin/sh. Water under the
bridge now.

Grepping /var/lib/dpkg/info/*.p* can be a quick way of finding
examples of dash's ways and means. However, you're probably wasting
your time converting your own scripts unless you need the efficiency.

And this statement:

"However, I'll go on record as opposing any motions to remove bash,
 the old man on the mountain of cli shells still gets the job done."

is an unfounded fear. The default login shell is bash, as usual.

Cheers,
David.

Re: My script almost works but spams the terminal its launched from if useing dash.

[Gene Heskett]

On Saturday 16 April 2016 14:02:16 Thomas Schmitt wrote:

> Hi,
>
> Gene Heskett wrote:
> > if [[ ${InMail} = 'gene' ]]
>
> test(1) is supposed to be portable
>
>   if test "${InMail}" = 'gene'
>
Thats slightly different, printed for tomorrows experiments.  Thank you.
I need to reboot to bring in a fresh kernel that was updated earlier 
today.  But I'm out of giddy-up, haveing repaired a dishwasher MCU based 
control module today in my own dishwasher. The parts houses for such 
wanted 266.55 USD for one that may, or may not have had the same 
software.  But I found 3 of the teeny electrolytics in it, 10 u-f at 16 
volts, were reading at about .02 u-f, so now there are a triplet of 10 
u-f x 16 volt tantalum caps in it.  I don't enjoy working on a pcb that 
has no schematic, not even online, but then I am also a C.E.T. 
(Certified Electronics Technician), but will plead to quit a bit of rust 
in the wet ram (its 81 yo now) in the 44 years since I sat down cold 
without cracking a book, to take that test back in '72.

> > There are too many places where a conditional would be needed
>
> The classic way is to use only gestures which are supported by the
> Bourne shell and to avoid certain peculiarities of some shells.
> In ./configure scripts of source packages one can see gestures
> like
>
>   if test "x${InMail}" = xgene
>
> which avoids to compare empty variable content.

In normal everyday operation, the variable ${InMail} will not be empty.

> See also
>  
> https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/P
>ortable-Shell.html
>
>
> Have a nice day :)
>
> Thomas

You too Thomas and thank you.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: My script almost works but spams the terminal its launched from if useing dash.

[Gene Heskett]

On Saturday 16 April 2016 13:11:54 Aero Maxx wrote:

> On 16/04/2016 17:45, Gene Heskett wrote:
> > On Saturday 16 April 2016 12:01:28 Aero Maxx wrote:
> >> On 16/04/2016 16:23, Gene Heskett wrote:
> >>> But when I run it with dash, it doesn't seem to work right, and
> >>> spams the terminal with its error messages.  One that appears to
> >>> kill its function is the bashism of using [[ ]] to surround string
> >>> variables, reported like this:
> >>> bin/mailwatcher: 64: bin/mailwatcher: [[: not found
> >>> bin/mailwatcher: 70: bin/mailwatcher: [[: not found
> >>> bin/mailwatcher: 77: bin/mailwatcher: [[: not found
> >>
> >> dash isn't the same as bash, as it has a limited set of
> >> instructions or commands it can do.
> >>
> >> But I too would be interested to know if it is possible to get it
> >> to work in dash, I don't believe it is, but I am happy to be
> >> corrected or proved wrong.
> >>
> >>> And finally, once its working with either shell, how do I shut it
> >>> up totally?  Even the above command line launch fails as it
> >>> outputs to that shell, a newline for every incoming mail which
> >>> gradually scrolls any output that was on-screen, offscreen without
> >>> leaving a prompt until I tap the return key to restore it.
> >>
> >> Also isn't the command you are running supposed to be as follows ?
> >>
> >>> bin/mailwatcher 2>&1 > /dev/null &
> >
> > Is the space you inserted into my line between the > and the
> > /dev/null a game changer? In either bash or dash?  Its been a while
> > since I last read the bash docs, but I don't recall there was any
> > emphasis on that.
>
> I'm sorry I was a bit too eager to reply and neglected to change what
> I had pasted in.
>
> I meant to say could you try this
>
> > bin/mailwatcher > /dev/null 2>&1 &
>
Now that is a re-arrangement I have not tried.  But will.  Thank you Aero 
Maxx.

> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: My script almost works but spams the terminal its launched from if useing dash.

[Thomas Schmitt]

Hi,

Gene Heskett wrote:
> if [[ ${InMail} = 'gene' ]]

test(1) is supposed to be portable

  if test "${InMail}" = 'gene'


> There are too many places where a conditional would be needed

The classic way is to use only gestures which are supported by the
Bourne shell and to avoid certain peculiarities of some shells.
In ./configure scripts of source packages one can see gestures
like

  if test "x${InMail}" = xgene

which avoids to compare empty variable content.

See also
  
https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Portable-Shell.html


Have a nice day :)

Thomas

Re: My script almost works but spams the terminal its launched from if useing dash.

[Linux-Fan]

[Sat, 16 Apr 2016 13:07:38 -0400] Gene Heskett 
wrote:
> On Saturday 16 April 2016 12:44:55 Sven Joachim wrote:
> >
> > https://wiki.ubuntu.com/DashAsBinSh has some information how to make
> > scripts portable.  The checkbashisms command in the devscripts
> > package can help you detect common non-portable constructions in
> > your scripts.
> >
> > Cheers,
> >Sven
> 
> A bookmarked now, much better explanatory link, thank you Sven.

In addition, I recommend consulting the standard whenever doubt arises:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html

... because there is a lot of outdated information on what is POSIX and
what is not. Fortunately, The Ubuntu Wiki link given above seems to be
OK.

> I think for my stuff, I should export the value of /bin/sh, write a 
> wrapper script to determine what /bin/sh is, and run the correct
> script to get the identical wanted functionality based on the value
> of the export.  There are too many places where a conditional would
> be needed so it would use command A or command B, and thats going to
> slow it down much more than just re-writing it into 2 scripts and
> running the correct one w/o all that gingerbread & bloat.

[...]

As far as I understand, just about all scripts which work under dash
also work under bash without changes. If your script is compatible
with dash, it does not need to check if it is running under bash,
because that will ``just work''. This means: If you do the work to port
the scripts to dash, you will likely not have to maintain a separate
version for bash.

HTH
Linux-Fan

-- 
http://masysma.lima-city.de/


pgpwdcEL3xOBz.pgp
Description: OpenPGP digital signature

Re: My script almost works but spams the terminal its launched from if useing dash.

[Aero Maxx]

On 16/04/2016 17:45, Gene Heskett wrote:

On Saturday 16 April 2016 12:01:28 Aero Maxx wrote:


On 16/04/2016 16:23, Gene Heskett wrote:

But when I run it with dash, it doesn't seem to work right, and
spams the terminal with its error messages.  One that appears to
kill its function is the bashism of using [[ ]] to surround string
variables, reported like this:
bin/mailwatcher: 64: bin/mailwatcher: [[: not found
bin/mailwatcher: 70: bin/mailwatcher: [[: not found
bin/mailwatcher: 77: bin/mailwatcher: [[: not found

dash isn't the same as bash, as it has a limited set of instructions
or commands it can do.

But I too would be interested to know if it is possible to get it to
work in dash, I don't believe it is, but I am happy to be corrected
or proved wrong.


And finally, once its working with either shell, how do I shut it up
totally?  Even the above command line launch fails as it outputs to
that shell, a newline for every incoming mail which gradually
scrolls any output that was on-screen, offscreen without leaving a
prompt until I tap the return key to restore it.

Also isn't the command you are running supposed to be as follows ?


bin/mailwatcher 2>&1 > /dev/null &


Is the space you inserted into my line between the > and the /dev/null a
game changer? In either bash or dash?  Its been a while since I last
read the bash docs, but I don't recall there was any emphasis on that.

I'm sorry I was a bit too eager to reply and neglected to change what I 
had pasted in.


I meant to say could you try this


bin/mailwatcher > /dev/null 2>&1 &


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: My script almost works but spams the terminal its launched from if useing dash.

[Gene Heskett]

On Saturday 16 April 2016 12:44:55 Sven Joachim wrote:
>
> https://wiki.ubuntu.com/DashAsBinSh has some information how to make
> scripts portable.  The checkbashisms command in the devscripts package
> can help you detect common non-portable constructions in your scripts.
>
> Cheers,
>Sven

A bookmarked now, much better explanatory link, thank you Sven.

I think for my stuff, I should export the value of /bin/sh, write a 
wrapper script to determine what /bin/sh is, and run the correct script 
to get the identical wanted functionality based on the value of the 
export.  There are too many places where a conditional would be needed 
so it would use command A or command B, and thats going to slow it down 
much more than just re-writing it into 2 scripts and running the correct 
one w/o all that gingerbread & bloat.

I have at least 3 background helper scripts, all of which would need to 
be fixed for the diffs.

However, I'll go on record as opposing any motions to remove bash, the 
old man on the mountain of cli shells still gets the job done.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: My script almost works but spams the terminal its launched from if useing dash.

[Gene Heskett]

On Saturday 16 April 2016 12:01:28 Aero Maxx wrote:

> On 16/04/2016 16:23, Gene Heskett wrote:
> > But when I run it with dash, it doesn't seem to work right, and
> > spams the terminal with its error messages.  One that appears to
> > kill its function is the bashism of using [[ ]] to surround string
> > variables, reported like this:
> > bin/mailwatcher: 64: bin/mailwatcher: [[: not found
> > bin/mailwatcher: 70: bin/mailwatcher: [[: not found
> > bin/mailwatcher: 77: bin/mailwatcher: [[: not found
>
> dash isn't the same as bash, as it has a limited set of instructions
> or commands it can do.
>
> But I too would be interested to know if it is possible to get it to
> work in dash, I don't believe it is, but I am happy to be corrected
> or proved wrong.
>
> > And finally, once its working with either shell, how do I shut it up
> > totally?  Even the above command line launch fails as it outputs to
> > that shell, a newline for every incoming mail which gradually
> > scrolls any output that was on-screen, offscreen without leaving a
> > prompt until I tap the return key to restore it.
>
> Also isn't the command you are running supposed to be as follows ?
>
> > bin/mailwatcher 2>&1 > /dev/null &
>
Is the space you inserted into my line between the > and the /dev/null a 
game changer? In either bash or dash?  Its been a while since I last 
read the bash docs, but I don't recall there was any emphasis on that.

Looking at man bash, I see this:
   The general format for redirecting output is:

  [n]>word

Dash lists the same syntax as one of several variations.

So if either has changed to require a space there, it apparently hasn't 
made it into the manpage.  I dare say that such a change, breaking a 
good share of our scripts, might lead to a search party carrying buckets 
of verbal hot tar and big bags of verbal abuse feathers. ;-)

Me, goes off scratching whats left of a thinning head of hair.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: My script almost works but spams the terminal its launched from if useing dash.

[Sven Joachim]

On 2016-04-16 11:23 -0400, Gene Heskett wrote:

> This bash script has lived in ~/bin for years, but the mention of dash as 
> a replacement for bash made me want to test it with dash by changing the 
> bang line to #!/bin/sh, which is of course (this is wheezy) a softlink 
> to /bin/dash.

FWIW, dash is not a replacement for bash, nor does it aim to be one.

> I am launching it with this command as I don't want it to make any noise 
> at all when its running, just do its job:
>
> bin/mailwatcher 2>&1 >/dev/null &
>
> But when I run it with dash, it doesn't seem to work right, and spams the 
> terminal with its error messages.  One that appears to kill its function 
> is the bashism of using [[ ]] to surround string variables, reported 
> like this:
> bin/mailwatcher: 64: bin/mailwatcher: [[: not found
> bin/mailwatcher: 70: bin/mailwatcher: [[: not found
> bin/mailwatcher: 77: bin/mailwatcher: [[: not found
>
> Which is nice, as I am seeing the reason it fails. Line 64 to illuminate 
> that is:
>   if [[ ${InMail} = 'gene' ]]
> The other 2 lines are similar except for 'gene'
> The return from inotifywait is what sets the value of ${InMail}
> Can these lines be re-constructed to be valid for either bash or dash?
> If so how?

https://wiki.ubuntu.com/DashAsBinSh has some information how to make
scripts portable.  The checkbashisms command in the devscripts package
can help you detect common non-portable constructions in your scripts.

Cheers,
   Sven

Re: My script almost works but spams the terminal its launched from if useing dash.

[Aero Maxx]

On 16/04/2016 16:23, Gene Heskett wrote:

But when I run it with dash, it doesn't seem to work right, and spams the
terminal with its error messages.  One that appears to kill its function
is the bashism of using [[ ]] to surround string variables, reported
like this:
bin/mailwatcher: 64: bin/mailwatcher: [[: not found
bin/mailwatcher: 70: bin/mailwatcher: [[: not found
bin/mailwatcher: 77: bin/mailwatcher: [[: not found


dash isn't the same as bash, as it has a limited set of instructions or 
commands it can do.


But I too would be interested to know if it is possible to get it to 
work in dash, I don't believe it is, but I am happy to be corrected

or proved wrong.


And finally, once its working with either shell, how do I shut it up
totally?  Even the above command line launch fails as it outputs to that
shell, a newline for every incoming mail which gradually scrolls any
output that was on-screen, offscreen without leaving a prompt until I
tap the return key to restore it.


Also isn't the command you are running supposed to be as follows ?


bin/mailwatcher 2>&1 > /dev/null &



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

My script almost works but spams the terminal its launched from if useing dash.

[Gene Heskett]

Greetings;

This bash script has lived in ~/bin for years, but the mention of dash as 
a replacement for bash made me want to test it with dash by changing the 
bang line to #!/bin/sh, which is of course (this is wheezy) a softlink 
to /bin/dash.

I am launching it with this command as I don't want it to make any noise 
at all when its running, just do its job:

bin/mailwatcher 2>&1 >/dev/null &

But when I run it with dash, it doesn't seem to work right, and spams the 
terminal with its error messages.  One that appears to kill its function 
is the bashism of using [[ ]] to surround string variables, reported 
like this:
bin/mailwatcher: 64: bin/mailwatcher: [[: not found
bin/mailwatcher: 70: bin/mailwatcher: [[: not found
bin/mailwatcher: 77: bin/mailwatcher: [[: not found

Which is nice, as I am seeing the reason it fails. Line 64 to illuminate 
that is:
if [[ ${InMail} = 'gene' ]]
The other 2 lines are similar except for 'gene'
The return from inotifywait is what sets the value of ${InMail}
Can these lines be re-constructed to be valid for either bash or dash?
If so how?

And finally, once its working with either shell, how do I shut it up 
totally?  Even the above command line launch fails as it outputs to that 
shell, a newline for every incoming mail which gradually scrolls any 
output that was on-screen, offscreen without leaving a prompt until I 
tap the return key to restore it.

Thank you for any insight on this.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page