vim: errors launching "/usr/bin/vi

vim: errors launching "/usr/bin/vi

[Beau James]

[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

This problem appeared with my most recent Cygwin update that included an 
update to "vim".

My Cygwin installation now show vim version 9.0.2115.

Launching VIM from the shell running in a mintty window using the full 
pathname "/usr/bin/vim" works fine.

But launching "/usr/bin/vi" (which has worked fine for many years, until 
the most recent update), results in a long string of startup E319 errors:

>     $ /usr/bin/vi
>     Error detected while processing /usr/share/vim/vim90/filetype.vim:
>     line   11:
>     E319: Sorry, the command is not available in this version: let
>     did_load_filetypes = 1
>     line   14:
>     E319: Sorry, the command is not available in this version: let
>     s:cpo_save = &cpo
>     line   48:
>     E319: Sorry, the command is not available in this version: func
>     s:StarSetf(ft)
>     line   52:
>     E319: Sorry, the command is not available in this version: endfunc
    etc. etc.

Note that the startup errors appear only when using the full pathname 
"/usr/bin/vi". Using the command name alone ("vi") relying on the search 
path does not trigger the startup errors; using either the full pathname 
"/usr/bin/vim" or the command name alone "vim" relying on the search 
path does not trigger the startup errors.

I encountered this because some of my longtime 'convenience' Windows 
desktop links were launching a mintty window using "vi":

>     Target: C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico
>     /usr/bin/vi /<targetfile>/

Easily fixed for me by changing "vi" to "vim". But don't know whether 
this change in behavior has any other implications?

Beau

Re: vim: errors launching "/usr/bin/vi

[Marco Atzeri]

On 20/12/2023 03:47, Beau James via Cygwin wrote:
> This problem appeared with my most recent Cygwin update that included an 
> update to "vim".
> 
> My Cygwin installation now show vim version 9.0.2115.
> 
> Launching VIM from the shell running in a mintty window using the full 
> pathname "/usr/bin/vim" works fine.
> 
> But launching "/usr/bin/vi" (which has worked fine for many years, until 
> the most recent update), results in a long string of startup E319 errors:
> 
>>     $ /usr/bin/vi
>>     Error detected while processing /usr/share/vim/vim90/filetype.vim:
>>     line   11:
>>     E319: Sorry, the command is not available in this version: let
>>     did_load_filetypes = 1
>>     line   14:
>>     E319: Sorry, the command is not available in this version: let
>>     s:cpo_save = &cpo
>>     line   48:
>>     E319: Sorry, the command is not available in this version: func
>>     s:StarSetf(ft)
>>     line   52:
>>     E319: Sorry, the command is not available in this version: endfunc
>     etc. etc.
> 
> Note that the startup errors appear only when using the full pathname 
> "/usr/bin/vi". Using the command name alone ("vi") relying on the search 
> path does not trigger the startup errors; using either the full pathname 
> "/usr/bin/vim" or the command name alone "vim" relying on the search 
> path does not trigger the startup errors.
> 

vi is usually an alias to vim

$ alias | grep vi

  alias vi='vim'

so you are in reality calling vim

$ which vim
/usr/bin/vim


I am investigating the /usr/bin/vi issue

Re: vim: errors launching "/usr/bin/vi

[marco atzeri]

On Wed, Dec 20, 2023 at 6:04 AM Marco Atzeri wrote:
>
> On 20/12/2023 03:47, Beau James via Cygwin wrote:
> > This problem appeared with my most recent Cygwin update that included an
> > update to "vim".
>
> vi is usually an alias to vim
>
> $ alias | grep vi
>
>   alias vi='vim'
>
> so you are in reality calling vim
>
> $ which vim
> /usr/bin/vim
>
>
> I am investigating the /usr/bin/vi issue
>

-2 version should have solved the issue

Re: vim: errors launching "/usr/bin/vi

[Lee]

On Wed, Dec 20, 2023 at 9:01 AM marco atzeri  wrote:
>
> On Wed, Dec 20, 2023 at 6:04 AM Marco Atzeri wrote:
> >
> > On 20/12/2023 03:47, Beau James via Cygwin wrote:
> > > This problem appeared with my most recent Cygwin update that included an
> > > update to "vim".
> >
> > vi is usually an alias to vim
> >
> > $ alias | grep vi
> >
> >   alias vi='vim'
> >
> > so you are in reality calling vim
> >
> > $ which vim
> > /usr/bin/vim
> >
> >
> > I am investigating the /usr/bin/vi issue
> >
>
> -2 version should have solved the issue

I don't get any error or warning messages now but 'vi' still doesn't
always get me the same thing:

$ vi --version | head -5
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:57:02)
Included patches: 1-2155
Modified by <cygwin@cygwin.com>
Compiled by <cygwin@cygwin.com>
Huge version without GUI.  Features included (+) or not (-):

$ /bin/sh

$ vi --version | head -5
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:53:22)
Included patches: 1-2155
Modified by <cygwin@cygwin.com>
Compiled by <cygwin@cygwin.com>
Tiny version without GUI.  Features included (+) or not (-):



Would you please let me know how to make an /etc/alternatives for vi/vim?
I want 'vi' to always invoke 'vim' and everything I tried with
alternatives failed :(

Thanks
Lee

Re: vim: errors launching "/usr/bin/vi

[matthew patton]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

> Would you please let me know how to make an /etc/alternatives for vi/vim?
did you install the alternatives package? I just use aliases (actually I set EDITOR=xxx) after I enumerate the editors I consider worthy of inclusion and resident. What DOES need nuking is the forced alias in /etc/profile.d. That's inexcusable interference in the system.  

Re: vim: errors launching "/usr/bin/vi

[Lee]

On Wed, Dec 20, 2023 at 1:57 PM matthew patton wrote:
>
> > Would you please let me know how to make an /etc/alternatives for vi/vim?
>
> did you install the alternatives package?

I installed cygwin back in 2017; I don't remember what all I've
installed but it seems to be there:
$ ls -l /usr/sbin/alt*
-rwxr-xr-x 1 root None 20499 Apr  4  2013 /usr/sbin/alternatives.exe

> I just use aliases (actually I set EDITOR=xxx) after I enumerate the editors I consider worthy of inclusion and resident.

That's my current work-around

# set the bash prompt
#   "$SHLVL" = 1 is true for the 1st shell, and incremented
#   each time another instance of bash is started.  eg
#     vi /tmp/foo
#     :sh
#   and you're in a new shell so SHLVL was incremented
#
if [  "$SHLVL" = 1 ]; then
    PS1='\[\e]2;\u@\h  \w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
else
    PS1='\[\e]2;\u@\h  \w\a\]\n\u@\h \w\n\$ '
    alias vi=vim
fi

> What DOES need nuking is the forced alias in /etc/profile.d. That's inexcusable interference in the system.

I'd say vi/vim needs to be put under /etc/alternatives
If anyone has access to a redhat linux system, do they 'alias vi=vim'
or put vi under /etc/alternatives?

Debian uses alternatives:
$ update-alternatives --query vi
Name: vi
Link: /usr/bin/vi
Slaves:
 vi.1.gz /usr/share/man/man1/vi.1.gz
 vi.da.1.gz /usr/share/man/da/man1/vi.1.gz
 vi.de.1.gz /usr/share/man/de/man1/vi.1.gz
 vi.fr.1.gz /usr/share/man/fr/man1/vi.1.gz
 vi.it.1.gz /usr/share/man/it/man1/vi.1.gz
 vi.ja.1.gz /usr/share/man/ja/man1/vi.1.gz
 vi.pl.1.gz /usr/share/man/pl/man1/vi.1.gz
 vi.ru.1.gz /usr/share/man/ru/man1/vi.1.gz
Status: auto
Best: /usr/bin/vim.basic
Value: /usr/bin/vim.basic

Alternative: /usr/bin/vim.basic
Priority: 30
Slaves:
 vi.1.gz /usr/share/man/man1/vim.1.gz
 vi.da.1.gz /usr/share/man/da/man1/vim.1.gz
 vi.de.1.gz /usr/share/man/de/man1/vim.1.gz
 vi.fr.1.gz /usr/share/man/fr/man1/vim.1.gz
 vi.it.1.gz /usr/share/man/it/man1/vim.1.gz
 vi.ja.1.gz /usr/share/man/ja/man1/vim.1.gz
 vi.pl.1.gz /usr/share/man/pl/man1/vim.1.gz
 vi.ru.1.gz /usr/share/man/ru/man1/vim.1.gz

$ update-alternatives --query vim
Name: vim
Link: /usr/bin/vim
Status: auto
Best: /usr/bin/vim.basic
Value: /usr/bin/vim.basic

Alternative: /usr/bin/vim.basic
Priority: 30

Regards,
Lee

Re: vim: errors launching "/usr/bin/vi

[gs-cygwin.com]

On Wed, Dec 20, 2023 at 02:23:49PM -0500, Lee via Cygwin wrote:
> If anyone has access to a redhat linux system, do they 'alias vi=vim'
> or put vi under /etc/alternatives?

FYI: neither.

$ cat /etc/fedora-release 
Fedora release 39 (Thirty Nine)

$ cat /usr/bin/vi
#!/usr/bin/sh

# run vim if:
# - 'vi' command is used and 'vim' binary is available
# - 'vim' command is used
# NOTE: Set up a local alias if you want vim -> vi functionality. We will not
# do it globally, because it messes up with available startup options (see 
# ':help starting', 'vi' is not capable of '-d'). The introducing an environment
# variable, which an user must set to get the feature, will do the same trick
# as setting an alias (needs user input, does not work with sudo), so it is left
# on user whether he decides to use an alias:
#
# alias vim=vi
#
# in bashrc file.

if test -f /usr/bin/vim
then
  exec /usr/bin/vim "$@"
fi

# run vi otherwise
exec /usr/libexec/vi "$@"

Re: vim: errors launching "/usr/bin/vi

[Lee]

On Wed, Dec 20, 2023 at 2:45 PM gs-cygwin wrote:
>
> On Wed, Dec 20, 2023 at 02:23:49PM -0500, Lee via Cygwin wrote:
> > If anyone has access to a redhat linux system, do they 'alias vi=vim'
> > or put vi under /etc/alternatives?
>
> FYI: neither.

Wow!  I would have never guessed 'wrapper script'
Thank you!

Lee


>
> $ cat /etc/fedora-release
> Fedora release 39 (Thirty Nine)
>
> $ cat /usr/bin/vi
> #!/usr/bin/sh
>
> # run vim if:
> # - 'vi' command is used and 'vim' binary is available
> # - 'vim' command is used
> # NOTE: Set up a local alias if you want vim -> vi functionality. We will not
> # do it globally, because it messes up with available startup options (see
> # ':help starting', 'vi' is not capable of '-d'). The introducing an environment
> # variable, which an user must set to get the feature, will do the same trick
> # as setting an alias (needs user input, does not work with sudo), so it is left
> # on user whether he decides to use an alias:
> #
> # alias vim=vi
> #
> # in bashrc file.
>
> if test -f /usr/bin/vim
> then
>   exec /usr/bin/vim "$@"
> fi
>
> # run vi otherwise
> exec /usr/libexec/vi "$@"

Re: vim: errors launching "/usr/bin/vi

[Ken Brown]

On 12/20/2023 1:34 PM, Lee via Cygwin wrote:
> On Wed, Dec 20, 2023 at 9:01 AM marco atzeri  wrote:
>>
>> On Wed, Dec 20, 2023 at 6:04 AM Marco Atzeri wrote:
>>>
>>> On 20/12/2023 03:47, Beau James via Cygwin wrote:
>>>> This problem appeared with my most recent Cygwin update that included an
>>>> update to "vim".
>>>
>>> vi is usually an alias to vim
>>>
>>> $ alias | grep vi
>>>
>>>    alias vi='vim'
>>>
>>> so you are in reality calling vim
>>>
>>> $ which vim
>>> /usr/bin/vim
>>>
>>>
>>> I am investigating the /usr/bin/vi issue
>>>
>>
>> -2 version should have solved the issue
> 
> I don't get any error or warning messages now but 'vi' still doesn't
> always get me the same thing:
> 
> $ vi --version | head -5
> VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:57:02)
> Included patches: 1-2155
> Modified by <cygwin@cygwin.com>
> Compiled by <cygwin@cygwin.com>
> Huge version without GUI.  Features included (+) or not (-):
> 
> $ /bin/sh
> 
> $ vi --version | head -5
> VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:53:22)
> Included patches: 1-2155
> Modified by <cygwin@cygwin.com>
> Compiled by <cygwin@cygwin.com>
> Tiny version without GUI.  Features included (+) or not (-):

Your second shell is not a login shell.  Could that be the problem?

Ken

Re: vim: errors launching "/usr/bin/vi

[matthew patton]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

 > I'd say vi/vim needs to be put under /etc/alternatives

No, because that's system-wide. 
Vi vs Vim is a personal choice. Also alternatives is for supporting multiple versions. Say v8.02 versus v9.1 of 'vim' on a system, one being in /usr/bin and the other in /usr/local/bin just as an example. And the sysadmin choosing (for whatever good reason) to preference the v9 software over the v8.

Re: vim: errors launching "/usr/bin/vi

[Brian Inglis]

On 2023-12-20 12:30, matthew patton via Cygwin wrote:
>> I'd say vi/vim needs to be put under /etc/alternatives

> No, because that's system-wide.
> Vi vs Vim is a personal choice. Also alternatives is for supporting multiple
> versions. Say v8.02 versus v9.1 of 'vim' on a system, one being in /usr/bin
> and the other in /usr/local/bin just as an example. And the sysadmin choosing
> (for whatever good reason) to preference the v9 software over the v8.

Most of us run Cygwin on a device called a /Personal Computer/ that allows us to 
make our own choices about OS, desktop UI, services, and configuration. ;^>

How many of you run shared server or administered Cygwin desktop setups?

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: vim: errors launching "/usr/bin/vi

[matthew patton]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

>> No, because that's system-wide.
>> Vi vs Vim is a personal choice. Also alternatives is for supporting multiple

> Most of us run Cygwin on a device called a /Personal Computer/ that allows us to 
> make our own choices about OS, desktop UI, services, and configuration. ;^>

yeah, yeah I know. It doesn't give license to pervert "correct behavior" though. :)
  

Re: vim: errors launching "/usr/bin/vi

[Brian Inglis]

On 2023-12-20 12:47, matthew patton wrote:
>>> No, because that's system-wide.
>>> Vi vs Vim is a personal choice. Also alternatives is for supporting
>>> multiple

>> Most of us run Cygwin on a device called a /Personal Computer/ that allows
>>  us to make our own choices about OS, desktop UI, services, and 
>> configuration. ;^>
> yeah, yeah I know. It doesn't give license to pervert "correct behavior" though. :)

Most distros differ in their default packages and configurations for server and 
desktop editions, so "correct behaviour" may also differ.

Cygwin tends to go along with Fedora desktop decisions: some features are 
disabled in some packages because FESCo does not agree with some packaging 
decisions or component sources.

I know some of this because I went looking to see if certain packages were 
available and/or provided by default on some distro server and desktop editions, 
and found that most of those decisions and that information is not really 
documented in any obvious place, just implemented, so you would have to install 
and run the editions to find out!

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: vim: errors launching "/usr/bin/vi

[Lee]

On Wed, Dec 20, 2023 at 2:44 PM Brian Inglis wrote:
>
> On 2023-12-20 12:30, matthew patton via Cygwin wrote:
> >> I'd say vi/vim needs to be put under /etc/alternatives
>
> > No, because that's system-wide.
> > Vi vs Vim is a personal choice. Also alternatives is for supporting multiple
> > versions. Say v8.02 versus v9.1 of 'vim' on a system, one being in /usr/bin
> > and the other in /usr/local/bin just as an example. And the sysadmin choosing
> > (for whatever good reason) to preference the v9 software over the v8.
>
> Most of us run Cygwin on a device called a /Personal Computer/ that allows us to
> make our own choices about OS, desktop UI, services, and configuration. ;^>
>
> How many of you run shared server or administered Cygwin desktop setups?

I have a normal user login with no privs and an administer login for
doing things like installing programs or updating the system.
I love Nancy Reagans' "Just Say No" to UAC prompts when I'm logged in
as a normal user :)

I suspect my wife has forgotten her password on this machine.

Lee

Re: vim: errors launching "/usr/bin/vi

[Lee]

On Wed, Dec 20, 2023 at 2:30 PM matthew patton  wrote:
>
>  > I'd say vi/vim needs to be put under /etc/alternatives
>
> No, because that's system-wide.

Which is what I want.

> Vi vs Vim is a personal choice.

Which I've made :)
Anyone that doesn't like that decision can make their own work-around,
but me with my normal and admin logins wants 'vi' to always behave the
same way.
I kinda doubt my wife would notice.. except maybe if syntax
hilighting/coloring broke

> Also alternatives is for supporting multiple versions. Say v8.02 versus v9.1 of 'vim' on a system, one being in /usr/bin and the other in /usr/local/bin just as an example. And the sysadmin choosing (for whatever good reason) to preference the v9 software over the v8.

man alternatives
NAME
       alternatives - maintain symbolic links determining default commands

It allows picking among multiple versions but it also allows picking
between different programs.

Regards,
Lee

>
> --
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

Re: vim: errors launching "/usr/bin/vi

[Lee]

On Wed, Dec 20, 2023 at 2:24 PM Ken Brown via Cygwin <cygwin@cygwin.com> wrote:
>
> On 12/20/2023 1:34 PM, Lee via Cygwin wrote:
> > On Wed, Dec 20, 2023 at 9:01 AM marco atzeri  wrote:
> >>
> >> On Wed, Dec 20, 2023 at 6:04 AM Marco Atzeri wrote:
> >>>
> >>> On 20/12/2023 03:47, Beau James via Cygwin wrote:
> >>>> This problem appeared with my most recent Cygwin update that included an
> >>>> update to "vim".
> >>>
> >>> vi is usually an alias to vim
> >>>
> >>> $ alias | grep vi
> >>>
> >>>    alias vi='vim'
> >>>
> >>> so you are in reality calling vim
> >>>
> >>> $ which vim
> >>> /usr/bin/vim
> >>>
> >>>
> >>> I am investigating the /usr/bin/vi issue
> >>>
> >>
> >> -2 version should have solved the issue
> >
> > I don't get any error or warning messages now but 'vi' still doesn't
> > always get me the same thing:
> >
> > $ vi --version | head -5
> > VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:57:02)
> > Included patches: 1-2155
> > Modified by <cygwin@cygwin.com>
> > Compiled by <cygwin@cygwin.com>
> > Huge version without GUI.  Features included (+) or not (-):
> >
> > $ /bin/sh
> >
> > $ vi --version | head -5
> > VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:53:22)
> > Included patches: 1-2155
> > Modified by <cygwin@cygwin.com>
> > Compiled by <cygwin@cygwin.com>
> > Tiny version without GUI.  Features included (+) or not (-):
>
> Your second shell is not a login shell.  Could that be the problem?

You need to define "problem" first :)

I want "vi" to always call "vim" .. hrmm.. unless I've explicitly done
something to explicitly over-ride that.

So anytime I type in 'vi' and don't get the VIM Huge version without
GUI I'd say that's a problem.

I've got "export EDITOR=vi" in my .bash_profile, so anytime $EDITOR is
called I want the huge version of vim.
If that doesn't happen I'd say that is a problem.

If I'm in a bash sheel & do /bin/sh I expect typing in 'vi' will get
me the same results as when I was in bash
Same deal with dash -- I still want my expected version of vim to run

So ... a very long way of saying No, I don't think the second shell
not being a login shell is 'the problem.'
My experience is that Debian always does the right thing wrt vi/vim.
Cygwin does not.  It'd be interesting to know if redhat linux uses
alternatives or an alias to decide which vi/vim gets called.

Regards,
Lee

Re: vim: errors launching "/usr/bin/vi

[matthew patton]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

> I've got "export EDITOR=vi" in my .bash_profile, so anytime $EDITOR is
> called I want the huge version of vim.
Then set EDITOR=<path_to_vim>
If you want to cheat and only use 'vi' then you need to walk the dependency chain and/or search_for_binary mechanism employed by the SHELL to find the correct target. You can of course set this as 'system-wide global' or down in your login shell, or in sub-shell scope.
It is NOT the application packager's job to do your homework for you, or to hijack the process because some percentage of people prefer it a certain way.

Also, you seem to be not aware that /bin/sh RARELY actually invokes BASH. On some Linux distros it does, but you should NOT rely on that being true anywhere else.