bgi@stbimbo.UUCP (Brad Isley) (09/28/90)
Re: The 501 pointer posted that was f2c compatible and mucho cleaned up.
I've finally managed to find the time to build this. It's on ISC 2.0.2.
The problem is, every time the user is prompted for input, there is an
extra linefeed before and after the prompt '>'. Ex:
blather blather text output.
>
_
^ - cursor. Anyone know what's happening ? I tried to wade through the
source and f2c libraries, but it looked pretty hopeless.
Thanx in advance for any clues!
--
-----------------------------\ / ..and Apple thought GUI was theirs!.. \
bgi@SalesTech.COM 841-4169 \---| Yer local zymurgist & Amiga hacker/user |
OR \ Klein bottle for sale- Inquire within /
brad@slammer.UUCP 925-9663 Brad Isley, Sales Technologies, Inc.mcdonald@aries.scs.uiuc.edu (Doug McDonald) (09/28/90)
In article <159@stbimbo.UUCP> bgi@stbimbo.UUCP (Brad Isley) writes: >Re: The 501 pointer posted that was f2c compatible and mucho cleaned up. >I've finally managed to find the time to build this. It's on ISC 2.0.2. > >The problem is, every time the user is prompted for input, there is an >extra linefeed before and after the prompt '>'. Ex: > > blather blather text output. > > > >_ >^ - cursor. Anyone know what's happening ? I tried to wade through the >source and f2c libraries, but it looked pretty hopeless. > Yes. (I wrote it). The first linefeed is there because I thought it looked good. The code is in the text output routine - I think. Maybe. You are on you own here. It is not considered a bug. The second is there because there is no way in legal Fortran to do otherwise!!!! However, f2c will allow it. Get into the correct subroutine (it IS documented, you know, right there in the docs!!) and enable the code that puts a $ (dollar sign) format descriptor in the read statement that outputs the >. This occurs in two places. Doug McDonald
mjd@saul.cis.upenn.edu (Mark-Jason Dominus) (10/02/90)
I just hacked into the C source and fixed the prompt to be the thing I wanted. That's ugly, but it works OK. -- In some sense a stochastic process can do better; at least it has a chance. Mark-Jason Dominus mjd@central.cis.upenn.edu