Why does my OS X Terminal display a blank window instead of a command prompt after installing MySQL?












1















After installing MySQL 5.1.50 64-bit and running the package that configures MyQL to run at startup, the Terminal app now sporadically display a blank window, like so:



alt text



I managed to get the command prompt back after following the instructions from the MacFixIt column at CNET : OS X Terminal displays a blank window instead of a command prompt



However, the Terminal will intermittently go blank and I have to repeat the process again and it's driving me nuts. The CNET article cures the symtoms but the cause of this problem is still unknown. Does anyone has any theories or experiences to share in order to fix this annoying problem permanently?










share|improve this question























  • Have you solved this problem?

    – JasKerr
    Oct 1 '10 at 11:24











  • It happened a few more times. Each time used the procedure suggested by CNET to fix it. Then it never happened again (so far). Wish I knew what caused it. Maybe Apple quietly push an update that fixed it.

    – GeneQ
    Oct 1 '10 at 11:30













  • A common source of this is if you run sudo and then close the terminal while it’s waiting for you to enter the password. This hangs sudo, which prevents any further logins. To resolve the issue, use Activity Monitor (or another terminal if you happen to have one open) to kill the sudo process. (Obviously, if there is no sudo process, this isn’t the issue.)

    – Chris Page
    Nov 3 '11 at 4:04











  • By the way, that C|Net article is incorrect about “…you can tell the terminal to specify the shell used and bypass the need to look up account information…” All shells and commands issued by Terminal are run via /usr/bin/login. All the UI is indicating is that the default shell is selected by /usr/bin/login (it looks at your user account info), but if you customize the shell, Terminal just tells /usr/bin/login to use that shell instead of the default. Login still must look up user account information to…login before running the shell or other command.

    – Chris Page
    Nov 3 '11 at 4:07


















1















After installing MySQL 5.1.50 64-bit and running the package that configures MyQL to run at startup, the Terminal app now sporadically display a blank window, like so:



alt text



I managed to get the command prompt back after following the instructions from the MacFixIt column at CNET : OS X Terminal displays a blank window instead of a command prompt



However, the Terminal will intermittently go blank and I have to repeat the process again and it's driving me nuts. The CNET article cures the symtoms but the cause of this problem is still unknown. Does anyone has any theories or experiences to share in order to fix this annoying problem permanently?










share|improve this question























  • Have you solved this problem?

    – JasKerr
    Oct 1 '10 at 11:24











  • It happened a few more times. Each time used the procedure suggested by CNET to fix it. Then it never happened again (so far). Wish I knew what caused it. Maybe Apple quietly push an update that fixed it.

    – GeneQ
    Oct 1 '10 at 11:30













  • A common source of this is if you run sudo and then close the terminal while it’s waiting for you to enter the password. This hangs sudo, which prevents any further logins. To resolve the issue, use Activity Monitor (or another terminal if you happen to have one open) to kill the sudo process. (Obviously, if there is no sudo process, this isn’t the issue.)

    – Chris Page
    Nov 3 '11 at 4:04











  • By the way, that C|Net article is incorrect about “…you can tell the terminal to specify the shell used and bypass the need to look up account information…” All shells and commands issued by Terminal are run via /usr/bin/login. All the UI is indicating is that the default shell is selected by /usr/bin/login (it looks at your user account info), but if you customize the shell, Terminal just tells /usr/bin/login to use that shell instead of the default. Login still must look up user account information to…login before running the shell or other command.

    – Chris Page
    Nov 3 '11 at 4:07
















1












1








1


4






After installing MySQL 5.1.50 64-bit and running the package that configures MyQL to run at startup, the Terminal app now sporadically display a blank window, like so:



alt text



I managed to get the command prompt back after following the instructions from the MacFixIt column at CNET : OS X Terminal displays a blank window instead of a command prompt



However, the Terminal will intermittently go blank and I have to repeat the process again and it's driving me nuts. The CNET article cures the symtoms but the cause of this problem is still unknown. Does anyone has any theories or experiences to share in order to fix this annoying problem permanently?










share|improve this question














After installing MySQL 5.1.50 64-bit and running the package that configures MyQL to run at startup, the Terminal app now sporadically display a blank window, like so:



alt text



I managed to get the command prompt back after following the instructions from the MacFixIt column at CNET : OS X Terminal displays a blank window instead of a command prompt



However, the Terminal will intermittently go blank and I have to repeat the process again and it's driving me nuts. The CNET article cures the symtoms but the cause of this problem is still unknown. Does anyone has any theories or experiences to share in order to fix this annoying problem permanently?







macos troubleshooting terminal






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Aug 25 '10 at 14:36









GeneQGeneQ

3,99622953




3,99622953













  • Have you solved this problem?

    – JasKerr
    Oct 1 '10 at 11:24











  • It happened a few more times. Each time used the procedure suggested by CNET to fix it. Then it never happened again (so far). Wish I knew what caused it. Maybe Apple quietly push an update that fixed it.

    – GeneQ
    Oct 1 '10 at 11:30













  • A common source of this is if you run sudo and then close the terminal while it’s waiting for you to enter the password. This hangs sudo, which prevents any further logins. To resolve the issue, use Activity Monitor (or another terminal if you happen to have one open) to kill the sudo process. (Obviously, if there is no sudo process, this isn’t the issue.)

    – Chris Page
    Nov 3 '11 at 4:04











  • By the way, that C|Net article is incorrect about “…you can tell the terminal to specify the shell used and bypass the need to look up account information…” All shells and commands issued by Terminal are run via /usr/bin/login. All the UI is indicating is that the default shell is selected by /usr/bin/login (it looks at your user account info), but if you customize the shell, Terminal just tells /usr/bin/login to use that shell instead of the default. Login still must look up user account information to…login before running the shell or other command.

    – Chris Page
    Nov 3 '11 at 4:07





















  • Have you solved this problem?

    – JasKerr
    Oct 1 '10 at 11:24











  • It happened a few more times. Each time used the procedure suggested by CNET to fix it. Then it never happened again (so far). Wish I knew what caused it. Maybe Apple quietly push an update that fixed it.

    – GeneQ
    Oct 1 '10 at 11:30













  • A common source of this is if you run sudo and then close the terminal while it’s waiting for you to enter the password. This hangs sudo, which prevents any further logins. To resolve the issue, use Activity Monitor (or another terminal if you happen to have one open) to kill the sudo process. (Obviously, if there is no sudo process, this isn’t the issue.)

    – Chris Page
    Nov 3 '11 at 4:04











  • By the way, that C|Net article is incorrect about “…you can tell the terminal to specify the shell used and bypass the need to look up account information…” All shells and commands issued by Terminal are run via /usr/bin/login. All the UI is indicating is that the default shell is selected by /usr/bin/login (it looks at your user account info), but if you customize the shell, Terminal just tells /usr/bin/login to use that shell instead of the default. Login still must look up user account information to…login before running the shell or other command.

    – Chris Page
    Nov 3 '11 at 4:07



















Have you solved this problem?

– JasKerr
Oct 1 '10 at 11:24





Have you solved this problem?

– JasKerr
Oct 1 '10 at 11:24













It happened a few more times. Each time used the procedure suggested by CNET to fix it. Then it never happened again (so far). Wish I knew what caused it. Maybe Apple quietly push an update that fixed it.

– GeneQ
Oct 1 '10 at 11:30







It happened a few more times. Each time used the procedure suggested by CNET to fix it. Then it never happened again (so far). Wish I knew what caused it. Maybe Apple quietly push an update that fixed it.

– GeneQ
Oct 1 '10 at 11:30















A common source of this is if you run sudo and then close the terminal while it’s waiting for you to enter the password. This hangs sudo, which prevents any further logins. To resolve the issue, use Activity Monitor (or another terminal if you happen to have one open) to kill the sudo process. (Obviously, if there is no sudo process, this isn’t the issue.)

– Chris Page
Nov 3 '11 at 4:04





A common source of this is if you run sudo and then close the terminal while it’s waiting for you to enter the password. This hangs sudo, which prevents any further logins. To resolve the issue, use Activity Monitor (or another terminal if you happen to have one open) to kill the sudo process. (Obviously, if there is no sudo process, this isn’t the issue.)

– Chris Page
Nov 3 '11 at 4:04













By the way, that C|Net article is incorrect about “…you can tell the terminal to specify the shell used and bypass the need to look up account information…” All shells and commands issued by Terminal are run via /usr/bin/login. All the UI is indicating is that the default shell is selected by /usr/bin/login (it looks at your user account info), but if you customize the shell, Terminal just tells /usr/bin/login to use that shell instead of the default. Login still must look up user account information to…login before running the shell or other command.

– Chris Page
Nov 3 '11 at 4:07







By the way, that C|Net article is incorrect about “…you can tell the terminal to specify the shell used and bypass the need to look up account information…” All shells and commands issued by Terminal are run via /usr/bin/login. All the UI is indicating is that the default shell is selected by /usr/bin/login (it looks at your user account info), but if you customize the shell, Terminal just tells /usr/bin/login to use that shell instead of the default. Login still must look up user account information to…login before running the shell or other command.

– Chris Page
Nov 3 '11 at 4:07












5 Answers
5






active

oldest

votes


















4














A common cause for this is a hung "sudo" process. If you run sudo and it prompts for your password, but you close the terminal, sudo will hang forever waiting for the password, and this blocks any other logins until you kill it.



The solution is to kill the "sudo" process with Activity Monitor.



I believe sudo has been fixed on Mac OS X Lion 10.7 to exit if you close the terminal.






share|improve this answer
























  • Killing all java processes has also solved this, for me

    – Peter Becich
    Jul 19 '16 at 1:18



















0














Try running jobs at the Terminal to see if that shell has any child processes in the background. If there is something super heavy running in the background maybe it is causing the shell to become unresponsive?






share|improve this answer
























  • It hngs at the Unix login. (As the title bar of the Terminal shows). Some rights or authentication related stuff perhaps is causing the problem.

    – GeneQ
    Aug 27 '10 at 10:24













  • Is it possible to investigate what is running after you get the prompt back but before it recurs?

    – dtlussier
    Aug 27 '10 at 12:45



















0














I just had the exact same problem, though it occurred after installing Git (or at least that is when I noticed the issue).



I opened the Activity Monitor and selected to show all processes. I noticed root was running several (> 10) login processes, few sh processes and a sudo process. I force-quitted them all, though some login processes didn't quit—probably the sudo kept them hanging. After this, Terminal worked normally and the excessive login processes I couldn't kill quitted.



I think the trick is to look for login and shell related processes which could hang new ones. Probably, in my case, killing the sudo would've been sufficient enough.



The CNet article you referred is good for a last resort.






share|improve this answer































    0















    1. Launch Activity Monitor

    2. Select "All Processes, Hierarchically"

    3. Look for your Terminal process

    4. Try to spot a process that might be "stuck" and interfering with the login


    Or:




    1. run fg in each active shell window


    In my case, somehow git diff head had got put in the background in one of my shells, so git and less appeared under a shell in which I thought there was just a bash process. When I did fg it fixed the problem. If most of your windows/tabs are just "login -> bash" then it should be easy to spot.






    share|improve this answer































      0














      I actually found that the issue, for me, was related to a hung "login" process. In following the suggestion above, I did not see any "sudo" process within the list from Activity Monitor, but I did notice a lot of "login" processes owned by root. I went through and started killing these, and one of them triggered something and the prompt came back within iTerm for me. I was able to avoid rebooting the machine.






      share|improve this answer























        Your Answer








        StackExchange.ready(function() {
        var channelOptions = {
        tags: "".split(" "),
        id: "3"
        };
        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: true,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: 10,
        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%2fsuperuser.com%2fquestions%2f180568%2fwhy-does-my-os-x-terminal-display-a-blank-window-instead-of-a-command-prompt-aft%23new-answer', 'question_page');
        }
        );

        Post as a guest















        Required, but never shown

























        5 Answers
        5






        active

        oldest

        votes








        5 Answers
        5






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        4














        A common cause for this is a hung "sudo" process. If you run sudo and it prompts for your password, but you close the terminal, sudo will hang forever waiting for the password, and this blocks any other logins until you kill it.



        The solution is to kill the "sudo" process with Activity Monitor.



        I believe sudo has been fixed on Mac OS X Lion 10.7 to exit if you close the terminal.






        share|improve this answer
























        • Killing all java processes has also solved this, for me

          – Peter Becich
          Jul 19 '16 at 1:18
















        4














        A common cause for this is a hung "sudo" process. If you run sudo and it prompts for your password, but you close the terminal, sudo will hang forever waiting for the password, and this blocks any other logins until you kill it.



        The solution is to kill the "sudo" process with Activity Monitor.



        I believe sudo has been fixed on Mac OS X Lion 10.7 to exit if you close the terminal.






        share|improve this answer
























        • Killing all java processes has also solved this, for me

          – Peter Becich
          Jul 19 '16 at 1:18














        4












        4








        4







        A common cause for this is a hung "sudo" process. If you run sudo and it prompts for your password, but you close the terminal, sudo will hang forever waiting for the password, and this blocks any other logins until you kill it.



        The solution is to kill the "sudo" process with Activity Monitor.



        I believe sudo has been fixed on Mac OS X Lion 10.7 to exit if you close the terminal.






        share|improve this answer













        A common cause for this is a hung "sudo" process. If you run sudo and it prompts for your password, but you close the terminal, sudo will hang forever waiting for the password, and this blocks any other logins until you kill it.



        The solution is to kill the "sudo" process with Activity Monitor.



        I believe sudo has been fixed on Mac OS X Lion 10.7 to exit if you close the terminal.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Aug 11 '11 at 7:11









        Chris PageChris Page

        2,5141635




        2,5141635













        • Killing all java processes has also solved this, for me

          – Peter Becich
          Jul 19 '16 at 1:18



















        • Killing all java processes has also solved this, for me

          – Peter Becich
          Jul 19 '16 at 1:18

















        Killing all java processes has also solved this, for me

        – Peter Becich
        Jul 19 '16 at 1:18





        Killing all java processes has also solved this, for me

        – Peter Becich
        Jul 19 '16 at 1:18













        0














        Try running jobs at the Terminal to see if that shell has any child processes in the background. If there is something super heavy running in the background maybe it is causing the shell to become unresponsive?






        share|improve this answer
























        • It hngs at the Unix login. (As the title bar of the Terminal shows). Some rights or authentication related stuff perhaps is causing the problem.

          – GeneQ
          Aug 27 '10 at 10:24













        • Is it possible to investigate what is running after you get the prompt back but before it recurs?

          – dtlussier
          Aug 27 '10 at 12:45
















        0














        Try running jobs at the Terminal to see if that shell has any child processes in the background. If there is something super heavy running in the background maybe it is causing the shell to become unresponsive?






        share|improve this answer
























        • It hngs at the Unix login. (As the title bar of the Terminal shows). Some rights or authentication related stuff perhaps is causing the problem.

          – GeneQ
          Aug 27 '10 at 10:24













        • Is it possible to investigate what is running after you get the prompt back but before it recurs?

          – dtlussier
          Aug 27 '10 at 12:45














        0












        0








        0







        Try running jobs at the Terminal to see if that shell has any child processes in the background. If there is something super heavy running in the background maybe it is causing the shell to become unresponsive?






        share|improve this answer













        Try running jobs at the Terminal to see if that shell has any child processes in the background. If there is something super heavy running in the background maybe it is causing the shell to become unresponsive?







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Aug 26 '10 at 21:39









        dtlussierdtlussier

        1,70521827




        1,70521827













        • It hngs at the Unix login. (As the title bar of the Terminal shows). Some rights or authentication related stuff perhaps is causing the problem.

          – GeneQ
          Aug 27 '10 at 10:24













        • Is it possible to investigate what is running after you get the prompt back but before it recurs?

          – dtlussier
          Aug 27 '10 at 12:45



















        • It hngs at the Unix login. (As the title bar of the Terminal shows). Some rights or authentication related stuff perhaps is causing the problem.

          – GeneQ
          Aug 27 '10 at 10:24













        • Is it possible to investigate what is running after you get the prompt back but before it recurs?

          – dtlussier
          Aug 27 '10 at 12:45

















        It hngs at the Unix login. (As the title bar of the Terminal shows). Some rights or authentication related stuff perhaps is causing the problem.

        – GeneQ
        Aug 27 '10 at 10:24







        It hngs at the Unix login. (As the title bar of the Terminal shows). Some rights or authentication related stuff perhaps is causing the problem.

        – GeneQ
        Aug 27 '10 at 10:24















        Is it possible to investigate what is running after you get the prompt back but before it recurs?

        – dtlussier
        Aug 27 '10 at 12:45





        Is it possible to investigate what is running after you get the prompt back but before it recurs?

        – dtlussier
        Aug 27 '10 at 12:45











        0














        I just had the exact same problem, though it occurred after installing Git (or at least that is when I noticed the issue).



        I opened the Activity Monitor and selected to show all processes. I noticed root was running several (> 10) login processes, few sh processes and a sudo process. I force-quitted them all, though some login processes didn't quit—probably the sudo kept them hanging. After this, Terminal worked normally and the excessive login processes I couldn't kill quitted.



        I think the trick is to look for login and shell related processes which could hang new ones. Probably, in my case, killing the sudo would've been sufficient enough.



        The CNet article you referred is good for a last resort.






        share|improve this answer




























          0














          I just had the exact same problem, though it occurred after installing Git (or at least that is when I noticed the issue).



          I opened the Activity Monitor and selected to show all processes. I noticed root was running several (> 10) login processes, few sh processes and a sudo process. I force-quitted them all, though some login processes didn't quit—probably the sudo kept them hanging. After this, Terminal worked normally and the excessive login processes I couldn't kill quitted.



          I think the trick is to look for login and shell related processes which could hang new ones. Probably, in my case, killing the sudo would've been sufficient enough.



          The CNet article you referred is good for a last resort.






          share|improve this answer


























            0












            0








            0







            I just had the exact same problem, though it occurred after installing Git (or at least that is when I noticed the issue).



            I opened the Activity Monitor and selected to show all processes. I noticed root was running several (> 10) login processes, few sh processes and a sudo process. I force-quitted them all, though some login processes didn't quit—probably the sudo kept them hanging. After this, Terminal worked normally and the excessive login processes I couldn't kill quitted.



            I think the trick is to look for login and shell related processes which could hang new ones. Probably, in my case, killing the sudo would've been sufficient enough.



            The CNet article you referred is good for a last resort.






            share|improve this answer













            I just had the exact same problem, though it occurred after installing Git (or at least that is when I noticed the issue).



            I opened the Activity Monitor and selected to show all processes. I noticed root was running several (> 10) login processes, few sh processes and a sudo process. I force-quitted them all, though some login processes didn't quit—probably the sudo kept them hanging. After this, Terminal worked normally and the excessive login processes I couldn't kill quitted.



            I think the trick is to look for login and shell related processes which could hang new ones. Probably, in my case, killing the sudo would've been sufficient enough.



            The CNet article you referred is good for a last resort.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Mar 21 '11 at 13:07









            Jari KeinänenJari Keinänen

            3162620




            3162620























                0















                1. Launch Activity Monitor

                2. Select "All Processes, Hierarchically"

                3. Look for your Terminal process

                4. Try to spot a process that might be "stuck" and interfering with the login


                Or:




                1. run fg in each active shell window


                In my case, somehow git diff head had got put in the background in one of my shells, so git and less appeared under a shell in which I thought there was just a bash process. When I did fg it fixed the problem. If most of your windows/tabs are just "login -> bash" then it should be easy to spot.






                share|improve this answer




























                  0















                  1. Launch Activity Monitor

                  2. Select "All Processes, Hierarchically"

                  3. Look for your Terminal process

                  4. Try to spot a process that might be "stuck" and interfering with the login


                  Or:




                  1. run fg in each active shell window


                  In my case, somehow git diff head had got put in the background in one of my shells, so git and less appeared under a shell in which I thought there was just a bash process. When I did fg it fixed the problem. If most of your windows/tabs are just "login -> bash" then it should be easy to spot.






                  share|improve this answer


























                    0












                    0








                    0








                    1. Launch Activity Monitor

                    2. Select "All Processes, Hierarchically"

                    3. Look for your Terminal process

                    4. Try to spot a process that might be "stuck" and interfering with the login


                    Or:




                    1. run fg in each active shell window


                    In my case, somehow git diff head had got put in the background in one of my shells, so git and less appeared under a shell in which I thought there was just a bash process. When I did fg it fixed the problem. If most of your windows/tabs are just "login -> bash" then it should be easy to spot.






                    share|improve this answer














                    1. Launch Activity Monitor

                    2. Select "All Processes, Hierarchically"

                    3. Look for your Terminal process

                    4. Try to spot a process that might be "stuck" and interfering with the login


                    Or:




                    1. run fg in each active shell window


                    In my case, somehow git diff head had got put in the background in one of my shells, so git and less appeared under a shell in which I thought there was just a bash process. When I did fg it fixed the problem. If most of your windows/tabs are just "login -> bash" then it should be easy to spot.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Nov 22 '13 at 5:26









                    Zac ThompsonZac Thompson

                    822913




                    822913























                        0














                        I actually found that the issue, for me, was related to a hung "login" process. In following the suggestion above, I did not see any "sudo" process within the list from Activity Monitor, but I did notice a lot of "login" processes owned by root. I went through and started killing these, and one of them triggered something and the prompt came back within iTerm for me. I was able to avoid rebooting the machine.






                        share|improve this answer




























                          0














                          I actually found that the issue, for me, was related to a hung "login" process. In following the suggestion above, I did not see any "sudo" process within the list from Activity Monitor, but I did notice a lot of "login" processes owned by root. I went through and started killing these, and one of them triggered something and the prompt came back within iTerm for me. I was able to avoid rebooting the machine.






                          share|improve this answer


























                            0












                            0








                            0







                            I actually found that the issue, for me, was related to a hung "login" process. In following the suggestion above, I did not see any "sudo" process within the list from Activity Monitor, but I did notice a lot of "login" processes owned by root. I went through and started killing these, and one of them triggered something and the prompt came back within iTerm for me. I was able to avoid rebooting the machine.






                            share|improve this answer













                            I actually found that the issue, for me, was related to a hung "login" process. In following the suggestion above, I did not see any "sudo" process within the list from Activity Monitor, but I did notice a lot of "login" processes owned by root. I went through and started killing these, and one of them triggered something and the prompt came back within iTerm for me. I was able to avoid rebooting the machine.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Dec 26 '18 at 21:05









                            not donald trumpnot donald trump

                            1




                            1






























                                draft saved

                                draft discarded




















































                                Thanks for contributing an answer to Super User!


                                • 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%2fsuperuser.com%2fquestions%2f180568%2fwhy-does-my-os-x-terminal-display-a-blank-window-instead-of-a-command-prompt-aft%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

                                flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

                                Mangá

                                Eduardo VII do Reino Unido