Bash: Why is a particular program not responding to CTRL {c,z,\} ?

[Ottavio Caruso]

Hi,

I periodically run a command, for example:

$ gen_text1 "cb?dw4lh+8@px,1y-" 186 | morse -f `echo $RANDOM % 400 +
500 | bc` -ecTsB -w 15 -n 19

where:

$ type gen_text1
gen_text1 is a function
gen_text1 ()
{
tr -dc "$1" < /dev/urandom | fold -w 1 | head -n "$2" | paste -sd
'\0' -
}

$ whatis morse
morse (1) - Morse-code trainer and QSO generator for aspiring
radio hams

Since moving from Debian Stretch to Debian Buster (home partition is the
same, so all dot files are unchanged), and consequently from bash v4 to
bash v5, I can't manage to "sigkill" this program from the terminal;
example:

$ gen_text1 "cb?dw4lh+8@px,1y-" 186 | morse -f `echo $RANDOM % 400 +
500 | bc` -ecTsB -w 15 -n 19
^C^C^C^C^C^C^C^C
^Z^Z^Z^Z^Z^Z^Z^Z^Z
^\^\^\^\^\^\^\^\^\


The only solution is to open another terminal and run "killall -9 morse".

This is what the program looks like from the other terminal before being
killed:

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
oc 25446 0.7 0.1 439780 5080 pts/1 Sl+ 07:39 0:00 morse
-f 547 -ecTsB -w 15 -n 19


I am not sure if I am doing anything wrong or something has changed from
bash v4 to bash v5. It's not the end of the world but it's annoying.

Any input will be appreciated.

--
Ottavio Caruso

[Christian Weisgerber]

On 2021-03-27, Ottavio Caruso <ottavio2006...@yahoo.com> wrote:

> Since moving from Debian Stretch to Debian Buster (home partition is the
> same, so all dot files are unchanged), and consequently from bash v4 to
> bash v5, I can't manage to "sigkill" this program from the terminal;

I'd start with "stty -a" to check the values of the intr, quit, susp
characters.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Janis Papanagnou]

> oc 25446 0.7 0.1 439780 5080 pts/1 Sl+ 07:39 0:00 morse^C

> -f 547 -ecTsB -w 15 -n 19

The process state 'S' says "interruptible sleep (waiting for an event
to complete)".

>
> I am not sure if I am doing anything wrong or something has changed from
> bash v4 to bash v5. It's not the end of the world but it's annoying.
>
> Any input will be appreciated.

Generally I also observe sometimes processes that can't be killed in
shell by ^C etc.; some processes or executed tasks may have disabled
handling of SIGINT, or maybe it's something different, hard to tell.
Is it the terminal or one of processes that catches these signals?
So my first try would be to send a SIGINT from outside not a SIGKILL.
What event is the process waiting for; inspecting the syslog may help
here. Then I'd approach the issue by simplifying the code to find the
source. Simplifying steps can be to replace the '`...|bc`' complexity
by a simple shell arithmetic expression 'morse $((RANDOM ...))'. And
as another step omit all unnecessary options to localize the issue.
(Adding options one by one later to see if some option may change the
behavior.) And also simplify the input; use a 'printf' instead of a
pipe expression (specifically if you rely on /dev/urandom) and omit
the function call.

Janis

[Ottavio Caruso]

On 27/03/2021 12:23, Christian Weisgerber wrote:
> On 2021-03-27, Ottavio Caruso <ottavio2006...@yahoo.com> wrote:
>
>> Since moving from Debian Stretch to Debian Buster (home partition is the
>> same, so all dot files are unchanged), and consequently from bash v4 to
>> bash v5, I can't manage to "sigkill" this program from the terminal;
>
> I'd start with "stty -a" to check the values of the intr, quit, susp
> characters.
>

intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt
= ^R;

Looks standard to me.

--
Ottavio Caruso

[Ottavio Caruso]

If by SIGINT you mean a standard kill, it doesn't work. The process must
be killed mercilessly with `kill -9`. I've checked both
/var/log/messages and /var/log/syslog, but nothing gets written there.

Then I'd approach the issue by simplifying the code to find the
> source. Simplifying steps can be to replace the '`...|bc`' complexity
> by a simple shell arithmetic expression 'morse $((RANDOM ...))'. And
> as another step omit all unnecessary options to localize the issue.
> (Adding options one by one later to see if some option may change the
> behavior.) And also simplify the input; use a 'printf' instead of a
> pipe expression (specifically if you rely on /dev/urandom) and omit
> the function call.

I'll give a look at that. Somebody wrote that function for me some time
ago and I just used without much understanding of it, to be completely
honest.


--
Ottavio Caruso

[Spiros Bousbouras]

On Sat, 27 Mar 2021 14:07:54 +0000

Ottavio Caruso <ottavio2006...@yahoo.com> wrote:
> On 27/03/2021 13:27, Janis Papanagnou wrote:
> > On 27.03.2021 08:48, Ottavio Caruso wrote:

[...]

> >> Since moving from Debian Stretch to Debian Buster (home partition is the
> >> same, so all dot files are unchanged), and consequently from bash v4 to
> >> bash v5, I can't manage to "sigkill" this program from the terminal;
> >> example:

[...]

> > Then I'd approach the issue by simplifying the code to find the
> > source. Simplifying steps can be to replace the '`...|bc`' complexity
> > by a simple shell arithmetic expression 'morse $((RANDOM ...))'. And
> > as another step omit all unnecessary options to localize the issue.
> > (Adding options one by one later to see if some option may change the
> > behavior.) And also simplify the input; use a 'printf' instead of a
> > pipe expression (specifically if you rely on /dev/urandom) and omit
> > the function call.
>
> I'll give a look at that. Somebody wrote that function for me some time
> ago and I just used without much understanding of it, to be completely
> honest.

Try also something like
grep 'Hello world' < /dev/urandom

and see if you can kill it with any of the methods you've tried. Look also
into man 4 random and the man page for BASH to see if it says anything
special about /dev/urandom .

[Janis Papanagnou]

On 27.03.2021 15:07, Ottavio Caruso wrote:
> On 27/03/2021 13:27, Janis Papanagnou wrote:
>>
>> Generally I also observe sometimes processes that can't be killed in
>> shell by ^C etc.; some processes or executed tasks may have disabled
>> handling of SIGINT, or maybe it's something different, hard to tell.
>> Is it the terminal or one of processes that catches these signals?
>> So my first try would be to send a SIGINT from outside not a SIGKILL.
>> What event is the process waiting for; inspecting the syslog may help
>> here.
>
> If by SIGINT you mean a standard kill, it doesn't work.

kill without option is SIGTERM (15), SIGINT is 2, SIGQUIT is 3; all
these signals (as opposed to e.g. SIGKILL (9)) can be intercepted
and handled by processes. I meant to try 'kill -2' (SIGINT, that is
on terminals usually available as Ctrl-C (^C)).

> The process must
> be killed mercilessly with `kill -9`. I've checked both
> /var/log/messages and /var/log/syslog, but nothing gets written there.
>
>
> Then I'd approach the issue by simplifying the code to find the
>> source. Simplifying steps can be to replace the '`...|bc`' complexity
>> by a simple shell arithmetic expression 'morse $((RANDOM ...))'. And
>> as another step omit all unnecessary options to localize the issue.
>> (Adding options one by one later to see if some option may change the
>> behavior.) And also simplify the input; use a 'printf' instead of a
>> pipe expression (specifically if you rely on /dev/urandom) and omit
>> the function call.
>
> I'll give a look at that. Somebody wrote that function for me some time
> ago and I just used without much understanding of it, to be completely
> honest.

The tests should start simple without that function

echo "Hello" | morse $((RANDOM % 400 + 500))

Then introduce a function but without using the 'urandom' device.
And so on. If questions arise on the way feel free to ask.

Janis

[Ottavio Caruso]

Yes, I can kill it with ctrl-c.

> Look also
> into man 4 random and the man page for BASH to see if it says anything
> special about /dev/urandom .

Nothing that catches my attention.

I've also used this function:

gen_text2 ()
{
tr -dc "$1" < /dev/urandom | head -c "$2";
printf "\n"
}

$ gen_text2 "cb?dw4lh+8@px,1y-" 186 | morse -f `echo $RANDOM % 400 +

500 | bc` -ecTsB -w 15 -n 19

Same thing, I can't kill it.


--
Ottavio Caruso

[Ottavio Caruso]

On 27/03/2021 14:27, Janis Papanagnou wrote:
> On 27.03.2021 15:07, Ottavio Caruso wrote:
>> On 27/03/2021 13:27, Janis Papanagnou wrote:
>>>
>>> Generally I also observe sometimes processes that can't be killed in
>>> shell by ^C etc.; some processes or executed tasks may have disabled
>>> handling of SIGINT, or maybe it's something different, hard to tell.
>>> Is it the terminal or one of processes that catches these signals?
>>> So my first try would be to send a SIGINT from outside not a SIGKILL.
>>> What event is the process waiting for; inspecting the syslog may help
>>> here.
>>
>> If by SIGINT you mean a standard kill, it doesn't work.
>
> kill without option is SIGTERM (15), SIGINT is 2, SIGQUIT is 3; all
> these signals (as opposed to e.g. SIGKILL (9)) can be intercepted
> and handled by processes. I meant to try 'kill -2' (SIGINT, that is
> on terminals usually available as Ctrl-C (^C)).

First of all, I have now used a different function:

gen_text2 ()
{
tr -dc "$1" < /dev/urandom | head -c "$2";
printf "\n"
}

$ gen_text2 "cb?dw4lh+8@px,1y-" 186 | morse -f `echo $RANDOM % 400 +

500 | bc` -ecTsB -w 15 -n 19

^C^C^C^C^C^Z^Z^Z^Z^Z^\^\^\^\^\^\^\^C^C

In another terminal tab:

$ ps aux|grep morse
oc 11356 0.0 0.1 439780 5120 pts/5 Sl+ 14:34 0:00 morse
-f 878 -ecTsB -w 15 -n 19
oc 11387 0.0 0.0 6076 892 pts/6 S+ 14:36 0:00 grep
--color=auto morse
$ kill -2 11356


Nope!

$ tail /var/log/syslog
$ tail /var/log/messages

Nothing relevant.

>
>> The process must
>> be killed mercilessly with `kill -9`. I've checked both
>> /var/log/messages and /var/log/syslog, but nothing gets written there.
>>
>>
>> Then I'd approach the issue by simplifying the code to find the
>>> source. Simplifying steps can be to replace the '`...|bc`' complexity
>>> by a simple shell arithmetic expression 'morse $((RANDOM ...))'. And
>>> as another step omit all unnecessary options to localize the issue.
>>> (Adding options one by one later to see if some option may change the
>>> behavior.) And also simplify the input; use a 'printf' instead of a
>>> pipe expression (specifically if you rely on /dev/urandom) and omit
>>> the function call.
>>
>> I'll give a look at that. Somebody wrote that function for me some time
>> ago and I just used without much understanding of it, to be completely
>> honest.
>
> The tests should start simple without that function
>
> echo "Hello" | morse $((RANDOM % 400 + 500))
>
> Then introduce a function but without using the 'urandom' device.
> And so on. If questions arise on the way feel free to ask.
>
> Janis
>

$ echo "Hello" | morse $((RANDOM % 400 + 500))
^C^C^C^C^C^C^C^C^C^Z^Z^Z^Z^Z^\^\^\^\^\^\

$ ps aux|grep morse
oc 11477 0.2 0.1 439780 5028 pts/6 Sl+ 14:40 0:00 morse 630
oc 11481 0.0 0.0 6076 892 pts/7 S+ 14:40 0:00 grep
--color=auto morse
$ kill -2 11477


Nope again.

I've checked on the Debian package search. Both Stretch and Buster use
the same version of morse, so nothing has changed in the source code.

-
Ottavio Caruso

[Janis Papanagnou]

On 27.03.2021 15:44, Ottavio Caruso wrote:
>
> $ echo "Hello" | morse $((RANDOM % 400 + 500))
> ^C^C^C^C^C^C^C^C^C^Z^Z^Z^Z^Z^\^\^\^\^\^\
>
> $ ps aux|grep morse
> oc 11477 0.2 0.1 439780 5028 pts/6 Sl+ 14:40 0:00 morse 630
> oc 11481 0.0 0.0 6076 892 pts/7 S+ 14:40 0:00 grep
> --color=auto morse
> $ kill -2 11477
>
>
> Nope again.

You mean even that primitive command is not killable? - Hmm..
Is calling 'morse' alone (no pipe, no arguments) killable?

Are you running the shell locally or remote through some tool?

My next steps would focus on the terminal. First I'd retry in
a new shell instance in a new window.

I'd also try a 'reset' and a 'stty sane' respectively before
starting that shell command.

Finally I'd use another 'morse' version - I am running an old
one, and I don't see the issue you have - to see if it's a bug.

Janis

[Ottavio Caruso]

On 27/03/2021 14:58, Janis Papanagnou wrote:
> On 27.03.2021 15:44, Ottavio Caruso wrote:
>>
>> $ echo "Hello" | morse $((RANDOM % 400 + 500))
>> ^C^C^C^C^C^C^C^C^C^Z^Z^Z^Z^Z^\^\^\^\^\^\
>>
>> $ ps aux|grep morse
>> oc 11477 0.2 0.1 439780 5028 pts/6 Sl+ 14:40 0:00 morse 630
>> oc 11481 0.0 0.0 6076 892 pts/7 S+ 14:40 0:00 grep
>> --color=auto morse
>> $ kill -2 11477
>>
>>
>> Nope again.
>
> You mean even that primitive command is not killable? - Hmm..
> Is calling 'morse' alone (no pipe, no arguments) killable?
>

morse alone will just display a help page. I've tried

$ morse -r

and I've run in the same issue.

> Are you running the shell locally or remote through some tool?

Local.

>
> My next steps would focus on the terminal. First I'd retry in
> a new shell instance in a new window.
>
> I'd also try a 'reset' and a 'stty sane' respectively before
> starting that shell command.

Done all of these and no joy.

>
> Finally I'd use another 'morse' version - I am running an old
> one, and I don't see the issue you have - to see if it's a bug.

That would be a problem. I'd have to do a reverse backport. Not sure if
this is possible. I'd have to ask on the Debian mailing lists.


--
Ottavio Caruso

[Janis Papanagnou]

On 27.03.2021 16:11, Ottavio Caruso wrote:
> [...] I've tried
>
> $ morse -r

(I don't know what that option does, my 'morse' doesn't list it;
as said I have only an old version running. My version runs also
without options: it waits for input to translate it to morse code.)

> and I've run in the same issue.
>
>>

>> Finally I'd use another 'morse' version - I am running an old
>> one, and I don't see the issue you have - to see if it's a bug.
>
> That would be a problem. I'd have to do a reverse backport. Not sure if
> this is possible. I'd have to ask on the Debian mailing lists.

I'd file a bug report.

Janis

[Spiros Bousbouras]

On Sat, 27 Mar 2021 15:11:59 +0000

Ottavio Caruso <ottavio2006...@yahoo.com> wrote:
> morse alone will just display a help page. I've tried
>
> $ morse -r
>
> and I've run in the same issue.

You can try
strace morse -r

or something similar and see if morse does anything with signals or changes
the settings of the terminal driver.

[Keith Thompson]

Ottavio Caruso <ottavio2006...@yahoo.com> writes:
[...]

> Since moving from Debian Stretch to Debian Buster (home partition is
> the same, so all dot files are unchanged), and consequently from bash
> v4 to bash v5, I can't manage to "sigkill" this program from the
> terminal; example:
>
> $ gen_text1 "cb?dw4lh+8@px,1y-" 186 | morse -f `echo $RANDOM % 400 +
> 500 | bc` -ecTsB -w 15 -n 19
> ^C^C^C^C^C^C^C^C
> ^Z^Z^Z^Z^Z^Z^Z^Z^Z
> ^\^\^\^\^\^\^\^\^\
>
> The only solution is to open another terminal and run "killall -9 morse".

"sigkill" is a misleading term here. SIGKILL is a specific signal, the
one sent by "kill -9" or "kill -KILL"; a program can't handle it.
Control-C sends SIGINT, Control-Z sends SIGTSTP, and Control-\
sends SIGQUIT (with normal tty settings).

The use of the word "kill" both for the command that sends a signal and
the name of a specific signal is admittedly confusing.

(I know this doesn't answer your question.)

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Keith Thompson]

Janis Papanagnou <janis_pa...@hotmail.com> writes:
> On 27.03.2021 15:44, Ottavio Caruso wrote:
>>
>> $ echo "Hello" | morse $((RANDOM % 400 + 500))
>> ^C^C^C^C^C^C^C^C^C^Z^Z^Z^Z^Z^\^\^\^\^\^\
>>
>> $ ps aux|grep morse
>> oc 11477 0.2 0.1 439780 5028 pts/6 Sl+ 14:40 0:00 morse 630
>> oc 11481 0.0 0.0 6076 892 pts/7 S+ 14:40 0:00 grep
>> --color=auto morse
>> $ kill -2 11477
>>
>>
>> Nope again.
>
> You mean even that primitive command is not killable? - Hmm..
> Is calling 'morse' alone (no pipe, no arguments) killable?
>
> Are you running the shell locally or remote through some tool?
>
> My next steps would focus on the terminal. First I'd retry in
> a new shell instance in a new window.
>
> I'd also try a 'reset' and a 'stty sane' respectively before
> starting that shell command.
>
> Finally I'd use another 'morse' version - I am running an old
> one, and I don't see the issue you have - to see if it's a bug.

Janis, it's likely you're running /usr/games/morse, part of the
"bsdgames" package. There's also a "morse" package that provides the
/usr/bin/morse command that Ottavio is using. (I'm on Ubuntu, but it
should be the similar on Debian.)

/usr/games/morse appears to operate purely on plain text input and
output. /usr/bin/morse works with sound.

>> I've checked on the Debian package search. Both Stretch and Buster use
>> the same version of morse, so nothing has changed in the source code.

[Janis Papanagnou]

On 28.03.2021 04:05, Keith Thompson wrote:
>
> Janis, it's likely you're running /usr/games/morse, part of the
> "bsdgames" package.

Yes, well observed. I indeed have (only) that one installed.

> There's also a "morse" package that provides the
> /usr/bin/morse command that Ottavio is using. (I'm on Ubuntu, but it
> should be the similar on Debian.)

Thanks for the hint.

> /usr/games/morse appears to operate purely on plain text input and
> output. /usr/bin/morse works with sound.

Janis

[jo...@schily.net]

In article <s3ndlq$btl$1...@dont-email.me>,

This is not sufficient. What is the state of "isig"?

--
EMail:jo...@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[jo...@schily.net]

In article <s3ne7r$gn8$1...@dont-email.me>,

Ottavio Caruso <ottavio2006...@yahoo.com> wrote:

>If by SIGINT you mean a standard kill, it doesn't work. The process must
>be killed mercilessly with `kill -9`. I've checked both
>/var/log/messages and /var/log/syslog, but nothing gets written there.

The state of the signals in the foregroubd process of a pipeline is important.

If you are on a modern OS that supports the proc tools from Roger Faulkner,
you can use psig(1) to print the signal state. If I do this e.g. for the
shell, I get with "psig $$":

25790: -bosh
HUP caught done 0
INT caught fault 0
QUIT caught fault 0
ILL caught done 0
TRAP caught done 0
ABRT caught done 0
EMT caught done 0
FPE caught done 0
KILL default
BUS caught done 0
SEGV caught sigsegv ONSTACK,SIGINFO
SYS caught done 0
PIPE caught done 0
ALRM caught done 0
TERM caught fault 0
USR1 caught done 0
USR2 caught done 0
CLD default NOCLDSTOP
...

Signals that are not in defalt state, usually do not work.

[Anssi Saari]

Ottavio Caruso <ottavio2006...@yahoo.com> writes:

> Hi,
>
> I periodically run a command, for example:
>
> $ gen_text1 "cb?dw4lh+8@px,1y-" 186 | morse -f `echo $RANDOM % 400 +
> 500 | bc` -ecTsB -w 15 -n 19

> where:
>
> $ type gen_text1
> gen_text1 is a function
> gen_text1 ()
> {
> tr -dc "$1" < /dev/urandom | fold -w 1 | head -n "$2" | paste -sd
> '\0' -
> }

I prefer code that can be copy-pasted but you had to line wrap it.

Anyways (assuming I got the line-wrap mangled code correctly) running
that I get one character output through the speakers, then morse seems
to hang. I can kill it with SIGHUP.

If I leave out the further options to morse (-ecTsB -w 15 -n 19) then it
beeps away for quite some time. At a guess I tried to remove all options
that produce output so with -eB -w 15 -n 19 morse also works.

I also took a peek at the source code. Morse does seem to install signal
handlers for SIGINT, SIGTERM, SIGQUIT, SIGTSTP which explains why SIGHUP
works. As for what goes wrong with those signal handlers when trying to
quit or suspend, I guess it's up to someone else to debug further.

[jo...@schily.net]

In article <sm0tuou...@lakka.kapsi.fi>, Anssi Saari <a...@sci.fi> wrote:

>Ottavio Caruso <ottavio2006...@yahoo.com> writes:

>I also took a peek at the source code. Morse does seem to install signal
>handlers for SIGINT, SIGTERM, SIGQUIT, SIGTSTP which explains why SIGHUP
>works. As for what goes wrong with those signal handlers when trying to
>quit or suspend, I guess it's up to someone else to debug further.

If you have the proctools from Roger Faulkner, you just need to call

psig <pid>

instead of searching for the source code...

[Anssi Saari]

Ottavio Caruso <ottavio2006...@yahoo.com> writes:

> I periodically run a command, for example:
>
> $ gen_text1 "cb?dw4lh+8@px,1y-" 186 | morse -f `echo $RANDOM % 400 +
> 500 | bc` -ecTsB -w 15 -n 19
>
> where:
>
> $ type gen_text1
> gen_text1 is a function
> gen_text1 ()
> {
> tr -dc "$1" < /dev/urandom | fold -w 1 | head -n "$2" | paste -sd
> '\0' -
> }

> $ whatis morse
> morse (1) - Morse-code trainer and QSO generator for
> aspiring radio hams

As an update, I noticed the morse package on Debian contains multiple
binaries for different sound output. The default "morse" uses PulseAudio
and seems to hang in the signal handlers and so won't die except with
kill -HUP (or kill -9). Of the other binaries morseALSA seems to work
better here. Doesn't output to a terminal but at least dies with ^C and
suspends with ^Z as one might expect.

[Ottavio Caruso]

On 29/03/2021 09:44, jo...@schily.net wrote:
> In article <s3ndlq$btl$1...@dont-email.me>,
> Ottavio Caruso <ottavio2006...@yahoo.com> wrote:
>> On 27/03/2021 12:23, Christian Weisgerber wrote:
>>> On 2021-03-27, Ottavio Caruso <ottavio2006...@yahoo.com> wrote:
>>>
>>>> Since moving from Debian Stretch to Debian Buster (home partition is the
>>>> same, so all dot files are unchanged), and consequently from bash v4 to
>>>> bash v5, I can't manage to "sigkill" this program from the terminal;
>>>
>>> I'd start with "stty -a" to check the values of the intr, quit, susp
>>> characters.
>>>
>>
>> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
>> eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt
>> = ^R;
>
> This is not sufficient. What is the state of "isig"?
>

It seems enabled:

$ stty -a
speed 38400 baud; rows 24; columns 80; line = 0;

intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt
= ^R;

werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
-ixoff
-iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0
vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc

--
Ottavio Caruso