Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • 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
    Message 1 of 6 , May 8, 2008
    • 0 Attachment
      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
      -~----------~----~----~----~------~----~------~--~---
    • Dasn
      ... 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
      Message 2 of 6 , May 10, 2008
      • 0 Attachment
        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


        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Dasn
        ... Oooops, I mean intend to generate an 0 , not suppress. :) ^^^^^^^^ -- Dasn --~--~---------~--~----~------------~-------~--~----~ You received this
        Message 3 of 6 , May 10, 2008
        • 0 Attachment
          On 11/05/08 08:32 +0800, Dasn wrote:
          >
          > 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.
          >

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


          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Gary Johnson
          On 2008-05-08, Gary Johnson wrote: [...] ... Bram, What s the status of this proposal? Is the official patch coming or do you have
          Message 4 of 6 , Jun 3, 2008
          • 0 Attachment
            On 2008-05-08, Gary Johnson <garyjohn@...> wrote:

            [...]

            > 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;
            >

            Bram,

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

            Regards,
            Gary


            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Bram Moolenaar
            ... 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
            Message 5 of 6 , Jun 3, 2008
            • 0 Attachment
              Gary Johnson wrote:

              > On 2008-05-08, Gary Johnson <garyjohn@...> wrote:
              >
              > [...]
              >
              > > 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;
              > >
              >
              > Bram,
              >
              > What's the status of this proposal? Is the official patch coming or
              > do you have reservations?

              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 -- Bram@... -- 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 ///

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • 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
              Message 6 of 6 , Jun 3, 2008
              • 0 Attachment
                On 2008-06-03, Bram Moolenaar <Bram@...> wrote:
                > Gary Johnson wrote:
                >
                > > On 2008-05-08, Gary Johnson <garyjohn@...> wrote:
                > >
                > > [...]
                > >
                > > > 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;
                > > >
                > >
                > > Bram,
                > >
                > > What's the status of this proposal? Is the official patch coming or
                > > do you have reservations?
                >
                > 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.

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

                Regards,
                Gary


                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_dev" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              Your message has been successfully submitted and would be delivered to recipients shortly.