Gvim running external program via TCC

[ohenryx]

This may be a little too arcane, but I’m going to throw it out there anyway. It definitely is a problem with TCC version 31.1.19. This may be a little hard to duplicate, and thus hard to fix, and I will accept that if it turns out to be the case.

I am running Gvim, version 9, on Windows. To be more specific, Gvim version 9.0.2189, and Windows 11 Education, Version 23H2, Build 22631.2861. When I’m dealing with a text file, I sometimes need to reformat lines, and I like to use the “par” command for that. The par that I use is distributed with Cygwin, version 1.53, “par - filter for reformatting paragraphs”.

I use the par program from within Gvim by the command:

1,21!par -w78

Which means take lines 1 through 21, pass them to the external par program, and then paste the results back in place.

Recently, a few weeks back, this started giving me problems. When I run the par program from within Gvim, the process does not return. Instead I get an icon down on the taskbar. If I mouse hover on this icon, it says:

C:\VIM\VIM90\vimrun.exe

“C:\VIM\VIM90” is the location where I have Gvim installed. If I click on the icon for vimrun, then it disappears, the Gvim process gets control back, and the lines I passed are properly formatted. In other words, everything works like it should except that I have to click on the icon for vimrun.exe in order to complete the process. I have tried a number of troubleshooting steps. I tried using “fmt” (also from Cygwin), same result. I downloaded the source code for the par program, compiled it with Tiny C, same result. I uninstalled Gvim, and installed the base 9.0 version from June of 2022, no help.

About all that’s left is to roll back Windows. Looking at my update history, on 12.13.2023 I installed KB5033375, and on 12.06.2023 I installed KB5032288. I am a little reluctant to start rolling back Windows update, sometimes that can cause more problems. Has anyone else encountered this issue?

ON EDIT: okay, forget rolling back windows, the problem is with TCC. If I start Gvim with comspec set to “cmd.exe”, the problem disappears. Completely uninstall TCC 31, install TCC 30 instead, the problem disappears. Any ideas?

 

[rconn]

Presumably Gvim is using "%comspec% /c ..." to execute the external commands. (Not a particularly good idea in Windows, but common in Linux apps.)

Nothing changed in that part of the TCC code in v31, though it is using an updated Microsoft RTL so there's a possibility there's a problem there.

If you start TCC with the "/..." option it turns on debugging and you can see exactly what Gvim is passing (probably something malformed). You can also check the variables _cmdline and CMDLINE2.

 

[ohenryx]

Thanks for responding. I have found a workaround, well actually, more than one. I will list them here in case anyone else runs into the problem and finds this thread with a google search.

1) in the _vimrc file (or in my case, mswin.vim, change the shell command from tcc.exe to cmd.exe

-or-

2) replace the vimrun.exe file in the vim directory with the one found here:

GitHub - 2072/Windowless-vimrun: A vimrun.exe replacement

 

[AnrDaemon]

3) Use a wrapper script to run (g)vim, and fix ComSpec in there. I do something similar to run Cygwin scripts via Windows associations:

File: cygwrap.btm

@SET PROMPT=@$S$P$_
@ECHO OFF
ON BREAK REM

IF "%~1" == "--install" GOTO :SETUP
IF "%~1" == "" GOTO :BANNER

CALL "%~dp0fix-path.btm"

SET "_BIN=%@PATH[%@FULL["%~0"]]"
SET "_ENV=%[_BIN]env.exe"
REM Hacking around cygpath caveat
IFF "%@INSTR[1,2,"%~1"]" = "\\" THEN
  SET _mode=-m
ELSE
  SET _mode=-u
ENDIFF
SET "CMDNAME=%@EXECSTR["%[_BIN]cygpath.exe" %[_mode] "%~1"]"
SHIFT

SET "LANG=%@EXECSTR[locale -uU]"
SET "ComSpec=%[SystemRoot]\System32\cmd.exe"
"%[_ENV]" -- "%[CMDNAME]" %$
QUIT %?

:BANNER
ECHO Cygwin script wrapper.
ECHO Usage:
ECHO.
ECHO   %@FILENAME["%~0"] script [parameters]
ECHO   %@FILENAME["%~0"] --install [.ext ...]
ECHO.
ECHO The ".sh" extension is always registered on install.
QUIT

:SETUP

FTYPE unixshell.script="%[ComSpec]" /B /C "%@FULL["%~0"]" "%%1" %%*
SHIFT
DO EXT IN /L .sh %$
  IFF "%@LEFT[1,%[EXT]]" == "." THEN
    ASSOC %[EXT]=unixshell.script
  ENDIFF
ENDDO

 

[ohenryx]

Interesting. I don't use many bash scripts, and when I do I'm usually running Ubuntu either in WSL or VMWare. I never really learned that much about bash scripting, we used c-shell where I worked and I became fairly accomplished at that. But then again, anything complex was done in perl, so ...

I am using option 2 (from my post above), replacing the vimrun module, and everything is working fine here.