$ help wait
wait: wait [-n] [id ...]
Wait for job completion and return exit status.
Waits for each process identified by an ID, which may be a process ID or a
job specification, and reports its termination status. If ID is not
given, waits for all currently active child processes, and the return
status is zero. If ID is a a job specification, waits for all processes
in that job's pipeline.
If the -n option is supplied, waits for the next job to terminate and
returns its exit status.
Exit Status:
Returns the status of the last ID; fails if ID is invalid or an invalid
option is given.
And tangentially, this is another case where I wish a “low quality” downvote/flag option was available. The article…does, I guess, do what it set out to, but not in a way that’s actually a good example of how to do things; as such, its current positioning at the top of the front page seems decidedly inappropriate to me. (The blog-self-promotion aspect almost lead me to downvote as spam, but it didn’t seem quite right…)
Hmm, though after considering a bit further, I guess using wait would actually be kind of cumbersome in the ^Z case. You could do a little dance of SIGCONTing it and then waiting on it, but that’s basically just manually issuing the syscalls that fg would be doing anyway. Criticism retracted. (Alright, think I’m through talking to myself now…)
I wonder if it would be useful to add an, “I changed my mind” feature to lobsters. After X minutes, you can no longer edit, but you can append a retraction, and an explanation of the retraction.
As @moses points out, letting your terminal buffer your next command is sufficient for wget, but mplayer wants to eat your terminal input and ^Z is a real bummer. So I use strace -p "$(pidof mplayer)" -o /dev/null; mplayer -shuffle ~/music/chill/* to enqueue chill music to follow the current mplayer task.
This won’t work on MacOS because you don’t have strace, and it won’t work by default on Ubuntu because strace -p is disabled by default (I guess the theory is that if an attacker compromises one of your processes, then this will stop them from compromising all of your other processes). If you think you know more about security than Ubuntu, you can enable it with echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope until the next reboot, or kernel.yama.ptrace_scope = 0 in /etc/sysctl.d/10-ptrace.conf after the next reboot.
My remaining problem is how to get mplayer to start up without a significant delay, plus reforming copyright law so I have guaranteed access to the things I want to open with it.
You mean to distinguish between the two? What I meant was that if you do “foo; bar”, “bar” will run when “foo” exits, regardless of whether or not it was successful. If you want to say, run “foo” and run “bar” on success but “baz” on failure, you could use an if-else.
I’d like to edit this parent comment, but I’m no longer able to. Be aware that it is mischievous and wrong (hat tip @zhemao)! The experiment I ran was:
And tangentially, this is another case where I wish a “low quality” downvote/flag option was available. The article…does, I guess, do what it set out to, but not in a way that’s actually a good example of how to do things; as such, its current positioning at the top of the front page seems decidedly inappropriate to me. (The blog-self-promotion aspect almost lead me to downvote as spam, but it didn’t seem quite right…)
Hmm, though after considering a bit further, I guess using
waitwould actually be kind of cumbersome in the^Zcase. You could do a little dance ofSIGCONTing it and thenwaiting on it, but that’s basically just manually issuing the syscalls thatfgwould be doing anyway. Criticism retracted. (Alright, think I’m through talking to myself now…)I wonder if it would be useful to add an, “I changed my mind” feature to lobsters. After X minutes, you can no longer edit, but you can append a retraction, and an explanation of the retraction.
What could be an issue with using
^Zto append another command? Is it bad practice?On BSD, you can do a little better with kqueue to wait for arbitrary processes.
http://www.tedunangst.com/files/pwait.c
As @moses points out, letting your terminal buffer your next command is sufficient for
wget, butmplayerwants to eat your terminal input and ^Z is a real bummer. So I usestrace -p "$(pidof mplayer)" -o /dev/null; mplayer -shuffle ~/music/chill/*to enqueue chill music to follow the currentmplayertask.This won’t work on MacOS because you don’t have
strace, and it won’t work by default on Ubuntu becausestrace -pis disabled by default (I guess the theory is that if an attacker compromises one of your processes, then this will stop them from compromising all of your other processes). If you think you know more about security than Ubuntu, you can enable it withecho 0 | sudo tee /proc/sys/kernel/yama/ptrace_scopeuntil the next reboot, orkernel.yama.ptrace_scope = 0in/etc/sysctl.d/10-ptrace.confafter the next reboot.My remaining problem is how to get
mplayerto start up without a significant delay, plus reforming copyright law so I have guaranteed access to the things I want to open with it.left as an exercise to the reader
fg doesn’t actually return the exit code of the last task though, so this is equivalent to just letting your terminal buffer your next command.
Presumably you’d also like to be notified if the long-running task fails.
Is there a proposed strategy which lets you see that?
You mean to distinguish between the two? What I meant was that if you do “foo; bar”, “bar” will run when “foo” exits, regardless of whether or not it was successful. If you want to say, run “foo” and run “bar” on success but “baz” on failure, you could use an if-else.
What I was pointing out was that you cannot do that. Try this:
Since ls ./fake typically has a non-zero exit code, we would expect to get “NOK” in response, but instead get “OK”.
Edit: I ran some more experiments, and I was wrong. Good catch!
zsh, but should be OK in bash.
EDIT: wait is nicer.
I’d like to edit this parent comment, but I’m no longer able to. Be aware that it is mischievous and wrong (hat tip @zhemao)! The experiment I ran was:
sleep 1 returns true, so it’s OK! I only backgrounded the sleep process, after all.
However, if I run:
So fg actually does return the exit code of the task you backgrounded admirably.