Groups > linux.debian.user > #166774 > unrolled thread

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

Started by	Gene Heskett <gheskett@shentel.net>
First post	2016-04-16 17:30 +0200
Last post	2016-04-17 16:40 +0200
Articles	20 on this page of 32 — 10 participants

Back to article view | Back to linux.debian.user

Page 1 of 2 [1] 2 Next page →

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

From	Gene Heskett <gheskett@shentel.net>
Date	2016-04-16 17:30 +0200
Subject	My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<roAky-5Ir-13@gated-at.bofh.it>

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 <http://geneslinuxbox.net:6309/gene>

[toc] | [next] | [standalone]

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

From	Aero Maxx <aero.maxx.d@gmail.com>
Date	2016-04-16 18:10 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<roAXg-6iM-25@gated-at.bofh.it>
In reply to	#166774

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

[toc] | [prev] | [next] | [standalone]

#166780

From	Gene Heskett <gheskett@shentel.net>
Date	2016-04-16 18:50 +0200
Message-ID	<roBzY-6BB-15@gated-at.bofh.it>
In reply to	#166778

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 <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

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

From	Aero Maxx <aero.maxx.d@gmail.com>
Date	2016-04-16 19:20 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<roC2Z-76O-15@gated-at.bofh.it>
In reply to	#166780

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

[toc] | [prev] | [next] | [standalone]

#166802

From	Gene Heskett <gheskett@shentel.net>
Date	2016-04-17 00:50 +0200
Message-ID	<roHcm-2nN-5@gated-at.bofh.it>
In reply to	#166782

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 <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

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

From	Michael Milliman <michael.e.milliman@gmail.com>
Date	2016-04-17 08:30 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<roOnw-8i1-3@gated-at.bofh.it>
In reply to	#166782


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

[toc] | [prev] | [next] | [standalone]

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

From	Jeremy Nicoll <jn.ml.dbn.25@letterboxes.org>
Date	2016-04-17 13:00 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<roSAO-2WB-13@gated-at.bofh.it>
In reply to	#166815

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.

[toc] | [prev] | [next] | [standalone]

#166823

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2016-04-17 13:50 +0200
Message-ID	<roTnc-3AB-15@gated-at.bofh.it>
In reply to	#166817

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

[toc] | [prev] | [next] | [standalone]

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

From	Jeremy Nicoll <jn.ml.dbn.25@letterboxes.org>
Date	2016-04-17 15:10 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<roUCC-4PT-11@gated-at.bofh.it>
In reply to	#166823


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.

[toc] | [prev] | [next] | [standalone]

#166831

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2016-04-17 15:30 +0200
Message-ID	<roUVX-4Z7-3@gated-at.bofh.it>
In reply to	#166829

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

[toc] | [prev] | [next] | [standalone]

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

From	Michael Milliman <michael.e.milliman@gmail.com>
Date	2016-04-17 15:40 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<roV5E-54M-3@gated-at.bofh.it>
In reply to	#166831


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

[toc] | [prev] | [next] | [standalone]

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

From	Jeremy Nicoll <jn.ml.dbn.25@letterboxes.org>
Date	2016-04-17 16:40 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<roW1I-5QE-11@gated-at.bofh.it>
In reply to	#166831

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.

[toc] | [prev] | [next] | [standalone]

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

From	Michael Milliman <michael.e.milliman@gmail.com>
Date	2016-04-17 15:30 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<roUVY-4Z7-19@gated-at.bofh.it>
In reply to	#166817


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

[toc] | [prev] | [next] | [standalone]

#166821

From	Gene Heskett <gheskett@shentel.net>
Date	2016-04-17 13:50 +0200
Message-ID	<roTnc-3AB-9@gated-at.bofh.it>
In reply to	#166815

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 <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

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

From	Andrew McGlashan <andrew.mcglashan@affinityvision.com.au>
Date	2016-04-22 06:30 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<rqAT7-4e7-19@gated-at.bofh.it>
In reply to	#166782

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

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

From	Michael Milliman <michael.e.milliman@gmail.com>
Date	2016-04-22 07:00 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<rqBm9-4rW-1@gated-at.bofh.it>
In reply to	#166929


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

[toc] | [prev] | [next] | [standalone]

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

From	Clive Standbridge <list-user@tgstandbridges.plus.com>
Date	2016-04-22 11:40 +0200
Subject	Re: Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<rqFJ9-8d9-19@gated-at.bofh.it>
In reply to	#166931

> > 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

[toc] | [prev] | [next] | [standalone]

#166941

From	Gene Heskett <gheskett@shentel.net>
Date	2016-04-22 10:30 +0200
Message-ID	<rqEDp-7qZ-17@gated-at.bofh.it>
In reply to	#166929

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 <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

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

From	David Wright <deblis@lionunicorn.co.uk>
Date	2016-04-22 13:10 +0200
Subject	Re: My script almost works but spams the terminal its launched from if useing dash.
Message-ID	<rqH8g-ZP-71@gated-at.bofh.it>
In reply to	#166929

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.

[toc] | [prev] | [next] | [standalone]

#166779

From	Sven Joachim <svenjoac@gmx.de>
Date	2016-04-16 18:50 +0200
Message-ID	<roBzY-6BB-13@gated-at.bofh.it>
In reply to	#166774

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2 [1] 2 Next page →

csiph-web

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

Contents

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

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

#166780

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

#166802

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

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

#166823

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

#166831

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

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

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

#166821

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

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

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

#166941

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

#166779