Control-C in here document (scripting)

[Clemens van Everdingen]

Hi,

How do I sent a control-c (^c)

from a here document within a script.

#! /usr/bin/ksh

function SWITCH {
exec >> //log/test.log 2>&1
set -x
date
exec telnet ${1} << EOF
admin
login
^c (not working like this)
date; portperfshow 30
EOF
}

SWITCH
SWITCH

[RAC_1]

May be kill -SIGINT in your script.

Anil

[Clemens van Everdingen]

Did not work !

Same problem.

[Mark Grant]

Why exactly do you want a ^C in here?

If it is to stop something running, and you want the result of the date and portperfshow command then can't you just use a different account that doesn't start this application in the .profile and perhaps use remsh.

[Clemens van Everdingen]

If not using ^c we need to change the passwords

The message is this:

Password:
Please change your passwords now.
Use Control-C to exit or press 'Enter' key to proceed.

If enter the we need to change the passwords.
We don't want to do that.

[Mark Grant]

Ok, if you are editing this script with "vi" you could try inserting a real control C with CTRL-V CTRL-C. This will give you a real CTRL C.

You might consider using "expect" instead.

[Peter Leddy_1]

Hi,

As far as I know to insert a control character in vi, when you are in insert mode type ctrl v and then ctrl c and ^C will be recognised.

Hope this helps,

Peter

[Timothy Cole_1 · Accepted solution]

login is really expecting a SIGINT, not a control character.

When you're doing it interactively, the effect of pressing ^C is to send SIGINT to the foreground process group.

This is handled directly by the tty driver, which delivers the signal (similarly for other control combinations, like ^Z, sending SIGTSTP -- this is configurable via stty(1)).

When reading from a heredoc, there is no tty involved (stdin is a pipe, not a tty device), so the raw ^C character gets passed through to login. No signals are sent.

[Timothy Cole_1]

Actually what's happening is a little more complicated than that (but not much), since you have telnet involved.

When telnet(1) receives a SIGINT from the terminal driver, it sends an _out of band_ sequence indicating the interrupt to the remote telnetd, which then sends a SIGINT to its own children (or does the equivalent on that OS).

As before, including a literal ^C in stdin will just result in the remote process recieving a literal ^C, rather than the expected SIGINT.

I'm not sure there's an easy solution -- you'd need to write something to parse telnet(1)'s stdout and send a SIGINT to it at the appropriate moment.

It might be less work to change the admin password by hand once so it doesn't complain.

If it's possible, I'd really recommend using SSH with public key authentication instead of telnet -- it's much more secure and you don't have to worry about passwords then.

[Clemens van Everdingen]

I tried all the suggestions, but indeed none of them is really working.

So I ended up changing the passwords.

Thanks for the suggestions.
Clemens