xdg-open block until spawned process is killed
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I have a lot of documents to view, and I'd like to view them one by one, so the next opens when I close the previous.
I've done this with evince before, with
for i in `ls | grep .pdf`; do evince $i; done
However doing the same with xdg-open fails because xdg-open does not block like evince does.
Is there a way to run the same for loop, but with xdg-open, so that when I close the application that was opened, the next iteration of the for loop runs?
bash xdg-open
add a comment |Â
up vote
1
down vote
favorite
I have a lot of documents to view, and I'd like to view them one by one, so the next opens when I close the previous.
I've done this with evince before, with
for i in `ls | grep .pdf`; do evince $i; done
However doing the same with xdg-open fails because xdg-open does not block like evince does.
Is there a way to run the same for loop, but with xdg-open, so that when I close the application that was opened, the next iteration of the for loop runs?
bash xdg-open
short answer: no. long answer: modify the source
â Ipor Sircer
Mar 5 at 16:32
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have a lot of documents to view, and I'd like to view them one by one, so the next opens when I close the previous.
I've done this with evince before, with
for i in `ls | grep .pdf`; do evince $i; done
However doing the same with xdg-open fails because xdg-open does not block like evince does.
Is there a way to run the same for loop, but with xdg-open, so that when I close the application that was opened, the next iteration of the for loop runs?
bash xdg-open
I have a lot of documents to view, and I'd like to view them one by one, so the next opens when I close the previous.
I've done this with evince before, with
for i in `ls | grep .pdf`; do evince $i; done
However doing the same with xdg-open fails because xdg-open does not block like evince does.
Is there a way to run the same for loop, but with xdg-open, so that when I close the application that was opened, the next iteration of the for loop runs?
bash xdg-open
edited Mar 5 at 15:17
Jeff Schaller
31.2k846105
31.2k846105
asked Mar 5 at 15:15
Brydon Gibson
13215
13215
short answer: no. long answer: modify the source
â Ipor Sircer
Mar 5 at 16:32
add a comment |Â
short answer: no. long answer: modify the source
â Ipor Sircer
Mar 5 at 16:32
short answer: no. long answer: modify the source
â Ipor Sircer
Mar 5 at 16:32
short answer: no. long answer: modify the source
â Ipor Sircer
Mar 5 at 16:32
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
I couldn't find a clean way, so this is a work-around; open each file then run a busy-loop waiting for "the" matching process to exit. I've also updated your for
loop so that you're not parsing ls and are quoting the filename parameter:
#!/bin/bash
for i in *.pdf
do
xdg-open "$i"
t=$(tty)
t=$t##/dev/
s=$(ps -o session= -p $$)
while pgrep -f "$i" --terminal "$t" --uid "$(id -u)" --session "$s" >/dev/null 2>&1
do
sleep 1
done
done
The assumption here is that xdg-open will open the file; that process gets forked off by the desktop environment and control returns to the script. The script then gathers the tty, session, and current user ID and asks pgrep
to look for (the) process matching all of these criteria:
- full process name includes the filename from the loop
- the associated terminal is the one we're running from
- the UID of the process matches ours
- the process session matches ours
... all in an attempt to catch only the corresponding process that xdg-open launched.
When that process no longer exists, we continue with the for
loop on to the next file.
If the one-second delay is too long, you could replace that (on Linux) with a sub-second sleep, or a simple :
for no waiting at all.
This is an awesome solution! A little hacky but it gets the job done. Very smart.
â Brydon Gibson
Mar 5 at 16:40
Thank you! Don't feel rushed to accept my (or any first) answer; I'm not an expert at desktop environments, so there may be a better way.
â Jeff Schaller
Mar 5 at 16:42
Unfortunately this will fail if the file is opened by an existing process. You can see this happen e.g. withgedit
, if thatâÂÂs the default editor for text files: startgedit
, thenxdg-open
a text file; the file will open ingedit
, and the above script wonâÂÂt match anything.
â Stephen Kitt
Mar 6 at 12:21
@StephenKitt would the gedit process have to have started from the same tty/session, too?
â Jeff Schaller
Mar 6 at 12:32
ThatâÂÂs not sufficient, because the file name doesnâÂÂt show up on the command line of the running process.
â Stephen Kitt
Mar 6 at 12:44
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
I couldn't find a clean way, so this is a work-around; open each file then run a busy-loop waiting for "the" matching process to exit. I've also updated your for
loop so that you're not parsing ls and are quoting the filename parameter:
#!/bin/bash
for i in *.pdf
do
xdg-open "$i"
t=$(tty)
t=$t##/dev/
s=$(ps -o session= -p $$)
while pgrep -f "$i" --terminal "$t" --uid "$(id -u)" --session "$s" >/dev/null 2>&1
do
sleep 1
done
done
The assumption here is that xdg-open will open the file; that process gets forked off by the desktop environment and control returns to the script. The script then gathers the tty, session, and current user ID and asks pgrep
to look for (the) process matching all of these criteria:
- full process name includes the filename from the loop
- the associated terminal is the one we're running from
- the UID of the process matches ours
- the process session matches ours
... all in an attempt to catch only the corresponding process that xdg-open launched.
When that process no longer exists, we continue with the for
loop on to the next file.
If the one-second delay is too long, you could replace that (on Linux) with a sub-second sleep, or a simple :
for no waiting at all.
This is an awesome solution! A little hacky but it gets the job done. Very smart.
â Brydon Gibson
Mar 5 at 16:40
Thank you! Don't feel rushed to accept my (or any first) answer; I'm not an expert at desktop environments, so there may be a better way.
â Jeff Schaller
Mar 5 at 16:42
Unfortunately this will fail if the file is opened by an existing process. You can see this happen e.g. withgedit
, if thatâÂÂs the default editor for text files: startgedit
, thenxdg-open
a text file; the file will open ingedit
, and the above script wonâÂÂt match anything.
â Stephen Kitt
Mar 6 at 12:21
@StephenKitt would the gedit process have to have started from the same tty/session, too?
â Jeff Schaller
Mar 6 at 12:32
ThatâÂÂs not sufficient, because the file name doesnâÂÂt show up on the command line of the running process.
â Stephen Kitt
Mar 6 at 12:44
add a comment |Â
up vote
2
down vote
accepted
I couldn't find a clean way, so this is a work-around; open each file then run a busy-loop waiting for "the" matching process to exit. I've also updated your for
loop so that you're not parsing ls and are quoting the filename parameter:
#!/bin/bash
for i in *.pdf
do
xdg-open "$i"
t=$(tty)
t=$t##/dev/
s=$(ps -o session= -p $$)
while pgrep -f "$i" --terminal "$t" --uid "$(id -u)" --session "$s" >/dev/null 2>&1
do
sleep 1
done
done
The assumption here is that xdg-open will open the file; that process gets forked off by the desktop environment and control returns to the script. The script then gathers the tty, session, and current user ID and asks pgrep
to look for (the) process matching all of these criteria:
- full process name includes the filename from the loop
- the associated terminal is the one we're running from
- the UID of the process matches ours
- the process session matches ours
... all in an attempt to catch only the corresponding process that xdg-open launched.
When that process no longer exists, we continue with the for
loop on to the next file.
If the one-second delay is too long, you could replace that (on Linux) with a sub-second sleep, or a simple :
for no waiting at all.
This is an awesome solution! A little hacky but it gets the job done. Very smart.
â Brydon Gibson
Mar 5 at 16:40
Thank you! Don't feel rushed to accept my (or any first) answer; I'm not an expert at desktop environments, so there may be a better way.
â Jeff Schaller
Mar 5 at 16:42
Unfortunately this will fail if the file is opened by an existing process. You can see this happen e.g. withgedit
, if thatâÂÂs the default editor for text files: startgedit
, thenxdg-open
a text file; the file will open ingedit
, and the above script wonâÂÂt match anything.
â Stephen Kitt
Mar 6 at 12:21
@StephenKitt would the gedit process have to have started from the same tty/session, too?
â Jeff Schaller
Mar 6 at 12:32
ThatâÂÂs not sufficient, because the file name doesnâÂÂt show up on the command line of the running process.
â Stephen Kitt
Mar 6 at 12:44
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
I couldn't find a clean way, so this is a work-around; open each file then run a busy-loop waiting for "the" matching process to exit. I've also updated your for
loop so that you're not parsing ls and are quoting the filename parameter:
#!/bin/bash
for i in *.pdf
do
xdg-open "$i"
t=$(tty)
t=$t##/dev/
s=$(ps -o session= -p $$)
while pgrep -f "$i" --terminal "$t" --uid "$(id -u)" --session "$s" >/dev/null 2>&1
do
sleep 1
done
done
The assumption here is that xdg-open will open the file; that process gets forked off by the desktop environment and control returns to the script. The script then gathers the tty, session, and current user ID and asks pgrep
to look for (the) process matching all of these criteria:
- full process name includes the filename from the loop
- the associated terminal is the one we're running from
- the UID of the process matches ours
- the process session matches ours
... all in an attempt to catch only the corresponding process that xdg-open launched.
When that process no longer exists, we continue with the for
loop on to the next file.
If the one-second delay is too long, you could replace that (on Linux) with a sub-second sleep, or a simple :
for no waiting at all.
I couldn't find a clean way, so this is a work-around; open each file then run a busy-loop waiting for "the" matching process to exit. I've also updated your for
loop so that you're not parsing ls and are quoting the filename parameter:
#!/bin/bash
for i in *.pdf
do
xdg-open "$i"
t=$(tty)
t=$t##/dev/
s=$(ps -o session= -p $$)
while pgrep -f "$i" --terminal "$t" --uid "$(id -u)" --session "$s" >/dev/null 2>&1
do
sleep 1
done
done
The assumption here is that xdg-open will open the file; that process gets forked off by the desktop environment and control returns to the script. The script then gathers the tty, session, and current user ID and asks pgrep
to look for (the) process matching all of these criteria:
- full process name includes the filename from the loop
- the associated terminal is the one we're running from
- the UID of the process matches ours
- the process session matches ours
... all in an attempt to catch only the corresponding process that xdg-open launched.
When that process no longer exists, we continue with the for
loop on to the next file.
If the one-second delay is too long, you could replace that (on Linux) with a sub-second sleep, or a simple :
for no waiting at all.
answered Mar 5 at 16:36
Jeff Schaller
31.2k846105
31.2k846105
This is an awesome solution! A little hacky but it gets the job done. Very smart.
â Brydon Gibson
Mar 5 at 16:40
Thank you! Don't feel rushed to accept my (or any first) answer; I'm not an expert at desktop environments, so there may be a better way.
â Jeff Schaller
Mar 5 at 16:42
Unfortunately this will fail if the file is opened by an existing process. You can see this happen e.g. withgedit
, if thatâÂÂs the default editor for text files: startgedit
, thenxdg-open
a text file; the file will open ingedit
, and the above script wonâÂÂt match anything.
â Stephen Kitt
Mar 6 at 12:21
@StephenKitt would the gedit process have to have started from the same tty/session, too?
â Jeff Schaller
Mar 6 at 12:32
ThatâÂÂs not sufficient, because the file name doesnâÂÂt show up on the command line of the running process.
â Stephen Kitt
Mar 6 at 12:44
add a comment |Â
This is an awesome solution! A little hacky but it gets the job done. Very smart.
â Brydon Gibson
Mar 5 at 16:40
Thank you! Don't feel rushed to accept my (or any first) answer; I'm not an expert at desktop environments, so there may be a better way.
â Jeff Schaller
Mar 5 at 16:42
Unfortunately this will fail if the file is opened by an existing process. You can see this happen e.g. withgedit
, if thatâÂÂs the default editor for text files: startgedit
, thenxdg-open
a text file; the file will open ingedit
, and the above script wonâÂÂt match anything.
â Stephen Kitt
Mar 6 at 12:21
@StephenKitt would the gedit process have to have started from the same tty/session, too?
â Jeff Schaller
Mar 6 at 12:32
ThatâÂÂs not sufficient, because the file name doesnâÂÂt show up on the command line of the running process.
â Stephen Kitt
Mar 6 at 12:44
This is an awesome solution! A little hacky but it gets the job done. Very smart.
â Brydon Gibson
Mar 5 at 16:40
This is an awesome solution! A little hacky but it gets the job done. Very smart.
â Brydon Gibson
Mar 5 at 16:40
Thank you! Don't feel rushed to accept my (or any first) answer; I'm not an expert at desktop environments, so there may be a better way.
â Jeff Schaller
Mar 5 at 16:42
Thank you! Don't feel rushed to accept my (or any first) answer; I'm not an expert at desktop environments, so there may be a better way.
â Jeff Schaller
Mar 5 at 16:42
Unfortunately this will fail if the file is opened by an existing process. You can see this happen e.g. with
gedit
, if thatâÂÂs the default editor for text files: start gedit
, then xdg-open
a text file; the file will open in gedit
, and the above script wonâÂÂt match anything.â Stephen Kitt
Mar 6 at 12:21
Unfortunately this will fail if the file is opened by an existing process. You can see this happen e.g. with
gedit
, if thatâÂÂs the default editor for text files: start gedit
, then xdg-open
a text file; the file will open in gedit
, and the above script wonâÂÂt match anything.â Stephen Kitt
Mar 6 at 12:21
@StephenKitt would the gedit process have to have started from the same tty/session, too?
â Jeff Schaller
Mar 6 at 12:32
@StephenKitt would the gedit process have to have started from the same tty/session, too?
â Jeff Schaller
Mar 6 at 12:32
ThatâÂÂs not sufficient, because the file name doesnâÂÂt show up on the command line of the running process.
â Stephen Kitt
Mar 6 at 12:44
ThatâÂÂs not sufficient, because the file name doesnâÂÂt show up on the command line of the running process.
â Stephen Kitt
Mar 6 at 12:44
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f428296%2fxdg-open-block-until-spawned-process-is-killed%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
short answer: no. long answer: modify the source
â Ipor Sircer
Mar 5 at 16:32