What's the best way to interrupt a running program in response to another program in a script?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












My usecase is a yad program that uses another script that mounts a filesystem. What i'm currently doing and somewhat unsatisfied by is a complex dance of kill and wait to 'simulate' having the return value of the yad available.



(mount script is above the snippet and irrelevant. Just be aware that it sends a write to the 'FD' - not SEL_FD - when it quits or remounts, which the code below uses to loop or not depending on GAME_SEL and REMOUNTED)



#stdout to FD (to get the selection on exit and still be a background proc)
GAME_SEL=$(mktemp -u -p "$XDG_RUNTIME_DIR" "$0##*/.XXXXXXXXXX")
mkfifo "$GAME_SEL"
exec SEL_FD<> "$GAME_SEL"

yad
--width=600
--height=660
--center
--window-icon "applications-games"
--title "Dosbox Launcher with games overlay"
--text=" Click to play"
--list
--noheaders
--search-column=2
--regex-search
--column="Path:HD"
--column="Game Config:TEXT"
--button=gtk-close:1
--button=gtk-ok:0
"$CONF_LIST[@]"
2>/dev/null 1>& "$SEL_FD" &
yad_pid=$!

#wait for copy-on-write-drive notification (quit or mount doesn't matter)
#and kill the dialog using yad signal for graceful failure termination
( read -u "$FD"; kill -USR2 $yad_pid ) &
pidof_killer=$!

#wait for yad termination and read its stdout on a timeout. If triggers timeout, it's empty
wait $yad_pid 2>/dev/null
read -t 0.1 -u "$SEL_FD" GAME
exec SEL_FD>&- #close FD

#kill the killer if still active
kill $pidof_killer 2>/dev/null
wait $pidof_killer 2>/dev/null #supresses 'Terminated' output too
#if the killer was already dead (it caught a notification), this is 0, otherwise != 0
REMOUNTED=$?


As far as i can tell i need this complexity because I need to background the yad process in order to be able to kill it in response to the mount script FD notification and this in turn causes the return value of yad (not the stdout which is captured by SEL_FD) to be uncapturable by the main script process. Is there a much better way of doing this logic? It feels like this is far too complex.







share|improve this question



















  • Note, with bash wait pid has a return code equal to that of the process waited on.
    – meuh
    Jun 21 at 9:52










  • That makes sense. I am already using that from the $? at the last line now that i think about it, just using the lack of any output and if the killer was still alive to differentiate if it was quit/unmount or remount of the filesystem instead of using the yad return code directly... that could get rid of the 'wait $pidof_killer' i guess.
    – i30817
    Jun 21 at 11:52















up vote
0
down vote

favorite












My usecase is a yad program that uses another script that mounts a filesystem. What i'm currently doing and somewhat unsatisfied by is a complex dance of kill and wait to 'simulate' having the return value of the yad available.



(mount script is above the snippet and irrelevant. Just be aware that it sends a write to the 'FD' - not SEL_FD - when it quits or remounts, which the code below uses to loop or not depending on GAME_SEL and REMOUNTED)



#stdout to FD (to get the selection on exit and still be a background proc)
GAME_SEL=$(mktemp -u -p "$XDG_RUNTIME_DIR" "$0##*/.XXXXXXXXXX")
mkfifo "$GAME_SEL"
exec SEL_FD<> "$GAME_SEL"

yad
--width=600
--height=660
--center
--window-icon "applications-games"
--title "Dosbox Launcher with games overlay"
--text=" Click to play"
--list
--noheaders
--search-column=2
--regex-search
--column="Path:HD"
--column="Game Config:TEXT"
--button=gtk-close:1
--button=gtk-ok:0
"$CONF_LIST[@]"
2>/dev/null 1>& "$SEL_FD" &
yad_pid=$!

#wait for copy-on-write-drive notification (quit or mount doesn't matter)
#and kill the dialog using yad signal for graceful failure termination
( read -u "$FD"; kill -USR2 $yad_pid ) &
pidof_killer=$!

#wait for yad termination and read its stdout on a timeout. If triggers timeout, it's empty
wait $yad_pid 2>/dev/null
read -t 0.1 -u "$SEL_FD" GAME
exec SEL_FD>&- #close FD

#kill the killer if still active
kill $pidof_killer 2>/dev/null
wait $pidof_killer 2>/dev/null #supresses 'Terminated' output too
#if the killer was already dead (it caught a notification), this is 0, otherwise != 0
REMOUNTED=$?


As far as i can tell i need this complexity because I need to background the yad process in order to be able to kill it in response to the mount script FD notification and this in turn causes the return value of yad (not the stdout which is captured by SEL_FD) to be uncapturable by the main script process. Is there a much better way of doing this logic? It feels like this is far too complex.







share|improve this question



















  • Note, with bash wait pid has a return code equal to that of the process waited on.
    – meuh
    Jun 21 at 9:52










  • That makes sense. I am already using that from the $? at the last line now that i think about it, just using the lack of any output and if the killer was still alive to differentiate if it was quit/unmount or remount of the filesystem instead of using the yad return code directly... that could get rid of the 'wait $pidof_killer' i guess.
    – i30817
    Jun 21 at 11:52













up vote
0
down vote

favorite









up vote
0
down vote

favorite











My usecase is a yad program that uses another script that mounts a filesystem. What i'm currently doing and somewhat unsatisfied by is a complex dance of kill and wait to 'simulate' having the return value of the yad available.



(mount script is above the snippet and irrelevant. Just be aware that it sends a write to the 'FD' - not SEL_FD - when it quits or remounts, which the code below uses to loop or not depending on GAME_SEL and REMOUNTED)



#stdout to FD (to get the selection on exit and still be a background proc)
GAME_SEL=$(mktemp -u -p "$XDG_RUNTIME_DIR" "$0##*/.XXXXXXXXXX")
mkfifo "$GAME_SEL"
exec SEL_FD<> "$GAME_SEL"

yad
--width=600
--height=660
--center
--window-icon "applications-games"
--title "Dosbox Launcher with games overlay"
--text=" Click to play"
--list
--noheaders
--search-column=2
--regex-search
--column="Path:HD"
--column="Game Config:TEXT"
--button=gtk-close:1
--button=gtk-ok:0
"$CONF_LIST[@]"
2>/dev/null 1>& "$SEL_FD" &
yad_pid=$!

#wait for copy-on-write-drive notification (quit or mount doesn't matter)
#and kill the dialog using yad signal for graceful failure termination
( read -u "$FD"; kill -USR2 $yad_pid ) &
pidof_killer=$!

#wait for yad termination and read its stdout on a timeout. If triggers timeout, it's empty
wait $yad_pid 2>/dev/null
read -t 0.1 -u "$SEL_FD" GAME
exec SEL_FD>&- #close FD

#kill the killer if still active
kill $pidof_killer 2>/dev/null
wait $pidof_killer 2>/dev/null #supresses 'Terminated' output too
#if the killer was already dead (it caught a notification), this is 0, otherwise != 0
REMOUNTED=$?


As far as i can tell i need this complexity because I need to background the yad process in order to be able to kill it in response to the mount script FD notification and this in turn causes the return value of yad (not the stdout which is captured by SEL_FD) to be uncapturable by the main script process. Is there a much better way of doing this logic? It feels like this is far too complex.







share|improve this question











My usecase is a yad program that uses another script that mounts a filesystem. What i'm currently doing and somewhat unsatisfied by is a complex dance of kill and wait to 'simulate' having the return value of the yad available.



(mount script is above the snippet and irrelevant. Just be aware that it sends a write to the 'FD' - not SEL_FD - when it quits or remounts, which the code below uses to loop or not depending on GAME_SEL and REMOUNTED)



#stdout to FD (to get the selection on exit and still be a background proc)
GAME_SEL=$(mktemp -u -p "$XDG_RUNTIME_DIR" "$0##*/.XXXXXXXXXX")
mkfifo "$GAME_SEL"
exec SEL_FD<> "$GAME_SEL"

yad
--width=600
--height=660
--center
--window-icon "applications-games"
--title "Dosbox Launcher with games overlay"
--text=" Click to play"
--list
--noheaders
--search-column=2
--regex-search
--column="Path:HD"
--column="Game Config:TEXT"
--button=gtk-close:1
--button=gtk-ok:0
"$CONF_LIST[@]"
2>/dev/null 1>& "$SEL_FD" &
yad_pid=$!

#wait for copy-on-write-drive notification (quit or mount doesn't matter)
#and kill the dialog using yad signal for graceful failure termination
( read -u "$FD"; kill -USR2 $yad_pid ) &
pidof_killer=$!

#wait for yad termination and read its stdout on a timeout. If triggers timeout, it's empty
wait $yad_pid 2>/dev/null
read -t 0.1 -u "$SEL_FD" GAME
exec SEL_FD>&- #close FD

#kill the killer if still active
kill $pidof_killer 2>/dev/null
wait $pidof_killer 2>/dev/null #supresses 'Terminated' output too
#if the killer was already dead (it caught a notification), this is 0, otherwise != 0
REMOUNTED=$?


As far as i can tell i need this complexity because I need to background the yad process in order to be able to kill it in response to the mount script FD notification and this in turn causes the return value of yad (not the stdout which is captured by SEL_FD) to be uncapturable by the main script process. Is there a much better way of doing this logic? It feels like this is far too complex.









share|improve this question










share|improve this question




share|improve this question









asked Jun 21 at 5:10









i30817

1284




1284











  • Note, with bash wait pid has a return code equal to that of the process waited on.
    – meuh
    Jun 21 at 9:52










  • That makes sense. I am already using that from the $? at the last line now that i think about it, just using the lack of any output and if the killer was still alive to differentiate if it was quit/unmount or remount of the filesystem instead of using the yad return code directly... that could get rid of the 'wait $pidof_killer' i guess.
    – i30817
    Jun 21 at 11:52

















  • Note, with bash wait pid has a return code equal to that of the process waited on.
    – meuh
    Jun 21 at 9:52










  • That makes sense. I am already using that from the $? at the last line now that i think about it, just using the lack of any output and if the killer was still alive to differentiate if it was quit/unmount or remount of the filesystem instead of using the yad return code directly... that could get rid of the 'wait $pidof_killer' i guess.
    – i30817
    Jun 21 at 11:52
















Note, with bash wait pid has a return code equal to that of the process waited on.
– meuh
Jun 21 at 9:52




Note, with bash wait pid has a return code equal to that of the process waited on.
– meuh
Jun 21 at 9:52












That makes sense. I am already using that from the $? at the last line now that i think about it, just using the lack of any output and if the killer was still alive to differentiate if it was quit/unmount or remount of the filesystem instead of using the yad return code directly... that could get rid of the 'wait $pidof_killer' i guess.
– i30817
Jun 21 at 11:52





That makes sense. I am already using that from the $? at the last line now that i think about it, just using the lack of any output and if the killer was still alive to differentiate if it was quit/unmount or remount of the filesystem instead of using the yad return code directly... that could get rid of the 'wait $pidof_killer' i guess.
– i30817
Jun 21 at 11:52
















active

oldest

votes











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%2f451017%2fwhats-the-best-way-to-interrupt-a-running-program-in-response-to-another-progra%23new-answer', 'question_page');

);

Post as a guest



































active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes










 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f451017%2fwhats-the-best-way-to-interrupt-a-running-program-in-response-to-another-progra%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?