MiKTeX does not work over SSH from the command line

[kalibera]

MiKTeX does not seem to be working without graphical interface even when it only communicates via the command line. Running miktex --version via an SSH session to the Windows machine produces no output, while on the same system, it works with graphical interface locally, producing

One MiKTeX Utility 0.2 (MiKTeX 21.8) 

© 2021 Christian Schenk

This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

On the same system, texify --version from the SSH session produces:

texify: Windows API error 0: The operation completed successfully.

With the graphical interface, this command also fails (which was already reported), but differently (MiKTeX 21.8, Utils.cpp:490 Internal error). On earlier versions of MiKTeX, it worked in the graphical interface for me, but still failed over the SSH session with the Windows API error 0: The operation completed successfully. error.

[edocevoli]

You can disable the GUI as follows:

initexmf --set-config-value=[MPM]AutoInstall=t

[kalibera]

Thanks for the quick advice, but unfortunately it does not solve the problem on my system.

ieuser@MSEDGEWIN10 C:\Users\IEUser>initexmf --set-config-value=[MPM]AutoInstall=t

ieuser@MSEDGEWIN10 C:\Users\IEUser>texify --version
texify: Windows API error 0: The operation completed successfully.

I've checked also in the graphical MiKTeX console that the packages are set to be installed automatically on-the-fly.

[edocevoli]

Seems to be a known issue.

[edocevoli]

Duplicate of #899

[kalibera]

Thanks, but this really seems to be a different issue. I've tried from scratch, installed MiKTeX 21.6 (user-only, set to automatically install packages on the fly, otherwise all defaults). Here, #899 does not apply, when normally using Windows, texify --version works and returns:

MiKTeX Compiler Driver 4.0 (MiKTeX 21.6)

© 1992-1999, 2001-2005 Free Software Foundation, Inc. © 1998-2020 Christian Schenk 
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But, when logged to Windows over an ssh session, texify --version fails:

Windows API error 0: The operation completed successfully.

It is probably because texify somehow tries to initialize the GUI or use some Windows API which is not available when logged via SSH, but I was hoping there would be a way of avoiding such calls in a command-line application.

[edocevoli]

MiKTeX utilities will no initialize a GUI.

Just opened a SSH session and ran texify --version. It works for me. I would rcommend that you search MiKTeX log files for error messages.

[kalibera]

Thanks for trying, so I tried on a different Windows 10 VM (19043, Windows 10 Education) and texify --version in 21.6 also worked fine over SSH session.

I've tried debugging the problem on the VM where it crashes (17763, Windows 10 Enterprise Evaluation) and I got this stack trace from windbg:

# Child-SP          RetAddr           Call Site
00 000000d6`c396ad50 00007ffa`6c9bf8bd MiKTeX210600_loc!MiKTeX::Locale::Translator::Translator+0xf756
01 000000d6`c396ad80 00007ffa`6c9c0a25 MiKTeX210600_app!MiKTeX::App::Application::LogWarn+0x1ce0f
02 000000d6`c396b0e0 00007ff7`d3fbf668 MiKTeX210600_app!MiKTeX::App::Application::LogWarn+0x1df77
03 000000d6`c396b240 00007ffa`82751080 texify+0x2f668
04 000000d6`c396b280 00007ffa`827526b5 VCRUNTIME140_1!_CallSettingFrame_LookupContinuationIndex+0x20 [d:\agent\_work\1\s\src\vctools\crt\vcruntime\src\eh\amd64\handlers.asm @ 98] 
05 000000d6`c396b2b0 00007ffa`97ad3bd6 VCRUNTIME140_1!__FrameHandler4::CxxCallCatchBlock+0x115 [d:\agent\_work\1\s\src\vctools\crt\vcruntime\src\eh\frame.cpp @ 1367] 
06 000000d6`c396b390 00007ff7`d3fb7100 ntdll!RcConsolidateFrames+0x6
07 000000d6`c396f1a0 00007ff7`d3fb8254 texify+0x27100
08 000000d6`c396f820 00007ffa`978f81f4 texify+0x28254
09 000000d6`c396f860 00007ffa`97a9a251 KERNEL32!BaseThreadInitThunk+0x14
0a 000000d6`c396f890 00000000`00000000 ntdll!RtlUserThreadStart+0x21

Well and then I realized that the active code page (chcp) in the SSH session is 0. When I set it to 437 by chcp 437, texify --version ran fine.

So maybe there is a way to make MiKTeX more robust when dealing with the locale setup, but the code page probably ought not to be zero in the first place (the VM is the 1809 one from https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kalibera]

I confirm the issue still exists in 21.8, e.g. miktex.exe --version also crashes, and setting a valid code page (e.g. chcp 437) still works as a workaround, in the mentioned Microsoft VM (an automated setup is e.g. in https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/vm.html, though it install more applications).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.