Sometimes it's convenient to use ` read -t 3 ` instead of ` sleep 3 `. How do I make it work with `nohup`?

Clash Royale CLAN TAG#URR8PPP
up vote
-2
down vote
favorite
Sometimes it's convenient to use read -t 3 instead of sleep 3. How do I make it work with nohup?
nohup bash -c ' date; read -t 3; date ' | tail -n 2 nohup.out
As you can see, read -t 3 does not wait for three seconds.
bash nohup read sleep
 |Â
show 4 more comments
up vote
-2
down vote
favorite
Sometimes it's convenient to use read -t 3 instead of sleep 3. How do I make it work with nohup?
nohup bash -c ' date; read -t 3; date ' | tail -n 2 nohup.out
As you can see, read -t 3 does not wait for three seconds.
bash nohup read sleep
2
How is that convenient or a substitute for sleep?read -t 3is to read from standard input with a 3 second timeout. Withnohup, it's/dev/nullfrom which reads return straight away. Also stdout and stderr are redirected by nohup to the nohup.out so it makes little sense to pipe totail, especially considering that you're tellingtailnot to read its stdin (by giving it a file to read as argument instead). What is it exactly that you want to do?
â Stéphane Chazelas
Feb 1 at 12:11
If you want a shell with builtin sleeping support, look atzsh(zselect) ormksh/ksh93(sleepbuiltin) instead ofbash.
â Stéphane Chazelas
Feb 1 at 12:20
Well,tailwas just for the sake of demonstration ((or) to help the reader with a quick test). I only needreadto play its input role when not under nohup, otherwise I'm fine with its sleep role. So essentially my question is how do I makereadnot break on those rarer occasions when I need to use nohup. Perhaps some kind of virtualstdinthat could make it happy and do the waiting?
â glarry
Feb 1 at 12:23
where do you want it to read from when under nohup? nohup is meant to detach a command from the terminal it's started from, so you wouldn't want to read from the terminal device in that. If you're usingreadas a sleep substitute that can be shortened by the user pressing enter, then it seems to me that returning straight away when under nohup (so when not interactive) is the right thing to do.
â Stéphane Chazelas
Feb 1 at 12:25
1
If you want to read with timeout if stdin is a terminal device and sleep otherwise, then it would beif [ -t 0 ]; then read -t 3; else sleep 3; fi
â Stéphane Chazelas
Feb 1 at 12:30
 |Â
show 4 more comments
up vote
-2
down vote
favorite
up vote
-2
down vote
favorite
Sometimes it's convenient to use read -t 3 instead of sleep 3. How do I make it work with nohup?
nohup bash -c ' date; read -t 3; date ' | tail -n 2 nohup.out
As you can see, read -t 3 does not wait for three seconds.
bash nohup read sleep
Sometimes it's convenient to use read -t 3 instead of sleep 3. How do I make it work with nohup?
nohup bash -c ' date; read -t 3; date ' | tail -n 2 nohup.out
As you can see, read -t 3 does not wait for three seconds.
bash nohup read sleep
asked Feb 1 at 12:03
glarry
15811
15811
2
How is that convenient or a substitute for sleep?read -t 3is to read from standard input with a 3 second timeout. Withnohup, it's/dev/nullfrom which reads return straight away. Also stdout and stderr are redirected by nohup to the nohup.out so it makes little sense to pipe totail, especially considering that you're tellingtailnot to read its stdin (by giving it a file to read as argument instead). What is it exactly that you want to do?
â Stéphane Chazelas
Feb 1 at 12:11
If you want a shell with builtin sleeping support, look atzsh(zselect) ormksh/ksh93(sleepbuiltin) instead ofbash.
â Stéphane Chazelas
Feb 1 at 12:20
Well,tailwas just for the sake of demonstration ((or) to help the reader with a quick test). I only needreadto play its input role when not under nohup, otherwise I'm fine with its sleep role. So essentially my question is how do I makereadnot break on those rarer occasions when I need to use nohup. Perhaps some kind of virtualstdinthat could make it happy and do the waiting?
â glarry
Feb 1 at 12:23
where do you want it to read from when under nohup? nohup is meant to detach a command from the terminal it's started from, so you wouldn't want to read from the terminal device in that. If you're usingreadas a sleep substitute that can be shortened by the user pressing enter, then it seems to me that returning straight away when under nohup (so when not interactive) is the right thing to do.
â Stéphane Chazelas
Feb 1 at 12:25
1
If you want to read with timeout if stdin is a terminal device and sleep otherwise, then it would beif [ -t 0 ]; then read -t 3; else sleep 3; fi
â Stéphane Chazelas
Feb 1 at 12:30
 |Â
show 4 more comments
2
How is that convenient or a substitute for sleep?read -t 3is to read from standard input with a 3 second timeout. Withnohup, it's/dev/nullfrom which reads return straight away. Also stdout and stderr are redirected by nohup to the nohup.out so it makes little sense to pipe totail, especially considering that you're tellingtailnot to read its stdin (by giving it a file to read as argument instead). What is it exactly that you want to do?
â Stéphane Chazelas
Feb 1 at 12:11
If you want a shell with builtin sleeping support, look atzsh(zselect) ormksh/ksh93(sleepbuiltin) instead ofbash.
â Stéphane Chazelas
Feb 1 at 12:20
Well,tailwas just for the sake of demonstration ((or) to help the reader with a quick test). I only needreadto play its input role when not under nohup, otherwise I'm fine with its sleep role. So essentially my question is how do I makereadnot break on those rarer occasions when I need to use nohup. Perhaps some kind of virtualstdinthat could make it happy and do the waiting?
â glarry
Feb 1 at 12:23
where do you want it to read from when under nohup? nohup is meant to detach a command from the terminal it's started from, so you wouldn't want to read from the terminal device in that. If you're usingreadas a sleep substitute that can be shortened by the user pressing enter, then it seems to me that returning straight away when under nohup (so when not interactive) is the right thing to do.
â Stéphane Chazelas
Feb 1 at 12:25
1
If you want to read with timeout if stdin is a terminal device and sleep otherwise, then it would beif [ -t 0 ]; then read -t 3; else sleep 3; fi
â Stéphane Chazelas
Feb 1 at 12:30
2
2
How is that convenient or a substitute for sleep?
read -t 3 is to read from standard input with a 3 second timeout. With nohup, it's /dev/null from which reads return straight away. Also stdout and stderr are redirected by nohup to the nohup.out so it makes little sense to pipe to tail, especially considering that you're telling tail not to read its stdin (by giving it a file to read as argument instead). What is it exactly that you want to do?â Stéphane Chazelas
Feb 1 at 12:11
How is that convenient or a substitute for sleep?
read -t 3 is to read from standard input with a 3 second timeout. With nohup, it's /dev/null from which reads return straight away. Also stdout and stderr are redirected by nohup to the nohup.out so it makes little sense to pipe to tail, especially considering that you're telling tail not to read its stdin (by giving it a file to read as argument instead). What is it exactly that you want to do?â Stéphane Chazelas
Feb 1 at 12:11
If you want a shell with builtin sleeping support, look at
zsh (zselect) or mksh/ksh93 (sleep builtin) instead of bash.â Stéphane Chazelas
Feb 1 at 12:20
If you want a shell with builtin sleeping support, look at
zsh (zselect) or mksh/ksh93 (sleep builtin) instead of bash.â Stéphane Chazelas
Feb 1 at 12:20
Well,
tail was just for the sake of demonstration ((or) to help the reader with a quick test). I only need read to play its input role when not under nohup, otherwise I'm fine with its sleep role. So essentially my question is how do I make read not break on those rarer occasions when I need to use nohup. Perhaps some kind of virtual stdin that could make it happy and do the waiting?â glarry
Feb 1 at 12:23
Well,
tail was just for the sake of demonstration ((or) to help the reader with a quick test). I only need read to play its input role when not under nohup, otherwise I'm fine with its sleep role. So essentially my question is how do I make read not break on those rarer occasions when I need to use nohup. Perhaps some kind of virtual stdin that could make it happy and do the waiting?â glarry
Feb 1 at 12:23
where do you want it to read from when under nohup? nohup is meant to detach a command from the terminal it's started from, so you wouldn't want to read from the terminal device in that. If you're using
read as a sleep substitute that can be shortened by the user pressing enter, then it seems to me that returning straight away when under nohup (so when not interactive) is the right thing to do.â Stéphane Chazelas
Feb 1 at 12:25
where do you want it to read from when under nohup? nohup is meant to detach a command from the terminal it's started from, so you wouldn't want to read from the terminal device in that. If you're using
read as a sleep substitute that can be shortened by the user pressing enter, then it seems to me that returning straight away when under nohup (so when not interactive) is the right thing to do.â Stéphane Chazelas
Feb 1 at 12:25
1
1
If you want to read with timeout if stdin is a terminal device and sleep otherwise, then it would be
if [ -t 0 ]; then read -t 3; else sleep 3; fiâ Stéphane Chazelas
Feb 1 at 12:30
If you want to read with timeout if stdin is a terminal device and sleep otherwise, then it would be
if [ -t 0 ]; then read -t 3; else sleep 3; fiâ Stéphane Chazelas
Feb 1 at 12:30
 |Â
show 4 more comments
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
read -t 3 (a ksh93 extension now also supported by zsh, bash and mksh) is meant to read one line (logical line in that lines may be continued with a trailing backslash as you don't use the -r option) from stdin into $REPLY with a 3 second timeout.
If stdin is a terminal, that will sleep for 3 seconds unless the user presses enter (and the script will be suspended with a SIGTTIN signal if it's started in background).
If it's a regular file, it will read that line from it and return straight away. If it's /dev/zero it will do a very busy read of gigabytes of zeros from there, etc.
nohup is the command you use to detach a command from a terminal. It redirects stdin to /dev/null and stdout and stderr to nohup.out. So typically you would not want to read from the terminal in that case.
read on /dev/null returns straight away with no data returned, that's what /dev/null is for.
If the purpose of using read -t is to have a kind of sleep that can be interrupted by the user (by pressing Enter) like when you want to give them the time to read a message which they can skip, then having read -t return straight away when non-interactive (like when running under nohup) would seem the right thing to do as there's no point delaying the script then.
But if you want to read from the terminal with timeout if stdin is a terminal, and sleep otherwise, then you would do:
if [ -t 0 ]; then
read -t 3
else
sleep 3
fi
[ -t n ] tests whether the file descriptor n (0 being stdin) refers to a terminal device.
You could do read -t 3 < /dev/tty but that would defeat the purpose of nohup by adding back the interaction with the terminal that nohup is meant to guard against.
As I implied above, I wouldn't mind deleting my question. I knew (why) the community wouldn't like it before the downvoting began. I agree that it broke some of their rules or expectations. I'm not suggesting that I agree to those rules; I don't; but on stackexchange I will not offer something that is not desired. I don't regret that I didn't delete my question, because I like your answer and I need it to stay here. I am a beginner so I guess the best way to frame my question is: is it improper for me to ask you to turn it into a Community Wiki post?
â glarry
Feb 1 at 22:29
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
read -t 3 (a ksh93 extension now also supported by zsh, bash and mksh) is meant to read one line (logical line in that lines may be continued with a trailing backslash as you don't use the -r option) from stdin into $REPLY with a 3 second timeout.
If stdin is a terminal, that will sleep for 3 seconds unless the user presses enter (and the script will be suspended with a SIGTTIN signal if it's started in background).
If it's a regular file, it will read that line from it and return straight away. If it's /dev/zero it will do a very busy read of gigabytes of zeros from there, etc.
nohup is the command you use to detach a command from a terminal. It redirects stdin to /dev/null and stdout and stderr to nohup.out. So typically you would not want to read from the terminal in that case.
read on /dev/null returns straight away with no data returned, that's what /dev/null is for.
If the purpose of using read -t is to have a kind of sleep that can be interrupted by the user (by pressing Enter) like when you want to give them the time to read a message which they can skip, then having read -t return straight away when non-interactive (like when running under nohup) would seem the right thing to do as there's no point delaying the script then.
But if you want to read from the terminal with timeout if stdin is a terminal, and sleep otherwise, then you would do:
if [ -t 0 ]; then
read -t 3
else
sleep 3
fi
[ -t n ] tests whether the file descriptor n (0 being stdin) refers to a terminal device.
You could do read -t 3 < /dev/tty but that would defeat the purpose of nohup by adding back the interaction with the terminal that nohup is meant to guard against.
As I implied above, I wouldn't mind deleting my question. I knew (why) the community wouldn't like it before the downvoting began. I agree that it broke some of their rules or expectations. I'm not suggesting that I agree to those rules; I don't; but on stackexchange I will not offer something that is not desired. I don't regret that I didn't delete my question, because I like your answer and I need it to stay here. I am a beginner so I guess the best way to frame my question is: is it improper for me to ask you to turn it into a Community Wiki post?
â glarry
Feb 1 at 22:29
add a comment |Â
up vote
3
down vote
accepted
read -t 3 (a ksh93 extension now also supported by zsh, bash and mksh) is meant to read one line (logical line in that lines may be continued with a trailing backslash as you don't use the -r option) from stdin into $REPLY with a 3 second timeout.
If stdin is a terminal, that will sleep for 3 seconds unless the user presses enter (and the script will be suspended with a SIGTTIN signal if it's started in background).
If it's a regular file, it will read that line from it and return straight away. If it's /dev/zero it will do a very busy read of gigabytes of zeros from there, etc.
nohup is the command you use to detach a command from a terminal. It redirects stdin to /dev/null and stdout and stderr to nohup.out. So typically you would not want to read from the terminal in that case.
read on /dev/null returns straight away with no data returned, that's what /dev/null is for.
If the purpose of using read -t is to have a kind of sleep that can be interrupted by the user (by pressing Enter) like when you want to give them the time to read a message which they can skip, then having read -t return straight away when non-interactive (like when running under nohup) would seem the right thing to do as there's no point delaying the script then.
But if you want to read from the terminal with timeout if stdin is a terminal, and sleep otherwise, then you would do:
if [ -t 0 ]; then
read -t 3
else
sleep 3
fi
[ -t n ] tests whether the file descriptor n (0 being stdin) refers to a terminal device.
You could do read -t 3 < /dev/tty but that would defeat the purpose of nohup by adding back the interaction with the terminal that nohup is meant to guard against.
As I implied above, I wouldn't mind deleting my question. I knew (why) the community wouldn't like it before the downvoting began. I agree that it broke some of their rules or expectations. I'm not suggesting that I agree to those rules; I don't; but on stackexchange I will not offer something that is not desired. I don't regret that I didn't delete my question, because I like your answer and I need it to stay here. I am a beginner so I guess the best way to frame my question is: is it improper for me to ask you to turn it into a Community Wiki post?
â glarry
Feb 1 at 22:29
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
read -t 3 (a ksh93 extension now also supported by zsh, bash and mksh) is meant to read one line (logical line in that lines may be continued with a trailing backslash as you don't use the -r option) from stdin into $REPLY with a 3 second timeout.
If stdin is a terminal, that will sleep for 3 seconds unless the user presses enter (and the script will be suspended with a SIGTTIN signal if it's started in background).
If it's a regular file, it will read that line from it and return straight away. If it's /dev/zero it will do a very busy read of gigabytes of zeros from there, etc.
nohup is the command you use to detach a command from a terminal. It redirects stdin to /dev/null and stdout and stderr to nohup.out. So typically you would not want to read from the terminal in that case.
read on /dev/null returns straight away with no data returned, that's what /dev/null is for.
If the purpose of using read -t is to have a kind of sleep that can be interrupted by the user (by pressing Enter) like when you want to give them the time to read a message which they can skip, then having read -t return straight away when non-interactive (like when running under nohup) would seem the right thing to do as there's no point delaying the script then.
But if you want to read from the terminal with timeout if stdin is a terminal, and sleep otherwise, then you would do:
if [ -t 0 ]; then
read -t 3
else
sleep 3
fi
[ -t n ] tests whether the file descriptor n (0 being stdin) refers to a terminal device.
You could do read -t 3 < /dev/tty but that would defeat the purpose of nohup by adding back the interaction with the terminal that nohup is meant to guard against.
read -t 3 (a ksh93 extension now also supported by zsh, bash and mksh) is meant to read one line (logical line in that lines may be continued with a trailing backslash as you don't use the -r option) from stdin into $REPLY with a 3 second timeout.
If stdin is a terminal, that will sleep for 3 seconds unless the user presses enter (and the script will be suspended with a SIGTTIN signal if it's started in background).
If it's a regular file, it will read that line from it and return straight away. If it's /dev/zero it will do a very busy read of gigabytes of zeros from there, etc.
nohup is the command you use to detach a command from a terminal. It redirects stdin to /dev/null and stdout and stderr to nohup.out. So typically you would not want to read from the terminal in that case.
read on /dev/null returns straight away with no data returned, that's what /dev/null is for.
If the purpose of using read -t is to have a kind of sleep that can be interrupted by the user (by pressing Enter) like when you want to give them the time to read a message which they can skip, then having read -t return straight away when non-interactive (like when running under nohup) would seem the right thing to do as there's no point delaying the script then.
But if you want to read from the terminal with timeout if stdin is a terminal, and sleep otherwise, then you would do:
if [ -t 0 ]; then
read -t 3
else
sleep 3
fi
[ -t n ] tests whether the file descriptor n (0 being stdin) refers to a terminal device.
You could do read -t 3 < /dev/tty but that would defeat the purpose of nohup by adding back the interaction with the terminal that nohup is meant to guard against.
edited Feb 1 at 13:08
answered Feb 1 at 12:56
Stéphane Chazelas
281k53516847
281k53516847
As I implied above, I wouldn't mind deleting my question. I knew (why) the community wouldn't like it before the downvoting began. I agree that it broke some of their rules or expectations. I'm not suggesting that I agree to those rules; I don't; but on stackexchange I will not offer something that is not desired. I don't regret that I didn't delete my question, because I like your answer and I need it to stay here. I am a beginner so I guess the best way to frame my question is: is it improper for me to ask you to turn it into a Community Wiki post?
â glarry
Feb 1 at 22:29
add a comment |Â
As I implied above, I wouldn't mind deleting my question. I knew (why) the community wouldn't like it before the downvoting began. I agree that it broke some of their rules or expectations. I'm not suggesting that I agree to those rules; I don't; but on stackexchange I will not offer something that is not desired. I don't regret that I didn't delete my question, because I like your answer and I need it to stay here. I am a beginner so I guess the best way to frame my question is: is it improper for me to ask you to turn it into a Community Wiki post?
â glarry
Feb 1 at 22:29
As I implied above, I wouldn't mind deleting my question. I knew (why) the community wouldn't like it before the downvoting began. I agree that it broke some of their rules or expectations. I'm not suggesting that I agree to those rules; I don't; but on stackexchange I will not offer something that is not desired. I don't regret that I didn't delete my question, because I like your answer and I need it to stay here. I am a beginner so I guess the best way to frame my question is: is it improper for me to ask you to turn it into a Community Wiki post?
â glarry
Feb 1 at 22:29
As I implied above, I wouldn't mind deleting my question. I knew (why) the community wouldn't like it before the downvoting began. I agree that it broke some of their rules or expectations. I'm not suggesting that I agree to those rules; I don't; but on stackexchange I will not offer something that is not desired. I don't regret that I didn't delete my question, because I like your answer and I need it to stay here. I am a beginner so I guess the best way to frame my question is: is it improper for me to ask you to turn it into a Community Wiki post?
â glarry
Feb 1 at 22:29
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f421189%2fsometimes-its-convenient-to-use-read-t-3-instead-of-sleep-3-how-do-i%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
How is that convenient or a substitute for sleep?
read -t 3is to read from standard input with a 3 second timeout. Withnohup, it's/dev/nullfrom which reads return straight away. Also stdout and stderr are redirected by nohup to the nohup.out so it makes little sense to pipe totail, especially considering that you're tellingtailnot to read its stdin (by giving it a file to read as argument instead). What is it exactly that you want to do?â Stéphane Chazelas
Feb 1 at 12:11
If you want a shell with builtin sleeping support, look at
zsh(zselect) ormksh/ksh93(sleepbuiltin) instead ofbash.â Stéphane Chazelas
Feb 1 at 12:20
Well,
tailwas just for the sake of demonstration ((or) to help the reader with a quick test). I only needreadto play its input role when not under nohup, otherwise I'm fine with its sleep role. So essentially my question is how do I makereadnot break on those rarer occasions when I need to use nohup. Perhaps some kind of virtualstdinthat could make it happy and do the waiting?â glarry
Feb 1 at 12:23
where do you want it to read from when under nohup? nohup is meant to detach a command from the terminal it's started from, so you wouldn't want to read from the terminal device in that. If you're using
readas a sleep substitute that can be shortened by the user pressing enter, then it seems to me that returning straight away when under nohup (so when not interactive) is the right thing to do.â Stéphane Chazelas
Feb 1 at 12:25
1
If you want to read with timeout if stdin is a terminal device and sleep otherwise, then it would be
if [ -t 0 ]; then read -t 3; else sleep 3; fiâ Stéphane Chazelas
Feb 1 at 12:30