@ character has aberrant behavior

This has been bedeviling me.

When I enter the @ character (not ^@) the following occurs:

(1) at the csh prompt: nothing and the @ does not displya

(2) within sqlplus

• @ displays
• it puts me on a new line (as if continuing the previous one)
• if I try to complete the sql command it complains of an invalid character
  stty -a shows me nothing that I can see (reproduced below). It's using xterm but I did a setenv TERM vt100 and it didn't matter.

% stty -a
speed 38400 baud; line = 0;
rows = 69; columns = 80
min = 1; time = 1;
intr = ^C; quit = ^\; erase = ^H; kill = @
eof = ^D; eol = ^@; eol2 <undef>; swtch <undef>
stop = ^S; start = ^Q; susp = ^Z; dsusp <undef>
werase <undef>; lnext <undef>
-parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -crts
-ignbrk brkint -ignpar -parmrk -inpck istrip -inlcr -igncr icrnl -iuclc
ixon ixany -ixoff -imaxbel -rtsxoff -ctsxon -ienqak
isig icanon -iexten -xcase echo echoe echok -echonl -noflsh
-echoctl -echoprt -echoke -flusho -pendin
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel -tostop tab3
%

When you set the kill character for your terminal input to be the @ sign, the behavior you are describing is exactly what you should expect. Most people now set their kill character to be the keyboard combination of holding down the control key and hitting the u key (which stty would show as ^U ).

Thx!

I mean, that was sort of obvious. (What an understatement!)

---------- Post updated at 05:32 PM ---------- Previous update was at 02:55 PM ----------

Here's my next question: why would HP do this? I mean, take over a regular character to use as a control character? This seems sort of lunatic.

It's not like there aren't alternatives like the ^U you suggested which is what linux has for xterm.

On early UNIX systems (with ASR-33 Teletypes as hardcopy (not CRT, LED, LCD, ...) terminals), the default ERASE and KILL characters were # and @ , respectively. The default characters used when you open a terminal device are set to system defaults (not terminal type defaults). The stty(1) man page on your system probably specifies what the defaults are on your system. If you don't like the defaults, add an stty command to your .profile (or similar shell initialization file for your login shell) to set the characters you want to use.

Thank you for the history. It was very interesting.

I put a setting in my .cshrc after your first email. I noticed I already had added stty's for intr and susp.

Which brings me to:

I would have thought that HP might have considered revising their default settings after a while. I mean, teletypes ...

Is this why HP-UX doesn't work very setting password with @ then? We're always being told to make password more complex, yet people like the @ and it works for AIX, RHEL, Windows AD, ....... but has a problem with HP-UX.

Thanks,
Robin

Yeah, the fact that @ is acting as a line kill character does indeed cause problems with passwords containing a @ character. You can't reset your kill character until after you login and run an stty command. However, see this old thread for a solution...
/t/cannot-telnet-hp-ux-with-nis-account/154016/1

I found it handy... Ever seen admin block the console because nervous on a trusted system?
hehe
Yes, if you make a typo either in the name or passwd, @ will empty the buffer which may not be the case with something else...
But of course it has side effects elsewhere ... no system is perfect haha

Well, back in the old days, a, um, friend of mine once gave two auditors accounts on an HP-UX system and told them that their passwords were something similar to:

xyzzy-plugh-shazam-@1
xyzzy-plugh-shazam-@2

thus convincing them that the HP-UX system in question supported long passwords.

When your password contains a character that is an ERASE or KILL character on that system, you can precede that character with a backslash ( \ ) when you are typing in your password and its special meaning will be escaped.