mhoyeMar 17

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.

Show threadwaffles 🇨🇦

@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.

Mar 17 at 5:52pmWeb
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?