Re: Trapping SIGINT?

[Stepan Kasal]

Hello Gary,

On Fri, Apr 14, 2006 at 05:02:43PM +0100, Gary V. Vaughan wrote:
> 102 -b, --batch                  buffer output, process interrupts\n\
> 103 -e, --interactive            unbuffer output, ignore interrupts\n\
> ...
> 242     if (isatty (STDIN_FILENO))
> 243       m4_set_interactive_opt (context, true);
> ...
> 335         case 'b':
> 336           m4_set_interactive_opt (context, false);
> 337           break;
> ...
> 352         case 'e':
> 353           m4_set_interactive_opt (context, true);
> 354           break;

thank you for your help.

> It appears that STDIN_FILENO will indeed be a tty, and that interrupts
> will be ignored.  There are a couple of solutions:
> 
>    i) add a </dev/null to the invocation

... this is what autom4te does now; it means that
        echo m4_PACKAGE_STRING | autom4te
doesn't work.

>   ii) add a -b flag to the options

This is what we can do, and the problem will be fixed.

>  iii) maybe, 242 should be:
>         if (isatty (STDIN_FILENO) && isatty (STDOUT_FILENO))'?

This still would not be enough for autom4te.  If it is going to make
a freezed file, if first runs m4 with output set to stdout, to make sure
that the ``macro definitions'' produce no output.

> The intention is to allow users to start an interactive m4 session, and
> be able to kill subprocesses with ^C and not accidentally drop out of m4
> back to the parent process.  I think (iii) is a reasonable approach, and
> maintains backwards compatibility with autoconf without tripping up
> interactive users...

If you run

        m4 file1 file2

it processes the input files and ends; why do you handle it as an
interactive session?
(If this were changes, then autom4te wouldn'e have to play with -b. ;-)

> 1.5 gradually become so different from m4 that it is almost a complete
> rewrite so it was redubbed 2.0 at some point along the way.

Thank you for telling me again, I'm sorry that I forgot this.

Thank you,
        Stepan