[tldistro] TexLive on MSYS2

[Naveen M K]

Hi Norbert,

> Well definitely, most programs that are not binaries or links to these
> binaries are links to scripts under texmf-dist/scripts.
> 
> Most prominently fmtutil, updmap, ...

I just read `./runscript --help` and it says, it automatically searches 
the `texmf-dist/scripts` directory? I attached the help message. What I 
think I should now is just rename `runscript.exe` to things they have 
symlinked. Also, there already exists `fmtutil.exe`,`updmap.exe`...

And for the engine I think I should copy the executable and not rename 
`runscript.exe` as they should be only working for things in script.

Am I wrong here or this is how things work on Windows?

> Yes, we have an universal wrapper in TeX Live: runscript.exe which
> passes the hard work on to runscript.lua which in turn starts the
> scripts (etiher with the TeX Live internal perl interpreter if it is a
> perl script, or with what we have).

If I understand correctly, my work would be to just copy `runscript.exe` 
which was build when building binaries to necessary scripts as I told 
above and other things should be handled automatically. It simplifies a 
lot of works thanks.

Regards,
Naveen
-------------- next part --------------
$ ./runscript --help

  Script wrappers in TeX Live on Windows

  Rationale

    Wrappers enable use of scripts on Windows as regular programs.
    They are also required for some binary programs to set up the
    right environment for them.

    Batch scripts can be used for wrapping but they are not as universal
    as binaries (there are some odd cases where they don't work) and
    it is hard to make them robust and secure.  Compiled binary wrappers
    don't suffer from these problems but they are harder to write, debug
    and maintain in comparison to scripts.  For these reasons a hybrid
    approach is taken that combines a binary stub with a launcher script.

  Adding wrappers for user scripts

    The script wrapping machinery is not limited to scripts shipped with
    TeX Live.  You can also use it for script programs from manually
    installed packages.  This should minimize problems when using them
    with TeX Live.

    First, make sure that there is an interpreter program available
    on your system for the script you want to use.  Interpreters for
    Perl, Lua and Tcl/Tk (GUI scripts only) are bundled with TeX
    Live, all others have to be installed independently.  Lua
    scripts are the most efficient to run, so if you consider
    writing a new script, that would be the recommended choice.

    The following script types and their file extensions are currently
    supported and searched in that order:

      Lua      (.tlu;.texlua;.lua) --  included
      Perl     (.pl)               --  included
      Ruby     (.rb)               --  requires installation
      Python   (.py)               --  requires installation
      Tcl      (.tcl)              --  included (GUI scripts only)
      Java     (.jar)              --  requires installation
      VBScript (.vbs)              --  part of Windows
      JScript  (.js)               --  part of Windows
      Batch    (.bat;.cmd)         --  part of Windows

    Finally, Unix-style extensionless scripts are searched as last and
    the interpreter program is established based on the she-bang (#!)
    specification on the very first line of the script.  This can be
    an arbitrary program but it must be present on the search path.

    Next, the script program needs to be installed somewhere below the
    'scripts' directory under one of the TEXMF trees (consult the
    documentation or texmf/web2c/texmf.cnf file for a list).  You may
    need to update the file search database afterwards with:

      mktexlsr [TEXMFDIR]

    It is also possible to use scripts that are outside of TEXMF hierarchy
    by adjusting TEXMFSCRIPTS environment or kpathsea variable, see
    kpathsea documentation for more information on setting its variables.

    Test if the script can be located with:

      kpsewhich --format=texmfscripts <script-name>.<ext>

    This should output the full path to the script if everything is
    properly installed and configured.  If this test is successful,
    the script can be run immediately with:

      runscript <script-name> [script arguments]

    If you prefer to call the script program simply by its name, copy
    and rename bin/win32/runscript.exe (or bin/win64/runscript.exe for
    64-bit Windows) to <script-name>.exe and put it somewhere on the
    search path.