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
Created attachment 22148 [details] The suggested patch to vimtutor
Thanks, fixed in 5.8-5