Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!mips!mips!sdd.hp.com!wupost!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!yuma!barnesdo
From: barnesdo@CS.ColoState.EDU (douglas barnes)
Newsgroups: comp.unix.bsd
Subject: Re: Help! 386bsd vi has some problems
Message-ID: <Aug12.064950.23207@yuma.ACNS.ColoState.EDU>
Date: 12 Aug 92 06:49:50 GMT
References: <BsqwqC.22D@obiwan.uucp> <BsuKru.DF1@obiwan.uucp>
Sender: news@yuma.ACNS.ColoState.EDU (News Account)
Organization: Colorado State University, Computer Science Department
Lines: 60
[This machine does not appear to believe in obiwan.uucp, or I would have
taken this nit offline]
In article <BsuKru.DF1@obiwan.uucp> you write:
>Well, since I believe I have overcome (fixed?) the problems I was having
>with vi I thought I might as well followup my own posting.
>
>In article <BsqwqC.22D@obiwan.uucp> bob@obiwan.uucp (Me) writes:
>>The vi from the binary distribution of 386bsd 0.1 seems to have some
>>operational problems. First, when I yank some lines into a named buffer
>>then change to a different file and try to paste from the named buffer
>>I get an error message "Error reading back from tmp file for pasting!"
>>and unreliable results (sometimes the paste seems to work, sometimes
>>partially, sometimes not at all). Seems to be okay if I don't switch
>>files. Looks like some kind of mishandling of the tmp file across
>>the switch.
>
>This was the result of three lines near the end of the tmpabort() function
>(in tmp.c) that unconditionally closed and unlinked the temp file.
>These three lines were not present in the distribution of elvis 1.5
>that I had gotten back in April (from prep.ai.mit.edu, I believe).
>Deleting these lines seemed to have fixed this problem. A patch is
>included below.
>
[...]
>
>*** /tmp/,RCSt1000970 Tue Aug 11 19:40:58 1992
>--- tmp.c Tue Aug 11 19:10:13 1992
>***************
>*** 594,602 ****
> blkinit();
> nlines = 0;
> initflags();
>- close(tmpfd);
>- tmpfd = -1;
I think that the above two lines are ok. It's just the unlink. If you
look in cut.c, in the vicinity of line 446, you'll see where it
opens the old tmp files to get the named buffers. Also note in
"maybezap" that if there are no named buffers in the tmpfile,
the file is unlinked, but the fd is not closed.
I'm not sure how much is gained by the close, but it's generally
good practice not to leave unreferenced fd's pointing at files that
don't exist anymore. As for the unlink -- toss it out by itself,
and everything works fine.
>- unlink(tmpname);
> return TRUE;
> }
>
>--- 594,599 ----
>--
>Bob Willcox ...!{rutgers|ames}!cs.utexas.edu!uudell!rancor!obiwan!bob
>Phone: 512 258-4224 (home)
> 512 838-3914 (work)
--
----------- -----------
douglas barnes Calgon can't take me away
barnesdo@CS.ColoState.EDU from the things I did today