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

Where is my system-wide init file?

Expand Messages
  • egarrulo
    On my Linux distro there are these system-wide initialization files: /etc/vim/gvimrc /etc/vim/vimrc /etc/vim/vimrc.tiny /usr/share/vim/gvimrc
    Message 1 of 11 , Dec 29, 2013
    • 0 Attachment
      On my Linux distro there are these system-wide initialization files:

      /etc/vim/gvimrc
      /etc/vim/vimrc
      /etc/vim/vimrc.tiny
      /usr/share/vim/gvimrc
      /usr/share/vim/vimrc
      /usr/share/vim/vimrc.tiny

      Does GVim load any of them?

      :echo $MYVIMRC

      returns ~/.vimrc, while

      :version

      returns

      system vimrc file: "$VIM/vimrc"
      user vimrc file: "$HOME/.vimrc"
      2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
      system gvimrc file: "$VIM/gvimrc"
      user gvimrc file: "$HOME/.gvimrc"
      2nd user gvimrc file: "~/.vim/gvimrc"
      system menu file: "$VIMRUNTIME/menu.vim"
      fall-back for $VIM: "/home/egarrulo/bin/vim/vim-7.4.280/share/vim"

      and

      :echo $VIM

      returns:

      /home/egarrulo/bin/vim/vim-7.4.280/share/vim

      and no .vimrc is there. Thus, GVim shouldn't be loading any of the
      above system-wide init files, but it seems it does.

      Any idea? Thanks.

      --
      --
      You received this message from the "vim_use" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_use" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Tony Mechelynck
      ... 1. Try ls -l on some of these files (in subfolders of /etc and of /usr/share) to see if any of them is a soft link. (Seeing if it s a hard link is less
      Message 2 of 11 , Dec 29, 2013
      • 0 Attachment
        On 29/12/13 11:48, egarrulo wrote:
        > On my Linux distro there are these system-wide initialization files:
        >
        > /etc/vim/gvimrc
        > /etc/vim/vimrc
        > /etc/vim/vimrc.tiny
        > /usr/share/vim/gvimrc
        > /usr/share/vim/vimrc
        > /usr/share/vim/vimrc.tiny
        >
        > Does GVim load any of them?
        >
        > :echo $MYVIMRC
        >
        > returns ~/.vimrc, while
        >
        > :version
        >
        > returns
        >
        > system vimrc file: "$VIM/vimrc"
        > user vimrc file: "$HOME/.vimrc"
        > 2nd user vimrc file: "~/.vim/vimrc"
        > user exrc file: "$HOME/.exrc"
        > system gvimrc file: "$VIM/gvimrc"
        > user gvimrc file: "$HOME/.gvimrc"
        > 2nd user gvimrc file: "~/.vim/gvimrc"
        > system menu file: "$VIMRUNTIME/menu.vim"
        > fall-back for $VIM: "/home/egarrulo/bin/vim/vim-7.4.280/share/vim"
        >
        > and
        >
        > :echo $VIM
        >
        > returns:
        >
        > /home/egarrulo/bin/vim/vim-7.4.280/share/vim
        >
        > and no .vimrc is there. Thus, GVim shouldn't be loading any of the
        > above system-wide init files, but it seems it does.
        >
        > Any idea? Thanks.
        >

        1. Try "ls -l" on some of these files (in subfolders of /etc and of
        /usr/share) to see if any of them is a soft link. (Seeing if it's a hard
        link is less obvious). Or maybe /home/egarrulo or
        /home/egarrulo/bin/vim/vim-7.4.280/share are soft links?

        2. Maybe there is another Vim (later in the $PATH) on your system? What
        does the bash commands

        type -a vim
        type -a gvim

        return? (I'm saying bash because in bash "type" is a builtin command,
        which reports even about aliases; I don't know how to get the same
        results with other shells.)

        Here too, apply "ls -l" to any answer until you've resolved all
        softlinks there might be (for instance, gvim may be a link to vim).


        The system-wide vimrc for that copy of Vim, sourced before the user's
        vimrc, is $VIM/vimrc — with whatever $VIM may be when that user runs
        Vim. You seem to find that $VIM is $HOME/vim/vim-7.4.280/share/vim, for
        another user it would probably not be a subfolder of _your_ $HOME.

        Also, I wonder why you have a "vim-7.4.280" link in that path. Do you
        change that at every patchlevel? Also, where did you get that "280"
        from? The current patchlevel is only 7.4.131.

        For the Vim that I compile for my home computer, I use Vim's defaults,
        namely:

        $VIM = /usr/local/share/vim
        $VIMRUNTIME = $VIM/vim74 (at version 7.4)
        The (Huge) vim executable is in /usr/local/bin
        The gvim executable is a soft link
        /usr/local/share/bin/gvim -> ./vim
        In addition I have a Tiny vim executable at /usr/local/bin/vi

        This way, my custom runtime files (not from the Vim distribution) at
        /usr/local/share/vim/vimfiles/ (system-wide) and, of course, at
        $HOME/.vim/ (single-user) will remain even after the release of Vim 7.5
        or 8.0.

        Best regards,
        Tony.
        --
        WHERE CAN THE MATTER BE
        Oh, dear, where can the matter be
        When it's converted to energy?
        There is a slight loss of parity.
        Johnny's so long at the fair.

        --
        --
        You received this message from the "vim_use" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_use" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Elena Garrulo
        Tony, thank you for your detailed answer. By following your advice, I have tracked down where Vim looks for its system-wide init file. It is either in
        Message 3 of 11 , Dec 29, 2013
        • 0 Attachment
          Tony, thank you for your detailed answer. By following your advice, I
          have tracked down where Vim looks for its system-wide init file. It
          is either in /etc/vim/ or in /usr/share/vim/, but I still don't
          understand why Vim looks there, considering that no Vim-related
          environment variable points there.

          Also, could it be that I'm experiencing frequent GVim crashes because
          my installation is not configured properly? There are no environment
          variable that are related to Vim. Should I create any?

          I'm answering your probing questions in case there are other things
          that I'm missing.

          On Sunday, December 29, 2013 12:43:43 PM UTC+1,
          Tony Mechelynck wrote: > 1. Try "ls -l" on some of these files (in
          subfolders of /etc and of > > /usr/share) to see if any of them is a
          soft link. (Seeing if it's a hard > > link is less obvious). Or maybe
          /home/egarrulo or > > /home/egarrulo/bin/vim/vim-7.4.280/share are
          soft links?

          Yes, the init files in /usr/share link to the same files in /etc.

          /home/egarrulo/bin/vim/vim-7.4.280 is the folder where I have
          installed Vim, after building it with:

          ./configure --prefix=/home/egarrulo/bin/vim/vim-7.4.280

          I did so to avoid clashing with the Vim version that comes with my
          distro.

          > 2. Maybe there is another Vim (later in the $PATH) on your system?

          Yes, there is: /usr/bin/vim. It is the build that comes with my distro.

          Thank you for making me learn the "type" command. Cool! :-)

          > The system-wide vimrc for that copy of Vim, sourced before the user's
          >
          > vimrc, is $VIM/vimrc — with whatever $VIM may be when that user runs
          >
          > Vim.

          $VIM is empty.


          > You seem to find that $VIM is $HOME/vim/vim-7.4.280/share/vim, for
          >
          > another user it would probably not be a subfolder of _your_ $HOME.
          >
          >
          >

          > Also, I wonder why you have a "vim-7.4.280" link in that path. Do you
          >
          > change that at every patchlevel? Also, where did you get that "280"
          >
          > from? The current patchlevel is only 7.4.131.

          Indeed, at startup, Vim says it is version 7.4.131.

          I didn't know about the patchlevel when I compiled Vim. I got the
          version from the "version.h" file:

          #define VIM_VERSION_MAJOR 7
          #define VIM_VERSION_MINOR 4
          #define VIM_VERSION_BUILD 280

          >
          >
          >
          > For the Vim that I compile for my home computer, I use Vim's defaults,
          >
          > namely:
          >
          >
          >
          > $VIM = /usr/local/share/vim
          >
          > $VIMRUNTIME = $VIM/vim74 (at version 7.4)

          I did the same. I only used the "--prefix" option with "./configure".

          --
          --
          You received this message from the "vim_use" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_use" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Gary Johnson
          ... To find that out, execute ... System vimrc files do not begin with a period, so you will not find a .vimrc among them. Only user vimrc files begin with
          Message 4 of 11 , Dec 29, 2013
          • 0 Attachment
            On 2013-12-29, egarrulo wrote:
            > On my Linux distro there are these system-wide initialization files:
            >
            > /etc/vim/gvimrc
            > /etc/vim/vimrc
            > /etc/vim/vimrc.tiny
            > /usr/share/vim/gvimrc
            > /usr/share/vim/vimrc
            > /usr/share/vim/vimrc.tiny
            >
            > Does GVim load any of them?

            To find that out, execute

            :scriptnames

            >
            > :echo $MYVIMRC
            >
            > returns ~/.vimrc, while
            >
            > :version
            >
            > returns
            >
            > system vimrc file: "$VIM/vimrc"
            > user vimrc file: "$HOME/.vimrc"
            > 2nd user vimrc file: "~/.vim/vimrc"
            > user exrc file: "$HOME/.exrc"
            > system gvimrc file: "$VIM/gvimrc"
            > user gvimrc file: "$HOME/.gvimrc"
            > 2nd user gvimrc file: "~/.vim/gvimrc"
            > system menu file: "$VIMRUNTIME/menu.vim"
            > fall-back for $VIM: "/home/egarrulo/bin/vim/vim-7.4.280/share/vim"
            >
            > and
            >
            > :echo $VIM
            >
            > returns:
            >
            > /home/egarrulo/bin/vim/vim-7.4.280/share/vim
            >
            > and no .vimrc is there. Thus, GVim shouldn't be loading any of the
            > above system-wide init files, but it seems it does.

            System vimrc files do not begin with a period, so you will not find
            a ".vimrc" among them. Only user vimrc files begin with a period,
            and even that is not always the case, as on Windows where the name
            is _vimrc and in newer Vim's where ~/.vim/vimrc is also valid.

            See

            :help startup

            for more.

            Regards,
            Gary

            --
            --
            You received this message from the "vim_use" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_use" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Elena Garrulo
            ... And the first line of the output reads: /usr/share/vim/vimrc That s what I was looking for. Thanks. ... Thanks for the clarification. -- -- You received
            Message 5 of 11 , Dec 29, 2013
            • 0 Attachment
              On Sunday, December 29, 2013 10:49:21 PM UTC+1, Gary Johnson wrote:
              > To find that out, execute
              >
              >
              >
              > :scriptnames

              And the first line of the output reads:

              /usr/share/vim/vimrc

              That's what I was looking for. Thanks.

              > System vimrc files do not begin with a period, so you will not find
              >
              > a ".vimrc" among them. Only user vimrc files begin with a period,
              >
              > and even that is not always the case, as on Windows where the name
              >
              > is _vimrc and in newer Vim's where ~/.vim/vimrc is also valid.

              Thanks for the clarification.

              --
              --
              You received this message from the "vim_use" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_use" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Tony Mechelynck
              ... Well, without any --prefix=, vim would have been built so as to install into subdirectories of /usr/local/ (as is does on my system: the executable as
              Message 6 of 11 , Dec 29, 2013
              • 0 Attachment
                On 29/12/13 21:15, Elena Garrulo wrote:
                > Tony, thank you for your detailed answer. By following your advice, I
                > have tracked down where Vim looks for its system-wide init file. It
                > is either in /etc/vim/ or in /usr/share/vim/, but I still don't
                > understand why Vim looks there, considering that no Vim-related
                > environment variable points there.
                >
                > Also, could it be that I'm experiencing frequent GVim crashes because
                > my installation is not configured properly? There are no environment
                > variable that are related to Vim. Should I create any?
                >
                > I'm answering your probing questions in case there are other things
                > that I'm missing.
                >
                > On Sunday, December 29, 2013 12:43:43 PM UTC+1,
                > Tony Mechelynck wrote: > 1. Try "ls -l" on some of these files (in
                > subfolders of /etc and of > > /usr/share) to see if any of them is a
                > soft link. (Seeing if it's a hard > > link is less obvious). Or maybe
                > /home/egarrulo or > > /home/egarrulo/bin/vim/vim-7.4.280/share are
                > soft links?
                >
                > Yes, the init files in /usr/share link to the same files in /etc.
                >
                > /home/egarrulo/bin/vim/vim-7.4.280 is the folder where I have
                > installed Vim, after building it with:
                >
                > ./configure --prefix=/home/egarrulo/bin/vim/vim-7.4.280
                >
                > I did so to avoid clashing with the Vim version that comes with my
                > distro.

                Well, without any --prefix=, vim would have been built so as to install
                into subdirectories of /usr/local/ (as is does on my system: the
                executable as /usr/local/bin/vim, the runtime files in
                /usr/local/share/vim/vim74/, and looking for your $VIM at
                /usr/local/share/vim/) and that wouldn't have overwritten your distro's
                Vim either. It would also, with no further ado, have put the newly
                compiled version before your distro's in the $PATH (since /usr/local/bin
                comes before /usr/bin) so invoking "vim" with no path at the shell
                prompt would have got your Vim and not the distro's.

                That location is "visible" to everyone but you may need to run "make
                install" from a root login (after login to root or su root). "make
                config" and "make" can still be run from any desired login.

                >
                >> 2. Maybe there is another Vim (later in the $PATH) on your system?
                >
                > Yes, there is: /usr/bin/vim. It is the build that comes with my distro.
                >
                > Thank you for making me learn the "type" command. Cool! :-)

                There is also "which" which is a separate program (and thus works for
                all shells) but it doesn't know about shell aliases.

                >
                >> The system-wide vimrc for that copy of Vim, sourced before the user's
                >>
                >> vimrc, is $VIM/vimrc — with whatever $VIM may be when that user runs
                >>
                >> Vim.
                >
                > $VIM is empty.
                >
                >
                >> You seem to find that $VIM is $HOME/vim/vim-7.4.280/share/vim, for
                >>
                >> another user it would probably not be a subfolder of _your_ $HOME.
                >>
                >>
                >>
                >
                >> Also, I wonder why you have a "vim-7.4.280" link in that path. Do you
                >>
                >> change that at every patchlevel? Also, where did you get that "280"
                >>
                >> from? The current patchlevel is only 7.4.131.
                >
                > Indeed, at startup, Vim says it is version 7.4.131.
                >
                > I didn't know about the patchlevel when I compiled Vim. I got the
                > version from the "version.h" file:
                >
                > #define VIM_VERSION_MAJOR 7
                > #define VIM_VERSION_MINOR 4
                > #define VIM_VERSION_BUILD 280

                I wonder what that VIM_VERSION_BUILD means.

                >
                >>
                >>
                >>
                >> For the Vim that I compile for my home computer, I use Vim's defaults,
                >>
                >> namely:
                >>
                >>
                >>
                >> $VIM = /usr/local/share/vim
                >>
                >> $VIMRUNTIME = $VIM/vim74 (at version 7.4)
                >
                > I did the same. I only used the "--prefix" option with "./configure".
                >

                Well, that is where you overrode Vim's defaults. As I said above, it was
                not necessary.


                Best regards,
                Tony.
                --
                You will be the victim of a bizarre joke.

                --
                --
                You received this message from the "vim_use" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_use" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Gary Johnson
                ... The which(1) v2.20 man page recommends using a shell function wrapper around which that finds aliases and functions as well. Regards, Gary -- -- You
                Message 7 of 11 , Dec 30, 2013
                • 0 Attachment
                  On 2013-12-30, Tony Mechelynck wrote:
                  > On 29/12/13 21:15, Elena Garrulo wrote:

                  > >Thank you for making me learn the "type" command. Cool! :-)
                  >
                  > There is also "which" which is a separate program (and thus works for
                  > all shells) but it doesn't know about shell aliases.

                  The which(1) v2.20 man page recommends using a shell function
                  wrapper around which that finds aliases and functions as well.

                  Regards,
                  Gary

                  --
                  --
                  You received this message from the "vim_use" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_use" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Erik Christiansen
                  ... Remarkable how much good sense can be found in manpages. For the last quarter century or more, I ve had (on every machine I touch¹): $ grep which .bashrc
                  Message 8 of 11 , Dec 31, 2013
                  • 0 Attachment
                    On 30.12.13 08:32, Gary Johnson wrote:
                    > On 2013-12-30, Tony Mechelynck wrote:
                    > > On 29/12/13 21:15, Elena Garrulo wrote:
                    >
                    > > >Thank you for making me learn the "type" command. Cool! :-)
                    > >
                    > > There is also "which" which is a separate program (and thus works for
                    > > all shells) but it doesn't know about shell aliases.
                    >
                    > The which(1) v2.20 man page recommends using a shell function
                    > wrapper around which that finds aliases and functions as well.

                    Remarkable how much good sense can be found in manpages. For the last
                    quarter century or more, I've had (on every machine I touch¹):

                    $ grep which .bashrc
                    alias which='type -a' # Checks aliases & functions also.

                    (Never could understand why I should ask the shell to type thingy,
                    then expect it to answer with which thingy it'd use, instead.)

                    Alas, the 2009 Debian manpage in my Ubuntu distro lacks the wisdom
                    you've found.

                    Erik

                    ¹ First HP-UX, then Solaris, now linux - all had "type" AFAIR.

                    --
                    Leibowitz's Rule:
                    When hammering a nail, you will never hit your finger if you hold the
                    hammer with both hands.

                    --
                    --
                    You received this message from the "vim_use" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_use" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Tony Mechelynck
                    ... The problem with this alias, IIUC, is when one tries to use vim `which somecommand` to edit an executable script, since the output of type is in a
                    Message 9 of 11 , Dec 31, 2013
                    • 0 Attachment
                      On 31/12/13 09:34, Erik Christiansen wrote:
                      > On 30.12.13 08:32, Gary Johnson wrote:
                      >> On 2013-12-30, Tony Mechelynck wrote:
                      >>> On 29/12/13 21:15, Elena Garrulo wrote:
                      >>
                      >>>> Thank you for making me learn the "type" command. Cool! :-)
                      >>>
                      >>> There is also "which" which is a separate program (and thus works for
                      >>> all shells) but it doesn't know about shell aliases.
                      >>
                      >> The which(1) v2.20 man page recommends using a shell function
                      >> wrapper around which that finds aliases and functions as well.
                      >
                      > Remarkable how much good sense can be found in manpages. For the last
                      > quarter century or more, I've had (on every machine I touch¹):
                      >
                      > $ grep which .bashrc
                      > alias which='type -a' # Checks aliases & functions also.

                      The problem with this alias, IIUC, is when one tries to use

                      vim `which somecommand`

                      to edit an executable script, since the output of "type" is in a
                      different format. I suppose you would have to do

                      vim `/usr/bin/which somecommand`

                      instead (at least on my system, which is in /usr/bin, not in plain /bin)
                      to bypass the alias, or else do it manually:

                      which somecommand # aliased to type -a
                      vim ~/bin/somecommand

                      >
                      > (Never could understand why I should ask the shell to type thingy,
                      > then expect it to answer with which thingy it'd use, instead.)
                      >
                      > Alas, the 2009 Debian manpage in my Ubuntu distro lacks the wisdom
                      > you've found.
                      >
                      > Erik
                      >
                      > ¹ First HP-UX, then Solaris, now linux - all had "type" AFAIR.
                      >

                      Best regards,
                      Tony.
                      --
                      hundred-and-one symptoms of being an internet addict:
                      60. As your car crashes through the guardrail on a mountain road, your first
                      instinct is to search for the "back" button.

                      --
                      --
                      You received this message from the "vim_use" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_use" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • Erik Christiansen
                      ... Sort of. Making which a helpful tool and convenient mnemonic for the vast majority of general use cases, makes it unsuited to that one, but not merely
                      Message 10 of 11 , Dec 31, 2013
                      • 0 Attachment
                        On 31.12.13 10:18, Tony Mechelynck wrote:
                        > On 31/12/13 09:34, Erik Christiansen wrote:
                        > >$ grep which .bashrc
                        > >alias which='type -a' # Checks aliases & functions also.
                        >
                        > The problem with this alias, IIUC, is when one tries to use
                        >
                        > vim `which somecommand`
                        >
                        > to edit an executable script, since the output of "type" is in a different
                        > format.

                        Sort of. Making "which" a helpful tool and convenient mnemonic for the
                        vast majority of general use cases, makes it unsuited to that one, but
                        not merely due to format. On this host, without looking further than
                        "which" itself, it finds several (prioritised) alternatives:

                        $ which which
                        which is aliased to `type -a'
                        which is /usr/bin/which
                        which is /bin/which

                        I'm not too sure how a command should mind-read which of several
                        alternatives we'd prefer to examine, now that we know what's there. OK,
                        sometimes picking the one which has path priority will be the right one.
                        So I'd have to go with your second strategy:

                        > I suppose you would have to do
                        >
                        > vim `/usr/bin/which somecommand`
                        >
                        > instead (at least on my system, which is in /usr/bin, not in plain /bin) to
                        > bypass the alias, or else do it manually:
                        >
                        > which somecommand # aliased to type -a
                        > vim ~/bin/somecommand

                        If we want to tweak the command with path priority, then we'd need to
                        vim .bashrc, to get at the alias. But if we wanted to examine the
                        underlying shell script which constitutes "which", then it'd be
                        vim /bin/which, since /usr/bin/which is just a link to that anyway.

                        Finding stuff in the filesystem is, at least here, a greater challenge
                        than invoking vim on a specific file, so maximising transparency has the
                        greater payoff, I find. Making an informed choice on which alternative
                        to edit seems to beat a tiny bit of automation, I figure. But needs
                        differ, I'll accept.

                        Here's wishing a happy new year to all Vimmers. (Under an hour and a half
                        away here.)

                        Erik

                        --
                        GNU's not Unix, but Unix is a beast; its plural form is Unixen.
                        - GNU grep 2.5.1-cvs manpage

                        --
                        --
                        You received this message from the "vim_use" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php

                        ---
                        You received this message because you are subscribed to the Google Groups "vim_use" group.
                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                        For more options, visit https://groups.google.com/groups/opt_out.
                      • Tony Mechelynck
                        ... Without -a (aka --all) it gives only the first one in the $PATH. ... Not here: linux:~ # type -a which which is /usr/bin/which which is /usr/bin/X11/which
                        Message 11 of 11 , Dec 31, 2013
                        • 0 Attachment
                          On 31/12/13 12:40, Erik Christiansen wrote:
                          > On 31.12.13 10:18, Tony Mechelynck wrote:
                          >> On 31/12/13 09:34, Erik Christiansen wrote:
                          >>> $ grep which .bashrc
                          >>> alias which='type -a' # Checks aliases & functions also.
                          >>
                          >> The problem with this alias, IIUC, is when one tries to use
                          >>
                          >> vim `which somecommand`
                          >>
                          >> to edit an executable script, since the output of "type" is in a different
                          >> format.
                          >
                          > Sort of. Making "which" a helpful tool and convenient mnemonic for the
                          > vast majority of general use cases, makes it unsuited to that one, but
                          > not merely due to format. On this host, without looking further than
                          > "which" itself, it finds several (prioritised) alternatives:
                          >
                          > $ which which
                          > which is aliased to `type -a'
                          > which is /usr/bin/which
                          > which is /bin/which
                          >
                          > I'm not too sure how a command should mind-read which of several
                          > alternatives we'd prefer to examine, now that we know what's there. OK,
                          > sometimes picking the one which has path priority will be the right one.

                          Without -a (aka --all) it gives only the first one in the $PATH.

                          > So I'd have to go with your second strategy:
                          >
                          >> I suppose you would have to do
                          >>
                          >> vim `/usr/bin/which somecommand`
                          >>
                          >> instead (at least on my system, which is in /usr/bin, not in plain /bin) to
                          >> bypass the alias, or else do it manually:
                          >>
                          >> which somecommand # aliased to type -a
                          >> vim ~/bin/somecommand
                          >
                          > If we want to tweak the command with path priority, then we'd need to
                          > vim .bashrc, to get at the alias. But if we wanted to examine the
                          > underlying shell script which constitutes "which", then it'd be
                          > vim /bin/which, since /usr/bin/which is just a link to that anyway.

                          Not here:

                          linux:~ # type -a which
                          which is /usr/bin/which
                          which is /usr/bin/X11/which
                          linux:~ # ls -l /usr/bin/X11
                          lrwxrwxrwx 1 root root 1 Jul 13 17:13 /usr/bin/X11 -> ./
                          linux:~ # ls -l /usr/bin/which
                          -rwxr-xr-x 1 root root 23144 Nov 5 2012 /usr/bin/which*
                          linux:~ # ls -l /bin/which
                          ls: cannot access /bin/which: No such file or directory

                          >
                          > Finding stuff in the filesystem is, at least here, a greater challenge
                          > than invoking vim on a specific file, so maximising transparency has the
                          > greater payoff, I find. Making an informed choice on which alternative
                          > to edit seems to beat a tiny bit of automation, I figure. But needs
                          > differ, I'll accept.
                          >
                          > Here's wishing a happy new year to all Vimmers. (Under an hour and a half
                          > away here.)
                          >
                          > Erik
                          >

                          Sure, happy new year to you all, though on _my_ clock it's only about
                          13:02 on the 31 as I type this.

                          Best regards,
                          Tony.
                          --
                          The makers may make
                          and the users may use,
                          but the fixers must fix
                          with but minimal clues

                          --
                          --
                          You received this message from the "vim_use" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php

                          ---
                          You received this message because you are subscribed to the Google Groups "vim_use" group.
                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
                          For more options, visit https://groups.google.com/groups/opt_out.
                        Your message has been successfully submitted and would be delivered to recipients shortly.