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

The name of the pictureThe name of the pictureThe name of the pictureClash 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.







share|improve this question
















  • 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











  • 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










  • 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




    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















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.







share|improve this question
















  • 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











  • 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










  • 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




    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













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.







share|improve this question












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.









share|improve this question











share|improve this question




share|improve this question










asked Feb 1 at 12:03









glarry

15811




15811







  • 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











  • 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










  • 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




    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













  • 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











  • 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










  • 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




    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








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











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.






share|improve this answer






















  • 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










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















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






























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.






share|improve this answer






















  • 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














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.






share|improve this answer






















  • 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












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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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
















  • 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












 

draft saved


draft discarded


























 


draft saved


draft discarded














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













































































Popular posts from this blog

Peggy Mitchell

Palaiologos

The Forum (Inglewood, California)