How to make pipe wait for end-of-file for then run a command?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
I tried the following command after watch this video on pipe shenanigans.
man -k . | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf | zathura -
It basically prints a list of manpages to dmenu for the user to select one of them, then it uses xargs to run man -Tpdf %
(print to stdout a pdf of the manpage git from the xargs' input) and pass the pdf to a pdf reader (zathura).
The problem is that (as you can see in the video) the pdf reader starts even before I select one manpage in dmenu. And if I click Esc and select none, the pdf reader is still open showing no document at all.
How can I make the pdf reader (and any other command in a pipe chain) to only run when its input reach a end-of-file or when it receives an input at all? Or, alternatively, how can I make a pipe chain to stop after one of the chained commands returns a non-zero exit status (so that if dmenu returns an error for not selecting an option, the following commands are not run)?
shell-script scripting pipe
add a comment |
I tried the following command after watch this video on pipe shenanigans.
man -k . | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf | zathura -
It basically prints a list of manpages to dmenu for the user to select one of them, then it uses xargs to run man -Tpdf %
(print to stdout a pdf of the manpage git from the xargs' input) and pass the pdf to a pdf reader (zathura).
The problem is that (as you can see in the video) the pdf reader starts even before I select one manpage in dmenu. And if I click Esc and select none, the pdf reader is still open showing no document at all.
How can I make the pdf reader (and any other command in a pipe chain) to only run when its input reach a end-of-file or when it receives an input at all? Or, alternatively, how can I make a pipe chain to stop after one of the chained commands returns a non-zero exit status (so that if dmenu returns an error for not selecting an option, the following commands are not run)?
shell-script scripting pipe
1
What shell are you using? Is this bash?
– terdon♦
6 hours ago
I've tried it on bash, zsh, and sh. All of them had the same behavior.
– Seninha
31 mins ago
1
Yes, the behavior is standard, I asked which shell because of bash'spipefail
option mentioned in Kusalandanda's answer.
– terdon♦
27 mins ago
add a comment |
I tried the following command after watch this video on pipe shenanigans.
man -k . | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf | zathura -
It basically prints a list of manpages to dmenu for the user to select one of them, then it uses xargs to run man -Tpdf %
(print to stdout a pdf of the manpage git from the xargs' input) and pass the pdf to a pdf reader (zathura).
The problem is that (as you can see in the video) the pdf reader starts even before I select one manpage in dmenu. And if I click Esc and select none, the pdf reader is still open showing no document at all.
How can I make the pdf reader (and any other command in a pipe chain) to only run when its input reach a end-of-file or when it receives an input at all? Or, alternatively, how can I make a pipe chain to stop after one of the chained commands returns a non-zero exit status (so that if dmenu returns an error for not selecting an option, the following commands are not run)?
shell-script scripting pipe
I tried the following command after watch this video on pipe shenanigans.
man -k . | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf | zathura -
It basically prints a list of manpages to dmenu for the user to select one of them, then it uses xargs to run man -Tpdf %
(print to stdout a pdf of the manpage git from the xargs' input) and pass the pdf to a pdf reader (zathura).
The problem is that (as you can see in the video) the pdf reader starts even before I select one manpage in dmenu. And if I click Esc and select none, the pdf reader is still open showing no document at all.
How can I make the pdf reader (and any other command in a pipe chain) to only run when its input reach a end-of-file or when it receives an input at all? Or, alternatively, how can I make a pipe chain to stop after one of the chained commands returns a non-zero exit status (so that if dmenu returns an error for not selecting an option, the following commands are not run)?
shell-script scripting pipe
shell-script scripting pipe
asked 6 hours ago
SeninhaSeninha
398210
398210
1
What shell are you using? Is this bash?
– terdon♦
6 hours ago
I've tried it on bash, zsh, and sh. All of them had the same behavior.
– Seninha
31 mins ago
1
Yes, the behavior is standard, I asked which shell because of bash'spipefail
option mentioned in Kusalandanda's answer.
– terdon♦
27 mins ago
add a comment |
1
What shell are you using? Is this bash?
– terdon♦
6 hours ago
I've tried it on bash, zsh, and sh. All of them had the same behavior.
– Seninha
31 mins ago
1
Yes, the behavior is standard, I asked which shell because of bash'spipefail
option mentioned in Kusalandanda's answer.
– terdon♦
27 mins ago
1
1
What shell are you using? Is this bash?
– terdon♦
6 hours ago
What shell are you using? Is this bash?
– terdon♦
6 hours ago
I've tried it on bash, zsh, and sh. All of them had the same behavior.
– Seninha
31 mins ago
I've tried it on bash, zsh, and sh. All of them had the same behavior.
– Seninha
31 mins ago
1
1
Yes, the behavior is standard, I asked which shell because of bash's
pipefail
option mentioned in Kusalandanda's answer.– terdon♦
27 mins ago
Yes, the behavior is standard, I asked which shell because of bash's
pipefail
option mentioned in Kusalandanda's answer.– terdon♦
27 mins ago
add a comment |
2 Answers
2
active
oldest
votes
All commands in a pipeline starts pretty much at the same time. It's only the I/O over the pipe that synchronises them. Also, a pipe can only hold as much information as the pipe's buffer allows.
You can therefore not avoid running one stage of a pipeline, because
- the command in that stage is started as soon as all other stages are started anyway, and
- if the command did not consume the input that comes in over the pipe, it would block the previous stages of the pipeline.
Instead, write the output to a file while letting the pipeline finish. Then use that file.
Example (as a function taking one argument):
myman () {
tmpfile=$( mktemp )
if man -k "$1" | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf >"$tmpfile"
then
zathura "$tmpfile"
fi
rm -f "$tmpfile"
}
This additionally would not run the zathura
program if the pipeline failed.
In the bash
shell, you would also want to set the pipefail
shell option with set -o pipefail
to have the pipeline return the exit status of the first command in the pipeline that fails. And you would want to make the tmpfile
variable local
:
myman () {
local tmpfile=$( mktemp )
if [ -o pipefail ]; then
set -o pipefail
trap 'set +o pipefail' RETURN
fi
if man -k "$1" | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf >"$tmpfile"
then
zathura "$tmpfile"
fi
rm -f "$tmpfile"
}
This sets the pipefail
option for the duration of the function, if it wasn't already set, and then unsets it if needed.
1
Whyrm -f
? Are you thinking of cases where the pipe changes the permissions of the tmpfile?
– terdon♦
6 hours ago
2
@terdon I'm thinking of cases where the temporary file is prematurely removed.rm -f
would not error out if the file already was removed (possibly byzathura
, I don't know).
– Kusalananda♦
6 hours ago
The first function does not work as expected: It will also make zathura show a black window, but now zathura runs after the pipeline finish, rather than running alongside the pipeline. This is because the pipeline returns the exit status of xargs, which is 0. The command that fails in the pipeline is dmenu (which returns 1 when I select nothing). The bash function with thepipefail
option works as expected (and in zsh too, which has the same option).
– Seninha
3 mins ago
add a comment |
Pdf files are supposed to be seekable; any pdf viewer will have to look first at the trailer and from there jump to the offsets from the xref table.
Since pipes are not seekable, zathura
is using an obfuscating trick, where it's copying all the input to a temporary file, and then use that temporary file as usually. This kind of "clever" trick is creating false hopes and is leading people to assume that pdf files are streamable.
But anyways, zathura
really does wait for the EOF before displaying the document, you don't have to do anything for that to hapen:
(sleep 10; cat file.pdf) | zathura -
# will really show the content of file.pdf after 10 seconds
The problem is that zathura
has no option to let it only open the window if the file's OK, and exit with an error case if that's not the case -- it will just stay there as if everything's OK:
$ dd if=file.pdf bs=50000 count=1 status=none | zathura -
error: could not open document # its window still hanging around showing nothing
$ echo $?
0 # really?
So even if you're redirecting the output to a temporary file yourself, and are only running zathura
with that tempfile if everything went OK, there's no guarantee that the user won't be served with a black window if zathura
doesn't like the output for one reason or another.
Btw,
man -X man
will display a manpage in an X11 window with gxditview
, even if it looks straight out of the '70 ;-)
And, of course, you could always use:
... | xargs xterm -e man
which, besides many other enhancements, will let you use regular expressions in searches and proper text selection.
add a comment |
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',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f515862%2fhow-to-make-pipe-wait-for-end-of-file-for-then-run-a-command%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
All commands in a pipeline starts pretty much at the same time. It's only the I/O over the pipe that synchronises them. Also, a pipe can only hold as much information as the pipe's buffer allows.
You can therefore not avoid running one stage of a pipeline, because
- the command in that stage is started as soon as all other stages are started anyway, and
- if the command did not consume the input that comes in over the pipe, it would block the previous stages of the pipeline.
Instead, write the output to a file while letting the pipeline finish. Then use that file.
Example (as a function taking one argument):
myman () {
tmpfile=$( mktemp )
if man -k "$1" | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf >"$tmpfile"
then
zathura "$tmpfile"
fi
rm -f "$tmpfile"
}
This additionally would not run the zathura
program if the pipeline failed.
In the bash
shell, you would also want to set the pipefail
shell option with set -o pipefail
to have the pipeline return the exit status of the first command in the pipeline that fails. And you would want to make the tmpfile
variable local
:
myman () {
local tmpfile=$( mktemp )
if [ -o pipefail ]; then
set -o pipefail
trap 'set +o pipefail' RETURN
fi
if man -k "$1" | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf >"$tmpfile"
then
zathura "$tmpfile"
fi
rm -f "$tmpfile"
}
This sets the pipefail
option for the duration of the function, if it wasn't already set, and then unsets it if needed.
1
Whyrm -f
? Are you thinking of cases where the pipe changes the permissions of the tmpfile?
– terdon♦
6 hours ago
2
@terdon I'm thinking of cases where the temporary file is prematurely removed.rm -f
would not error out if the file already was removed (possibly byzathura
, I don't know).
– Kusalananda♦
6 hours ago
The first function does not work as expected: It will also make zathura show a black window, but now zathura runs after the pipeline finish, rather than running alongside the pipeline. This is because the pipeline returns the exit status of xargs, which is 0. The command that fails in the pipeline is dmenu (which returns 1 when I select nothing). The bash function with thepipefail
option works as expected (and in zsh too, which has the same option).
– Seninha
3 mins ago
add a comment |
All commands in a pipeline starts pretty much at the same time. It's only the I/O over the pipe that synchronises them. Also, a pipe can only hold as much information as the pipe's buffer allows.
You can therefore not avoid running one stage of a pipeline, because
- the command in that stage is started as soon as all other stages are started anyway, and
- if the command did not consume the input that comes in over the pipe, it would block the previous stages of the pipeline.
Instead, write the output to a file while letting the pipeline finish. Then use that file.
Example (as a function taking one argument):
myman () {
tmpfile=$( mktemp )
if man -k "$1" | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf >"$tmpfile"
then
zathura "$tmpfile"
fi
rm -f "$tmpfile"
}
This additionally would not run the zathura
program if the pipeline failed.
In the bash
shell, you would also want to set the pipefail
shell option with set -o pipefail
to have the pipeline return the exit status of the first command in the pipeline that fails. And you would want to make the tmpfile
variable local
:
myman () {
local tmpfile=$( mktemp )
if [ -o pipefail ]; then
set -o pipefail
trap 'set +o pipefail' RETURN
fi
if man -k "$1" | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf >"$tmpfile"
then
zathura "$tmpfile"
fi
rm -f "$tmpfile"
}
This sets the pipefail
option for the duration of the function, if it wasn't already set, and then unsets it if needed.
1
Whyrm -f
? Are you thinking of cases where the pipe changes the permissions of the tmpfile?
– terdon♦
6 hours ago
2
@terdon I'm thinking of cases where the temporary file is prematurely removed.rm -f
would not error out if the file already was removed (possibly byzathura
, I don't know).
– Kusalananda♦
6 hours ago
The first function does not work as expected: It will also make zathura show a black window, but now zathura runs after the pipeline finish, rather than running alongside the pipeline. This is because the pipeline returns the exit status of xargs, which is 0. The command that fails in the pipeline is dmenu (which returns 1 when I select nothing). The bash function with thepipefail
option works as expected (and in zsh too, which has the same option).
– Seninha
3 mins ago
add a comment |
All commands in a pipeline starts pretty much at the same time. It's only the I/O over the pipe that synchronises them. Also, a pipe can only hold as much information as the pipe's buffer allows.
You can therefore not avoid running one stage of a pipeline, because
- the command in that stage is started as soon as all other stages are started anyway, and
- if the command did not consume the input that comes in over the pipe, it would block the previous stages of the pipeline.
Instead, write the output to a file while letting the pipeline finish. Then use that file.
Example (as a function taking one argument):
myman () {
tmpfile=$( mktemp )
if man -k "$1" | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf >"$tmpfile"
then
zathura "$tmpfile"
fi
rm -f "$tmpfile"
}
This additionally would not run the zathura
program if the pipeline failed.
In the bash
shell, you would also want to set the pipefail
shell option with set -o pipefail
to have the pipeline return the exit status of the first command in the pipeline that fails. And you would want to make the tmpfile
variable local
:
myman () {
local tmpfile=$( mktemp )
if [ -o pipefail ]; then
set -o pipefail
trap 'set +o pipefail' RETURN
fi
if man -k "$1" | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf >"$tmpfile"
then
zathura "$tmpfile"
fi
rm -f "$tmpfile"
}
This sets the pipefail
option for the duration of the function, if it wasn't already set, and then unsets it if needed.
All commands in a pipeline starts pretty much at the same time. It's only the I/O over the pipe that synchronises them. Also, a pipe can only hold as much information as the pipe's buffer allows.
You can therefore not avoid running one stage of a pipeline, because
- the command in that stage is started as soon as all other stages are started anyway, and
- if the command did not consume the input that comes in over the pipe, it would block the previous stages of the pipeline.
Instead, write the output to a file while letting the pipeline finish. Then use that file.
Example (as a function taking one argument):
myman () {
tmpfile=$( mktemp )
if man -k "$1" | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf >"$tmpfile"
then
zathura "$tmpfile"
fi
rm -f "$tmpfile"
}
This additionally would not run the zathura
program if the pipeline failed.
In the bash
shell, you would also want to set the pipefail
shell option with set -o pipefail
to have the pipeline return the exit status of the first command in the pipeline that fails. And you would want to make the tmpfile
variable local
:
myman () {
local tmpfile=$( mktemp )
if [ -o pipefail ]; then
set -o pipefail
trap 'set +o pipefail' RETURN
fi
if man -k "$1" | dmenu -l 20 | awk '{print $1}' | xargs -r man -Tpdf >"$tmpfile"
then
zathura "$tmpfile"
fi
rm -f "$tmpfile"
}
This sets the pipefail
option for the duration of the function, if it wasn't already set, and then unsets it if needed.
edited 5 hours ago
answered 6 hours ago
Kusalananda♦Kusalananda
144k18268448
144k18268448
1
Whyrm -f
? Are you thinking of cases where the pipe changes the permissions of the tmpfile?
– terdon♦
6 hours ago
2
@terdon I'm thinking of cases where the temporary file is prematurely removed.rm -f
would not error out if the file already was removed (possibly byzathura
, I don't know).
– Kusalananda♦
6 hours ago
The first function does not work as expected: It will also make zathura show a black window, but now zathura runs after the pipeline finish, rather than running alongside the pipeline. This is because the pipeline returns the exit status of xargs, which is 0. The command that fails in the pipeline is dmenu (which returns 1 when I select nothing). The bash function with thepipefail
option works as expected (and in zsh too, which has the same option).
– Seninha
3 mins ago
add a comment |
1
Whyrm -f
? Are you thinking of cases where the pipe changes the permissions of the tmpfile?
– terdon♦
6 hours ago
2
@terdon I'm thinking of cases where the temporary file is prematurely removed.rm -f
would not error out if the file already was removed (possibly byzathura
, I don't know).
– Kusalananda♦
6 hours ago
The first function does not work as expected: It will also make zathura show a black window, but now zathura runs after the pipeline finish, rather than running alongside the pipeline. This is because the pipeline returns the exit status of xargs, which is 0. The command that fails in the pipeline is dmenu (which returns 1 when I select nothing). The bash function with thepipefail
option works as expected (and in zsh too, which has the same option).
– Seninha
3 mins ago
1
1
Why
rm -f
? Are you thinking of cases where the pipe changes the permissions of the tmpfile?– terdon♦
6 hours ago
Why
rm -f
? Are you thinking of cases where the pipe changes the permissions of the tmpfile?– terdon♦
6 hours ago
2
2
@terdon I'm thinking of cases where the temporary file is prematurely removed.
rm -f
would not error out if the file already was removed (possibly by zathura
, I don't know).– Kusalananda♦
6 hours ago
@terdon I'm thinking of cases where the temporary file is prematurely removed.
rm -f
would not error out if the file already was removed (possibly by zathura
, I don't know).– Kusalananda♦
6 hours ago
The first function does not work as expected: It will also make zathura show a black window, but now zathura runs after the pipeline finish, rather than running alongside the pipeline. This is because the pipeline returns the exit status of xargs, which is 0. The command that fails in the pipeline is dmenu (which returns 1 when I select nothing). The bash function with the
pipefail
option works as expected (and in zsh too, which has the same option).– Seninha
3 mins ago
The first function does not work as expected: It will also make zathura show a black window, but now zathura runs after the pipeline finish, rather than running alongside the pipeline. This is because the pipeline returns the exit status of xargs, which is 0. The command that fails in the pipeline is dmenu (which returns 1 when I select nothing). The bash function with the
pipefail
option works as expected (and in zsh too, which has the same option).– Seninha
3 mins ago
add a comment |
Pdf files are supposed to be seekable; any pdf viewer will have to look first at the trailer and from there jump to the offsets from the xref table.
Since pipes are not seekable, zathura
is using an obfuscating trick, where it's copying all the input to a temporary file, and then use that temporary file as usually. This kind of "clever" trick is creating false hopes and is leading people to assume that pdf files are streamable.
But anyways, zathura
really does wait for the EOF before displaying the document, you don't have to do anything for that to hapen:
(sleep 10; cat file.pdf) | zathura -
# will really show the content of file.pdf after 10 seconds
The problem is that zathura
has no option to let it only open the window if the file's OK, and exit with an error case if that's not the case -- it will just stay there as if everything's OK:
$ dd if=file.pdf bs=50000 count=1 status=none | zathura -
error: could not open document # its window still hanging around showing nothing
$ echo $?
0 # really?
So even if you're redirecting the output to a temporary file yourself, and are only running zathura
with that tempfile if everything went OK, there's no guarantee that the user won't be served with a black window if zathura
doesn't like the output for one reason or another.
Btw,
man -X man
will display a manpage in an X11 window with gxditview
, even if it looks straight out of the '70 ;-)
And, of course, you could always use:
... | xargs xterm -e man
which, besides many other enhancements, will let you use regular expressions in searches and proper text selection.
add a comment |
Pdf files are supposed to be seekable; any pdf viewer will have to look first at the trailer and from there jump to the offsets from the xref table.
Since pipes are not seekable, zathura
is using an obfuscating trick, where it's copying all the input to a temporary file, and then use that temporary file as usually. This kind of "clever" trick is creating false hopes and is leading people to assume that pdf files are streamable.
But anyways, zathura
really does wait for the EOF before displaying the document, you don't have to do anything for that to hapen:
(sleep 10; cat file.pdf) | zathura -
# will really show the content of file.pdf after 10 seconds
The problem is that zathura
has no option to let it only open the window if the file's OK, and exit with an error case if that's not the case -- it will just stay there as if everything's OK:
$ dd if=file.pdf bs=50000 count=1 status=none | zathura -
error: could not open document # its window still hanging around showing nothing
$ echo $?
0 # really?
So even if you're redirecting the output to a temporary file yourself, and are only running zathura
with that tempfile if everything went OK, there's no guarantee that the user won't be served with a black window if zathura
doesn't like the output for one reason or another.
Btw,
man -X man
will display a manpage in an X11 window with gxditview
, even if it looks straight out of the '70 ;-)
And, of course, you could always use:
... | xargs xterm -e man
which, besides many other enhancements, will let you use regular expressions in searches and proper text selection.
add a comment |
Pdf files are supposed to be seekable; any pdf viewer will have to look first at the trailer and from there jump to the offsets from the xref table.
Since pipes are not seekable, zathura
is using an obfuscating trick, where it's copying all the input to a temporary file, and then use that temporary file as usually. This kind of "clever" trick is creating false hopes and is leading people to assume that pdf files are streamable.
But anyways, zathura
really does wait for the EOF before displaying the document, you don't have to do anything for that to hapen:
(sleep 10; cat file.pdf) | zathura -
# will really show the content of file.pdf after 10 seconds
The problem is that zathura
has no option to let it only open the window if the file's OK, and exit with an error case if that's not the case -- it will just stay there as if everything's OK:
$ dd if=file.pdf bs=50000 count=1 status=none | zathura -
error: could not open document # its window still hanging around showing nothing
$ echo $?
0 # really?
So even if you're redirecting the output to a temporary file yourself, and are only running zathura
with that tempfile if everything went OK, there's no guarantee that the user won't be served with a black window if zathura
doesn't like the output for one reason or another.
Btw,
man -X man
will display a manpage in an X11 window with gxditview
, even if it looks straight out of the '70 ;-)
And, of course, you could always use:
... | xargs xterm -e man
which, besides many other enhancements, will let you use regular expressions in searches and proper text selection.
Pdf files are supposed to be seekable; any pdf viewer will have to look first at the trailer and from there jump to the offsets from the xref table.
Since pipes are not seekable, zathura
is using an obfuscating trick, where it's copying all the input to a temporary file, and then use that temporary file as usually. This kind of "clever" trick is creating false hopes and is leading people to assume that pdf files are streamable.
But anyways, zathura
really does wait for the EOF before displaying the document, you don't have to do anything for that to hapen:
(sleep 10; cat file.pdf) | zathura -
# will really show the content of file.pdf after 10 seconds
The problem is that zathura
has no option to let it only open the window if the file's OK, and exit with an error case if that's not the case -- it will just stay there as if everything's OK:
$ dd if=file.pdf bs=50000 count=1 status=none | zathura -
error: could not open document # its window still hanging around showing nothing
$ echo $?
0 # really?
So even if you're redirecting the output to a temporary file yourself, and are only running zathura
with that tempfile if everything went OK, there's no guarantee that the user won't be served with a black window if zathura
doesn't like the output for one reason or another.
Btw,
man -X man
will display a manpage in an X11 window with gxditview
, even if it looks straight out of the '70 ;-)
And, of course, you could always use:
... | xargs xterm -e man
which, besides many other enhancements, will let you use regular expressions in searches and proper text selection.
edited 2 hours ago
answered 3 hours ago
mosvymosvy
10.9k11340
10.9k11340
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f515862%2fhow-to-make-pipe-wait-for-end-of-file-for-then-run-a-command%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
What shell are you using? Is this bash?
– terdon♦
6 hours ago
I've tried it on bash, zsh, and sh. All of them had the same behavior.
– Seninha
31 mins ago
1
Yes, the behavior is standard, I asked which shell because of bash's
pipefail
option mentioned in Kusalandanda's answer.– terdon♦
27 mins ago