I've the following bash script:

------- begin --------
#!/usr/bin/env bash

nohup while :; do
if some-cond; then
nohup some-command &>/dev/null &
fi
sleep 5
done &>/dev/null &
------- end --------

It seems that the first “nohup” in the script is unnecessary/superfluous, i.e., the same effect can be achieved with or without it - after I exit the terminal, the process still keeps running.
Are there any tips for this behavior of the bash shell?

Regards,
HZ

On Thu, 23 Dec 2021 01:21:45 -0800 (PST)
"hongy...@gmail.com" <hongyi.zhao@gmail.com> wrote:
> I've the following bash script:
>
> ------- begin --------
> #!/usr/bin/env bash
>
> nohup while :; do
> if some-cond; then
> nohup some-command &>/dev/null &
> fi
> sleep 5
> done &>/dev/null &
> ------- end --------
>
> It seems that the first “nohup” in the script is
> unnecessary/superfluous, i.e., the same effect can be achieved
> with or without it - after I exit the terminal, the process still
> keeps running.

I don't think that nohup is a shell builtin. So if you were to try your
construct with actual commands , BASH would print some error message due
to being unable to parse the code. Perhaps you wouldn't see the error
message due to the redirections you make but my guess is that you would.

It would have been best if you had actually posted the code with which
you did your experiments instead of replacing it with a generic version.
A generic version which shows the general rule you think applies would
have been fine but *in addition* to actual running code.

--
vlaho.ninja/prog

On Thursday, December 23, 2021 at 10:07:45 PM UTC+8, Spiros Bousbouras wrote:
> On Thu, 23 Dec 2021 01:21:45 -0800 (PST)
> "hongy...@gmail.com" <hongy...@gmail.com> wrote:
> > I've the following bash script:
> >
> > ------- begin --------
> > #!/usr/bin/env bash
> >
> > nohup while :; do
> > if some-cond; then
> > nohup some-command &>/dev/null &
> > fi
> > sleep 5
> > done &>/dev/null &
> > ------- end --------
> >
> > It seems that the first “nohup” in the script is
> > unnecessary/superfluous, i.e., the same effect can be achieved
> > with or without it - after I exit the terminal, the process still
> > keeps running.
> I don't think that nohup is a shell builtin. So if you were to try your
> construct with actual commands , BASH would print some error message due
> to being unable to parse the code. Perhaps you wouldn't see the error
> message due to the redirections you make but my guess is that you would.
>
> It would have been best if you had actually posted the code with which
> you did your experiments instead of replacing it with a generic version.
> A generic version which shows the general rule you think applies would
> have been fine but *in addition* to actual running code.

See the following:

#!/usr/bin/env bash

nohup while :; do
if ! lsof -i :18080 &>/dev/null; then
nohup socat -v -d -d TCP4-LISTEN:18080,fork,reuseaddr PROXY:my.domain.com:10.8.10.100:80,proxyport=6002 &>/dev/null &
fi
sleep 5
done &>/dev/null &

HZ

"hongy...@gmail.com" <hongyi.zhao@gmail.com> writes:
[...]
>> On Thu, 23 Dec 2021 01:21:45 -0800 (PST)
>> "hongy...@gmail.com" <hongy...@gmail.com> wrote:
[...]
>> > It seems that the first “nohup” in the script is
>> > unnecessary/superfluous, i.e., the same effect can be achieved
>> > with or without it - after I exit the terminal, the process still
>> > keeps running.
[...]
> See the following:
>
> #!/usr/bin/env bash
>
> nohup while :; do
> if ! lsof -i :18080 &>/dev/null; then
> nohup socat -v -d -d TCP4-LISTEN:18080,fork,reuseaddr PROXY:my.domain.com:10.8.10.100:80,proxyport=6002 &>/dev/null &
> fi
> sleep 5
> done &>/dev/null &

Yes, I see it. What about it? Did you run it? What happened?

In your initial post, you say the first "nohup" is superfluous, that the
same effect is achieved with or without it. But when I try to run your most
recent script, I get the result I expected:

./tmp.bash: line 3: syntax error near unexpected token `do'
./tmp.bash: line 3: `nohup while :; do'

Either you got the same error message and didn't bother to mention it,
or you didn't get the same error message and something very strange is
going on (perhaps the script you posted doesn't match the script you
ran). Which is it?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On Friday, December 24, 2021 at 9:35:18 AM UTC+8, Keith Thompson wrote:
> "hongy...@gmail.com" <hongy...@gmail.com> writes:
> [...]
> >> On Thu, 23 Dec 2021 01:21:45 -0800 (PST)
> >> "hongy...@gmail.com" <hongy...@gmail.com> wrote:
> [...]
> >> > It seems that the first “nohup” in the script is
> >> > unnecessary/superfluous, i.e., the same effect can be achieved
> >> > with or without it - after I exit the terminal, the process still
> >> > keeps running.
> [...]
> > See the following:
> >
> > #!/usr/bin/env bash
> >
> > nohup while :; do
> > if ! lsof -i :18080 &>/dev/null; then
> > nohup socat -v -d -d TCP4-LISTEN:18080,fork,reuseaddr PROXY:my.domain.com:10.8.10.100:80,proxyport=6002 &>/dev/null &
> > fi
> > sleep 5
> > done &>/dev/null &
> Yes, I see it. What about it? Did you run it? What happened?
>
> In your initial post, you say the first "nohup" is superfluous, that the
> same effect is achieved with or without it. But when I try to run your most
> recent script, I get the result I expected:
>
> ./tmp.bash: line 3: syntax error near unexpected token `do'
> ./tmp.bash: line 3: `nohup while :; do'

Now, I retried the script above, and obtained the exactly same error as yours.
> Either you got the same error message and didn't bother to mention it,
> or you didn't get the same error message and something very strange is
> going on (perhaps the script you posted doesn't match the script you
> ran). Which is it?

Really, you're right. I tried the first `nohup` stripped version in both cases, so I came to the wrong conclusion.

HZ

On 23/12/2021 09:21, hongy...@gmail.com wrote:
> I've the following bash script:
>
> ------- begin --------
> #!/usr/bin/env bash
>
> nohup while :; do
> if some-cond; then
> nohup some-command &>/dev/null &
> fi
> sleep 5
> done &>/dev/null &
> ------- end --------
>
> It seems that the first “nohup” in the script is unnecessary/superfluous, i.e., the same effect can be achieved with or without it - after I exit the terminal, the process still keeps running.
>
> Are there any tips for this behavior of the bash shell?
>
> Regards,
> HZ

Does it really need to check every 5 seconds?

Why can't you just cron it every minute?

hongy...@gmail.com <hongyi.zhao@gmail.com> wrote:
> I've the following bash script:
>
> ------- begin --------
> #!/usr/bin/env bash
>
> nohup while :; do
while is a built in, no need for that here

> if some-cond; then
> nohup some-command &>/dev/null &

nohup here is a builtin too, there is an external nohup
but you need specify something like /usr/bin/nohup
instead.

> fi
> sleep 5
What happens if 'some-cond' always succeeds and
'some-command' executes for much longer than 5
seconds ? That could slow down your system quite
a bit

I would add a 'wait' after 'some-command'.

> done &>/dev/null &
> ------- end --------
>
<snip>
>
> Are there any tips for this behavior of the bash shell?

As someone suggested, cron may be a better choice. But
instead of having nohup all over the place put all of
this into a script and use nohup on that script.

--
csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

On Friday, December 24, 2021 at 7:33:59 PM UTC+8, Richard Harnden wrote:
> On 23/12/2021 09:21, hongy...@gmail.com wrote:
> > I've the following bash script:
> >
> > ------- begin --------
> > #!/usr/bin/env bash
> >
> > nohup while :; do
> > if some-cond; then
> > nohup some-command &>/dev/null &
> > fi
> > sleep 5
> > done &>/dev/null &
> > ------- end --------
> >
> > It seems that the first “nohup” in the script is unnecessary/superfluous, i.e., the same effect can be achieved with or without it - after I exit the terminal, the process still keeps running.
> >
> > Are there any tips for this behavior of the bash shell?
> >
> > Regards,
> > HZ
> Does it really need to check every 5 seconds?

Just as an example, but 5 second checking intervals will not bring much extra load.

> Why can't you just cron it every minute?

Do you mean cron doesn't support the time controlling granularity in seconds?

On 24.12.2021 14:28, John McCue wrote:
>
> nohup here is a builtin too, there is an external nohup
> but you need specify something like /usr/bin/nohup
> instead.

That's not true.

Janis

Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> On 24.12.2021 14:28, John McCue wrote:
>>
>> nohup here is a builtin too, there is an external nohup
>> but you need specify something like /usr/bin/nohup
>> instead.
>
> That's not true.

Interesting, for me it is:
which nohup
nohup: shell built-in command.

But I went into bash and it is not, I was not expecting that.
Good to know.

So it depends upon your shell.

> Janis

--
csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

John McCue <jmccue@fuzzball.mhome.org> writes:
[...]
> nohup here is a builtin too, there is an external nohup
> but you need specify something like /usr/bin/nohup
> instead.
[...]

nohup is a builtin in csh and tcsh, not in bash, ksh, or zsh.

If you're using csh, it's definitely worth mentioning that fact.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 24.12.2021 21:55, John McCue wrote:
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>> On 24.12.2021 14:28, John McCue wrote:
>>>
>>> nohup here is a builtin too, there is an external nohup
>>> but you need specify something like /usr/bin/nohup
>>> instead.
>>
>> That's not true.
>
> Interesting, for me it is:
> which nohup
> nohup: shell built-in command.

Out of curiosity; which shell is that?

> But I went into bash and it is not, I was not expecting that.
> Good to know.
>
> So it depends upon your shell.

Yes, it's up to the shell whether a command is provided as builtin
or not. I've tried with ksh, which has a builtin command that shows
all the builtins, but you can also use an own test (disabling PATH)

$ bash -c '( PATH= ; nohup sleep 1 )'
bash: nohup: No such file or directory

(or use 'which' or 'whence -a' depending on your system environment
or shell). Also in Ksh (and I think in Bash as well) it's possible
to implement a builtin nohup and dynamically load it as builtin, so
it's also no static property of any shell but depends on the actual
system. It boils down to not making any assumptions about builtins,
unless the standardized ones.

Janis

Janis Papanagnou <janis_papanagnou@hotmail.com> writes:
> On 24.12.2021 21:55, John McCue wrote:
>> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>>> On 24.12.2021 14:28, John McCue wrote:
>>>>
>>>> nohup here is a builtin too, there is an external nohup
>>>> but you need specify something like /usr/bin/nohup
>>>> instead.
>>>
>>> That's not true.
>>
>> Interesting, for me it is:
>> which nohup
>> nohup: shell built-in command.
>
> Out of curiosity; which shell is that?
>
>> But I went into bash and it is not, I was not expecting that.
>> Good to know.
>>
>> So it depends upon your shell.
>
> Yes, it's up to the shell whether a command is provided as builtin
> or not. I've tried with ksh, which has a builtin command that shows
> all the builtins, but you can also use an own test (disabling PATH)
>
> $ bash -c '( PATH= ; nohup sleep 1 )'
> bash: nohup: No such file or directory
>
> (or use 'which' or 'whence -a' depending on your system environment
> or shell). Also in Ksh (and I think in Bash as well) it's possible
> to implement a builtin nohup and dynamically load it as builtin, so
> it's also no static property of any shell but depends on the actual
> system. It boils down to not making any assumptions about builtins,
> unless the standardized ones.

"which" is typically an external command and *not* a builtin, so it has
no way of knowing about builtins for the current shell.

For Bourne-like shells, I find "type" or "type -a" (a builtin) to be
much better than "which".

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 25.12.2021 01:03, Keith Thompson wrote:
>
> "which" is typically an external command and *not* a builtin, so it has
> no way of knowing about builtins for the current shell.

You are absolutely right.

> For Bourne-like shells, I find "type" or "type -a" (a builtin) to be
> much better than "which".

In Kornshell I use "whence -a". BTW (in Kornshell)

$ whence -a whence
whence is a shell builtin

$ whence -a type
type is an alias for 'whence -v'
type is a shell builtin

Janis

On 24/12/2021 23:59, Janis Papanagnou wrote:
> On 24.12.2021 21:55, John McCue wrote:
>> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>>> On 24.12.2021 14:28, John McCue wrote:
>>>>
>>>> nohup here is a builtin too, there is an external nohup
>>>> but you need specify something like /usr/bin/nohup
>>>> instead.
>>>
>>> That's not true.
>>
>> Interesting, for me it is:
>> which nohup
>> nohup: shell built-in command.
>
> Out of curiosity; which shell is that?
>
>> But I went into bash and it is not, I was not expecting that.
>> Good to know.
>>
>> So it depends upon your shell.
>
> Yes, it's up to the shell whether a command is provided as builtin
> or not. I've tried with ksh, which has a builtin command that shows
> all the builtins, but you can also use an own test (disabling PATH)
>
> $ bash -c '( PATH= ; nohup sleep 1 )'
> bash: nohup: No such file or directory
>
> (or use 'which' or 'whence -a' depending on your system environment
> or shell). Also in Ksh (and I think in Bash as well) it's possible
> to implement a builtin nohup and dynamically load it as builtin, so
> it's also no static property of any shell but depends on the actual
> system. It boils down to not making any assumptions about builtins,
> unless the standardized ones.
>
> Janis
>

Read his sig. It's csh by the looks.

--
Chris Elvidge
England

Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> On 24.12.2021 21:55, John McCue wrote:
>> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>>> On 24.12.2021 14:28, John McCue wrote:
<snip>
> Out of curiosity; which shell is that?

On Linux/BSD tcsh, at work csh on aix.

> Janis

--
csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> John McCue <jmccue@fuzzball.mhome.org> writes:
> [...]
>> nohup here is a builtin too, there is an external nohup
>> but you need specify something like /usr/bin/nohup
>> instead.
> [...]
>
> nohup is a builtin in csh and tcsh, not in bash, ksh, or zsh.
>
> If you're using csh, it's definitely worth mentioning that fact.

Only on aix, but on systems that come with tcsh, I use that :)

--
csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

On 25.12.2021 01:27, John McCue wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> John McCue <jmccue@fuzzball.mhome.org> writes:
>> [...]
>>> nohup here is a builtin too, there is an external nohup
>>> but you need specify something like /usr/bin/nohup
>>> instead.
>> [...]
>>
>> nohup is a builtin in csh and tcsh, not in bash, ksh, or zsh.
>>
>> If you're using csh, it's definitely worth mentioning that fact.
>
> Only on aix, but on systems that come with tcsh, I use that :)

The problem is that the OP used a sh based shell - the shell family
used for programming (as opposed to the csh family, deprecated for
that purpose) -, and so it's misleading to inspect ones interactive
csh based shell to test for the buitin status of a command used in
the actually used shell for programming. That had been irritating me,
more so after testing a couple of sh based shells, that's why I asked.

Janis

On Saturday, December 25, 2021 at 6:17:46 AM UTC+8, Keith Thompson wrote:
> John McCue <jmc...@fuzzball.mhome.org> writes:
> [...]
> > nohup here is a builtin too, there is an external nohup
> > but you need specify something like /usr/bin/nohup
> > instead.
> [...]
>
> nohup is a builtin in csh and tcsh, not in bash, ksh, or zsh.

Yep. As shown below:

$ csh -c '( set PATH= ; nohup sleep 1 )'
$ tcsh -c '( set PATH= ; nohup sleep 1 )'
$ bash -c '( PATH= ; nohup sleep 1 )'
bash: nohup: No such file or directory
$ zsh -c '( PATH= ; nohup sleep 1 )'
zsh:1: command not found: nohup
$ ksh -c '( PATH= ; nohup sleep 1 )'
ksh: nohup: not found

> If you're using csh, it's definitely worth mentioning that fact.
> --
> Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
> Working, but not speaking, for Philips
> void Void(void) { Void(); } /* The recursive call of the void */

On Sat, 25 Dec 2021 01:47:33 +0100
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> On 25.12.2021 01:27, John McCue wrote:
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> >> John McCue <jmccue@fuzzball.mhome.org> writes:
> >> [...]
> >>> nohup here is a builtin too, there is an external nohup
> >>> but you need specify something like /usr/bin/nohup
> >>> instead.
> >> [...]
> >>
> >> nohup is a builtin in csh and tcsh, not in bash, ksh, or zsh.
> >>
> >> If you're using csh, it's definitely worth mentioning that fact.
> >
> > Only on aix, but on systems that come with tcsh, I use that :)
>
> The problem is that the OP used a sh based shell - the shell family
> used for programming (as opposed to the csh family, deprecated for
> that purpose) -, and so it's misleading to inspect ones interactive
> csh based shell to test for the buitin status of a command used in
> the actually used shell for programming.

What shell one uses for programming is up to personal taste so it's
meaningless to say things like "the shell family used for programming" or
"deprecated for that purpose" or "the actually used shell for programming".
However <sq4htl$lo5$1@dont-email.me> has
{ hongy...@gmail.com <hongyi.zhao@gmail.com> wrote:
> I've the following bash script:
>
> ------- begin --------
> #!/usr/bin/env bash
>
> nohup while :; do
while is a built in, no need for that here

> if some-cond; then
> nohup some-command &>/dev/null &

nohup here is a builtin too, there is an external nohup
but you need specify something like /usr/bin/nohup
instead.
} So it quotes code which explicitly mentions BASH .In such a context , it
seems to me that the natural interpretation of "nohup here is a builtin too"
is that some version of BASH is being referenced. Since John really meant
(t)csh , he should have made that explicit.

--
Criticizing Asimov because his characters aren't as good as Jane
Austen's strikes me as being like criticizing Pride and Prejudice
because it doesn't have any robots.
Pete McCutchen

On 25.12.2021 03:05, Spiros Bousbouras wrote:
> On Sat, 25 Dec 2021 01:47:33 +0100
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>>
>> The problem is that the OP used a sh based shell - the shell family
>> used for programming (as opposed to the csh family, deprecated for
>> that purpose) -, and so it's misleading to inspect ones interactive
>> csh based shell to test for the buitin status of a command used in
>> the actually used shell for programming.
>
> What shell one uses for programming is up to personal taste

Yes.

> so it's
> meaningless to say things like "the shell family used for programming" or
> "deprecated for that purpose" or "the actually used shell for programming".

No.

Janis

On 25.12.2021 03:05, Spiros Bousbouras wrote:
> On Sat, 25 Dec 2021 01:47:33 +0100
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>> On 25.12.2021 01:27, John McCue wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> John McCue <jmccue@fuzzball.mhome.org> writes:
>>>> [...]
>>>>> nohup here is a builtin too, there is an external nohup
>>>>> but you need specify something like /usr/bin/nohup
>>>>> instead.
>>>> [...]
>>>>
>>>> nohup is a builtin in csh and tcsh, not in bash, ksh, or zsh.
>>>>
>>>> If you're using csh, it's definitely worth mentioning that fact.
>>>
>>> Only on aix, but on systems that come with tcsh, I use that :)
>>
>> The problem is that the OP used a sh based shell - the shell family
>> used for programming (as opposed to the csh family, deprecated for
>> that purpose) -, and so it's misleading to inspect ones interactive
>> csh based shell to test for the buitin status of a command used in
>> the actually used shell for programming.
>
> [...]
>
> So it quotes code which explicitly mentions BASH .In such a context , it
> seems to me that the natural interpretation of "nohup here is a builtin too"
> is that some version of BASH is being referenced. Since John really meant
> (t)csh , he should have made that explicit.

The poster used code for shells usually taken for programming, but
more importantly code that won't run in the csh family of shells.
One aspect is that (some/most) folks use one shell for interactive
use and another shell for programming. If these shells differ WRT
the shell family one should not interactively test [programmable]
shell behavior while working with that interactive shell. That was
the point of my reply.

We agree (and had already agreed) that this should be made explicit.

Janis