mch_expand_wildcards() fails with Solaris /usr/bin/ksh

[Gary Johnson]

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;

[Dasn]

On 08/05/08 17:40 -0700, Gary Johnson wrote:
>
> 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 >
>

I think you are right. Originally, the second 'echo' was intend to
suppress an '\0' at the end of each matched items for working on many
kinds of POSIX shells. As the record is now considered NL separated, the
additional echo is not necessary.

I tested your version of vimglob() on OBSD with ksh, fine.

--
Dasn

[Dasn]

Oooops, I mean "intend to generate an '\0'", not suppress. :)
^^^^^^^^
--
Dasn

[Gary Johnson]

On 2008-05-08, Gary Johnson <gary...@spk.agilent.com> wrote:

[...]

Bram,

What's the status of this proposal? Is the official patch coming or
do you have reservations?

Regards,
Gary

[Bram Moolenaar]

Gary Johnson wrote:

It's in the todo list. We have had problems in this area before, so I
need to look into it. It does make a lot of sense.

--
Engineers will go without food and hygiene for days to solve a problem.
(Other times just because they forgot.)
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Gary Johnson]

Thanks very much. I understand your caution. I just wanted to be
sure that it hadn't fallen through the cracks.

Regards,
Gary