Control-C in bash ???

On a PC, I can, for instance, enter "ping 192.168.1.4", then hit Control-C and stop the ping. For the life of me, I can't figure out how to do the same on my MPC860 system!!!

I have an MPC860 running 2.4.19, with a mostly unmodified eldk distribution from Wolfgang Denx. I did modify the init script to use /dev/console instead of /ttyx (standard driver using SMC1). I'd not only like a solution, I want to undertand how cancelling a shell command is supposed to work - I've poked around and I can't figure out what's supposed to happen - Does the shell generate a SIGINT, or the uart driver, or what? Any enlightenment will be greatly appreciated...

Mark Chambers
[email protected]

-------------------------------------------------------

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

I belive that the problem is that the control-C never arives on the console as the serial-comunication package you are using does not deliver it (atleast minicom does not) - You can use ping -c 1 (not sure if your ping also takes -c # for the count) to ensure that it will terminate after one ping package. That was my workaround...

hofrat

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

This is the old ELDK, then? The current version includes

	3:2345:respawn:/sbin/mingetty --noclear console

and a fix for the ^C problem....

You need a controlling terminal. We modified login: to set it as needed. See the previous thread ("RAMDISK IMAGES(2): ash has no job control").

Best regards,

Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: [email protected] "There are three principal ways to lose money: wine, women, and en- gineers. While the first two are more pleasant, the third is by far
the more certain." -- Baron Rothschild, ca. 1800

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Thanks for your help on this one. I changed the last line of etc/inittab to

        3:2345:respawn:/sbin/mingetty --noclear tts/0

and added "tts/0" to etc/securetty and now I get a console with job control.
I don't know how long it would have taken me to discover "job control" or "controlling tty"!! (I'm learning linux from the ground up)

Thanks again,
Mark Chambers

Original message:

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

if you boot init=/bin/sh or whatever and your init/login doesn't set the tty up, you will need to do it yourself (man stty).

--cw

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Hi Mark,

I had exactly the same problem with ash (busybox version), but I found it went away when I replaced

ttyS0::respawn:-/bin/sh

in /etc/inittab with

ttyS0::respawn:/sbin/login

I have no idea why....

Alex

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

I explained this a couple of times before on the list:

Signal handling depends on a controlling tty. If you start a shell directly, you don't get one, so ^C will not work.

We modified the login in our ELDK a bit to assign a controlling tty, so any shell started from login will behave as expected.

This is all the magic that it takes:

-> cat /opt/eldk/build/target_rpms/util-linux/SOURCES/login-eldk.patch

@@ -259,6 +259,7 @@
 
     flags &= ~O_NONBLOCK;
     fcntl(fd, F_SETFL, flags);
+    ioctl(fd, TIOCSCTTY);
 
     for (i = 0 ; i < fd ; i++)
       close(i);

Best regards,

Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: [email protected]
"Free markets select for winning solutions." - Eric S. Raymond

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

If all of you would look back into the mailing list archives you would notice this discussion before. The reason ctl-C won't work is you need a "controlling tty" device.

The program that is started as process ID 1 is a special program (expected to be '/sbin/init') and can't be used as a 'controlling tty'. Signals to this process are managed differently in the kernel. Any program you start in this process ID slot, which is you favorite shell or busybox or whatever, can't assign a controlling tty and get the ctl-C signals. It doesn't matter how it is built or what ioctls you try to send to the driver.

If you start up init, or run /bin/login or any of a variety of things you can do to actually configure a controlling tty and spawn a shell will obivously work as expected. Starting up a shell as 'init=/bin/sh', or some other program in the 'init' PID 1 slot is considered a recovery method and will lose some of its tty functions. Even for a shell not in the PID 1 slot, you have to do something along the path to configure a driver as a "controlling tty", using /bin/login or the methods Wolfgang described in past messages.

Thanks.

	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/