Ambiguous output redirect

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











up vote
0
down vote

favorite












I'm trying to redirect stderr to stdout and then out to a file in an init script, but when I introduce stderr to stdout I get the “Ambiguous output redirect” error. Stdout alone does not result in the error, and writes to the log file where I stated. I've tried the following



-jar /jbeaulau_test/microservices/config-server-0.0.2-RELEASE.jar &>/jbeaulau_test/microservices/log/all.log &

-jar /jbeaulau_test/microservices/config-server-0.0.2-RELEASE.jar >/jbeaulau_test/microservices/log/all.log 2>&1 &


Any advice would be appreciated.







share|improve this question






















  • Advice: (1) Don’t give example commands that are > 100 characters long if you don’t have to.  You could demonstrate the problem with echo &> foo.  (2) Don’t give example commands that are asynchronous if you don’t have to.  (3) Learn about shells.  There’s more than one shell in the Unixverse, and they accept different command syntaxes.  Learn how to tell what shell you’re using.
    – Scott
    Jan 23 at 3:42






  • 2




    Possible duplicate of stderr redirection not working in csh
    – Scott
    Jan 23 at 3:42










  • See also Inconsistency of stderr redirection between tcsh and other shells, What are the shell’s control and redirection operators?, Difference between 2>&-, 2>/dev/null, |&, &>/dev/null and >/dev/null 2>&1 and Redirection differences between &> >& and 2>&1.
    – Scott
    Jan 23 at 3:42










  • Which shell are you using?
    – andcoz
    Jan 23 at 9:16










  • Sorry, should have noted this is in Bash
    – jbeaulau
    Jan 23 at 19:44














up vote
0
down vote

favorite












I'm trying to redirect stderr to stdout and then out to a file in an init script, but when I introduce stderr to stdout I get the “Ambiguous output redirect” error. Stdout alone does not result in the error, and writes to the log file where I stated. I've tried the following



-jar /jbeaulau_test/microservices/config-server-0.0.2-RELEASE.jar &>/jbeaulau_test/microservices/log/all.log &

-jar /jbeaulau_test/microservices/config-server-0.0.2-RELEASE.jar >/jbeaulau_test/microservices/log/all.log 2>&1 &


Any advice would be appreciated.







share|improve this question






















  • Advice: (1) Don’t give example commands that are > 100 characters long if you don’t have to.  You could demonstrate the problem with echo &> foo.  (2) Don’t give example commands that are asynchronous if you don’t have to.  (3) Learn about shells.  There’s more than one shell in the Unixverse, and they accept different command syntaxes.  Learn how to tell what shell you’re using.
    – Scott
    Jan 23 at 3:42






  • 2




    Possible duplicate of stderr redirection not working in csh
    – Scott
    Jan 23 at 3:42










  • See also Inconsistency of stderr redirection between tcsh and other shells, What are the shell’s control and redirection operators?, Difference between 2>&-, 2>/dev/null, |&, &>/dev/null and >/dev/null 2>&1 and Redirection differences between &> >& and 2>&1.
    – Scott
    Jan 23 at 3:42










  • Which shell are you using?
    – andcoz
    Jan 23 at 9:16










  • Sorry, should have noted this is in Bash
    – jbeaulau
    Jan 23 at 19:44












up vote
0
down vote

favorite









up vote
0
down vote

favorite











I'm trying to redirect stderr to stdout and then out to a file in an init script, but when I introduce stderr to stdout I get the “Ambiguous output redirect” error. Stdout alone does not result in the error, and writes to the log file where I stated. I've tried the following



-jar /jbeaulau_test/microservices/config-server-0.0.2-RELEASE.jar &>/jbeaulau_test/microservices/log/all.log &

-jar /jbeaulau_test/microservices/config-server-0.0.2-RELEASE.jar >/jbeaulau_test/microservices/log/all.log 2>&1 &


Any advice would be appreciated.







share|improve this question














I'm trying to redirect stderr to stdout and then out to a file in an init script, but when I introduce stderr to stdout I get the “Ambiguous output redirect” error. Stdout alone does not result in the error, and writes to the log file where I stated. I've tried the following



-jar /jbeaulau_test/microservices/config-server-0.0.2-RELEASE.jar &>/jbeaulau_test/microservices/log/all.log &

-jar /jbeaulau_test/microservices/config-server-0.0.2-RELEASE.jar >/jbeaulau_test/microservices/log/all.log 2>&1 &


Any advice would be appreciated.









share|improve this question













share|improve this question




share|improve this question








edited Jan 23 at 23:22









jayhendren

5,08721340




5,08721340










asked Jan 23 at 0:06









jbeaulau

12




12











  • Advice: (1) Don’t give example commands that are > 100 characters long if you don’t have to.  You could demonstrate the problem with echo &> foo.  (2) Don’t give example commands that are asynchronous if you don’t have to.  (3) Learn about shells.  There’s more than one shell in the Unixverse, and they accept different command syntaxes.  Learn how to tell what shell you’re using.
    – Scott
    Jan 23 at 3:42






  • 2




    Possible duplicate of stderr redirection not working in csh
    – Scott
    Jan 23 at 3:42










  • See also Inconsistency of stderr redirection between tcsh and other shells, What are the shell’s control and redirection operators?, Difference between 2>&-, 2>/dev/null, |&, &>/dev/null and >/dev/null 2>&1 and Redirection differences between &> >& and 2>&1.
    – Scott
    Jan 23 at 3:42










  • Which shell are you using?
    – andcoz
    Jan 23 at 9:16










  • Sorry, should have noted this is in Bash
    – jbeaulau
    Jan 23 at 19:44
















  • Advice: (1) Don’t give example commands that are > 100 characters long if you don’t have to.  You could demonstrate the problem with echo &> foo.  (2) Don’t give example commands that are asynchronous if you don’t have to.  (3) Learn about shells.  There’s more than one shell in the Unixverse, and they accept different command syntaxes.  Learn how to tell what shell you’re using.
    – Scott
    Jan 23 at 3:42






  • 2




    Possible duplicate of stderr redirection not working in csh
    – Scott
    Jan 23 at 3:42










  • See also Inconsistency of stderr redirection between tcsh and other shells, What are the shell’s control and redirection operators?, Difference between 2>&-, 2>/dev/null, |&, &>/dev/null and >/dev/null 2>&1 and Redirection differences between &> >& and 2>&1.
    – Scott
    Jan 23 at 3:42










  • Which shell are you using?
    – andcoz
    Jan 23 at 9:16










  • Sorry, should have noted this is in Bash
    – jbeaulau
    Jan 23 at 19:44















Advice: (1) Don’t give example commands that are > 100 characters long if you don’t have to.  You could demonstrate the problem with echo &> foo.  (2) Don’t give example commands that are asynchronous if you don’t have to.  (3) Learn about shells.  There’s more than one shell in the Unixverse, and they accept different command syntaxes.  Learn how to tell what shell you’re using.
– Scott
Jan 23 at 3:42




Advice: (1) Don’t give example commands that are > 100 characters long if you don’t have to.  You could demonstrate the problem with echo &> foo.  (2) Don’t give example commands that are asynchronous if you don’t have to.  (3) Learn about shells.  There’s more than one shell in the Unixverse, and they accept different command syntaxes.  Learn how to tell what shell you’re using.
– Scott
Jan 23 at 3:42




2




2




Possible duplicate of stderr redirection not working in csh
– Scott
Jan 23 at 3:42




Possible duplicate of stderr redirection not working in csh
– Scott
Jan 23 at 3:42












See also Inconsistency of stderr redirection between tcsh and other shells, What are the shell’s control and redirection operators?, Difference between 2>&-, 2>/dev/null, |&, &>/dev/null and >/dev/null 2>&1 and Redirection differences between &> >& and 2>&1.
– Scott
Jan 23 at 3:42




See also Inconsistency of stderr redirection between tcsh and other shells, What are the shell’s control and redirection operators?, Difference between 2>&-, 2>/dev/null, |&, &>/dev/null and >/dev/null 2>&1 and Redirection differences between &> >& and 2>&1.
– Scott
Jan 23 at 3:42












Which shell are you using?
– andcoz
Jan 23 at 9:16




Which shell are you using?
– andcoz
Jan 23 at 9:16












Sorry, should have noted this is in Bash
– jbeaulau
Jan 23 at 19:44




Sorry, should have noted this is in Bash
– jbeaulau
Jan 23 at 19:44










2 Answers
2






active

oldest

votes

















up vote
2
down vote













If you're running (t)csh, you get Ambiguous output redirect. if you try to set up two conflicting redirections:



> echo foo > a > b
Ambiguous output redirect.


In Bash, you could get a similar error if use an array with multiple elements in place of the filename:



$ set aa bb
$ echo foo > "$@"
bash: "$@": ambiguous redirect


As mentioned in answers to stderr redirection not working in csh, the >& operator works in (t)csh to redirect both stdout and stderr. 2>&1 is the standard way to redirect stderr to the same place as stdout, but (t)csh doesn't support that. Instead, it takes the combination > foo 2>&1 as a redirection to foo, a regular argument 2, and a redirection to 1, and the redirections conflict, so you get the error.



>& also works in Bash and zsh, but isn't a standard feature.






share|improve this answer



























    up vote
    -1
    down vote













    The second entry should work fine. The "ambiguous redirect" error sometimes happens if you either have spaces where they shouldn't be, or conversely when an important space is missing.



    I would simplify your command to demonstrate:



    echo "Test" >/tmp/x.txt 2>&1 &


    The ">/tmp/x.txt" part will redirect stdout (file handle #1). A space between the > and the file name is permitted (although in this context would be confusing), but otherwise there should not be any spaces in here.



    The 2>&1 will redirect stderr (file handle 2) to whatever file handle 1 goes to (which is stdout). There must not be any spaces in here, either.



    The & will background your task. This must be offset with a space from the preceding character.



    Reversing the two redirections does not work (although echo is a poor choice here since it does not produce stderr output):



    echo "This will not work" 2>&1 >/tmp/x.txt &


    This means:



    2>&1


    Redirect file handle 2 to where file handle 1 goes (which at this point is still the console)



    >/tmp/x.txt


    Redirect file handle 1 to a file - but since file handle 2 (stderr) is already redirected at this point, it will keep its destination and still go to the console.



    The first command you wrote is simply a syntax error.



    echo &>/tmp/x.txt


    Update: @Wildcard pointed out in the comments that this is actually valid syntax.






    share|improve this answer






















    • The ">/tmp/x.txt" part will redirect stdout (file handle #1). It must not contain any spaces. . It can contain the space. command >out.txt == command > out.txt
      – fugitive
      Jan 23 at 0:57










    • You are right; I made a mistake there. Fixing it.
      – Kevin Keane
      Jan 23 at 1:09










    • "The first command you wrote is simply a syntax error." No, it's not; it's the preferred Bash syntax for redirecting both stdout and stderr. See LESS='+/Redirecting Standard Output and Standard Error' man bash
      – Wildcard
      Jan 23 at 3:32










    • @Wildcard - thanks. I never stop learning!
      – Kevin Keane
      Jan 23 at 17:15










    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%2f418972%2fambiguous-output-redirect%23new-answer', 'question_page');

    );

    Post as a guest






























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    2
    down vote













    If you're running (t)csh, you get Ambiguous output redirect. if you try to set up two conflicting redirections:



    > echo foo > a > b
    Ambiguous output redirect.


    In Bash, you could get a similar error if use an array with multiple elements in place of the filename:



    $ set aa bb
    $ echo foo > "$@"
    bash: "$@": ambiguous redirect


    As mentioned in answers to stderr redirection not working in csh, the >& operator works in (t)csh to redirect both stdout and stderr. 2>&1 is the standard way to redirect stderr to the same place as stdout, but (t)csh doesn't support that. Instead, it takes the combination > foo 2>&1 as a redirection to foo, a regular argument 2, and a redirection to 1, and the redirections conflict, so you get the error.



    >& also works in Bash and zsh, but isn't a standard feature.






    share|improve this answer
























      up vote
      2
      down vote













      If you're running (t)csh, you get Ambiguous output redirect. if you try to set up two conflicting redirections:



      > echo foo > a > b
      Ambiguous output redirect.


      In Bash, you could get a similar error if use an array with multiple elements in place of the filename:



      $ set aa bb
      $ echo foo > "$@"
      bash: "$@": ambiguous redirect


      As mentioned in answers to stderr redirection not working in csh, the >& operator works in (t)csh to redirect both stdout and stderr. 2>&1 is the standard way to redirect stderr to the same place as stdout, but (t)csh doesn't support that. Instead, it takes the combination > foo 2>&1 as a redirection to foo, a regular argument 2, and a redirection to 1, and the redirections conflict, so you get the error.



      >& also works in Bash and zsh, but isn't a standard feature.






      share|improve this answer






















        up vote
        2
        down vote










        up vote
        2
        down vote









        If you're running (t)csh, you get Ambiguous output redirect. if you try to set up two conflicting redirections:



        > echo foo > a > b
        Ambiguous output redirect.


        In Bash, you could get a similar error if use an array with multiple elements in place of the filename:



        $ set aa bb
        $ echo foo > "$@"
        bash: "$@": ambiguous redirect


        As mentioned in answers to stderr redirection not working in csh, the >& operator works in (t)csh to redirect both stdout and stderr. 2>&1 is the standard way to redirect stderr to the same place as stdout, but (t)csh doesn't support that. Instead, it takes the combination > foo 2>&1 as a redirection to foo, a regular argument 2, and a redirection to 1, and the redirections conflict, so you get the error.



        >& also works in Bash and zsh, but isn't a standard feature.






        share|improve this answer












        If you're running (t)csh, you get Ambiguous output redirect. if you try to set up two conflicting redirections:



        > echo foo > a > b
        Ambiguous output redirect.


        In Bash, you could get a similar error if use an array with multiple elements in place of the filename:



        $ set aa bb
        $ echo foo > "$@"
        bash: "$@": ambiguous redirect


        As mentioned in answers to stderr redirection not working in csh, the >& operator works in (t)csh to redirect both stdout and stderr. 2>&1 is the standard way to redirect stderr to the same place as stdout, but (t)csh doesn't support that. Instead, it takes the combination > foo 2>&1 as a redirection to foo, a regular argument 2, and a redirection to 1, and the redirections conflict, so you get the error.



        >& also works in Bash and zsh, but isn't a standard feature.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 23 at 10:11









        ilkkachu

        49.8k674137




        49.8k674137






















            up vote
            -1
            down vote













            The second entry should work fine. The "ambiguous redirect" error sometimes happens if you either have spaces where they shouldn't be, or conversely when an important space is missing.



            I would simplify your command to demonstrate:



            echo "Test" >/tmp/x.txt 2>&1 &


            The ">/tmp/x.txt" part will redirect stdout (file handle #1). A space between the > and the file name is permitted (although in this context would be confusing), but otherwise there should not be any spaces in here.



            The 2>&1 will redirect stderr (file handle 2) to whatever file handle 1 goes to (which is stdout). There must not be any spaces in here, either.



            The & will background your task. This must be offset with a space from the preceding character.



            Reversing the two redirections does not work (although echo is a poor choice here since it does not produce stderr output):



            echo "This will not work" 2>&1 >/tmp/x.txt &


            This means:



            2>&1


            Redirect file handle 2 to where file handle 1 goes (which at this point is still the console)



            >/tmp/x.txt


            Redirect file handle 1 to a file - but since file handle 2 (stderr) is already redirected at this point, it will keep its destination and still go to the console.



            The first command you wrote is simply a syntax error.



            echo &>/tmp/x.txt


            Update: @Wildcard pointed out in the comments that this is actually valid syntax.






            share|improve this answer






















            • The ">/tmp/x.txt" part will redirect stdout (file handle #1). It must not contain any spaces. . It can contain the space. command >out.txt == command > out.txt
              – fugitive
              Jan 23 at 0:57










            • You are right; I made a mistake there. Fixing it.
              – Kevin Keane
              Jan 23 at 1:09










            • "The first command you wrote is simply a syntax error." No, it's not; it's the preferred Bash syntax for redirecting both stdout and stderr. See LESS='+/Redirecting Standard Output and Standard Error' man bash
              – Wildcard
              Jan 23 at 3:32










            • @Wildcard - thanks. I never stop learning!
              – Kevin Keane
              Jan 23 at 17:15














            up vote
            -1
            down vote













            The second entry should work fine. The "ambiguous redirect" error sometimes happens if you either have spaces where they shouldn't be, or conversely when an important space is missing.



            I would simplify your command to demonstrate:



            echo "Test" >/tmp/x.txt 2>&1 &


            The ">/tmp/x.txt" part will redirect stdout (file handle #1). A space between the > and the file name is permitted (although in this context would be confusing), but otherwise there should not be any spaces in here.



            The 2>&1 will redirect stderr (file handle 2) to whatever file handle 1 goes to (which is stdout). There must not be any spaces in here, either.



            The & will background your task. This must be offset with a space from the preceding character.



            Reversing the two redirections does not work (although echo is a poor choice here since it does not produce stderr output):



            echo "This will not work" 2>&1 >/tmp/x.txt &


            This means:



            2>&1


            Redirect file handle 2 to where file handle 1 goes (which at this point is still the console)



            >/tmp/x.txt


            Redirect file handle 1 to a file - but since file handle 2 (stderr) is already redirected at this point, it will keep its destination and still go to the console.



            The first command you wrote is simply a syntax error.



            echo &>/tmp/x.txt


            Update: @Wildcard pointed out in the comments that this is actually valid syntax.






            share|improve this answer






















            • The ">/tmp/x.txt" part will redirect stdout (file handle #1). It must not contain any spaces. . It can contain the space. command >out.txt == command > out.txt
              – fugitive
              Jan 23 at 0:57










            • You are right; I made a mistake there. Fixing it.
              – Kevin Keane
              Jan 23 at 1:09










            • "The first command you wrote is simply a syntax error." No, it's not; it's the preferred Bash syntax for redirecting both stdout and stderr. See LESS='+/Redirecting Standard Output and Standard Error' man bash
              – Wildcard
              Jan 23 at 3:32










            • @Wildcard - thanks. I never stop learning!
              – Kevin Keane
              Jan 23 at 17:15












            up vote
            -1
            down vote










            up vote
            -1
            down vote









            The second entry should work fine. The "ambiguous redirect" error sometimes happens if you either have spaces where they shouldn't be, or conversely when an important space is missing.



            I would simplify your command to demonstrate:



            echo "Test" >/tmp/x.txt 2>&1 &


            The ">/tmp/x.txt" part will redirect stdout (file handle #1). A space between the > and the file name is permitted (although in this context would be confusing), but otherwise there should not be any spaces in here.



            The 2>&1 will redirect stderr (file handle 2) to whatever file handle 1 goes to (which is stdout). There must not be any spaces in here, either.



            The & will background your task. This must be offset with a space from the preceding character.



            Reversing the two redirections does not work (although echo is a poor choice here since it does not produce stderr output):



            echo "This will not work" 2>&1 >/tmp/x.txt &


            This means:



            2>&1


            Redirect file handle 2 to where file handle 1 goes (which at this point is still the console)



            >/tmp/x.txt


            Redirect file handle 1 to a file - but since file handle 2 (stderr) is already redirected at this point, it will keep its destination and still go to the console.



            The first command you wrote is simply a syntax error.



            echo &>/tmp/x.txt


            Update: @Wildcard pointed out in the comments that this is actually valid syntax.






            share|improve this answer














            The second entry should work fine. The "ambiguous redirect" error sometimes happens if you either have spaces where they shouldn't be, or conversely when an important space is missing.



            I would simplify your command to demonstrate:



            echo "Test" >/tmp/x.txt 2>&1 &


            The ">/tmp/x.txt" part will redirect stdout (file handle #1). A space between the > and the file name is permitted (although in this context would be confusing), but otherwise there should not be any spaces in here.



            The 2>&1 will redirect stderr (file handle 2) to whatever file handle 1 goes to (which is stdout). There must not be any spaces in here, either.



            The & will background your task. This must be offset with a space from the preceding character.



            Reversing the two redirections does not work (although echo is a poor choice here since it does not produce stderr output):



            echo "This will not work" 2>&1 >/tmp/x.txt &


            This means:



            2>&1


            Redirect file handle 2 to where file handle 1 goes (which at this point is still the console)



            >/tmp/x.txt


            Redirect file handle 1 to a file - but since file handle 2 (stderr) is already redirected at this point, it will keep its destination and still go to the console.



            The first command you wrote is simply a syntax error.



            echo &>/tmp/x.txt


            Update: @Wildcard pointed out in the comments that this is actually valid syntax.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 23 at 17:19

























            answered Jan 23 at 0:55









            Kevin Keane

            26819




            26819











            • The ">/tmp/x.txt" part will redirect stdout (file handle #1). It must not contain any spaces. . It can contain the space. command >out.txt == command > out.txt
              – fugitive
              Jan 23 at 0:57










            • You are right; I made a mistake there. Fixing it.
              – Kevin Keane
              Jan 23 at 1:09










            • "The first command you wrote is simply a syntax error." No, it's not; it's the preferred Bash syntax for redirecting both stdout and stderr. See LESS='+/Redirecting Standard Output and Standard Error' man bash
              – Wildcard
              Jan 23 at 3:32










            • @Wildcard - thanks. I never stop learning!
              – Kevin Keane
              Jan 23 at 17:15
















            • The ">/tmp/x.txt" part will redirect stdout (file handle #1). It must not contain any spaces. . It can contain the space. command >out.txt == command > out.txt
              – fugitive
              Jan 23 at 0:57










            • You are right; I made a mistake there. Fixing it.
              – Kevin Keane
              Jan 23 at 1:09










            • "The first command you wrote is simply a syntax error." No, it's not; it's the preferred Bash syntax for redirecting both stdout and stderr. See LESS='+/Redirecting Standard Output and Standard Error' man bash
              – Wildcard
              Jan 23 at 3:32










            • @Wildcard - thanks. I never stop learning!
              – Kevin Keane
              Jan 23 at 17:15















            The ">/tmp/x.txt" part will redirect stdout (file handle #1). It must not contain any spaces. . It can contain the space. command >out.txt == command > out.txt
            – fugitive
            Jan 23 at 0:57




            The ">/tmp/x.txt" part will redirect stdout (file handle #1). It must not contain any spaces. . It can contain the space. command >out.txt == command > out.txt
            – fugitive
            Jan 23 at 0:57












            You are right; I made a mistake there. Fixing it.
            – Kevin Keane
            Jan 23 at 1:09




            You are right; I made a mistake there. Fixing it.
            – Kevin Keane
            Jan 23 at 1:09












            "The first command you wrote is simply a syntax error." No, it's not; it's the preferred Bash syntax for redirecting both stdout and stderr. See LESS='+/Redirecting Standard Output and Standard Error' man bash
            – Wildcard
            Jan 23 at 3:32




            "The first command you wrote is simply a syntax error." No, it's not; it's the preferred Bash syntax for redirecting both stdout and stderr. See LESS='+/Redirecting Standard Output and Standard Error' man bash
            – Wildcard
            Jan 23 at 3:32












            @Wildcard - thanks. I never stop learning!
            – Kevin Keane
            Jan 23 at 17:15




            @Wildcard - thanks. I never stop learning!
            – Kevin Keane
            Jan 23 at 17:15












             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f418972%2fambiguous-output-redirect%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?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay