mhoye

Is there an elegant way, in the shell, to say “run this program until this other program is finished”?

I know I could run a thing, get a PID and then append a command with “&& kill pid” or something but that feels clunky.

Mar 17 at 5:50pmWeb
Show threadwaffles 🇨🇦Mar 17

@mhoye isn’t that what the ‘wait’ cmd does?

Edit: oh I understand what you’re saying. That sounds more complicated and now I also want to know if there’s an existing solution.

Show threadmhoyeMar 17
@waffles I thought wait was “pause here until a process exits and then continue” but not “run foo until that process exits” without extra work.
Show threadGlyphMar 17
@mhoye @waffles the "until" in "run foo until" suggests a signal at the end though, which means you've got all the usual signal handling choices (HUP? INT? TERM? KILL? start with one and escalate?), so "$!" and kill and wait seems somewhat necessary
Show threadGlyphMar 17
@mhoye @waffles not to mention who wants what file descriptors. can you say anything else about the underlying problem?
Show threadmhoyeMar 17
@glyph @waffles Really, the underlying problem is that I have a program to run that's single threaded, offers no visible progress indicators and might take ages. All I want is "run [screensaver] until [job] finishes then pop up [alert]"
Show threadGlyphMar 17
@mhoye @waffles yeah I golfed it for a while but really can't come up with anything better than https://gist.github.com/glyph/a063c96615dbebc1d43109610407b433
firstsecond.sh

GitHub Gist: instantly share code, notes, and snippets.

Gist
Show threadGlyphMar 17
@mhoye @waffles it's super annoying that everything that looks like a "higher order function" in shell is actually just a string, it makes this sort of thing very annoying 😐
Show threadmhoyeMar 17
@glyph @waffles that is very similar to where I ended up, too. Thanks for taking a look.
Show threadGlyphMar 17
@mhoye @waffles it was an interesting problem and definitely one I've faced before. real solution is of course your main thing should have a --progress option :). I'll follow up if ricocheting thoughts produce something better later
Show threadsamir, a terminally deprecated methodMar 17

@glyph @mhoye @waffles This doesn’t solve the problem completely, but in case it’s useful: you might find pv helpful. It will render a progress bar and pipe a file into stdout, which you can then pipe to another process.

https://man7.org/linux/man-pages/man1/pv.1.html

pv(1) - Linux manual page

Show threadGlyphMar 17
@samir @mhoye @waffles I skipped over recommendations like this (and others, like zsh coproc) because I assumed if some file I/O were happening he would have said so, but perhaps useful for onlookers :)
Show threadThird spruce tree on the leftMar 17

@glyph @mhoye @waffles

I don't see any reason not to just kill the screensaver progA after long.running.progB terminates. If progA were _doing_ something with files, then maybe send it a SIGTERM/HUP not a SIGKILL, but if its NOT doing i/o just kill it.

1. run and background progA&
2. progB
3. kill -1/15 pogA (or by PID)

You're just hung up (heh) over a hard kill feeling clunky? If progA is written correctly itll properly handle a SIGINT/TERM/HUP and close nice.

Show threadmhoyeMar 17

@tezoatlipoca @glyph @waffles

If you don't see any reason to do the thing I specifically said I wanted to do, consider that an opportunity for inquiry rather than sanctimony. With exactly one hundred percent of the respect this is due, if I wanted to just kill the process manually when I observe that it is finished, the question I'm asking would not exist.

Show threadMatt PanaroMar 17
@mhoye @glyph @waffles
ok I'm firing from the hip here, but will a bash coprocess help?
Show threadBlackoverflowMar 17

@mhoye
This works by killing the whole subshell process tree:
`(run_this & other_program; kill 0)`

Tried with `(vlc & sleep 3s; kill 0)`

Show threadMarcos DioneMar 17
@blackoverflow @mhoye I was about to say "somethimg something cgroups", but this looks way simpler.
Show threadChristmas TreeMar 17
@blackoverflow @mhoye daaaammmnnn that's clever!
Show threadChris SiebenmannMar 17

@mhoye Unfortunately, I think the Unix process and signal model makes this inextricably messy. There's no polite general way to ask a process to terminate, and you can only easily find out about a child ending if you're its parent. So you're going to have to kill the process with a signal and that means knowing its PID and ... mess.

(If the program has a specific API where you can say 'please exit', you can use it, but that's not a general solution.)

Show threadzevMar 18

@cks @mhoye

There's no polite general way to ask a process to terminate

Is that not what SIGTERM is? (I suppose it could be argued that a signal that defaults to immediate termination isn't entirely "polite", but hopefully a program that would actually be sensitive to such impoliteness would install a handler for it to do appropriate things before exiting.)

you can only easily find out about a child ending if you're its parent.

In terms of portable mechanisms yes, though on a reasonably recent Linux you can use poll(2) or the like on a a pidfd for a non-child process.

(Offhand I don't know of any existing tools that expose pidfds in a shell-convenient way, but if someone were sufficiently desperate I expect a bash extension loaded via enable -f could probably do it in a reasonably ergonomic fashion.)

Show threadChris SiebenmannMar 18
@zev @mhoye It's not safe to SIGTERM arbitrary programs and assume that everything will go fine, so in that sense it's not polite. In my view, a polite general way would have to be something that processes ignore by default. SIGTERM's defaults make it not an 'ask', not really.
Show threadAN/CRM-114Mar 18

@mhoye uh I’m away from my desk and this is probably wrong but can you run a sub shell like

{ myexpensivecommand; kill $PPID } &

Show threadBen RosengartMar 18
@mhoye if it’s the parent of the other program, you can trap SIGCHLD?