Ctrl-C (Break key) for Mac?

[mfram]

That is interesting behavior with that while loop using the ping command. I was able to stop it indirectly which is good enough I suppose.

First, use control-z to get back to the shell. That will suspend the job and put it in the background. But doesn't kill it. After that, you can use 'kill %1' to kill the job.

mbp-wl:~$ while true; do ping -c 3 yahoo.com; done
PING yahoo.com (98.139.183.24): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- yahoo.com ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
PING yahoo.com (98.139.183.24): 56 data bytes
Request timeout for icmp_seq 0
^Z
[1]+  Stopped                 ping -c 3 yahoo.com
mbp-wl:~$ kill %1

[1]+  Stopped                 ping -c 3 yahoo.com
mbp-wl:~$ 
[1]+  Terminated: 15          ping -c 3 yahoo.com
mbp-wl:~$

First I tried control-C which only killed the ping program but not the loop. Then I used control-Z which forced the job to be suspended in the background. 'kill %1' means to kill background job 1 in your shell.

 

[macrumnev]

That is interesting behavior with that while loop using the ping command. I was able to stop it indirectly which is good enough I suppose.

First, use control-z to get back to the shell. That will suspend the job and put it in the background. But doesn't kill it. After that, you can use 'kill %1' to kill the job.

mbp-wl:~$ while true; do ping -c 3 yahoo.com; done
PING yahoo.com (98.139.183.24): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- yahoo.com ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
PING yahoo.com (98.139.183.24): 56 data bytes
Request timeout for icmp_seq 0
^Z
[1]+  Stopped                 ping -c 3 yahoo.com
mbp-wl:~$ kill %1

[1]+  Stopped                 ping -c 3 yahoo.com
mbp-wl:~$ 
[1]+  Terminated: 15          ping -c 3 yahoo.com
mbp-wl:~$

First I tried control-C which only killed the ping program but not the loop. Then I used control-Z which forced the job to be suspended in the background. 'kill %1' means to kill background job 1 in your shell.

OMG, you did it! Yes, it would be nice to be in one keystroke, but at least now I don't have to close the window. Awesome, mfram. Thanks!

----------

I did read the thread. In fact, I reread it, including my earlier replies. I also went and read your other posts, few though they were, to see if they shed any light on your experience level or gave insight into what kind of while loop you were referring to. Other than what you posted, I have no way of knowing what you know, or guessing what you might mean.

If you're having trouble with a specific command-line construct, then you need to post it, in the exact form that's causing the problem. Putting in fillers and placeholders may not work. You agreed that details are important, yet you posted an example whose details differed from the command-line you were having problems with.

One reason for posting the exact command-line you're having problems with is to replicate the problem here on my machine, and to study ways of solving the problem. If you post a different problem, then all I can do is to study the problem you posted.

One of the ways to solve problems is to restructure them. That's what I did with the ping example you posted. If you'd posted the actual commands you were having trouble with, I would have studied those. I might not have found a solution, but at least I'd be looking for a solution for what you were actually having a problem with. Since you didn't post it in any of your replies, I can't possibly offer any other ideas for solutions.

To see how ctrl-c or command-dot stops a while loop in the shell, try these:

while true; do true; done
while true; do false; done
while true; do sleep 5; done

You should see that each of these is interruptible. This suggests the problem isn't with the while/do/done per se, but something else. That's just a guess, since we still don't know exactly what commands you're having trouble with.

Chown33,
Yesterday was a bombardment of conflict in numerous sites and at work, with people attacking my code, and making me repeat myself, and I was overly harsh with you. I apologize for that. You still remained polite, much to your credit.

 

[dyn]

For example in terminal, if I typed a long line but want to abort it, I used press Ctrl-C to cancel it in a different OS.

You should actually use ctrl-u for that (it's clear line). Ctrl-c is what you use to abort (break) something that is already running.

These things also depend on the shell (bash, zsh, tcsh, etc.) you use. However, the use of the control key here is the same as in Linux which is rather nice. Or worded differently: you can use the same keybindings as in Linux when using the shell.

 

[subsonix]

You should actually use ctrl-u for that (it's clear line). Ctrl-c is what you use to abort (break) something that is already running.

You certainly can use ctrl-c in this case, it will not clear the current line, but give you a new fresh one.

 

[AlanShutko]

One thing I have discovered is I may need to hold down control-c to kill a while loop. I often need to kill the currently running process so the signal is directed at the shell again, then send the signal to the shell before it manages to start the next process in the loop. A while-true loop doesn't have this problem as true (and false) are bash builtins.

 

[dyn]

You certainly can use ctrl-c in this case, it will not clear the current line, but give you a new fresh one.

You can also do that with ctrl-d and restarting the shell, rebooting the machine and so on but that doesn't mean it is the correct way or the easiest way of doing it

Ctrl-u is clear line, ctrl-c is break which is something completely different. Break will abort the line, meaning that it will leave whatever is on it and go to the next. That might be something that you'd want.

Although ctrl-c has almost a similar function as ctrl-u it is not meant to clear lines. UNIX is filled with these kind of subtle differences that you really need to understand. A lot of times these differences explain why things are behaving a certain way (read: doing something completely different than what you are expecting).

 

[subsonix]

Ctrl-u is clear line, ctrl-c is break which is something completely different. Break will abort the line, meaning that it will leave whatever is on it and go to the next. That might be something that you'd want.

Although ctrl-c has almost a similar function as ctrl-u it is not meant to clear lines. UNIX is filled with these kind of subtle differences that you really need to understand. A lot of times these differences explain why things are behaving a certain way (read: doing something completely different than what you are expecting).

I did not say it's meant to clear lines, and it doesn't. But it makes perfect sense that sending ctrl-c to the shell aborts the current line if you have not yet pressed enter.

The poster you quoted claimed it did not work to abort the current line, but it does.

I know they are different, and ctrl-u makes no sense outside of a shell, ctrl-c or SIGINT does though.

 

[dyt1983]

You should actually use ctrl-u for that (it's clear line). Ctrl-c is what you use to abort (break) something that is already running.

These things also depend on the shell (bash, zsh, tcsh, etc.) you use.

Actually... ^C and ^U (the default usages) are not totally dependent on the shell. They are provided by the terminal interface (termio or termcap depending on what UNIX-like system you are using). On most BSD-like systems they can be change by the stty command, and if you invoke other shells without parsing initialization scripts the terminal kill and interrupt keys will stay the same. Sure, a shell or any program can disable or change the terminal control chars (like tcsh does with ^U), but in practice a change to the terminal will be honored within the common shells. Like if I change my kill from ^U to ^? and run tcsh, ^U will still buffer the killed line, but ^? will just kill the line.

I know they are different, and ctrl-u makes no sense outside of a shell, ctrl-c or SIGINT does though.

Well, they're terminal-specific, not shell... so they do make sense if you're not running a shell. Like the login prompt before a shell is invoked will use the cchars, or any application that doesn't change or disable the cchars will also honor them even if not running as a subprocess of a shell ... like a program run as the default on a tty rather than login.

I wouldn't have brought this up except you guys were getting awfully picky about semantics and seemingly ignoring the elephant in the room.

 

[dyn]

The poster you quoted claimed it did not work to abort the current line, but it does.

That wasn't in the quote I used and I did that for a very good reason. What's in the quote is what he actually wanted to do. That 1 sentence is what he wants to accomplish. That's what this topic is about. Everything else is just noise.

I wouldn't have brought this up except you guys were getting awfully picky about semantics and seemingly ignoring the elephant in the room.

Then you have misunderstood my post. I was trying to keep things very simple and steer away from complex information like yours. The easiest way to remember things: ctrl-u for clearing a line, ctrl-c for stopping a command (usually one that doesn't want to stop) and things might be different from shell to shell due to the default settings it comes with as well as the terminal it runs in. For someone who barely understands that the ctrl key holds special meaning in the world of shells and who simply wants to clear a line that's more than enough to know.

Let's not make things even more confusing for the OP!

 

[subsonix]

That wasn't in the quote I used and I did that for a very good reason. What's in the quote is what he actually wanted to do. That 1 sentence is what he wants to accomplish. That's what this topic is about. Everything else is just noise.

You're funny.

For example in terminal, if I typed a long line but want to abort it, I used press Ctrl-C to cancel it in a different OS.

It seems pretty clear that he wanted to abort or cancel it, and the implication is that ctrl-c does not work for this in OS X. Back in 2010 when the OP had this problem, the reason it did not work was that cmd-c was used. I just added a comment to say that, yes it does actually work to abort or cancel with ctrl-c. It's not noise, it's a matter of fact.

 

[kelmblade]

Where have you been all my life!!! One simple command. That's all I wanted. I started with CPM based systems and eventually moved to the DOS world. My use of Linux and Macs is a recent thing. It shouldn't be all that hard to provide a map for similar commands between the two, but for some reason, finding such maps are extremely difficult. It's as if the folks who come from disparate worlds refuse to acknowledge each other's existence.

This simple command has plagued me for the nearly four years I've spent in the Mac world. THANK YOU so much for (finally!!!) providing me with the simple keyboard combination I needed to terminate the programs or batch files I was running in a terminal session. This is NOT !@#$ing rocket science!! It shouldn't be so difficult. Oi!!