rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: culliton@srg.af.mil (Tom Culliton x2278)
To: rc@hawkwind.utcs.toronto.edu
Subject: Re: trip took a wrong turn: dot -i
Date: Mon, 10 May 1993 18:56:14 -0400	[thread overview]
Message-ID: <9305101856.aa14389@ceres.srg.af.mil> (raw)

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


             reply	other threads:[~1993-05-11  1:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-05-10 22:56 Tom Culliton x2278 [this message]
  -- strict thread matches above, loose matches on Subject: below --
1993-05-12  5:37 Byron Rakitzis
1993-05-11 12:15 rsalz
1993-04-22  2:01 Paul Haahr
1993-04-21 23:55 Tom Culliton x2278
1993-04-21 23:26 Tom Culliton x2278

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9305101856.aa14389@ceres.srg.af.mil \
    --to=culliton@srg.af.mil \
    --cc=rc@hawkwind.utcs.toronto.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).