How to make a pipeline wait for end-of-file or stop after an error?shell unexpected end of file errorsyntax...

web3.py web3.isConnected() returns false always

How do I reattach a shelf to the wall when it ripped out of the wall?

How can the Zone of Truth spell be defeated without the caster knowing?

What is Niska's accent?

Symbolic Multivariate Distribution

Is the claim "Employers won't employ people with no 'social media presence'" realistic?

US visa is under administrative processing, I need the passport back ASAP

Exchange,swap or switch

How can I practically buy stocks?

The Defining Moment

Is there a way to get a compiler for the original B programming language?

Question about かな and だろう

Why isn't the definition of absolute value applied when squaring a radical containing a variable?

Is it idiomatic to construct against `this`?

Will tsunami waves travel forever if there was no land?

Pulling the rope with one hand is as heavy as with two hands?

what is the sudo password for a --disabled-password user

Packing rectangles: Does rotation ever help?

As an international instructor, should I openly talk about my accent?

Interpret a multiple linear regression when Y is log transformed

How to verbalise code in Mathematica?

Examples of non trivial equivalence relations , I mean equivalence relations without the expression " same ... as" in their definition?

What happened to Captain America in Endgame?

How to solve constants out of the internal energy equation?



How to make a pipeline wait for end-of-file or stop after an error?


shell unexpected end of file errorsyntax error: unexpected end of filesyntax error: unexpected end of the fileNamed pipes: several experiments leads to confusionSyntax Error: unexpected end of file — Bash scriptHow does a pipeline knows when to stopFixing Signal 13 (SIGPIPE) error for find and grep pipelineError message - dummy.sh: line 29: syntax error: unexpected end of filehow to make Expect to wait until another script finishedHow to make reading and writing the same file in the same pipeline always “fail”?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







4















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)?










share|improve this question




















  • 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
    1 hour ago






  • 1





    Yes, the behavior is standard, I asked which shell because of bash's pipefail option mentioned in Kusalandanda's answer.

    – terdon
    1 hour ago


















4















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)?










share|improve this question




















  • 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
    1 hour ago






  • 1





    Yes, the behavior is standard, I asked which shell because of bash's pipefail option mentioned in Kusalandanda's answer.

    – terdon
    1 hour ago














4












4








4








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)?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 38 mins ago







Seninha

















asked 7 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
    1 hour ago






  • 1





    Yes, the behavior is standard, I asked which shell because of bash's pipefail option mentioned in Kusalandanda's answer.

    – terdon
    1 hour ago














  • 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
    1 hour ago






  • 1





    Yes, the behavior is standard, I asked which shell because of bash's pipefail option mentioned in Kusalandanda's answer.

    – terdon
    1 hour 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
1 hour ago





I've tried it on bash, zsh, and sh. All of them had the same behavior.

– Seninha
1 hour ago




1




1





Yes, the behavior is standard, I asked which shell because of bash's pipefail option mentioned in Kusalandanda's answer.

– terdon
1 hour ago





Yes, the behavior is standard, I asked which shell because of bash's pipefail option mentioned in Kusalandanda's answer.

– terdon
1 hour ago










2 Answers
2






active

oldest

votes


















3














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




  1. the command in that stage is started as soon as all other stages are started anyway, and

  2. 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" && [ -s "$tmpfile" ]
then
zathura "$tmpfile"
fi

rm -f "$tmpfile"
}


This additionally would not run the zathura program if the pipeline failed (the xargs part returned non-zero) or the generated file is empty.



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.






share|improve this answer





















  • 1





    Why rm -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 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
    45 mins ago













  • @Seninha I fixed the first function by letting it check whether the generated file is non-empty.

    – Kusalananda
    37 mins ago



















2














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 only open the window if the file's OK, and exit with an error 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 if everything was OK, there's no guarantee that the user will not 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.






share|improve this answer


























    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
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f515862%2fhow-to-make-a-pipeline-wait-for-end-of-file-or-stop-after-an-error%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









    3














    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




    1. the command in that stage is started as soon as all other stages are started anyway, and

    2. 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" && [ -s "$tmpfile" ]
    then
    zathura "$tmpfile"
    fi

    rm -f "$tmpfile"
    }


    This additionally would not run the zathura program if the pipeline failed (the xargs part returned non-zero) or the generated file is empty.



    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.






    share|improve this answer





















    • 1





      Why rm -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 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
      45 mins ago













    • @Seninha I fixed the first function by letting it check whether the generated file is non-empty.

      – Kusalananda
      37 mins ago
















    3














    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




    1. the command in that stage is started as soon as all other stages are started anyway, and

    2. 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" && [ -s "$tmpfile" ]
    then
    zathura "$tmpfile"
    fi

    rm -f "$tmpfile"
    }


    This additionally would not run the zathura program if the pipeline failed (the xargs part returned non-zero) or the generated file is empty.



    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.






    share|improve this answer





















    • 1





      Why rm -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 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
      45 mins ago













    • @Seninha I fixed the first function by letting it check whether the generated file is non-empty.

      – Kusalananda
      37 mins ago














    3












    3








    3







    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




    1. the command in that stage is started as soon as all other stages are started anyway, and

    2. 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" && [ -s "$tmpfile" ]
    then
    zathura "$tmpfile"
    fi

    rm -f "$tmpfile"
    }


    This additionally would not run the zathura program if the pipeline failed (the xargs part returned non-zero) or the generated file is empty.



    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.






    share|improve this answer















    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




    1. the command in that stage is started as soon as all other stages are started anyway, and

    2. 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" && [ -s "$tmpfile" ]
    then
    zathura "$tmpfile"
    fi

    rm -f "$tmpfile"
    }


    This additionally would not run the zathura program if the pipeline failed (the xargs part returned non-zero) or the generated file is empty.



    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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 38 mins ago

























    answered 6 hours ago









    KusalanandaKusalananda

    144k18268448




    144k18268448








    • 1





      Why rm -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 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
      45 mins ago













    • @Seninha I fixed the first function by letting it check whether the generated file is non-empty.

      – Kusalananda
      37 mins ago














    • 1





      Why rm -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 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
      45 mins ago













    • @Seninha I fixed the first function by letting it check whether the generated file is non-empty.

      – Kusalananda
      37 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
    45 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
    45 mins ago















    @Seninha I fixed the first function by letting it check whether the generated file is non-empty.

    – Kusalananda
    37 mins ago





    @Seninha I fixed the first function by letting it check whether the generated file is non-empty.

    – Kusalananda
    37 mins ago













    2














    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 only open the window if the file's OK, and exit with an error 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 if everything was OK, there's no guarantee that the user will not 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.






    share|improve this answer






























      2














      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 only open the window if the file's OK, and exit with an error 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 if everything was OK, there's no guarantee that the user will not 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.






      share|improve this answer




























        2












        2








        2







        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 only open the window if the file's OK, and exit with an error 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 if everything was OK, there's no guarantee that the user will not 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.






        share|improve this answer















        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 only open the window if the file's OK, and exit with an error 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 if everything was OK, there's no guarantee that the user will not 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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 27 mins ago

























        answered 4 hours ago









        mosvymosvy

        10.9k11340




        10.9k11340






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f515862%2fhow-to-make-a-pipeline-wait-for-end-of-file-or-stop-after-an-error%23new-answer', 'question_page');
            }
            );

            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







            Popular posts from this blog

            Can't compile dgruyter and caption packagesLaTeX templates/packages for writing a patent specificationLatex...

            Schneeberg (Smreczany) Bibliografia | Menu...

            Hans Bellmer Spis treści Życiorys | Upamiętnienie | Przypisy | Bibliografia | Linki zewnętrzne |...