This is the continuation of a discussion in the "Efficient Vim
editing? Hitting a wall." thread of the vim_use list. I'm
continuing it here because it is now a developer issue.
Background:
I'm using vim 7.1.297 and netrw v125k on SunOS 5.8. I have some
directories, such as ~/.mozilla/firefox/o5jp3xlr.default/extensions,
that contain directories whose names begin with '{' and end with
'}', e.g.,
{21350f60-90a5-11da-a72b-0800208c9a68}
When I edit the parent directory, move the cursor to a {...}
directory, and hit Enter, the directory listing shows only
../
and a blank line.
Using Cygwin or Linux, the same version of vim and the same version
of netrw display the directory contents correctly.
Using SunOS, the directory will display correctly if I change SHELL
to /usr/bin/zsh before starting vim. It does not work correctly if
SHELL is /usr/bin/sh, /usr/bin/ksh, or /usr/bin/csh.
Wildcard Expansion:
Netrw uses the glob() function to find the contents of a directory
by expanding the name of the directory appended with "/*". The
glob() function in turn uses the shell to perform wildcard
expansion. The function mch_expand_wildcards() in os_unix.c, looks
at the value of SHELL (i.e., the 'shell' option), and if the shell
ends with "sh" but is not "csh" or "zsh", the function uses the
sh_vimglob_func to expand any filename patterns having wildcards.
The value of sh_vimglob_func is initially
vimglob() { while [ $# -ge 1 ]; do echo -n "$1"; echo; shift; done };
vimglob >
To this is appended a temporary file name and the filename pattern
to be expanded. The result is assigned to argv[2] and given to the
shell to be executed by a call to execvp() with argv[0] set to the
shell and argv[1] set to "-c".
The Problem:
The basic problem is that "echo -n" is not portable. This is
mentioned in the echo(1) man page on SunOS and has been discussed
numerous times on comp.unix.shell. In particular, the echo commands
in sh and ksh on HP-UX and Solaris do not have a -n option.
Consequently, the sh_vimglob_func fails on those shells and systems.
The Proposed Solution:
I don't know the history or rationale behind the current
implementation of sh_vimglob_func, but it seems odd that the first
echo is given the -n option to suppress the final newline, then a
second echo is used to create a newline in the same place. The
solution, therefore, seems to be to eliminate the -n option to the
first echo command and eliminate the second echo command completely.
The resulting initial value of sh_vimglob_func is
vimglob() { while [ $# -ge 1 ]; do echo "$1"; shift; done }; vimglob >
This fixes the problem on SunOS with sh and ksh and would seem to
improve portability. It does not fix the problem on SunOS with csh,
but I think that problem has a different cause.
I have made this change to vim 7.1.297 on Cygwin, Linux and SunOS
and have so far not observed any adverse effects. The patch is
included below.
Regards,
Gary
-------------------------- os_unix.c.diff --------------------------
*** os_unix.c.orig Wed May 7 17:17:29 2008
--- os_unix.c Thu May 8 14:15:01 2008
***************
*** 5152,5158 ****
static int did_find_nul = FALSE;
int ampersent = FALSE;
/* vimglob() function to define for Posix shell */
! static char *sh_vimglob_func = "vimglob() { while [ $# -ge 1 ]; do echo
-n \"$1\"; echo; shift; done }; vimglob >";
*num_file = 0; /* default: no files found */
*file = NULL;
--- 5152,5158 ----
static int did_find_nul = FALSE;
int ampersent = FALSE;
/* vimglob() function to define for Posix shell */
! static char *sh_vimglob_func = "vimglob() { while [ $# -ge 1 ]; do echo
\"$1\"; shift; done }; vimglob >";
*num_file = 0; /* default: no files found */
*file = NULL;
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
