Bug 46518

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18pre21 i686; en-US; rv:0.9.1)
Gecko/20010620

Description of problem:
The vimtutor script, built from this source: vim-5.7-0.6x.src.rpm contains
a race condition that is exposed when the DISPLAY environment variable is
set (i.e, when running under X), and /usr/X11R6/bin/gvim is available.  The
race condition occurs because, by default, gvim forks itself into the
background.  The suggested fix is to add the "-f" option to the gvim
command line, i.e., apply this patch to vimtutor:

--- vimtutor.orig       Wed Jun 27 10:58:56 2001
+++ vimtutor    Wed Jun 27 10:58:04 2001
@@ -6,7 +6,7 @@

 VIM=/bin/vi
 [ -x /usr/bin/vim ] && VIM=/usr/bin/vim
-[ ! -z "$DISPLAY" -a -x /usr/X11R6/bin/gvim ] && VIM=/usr/X11R6/bin/gvim
+[ ! -z "$DISPLAY" -a -x /usr/X11R6/bin/gvim ] && VIM="/usr/X11R6/bin/gvim -f"

 TUTORCOPY=/tmp/tutor$$
 export TUTORCOPY


How reproducible:
Sometimes

Steps to Reproduce:
1. Make sure you're running under X (not on a text console), make sure
/usr/X11R6/bin/gvim is executable, and make sure the DISPLAY environment
variable is set.
2. Run the vimtutor script by typing "vimtutor"
3.
	

Actual Results:  Most of the times, gvim will start, editing a blank file
named /tmp/tutorPID (where PID is vimtutor's process ID).

Expected Results:  For gvim to be editing a copy of the tutorial, not a
blank file.

Additional info:

This bug was first found by Thomas Carlson (tandrewc.edu). 
Thomas also suggested adding "-f" option to the gvim command as a fix.  We
can reproduce it quite consistently on our school's dual-processor Pentium
II Linux machines.  The following is a portion of an email I sent to our
school's support folks regarding this problem.  


To understand the problem, look at the vimtutor script:

1    #! /bin/sh
2    #
3    # Start Vim on a copy of the tutor file.
4
5    # Use Vim to copy the tutor, it knows the value of $VIMRUNTIME
6
7    VIM=/bin/vi
8    [ -x /usr/bin/vim ] && VIM=/usr/bin/vim
9    [ ! -z "$DISPLAY" -a -x /usr/X11R6/bin/gvim ] && VIM =/X11R6/bin/gvim
10
11   TUTORCOPY=/tmp/tutor$$
12   export TUTORCOPY
13   $VIM -u NONE -c 'e $VIMRUNTIME/tutor/tutor' -c 'w! $TUTORCOPY' -c 'q'
14
15   # Start vim without any .vimrc, set 'nocompatible'
16   $VIM -u NONE -c "set nocp" $TUTORCOPY
17
18   # remove the copy of the tutor
19   rm $TUTORCOPY

It should be quite obviouos that, for proper execution, the copying of
the tutorial on line 13 _must_ complete before vim is told to edit
that copy on line 16, and that the editing session started on line 16
_must_ complete before the "rm" command on line 19 gets to run.

Unfortunately, gvim forks itself into the background by default, so
the order of execution I described in the previous paragraph is no
longer guaranteed.  The results vary, but generally the user ends up
editing a blank file, instead of a copy of the tutorial, as expected.

The solution ThomasCarlson (tandrewc.edu) has suggested is
to pass gvim a "-f" option, which will prevent gvim from forking itself
into the background, guarantee sequential execution, and restore world
peace ;-)

The one-line patch is below:

--- vimtutor.orig       Wed Jun 27 10:58:56 2001
+++ vimtutor    Wed Jun 27 10:58:04 2001
@@ -6,7 +6,7 @@

 VIM=/bin/vi
 [ -x /usr/bin/vim ] && VIM=/usr/bin/vim
-[ ! -z "$DISPLAY" -a -x /usr/X11R6/bin/gvim ] && VIM=/usr/X11R6/bin/gvim
+[ ! -z "$DISPLAY" -a -x /usr/X11R6/bin/gvim ] && VIM="/usr/X11R6/bin/gvim -f"

 TUTORCOPY=/tmp/tutor$$
 export TUTORCOPY