From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2810>; Mon, 10 May 1993 21:30:30 -0400
Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA24846; Mon, 10 May 93 21:29:45 -0400
Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 211403.11226; Mon, 10 May 1993 21:14:03 EDT
Received: from ceres.srg.af.mil by srg.srg.af.mil
	id aa02106; Mon, 10 May 93 20:56:54 EDT
From:	culliton@srg.af.mil (Tom Culliton x2278)
X-Mailer: SCO System V Mail (version 3.2)
To:	rc@hawkwind.utcs.toronto.edu
Subject: Re: trip took a wrong turn: dot -i
Date:	Mon, 10 May 1993 18:56:14 -0400
Message-Id: <9305101856.aa14389@ceres.srg.af.mil>

First I encountered this problem with -i when I fixed trip.rc.

> For example on my system feeding the following script to rc makes it
> stop and wait for user commands but doesn't ever print the prompt!
> 
> ------------------------------------------------------------------------------
> #! /bin/rc
> echo 'This is test of ". -i"'
> echo 'First we set the prompt to something we''ll recognize'
> prompt=(PROMPT1 PROMPT2)
> echo 'we now try to go interactive'
> . -i /dev/tty
> echo 'end of interaction'
> ------------------------------------------------------------------------------

Then I narrowed it down to being readline related.

> My earlier message didn't mention that I'm using GNU readline with rc. 
> From looking at the code it seems like a bug in the section of input.c
> around line 118 which is conditionally included for READLINE.  If my
> brain was working better (or when it is) I might have a go at fixing
> it.

Now I understand exactly what is happening but can't decide what the
"right way" to fix it is.  Maybe Byron or Chet can make a suggestion.

Without READLINE defined there is some code in input.c and lex.c that
print the appropriate prompts if the global variable interactive is
TRUE.  With READLINE defined, they simply set the variable prompt which
gets passed to the readline function.  So far, so good.  However, if the
fd beig read is not stdin, readline is not called, and as a result no
prompt gets printed.  Blech!

I see two possible solutions. 

1) If we're not going to call readline, print the prompts, either where
they would be printed "normally" or in the code surrounding the readline
call.  This is simple but inconsistent.

2) Tell readline to use the appropriate fd by setting rl_instream or
some other means.  Unfortunately readline seems to want to deal in FILE
*'s rather than fd's, so a fdopen() might be required to get one, which
seems pretty silly because readline always does a fileno() on them!

Chet: Is there a better way to twist readline's tail?  Byron: Care to
state a preference?  I'll post a patch as soon as the choice becomes
clear.

Tom