Why does my OS X Terminal display a blank window instead of a command prompt after installing MySQL?
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:
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
add a comment |
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:
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
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 runsudo
and then close the terminal while it’s waiting for you to enter the password. This hangssudo
, which prevents any further logins. To resolve the issue, use Activity Monitor (or another terminal if you happen to have one open) to kill thesudo
process. (Obviously, if there is nosudo
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
add a comment |
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:
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
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:
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
macos troubleshooting terminal
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 runsudo
and then close the terminal while it’s waiting for you to enter the password. This hangssudo
, which prevents any further logins. To resolve the issue, use Activity Monitor (or another terminal if you happen to have one open) to kill thesudo
process. (Obviously, if there is nosudo
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
add a comment |
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 runsudo
and then close the terminal while it’s waiting for you to enter the password. This hangssudo
, which prevents any further logins. To resolve the issue, use Activity Monitor (or another terminal if you happen to have one open) to kill thesudo
process. (Obviously, if there is nosudo
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
add a comment |
5 Answers
5
active
oldest
votes
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.
Killing alljava
processes has also solved this, for me
– Peter Becich
Jul 19 '16 at 1:18
add a comment |
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?
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
add a comment |
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.
add a comment |
- Launch Activity Monitor
- Select "All Processes, Hierarchically"
- Look for your Terminal process
- Try to spot a process that might be "stuck" and interfering with the login
Or:
- 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.
add a comment |
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%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
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.
Killing alljava
processes has also solved this, for me
– Peter Becich
Jul 19 '16 at 1:18
add a comment |
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.
Killing alljava
processes has also solved this, for me
– Peter Becich
Jul 19 '16 at 1:18
add a comment |
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.
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.
answered Aug 11 '11 at 7:11
Chris PageChris Page
2,5241635
2,5241635
Killing alljava
processes has also solved this, for me
– Peter Becich
Jul 19 '16 at 1:18
add a comment |
Killing alljava
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
add a comment |
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?
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
add a comment |
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?
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
add a comment |
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?
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?
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Mar 21 '11 at 13:07
Jari KeinänenJari Keinänen
3162620
3162620
add a comment |
add a comment |
- Launch Activity Monitor
- Select "All Processes, Hierarchically"
- Look for your Terminal process
- Try to spot a process that might be "stuck" and interfering with the login
Or:
- 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.
add a comment |
- Launch Activity Monitor
- Select "All Processes, Hierarchically"
- Look for your Terminal process
- Try to spot a process that might be "stuck" and interfering with the login
Or:
- 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.
add a comment |
- Launch Activity Monitor
- Select "All Processes, Hierarchically"
- Look for your Terminal process
- Try to spot a process that might be "stuck" and interfering with the login
Or:
- 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.
- Launch Activity Monitor
- Select "All Processes, Hierarchically"
- Look for your Terminal process
- Try to spot a process that might be "stuck" and interfering with the login
Or:
- 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.
answered Nov 22 '13 at 5:26
Zac ThompsonZac Thompson
822913
822913
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Dec 26 '18 at 21:05
not donald trumpnot donald trump
1
1
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 hangssudo
, which prevents any further logins. To resolve the issue, use Activity Monitor (or another terminal if you happen to have one open) to kill thesudo
process. (Obviously, if there is nosudo
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