If your .vimrc does a "cd", any files on the command line aren't found

[GoogleCodeExporter]

What steps will reproduce the problem?

echo "cd /tmp" >> ~/.vimrc
echo "foo" > /tmp/foo.txt
cd ~ # or not /tmp
echo "bar" > bar.txt
mvim bar.txt # Opens new file called /tmp/bar.txt
mvim foo.txt # Opens /tmp/foo.txt even though you are in ~

What is the expected output? What do you see instead?

regular vim and the old carbon gvim expand command line arguments BEFORE 
sourcing any of 
the .rc files, so your rc file can cd wherever you want and it'll still know 
what files to o pen

What version of MacVim and OS X are you using (see "MacVim->About MacVim" and  
"Apple 
Menu->About This Mac" menu items, e.g. "Snapshot 40, 10.5.6 Intel")?

Latest release version I downloaded today.

VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Aug 21 2008 12:51:59)
MacOS X (unix) version
Compiled by Bjorn Winckler <bjorn.winckler@gmail.com>
Huge version with MacVim GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval +browse ++builtin_terms +byte_offset +cindent 
+clientserver 
+clipboard +cmdline_compl
+cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape 
+dialog_con_gui +diff 
+digraphs +dnd -ebcdic +emacs_tags +eval
 +ex_extra +extra_search +farsi +file_in_path +find_in_path +float +folding -footer +fork() 
+fullscreen -gettext -hangul_input
+iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak 
+lispindent +listcmds 
+localmap +menu +mksession
+modify_fname +mouse +mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm 
+mouse_netterm -mouse_sysmouse +mouse_xterm +multi_byte
+multi_lang -mzscheme -netbeans_intg +odbeditor -osfiletype +path_extra -perl 
+postscript 
+printer +profile +python +quickfix
+reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff +statusline 
-sun_workshop 
+syntax +tag_binary +tag_old_static
-tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar 
+transparency 
+user_commands +vertsplit +virtualedit
+visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows 
+writebackup -X11 
-xfontset -xim -xsmp -xterm_clipboard
-xterm_save
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/Applications/Vim.app/Contents/Resources/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall 
-Wno-unknown-
pragmas -pipe -I. -Iproto -DMACOS_X_UNIX -no-
cpp-precomp -I/Developer/SDKs/MacOSX10.4u.sdk/Developer/Headers/FlatCarbon  -g 
-O -
isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch
i386 -arch ppc     -
I/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Python.framework/Vers
ions/2
.3/include/python2.3  -I
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universa
l-
darwin9.0
Linking: gcc   -L. -arch ppc -arch i386  -L/usr/local/lib -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -o Vim -f
ramework Cocoa -framework Carbon      -lncurses  -liconv    -framework Python  
-lruby -lm

Original issue reported on code.google.com by davetron...@gmail.com on 6 May 2009 at 5:52

[GoogleCodeExporter]

Also, if you  did 

mvim *.txt

in my above example, the correct file would be opened

I realize that the shell does the expansion, but this seems kindof weird to em

Original comment by davetron...@gmail.com on 6 May 2009 at 5:55

[GoogleCodeExporter]

This problem seems to only appear in the stable build.  I tried it with the 
latest snapshot first and could not 
recreate the problem there.

Please download the snapshot build and use that instead.  In the meantime I'll 
try to figure out what is causing 
this in the stable build but this is very low priority I'm afraid.

Original comment by bjorn.winckler@gmail.com on 11 May 2009 at 4:40

[GoogleCodeExporter]

Ok, I figured out why there is a problem in the stable build but not the 
snapshot.  The forking code changed 
so that forking happens right after scanning the command line arguments in the 
snapshot build whereas in 
the stable build it will read the vimrc files before forking.  Thus it reads 
the vimrc file, changes directory as a 
result, then forks.

I will not fix this in the stable build (it is not a critical bug) so if you 
really need to have "cd" in your vimrc you 
will have to use the snapshot instead (and I don't see any reason why you 
wouldn't want to that...it is not 
unstable).  Alternatively, you can tell Vim not to fork by passing the "-f" 
flag to "mvim" -- that also takes care 
of the problem.

Original comment by bjorn.winckler@gmail.com on 11 May 2009 at 4:49

• Changed state: WontFix

[GoogleCodeExporter]

I agree this is not critical; I've worked around it by moving my 'cd' command 
around.  I can wait for the next 
stable build.  Thanks!

Original comment by davetron...@gmail.com on 11 May 2009 at 4:55

[GoogleCodeExporter]

For what it's worth I was running into this problem in gVim today on Windows (a 
Google search yielded this thread) and my workaround is worth presenting here 
so that others may find it...

In my .vimrc:

if argc() == 0
   cd wherever
endif

That way it won't do the cd if there are command line arguments.  I'm not sure 
if this meets your requirements or not, but it met mine since I only wanted the 
cd to happen when I was opening gVim without any args.

Original comment by tom.plun...@gmail.com on 11 Sep 2010 at 1:51