Getting rid of all the .cmd files

[mmomtchev]

@ilg-ul, have you considered a system where, on Windows, instead of three shell script files (.cmd, .sh and .ps1), there is a single precompiled .exe stub that can be configured at runtime via a separate text file what to launch:

python.exe
python.command

with python.command containing bin\python.exe the directory to be resolved through xpm by python.exe which will simply do an execvp call to replace itself?

The .exe is precompiled to avoid requiring a compilation step. This is the system used by pip itself. It carries a number of precompiled .exe - x64, i32, 'arm64`...

Yours is the npm system, which chokes cmake.

[ilg-ul]

No, I did not consider alternate solutions, xpm is somehow an extension to npm, and it tries to use the same solutions.

I agree that the npm system creates some additional problems when the tools are not invokes via shells (like cmake).

But the idea is interesting, and I'll retain it.

[ilg-ul]

I was thinking on this suggestion, and it seems feasible.

For compatibility reasons, the existing .cmd, .ps1 and .sh shims should be preserved, but in addition two more files should be added for each tool, an .exe Windows executable and a text file, let's name it .command for now.

The executable is the same binary for all tools, when started it gets its own name, computes the associated text file name, opens it and executes the command, probably with execvp, with the same arguments and the same environment.

The generic executable is embedded into xpm, which, during the install command, copies it to .bin with the needed tool name and generates the associated command file.

For simple cases when this mechanism is used to start another .exe, the command file can be a single line, with the absolute path to the actual executable.

It is not clear how the command file should look like in case the tool is a script, like js/ts, python, etc, probably it should include the interpreter name and the absolute path to the script.

Is this what you suggested?

[mmomtchev]

Exactly.

I don't have an idea about the scripts - how did these scripts work in the first place? There was a .cmd in bin that was calling another .cmd? On my desktop, calling execvp on a .cmd file starts an infinite run of the AntiMalware Service Executable that continues until I reboot.

[ilg-ul]

I don't have an idea about the scripts - how did these scripts work in the first place?

Let's take the clang xPack as an example. For a plain executable like clang, the clang.cmd shim looks like this:

@ECHO off
GOTO start
:find_dp0
SET dp0=%~dp0
EXIT /b
:start
SETLOCAL
CALL :find_dp0
"C:\Users\ilg\AppData\Roaming\xPacks\@xpack-dev-tools\clang\17.0.6-2.1\.content\bin\clangd.exe"   %*

However, for scan-build-py, which is a python script which looks like this

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
# See https://llvm.org/LICENSE.txt for license information.
# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception

import multiprocessing
import sys
import os.path
this_dir = os.path.dirname(os.path.realpath(__file__))
sys.path.append(os.path.join(os.path.dirname(this_dir), 'lib'))

from libscanbuild.analyze import scan_build

if __name__ == '__main__':
    multiprocessing.freeze_support()
    sys.exit(scan_build())

the scan-build-py.cmd shim is different:

@ECHO off
GOTO start
:find_dp0
SET dp0=%~dp0
EXIT /b
:start
SETLOCAL
CALL :find_dp0

IF EXIST "python3.exe" (
  SET "_prog=python3.exe"
) ELSE (
  SET "_prog=python3"
  SET PATHEXT=%PATHEXT:;.JS;=;%
)

endLocal & goto #_undefined_# 2>NUL || title %COMSPEC% & "%_prog%"  C:\Users\ilg\AppData\Roaming\xPacks\@xpack-dev-tools\clang\17.0.6-2.1\.content\bin\scan-build-py %*

Similarly for other cases, like JavaScript, when the actual script is invoked via node, bash scripts, perl scripts, etc.

The challenge here is to design a format for the .command file and respectively the functionality of the common .exe forwarder that covers these cases too.