Re: BUG: vared in function

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

On May 31, 11:28pm, Peter Stephenson wrote:
> Subject: Re: BUG: vared in function
> Peter Stephenson wrote:
> > Bernd Eggink wrote:
> > > Argh... 
> > > 
> > >    # t
> > >    vared -cp "Aha: " BLAH
> > > 
> > >    % t
> > >    t:vared:2: ZLE not enabled
> > > 
> > > This breaks lots of my scripts! 

This is happening because of my bug report to the effect that vared was
improperly munging the TTY settings in an interactive shell that had ZLE
explicitly turned off (as e.g. inside and emacs shell buffer).

I don't know how that interacts with Peter's patch (I'll try it later when
I get home).

> I'm in two minds on whether to commit this.  On the one hand, there is more
> of a potential for problems with read or vared.  On the other hand, without
> it it introduces a new problem just for one version.

I think there's a bug here:

> +    /* We should have a SHTTY opened by now. */
> +    if (SHTTY == -1) {
> +	/* Unfortunately, we didn't. */
> +	fprintf(stderr, "not interactive and can't open terminal\n");
> +	fflush(stderr);
> +	return 1;
> +    }

That `return 1;' is supposed to be an abort of (what is now) the *caller*
of openttyspecially().  As you have it, that's going to make the caller
think that opening the tty succeeded.  If you're going to pull this stuff
out into a function, you need three return states, not two.