Dear LIst, 

I used today the help of WinEdt , because of the PATH for the QR Code i wanted to try, and i found this one, sorry, a little bit long: 

PATH

The PATH environment variable contains a list of directories where Windows should search for executable files when the path specification is not present in the command line. It is important that you understand that WinEdt launches external applications (such as TeX or LaTeX) through the associated command line (with additional parameters), which is passed to the appropriate Windows API function. WinEdt merely makes the process transparent by providing a customizable user-defined GUI (Graphical User Interface) in the form of a toolbar button (or a menu item) named LaTeX. WinEdt does not know in advance if and where you have installed your TeX and thus avoids calling the executables with a full path specification. However, it is strongly recommended that your PATH contains the TeX bin directory. In the Diagnosis page of this dialog, WinEdt will display the PATH variable particular to your system.

Recent versions of TeX put their bin folder to the Windows PATH variable during installation. It is by this means that WinEdt can detect them automatically. If your PATH variable (as displayed in Diagnosis page) does not contain this folder (e.g. the folder where latex.exe is to be found), you probably don't have a properly installed TeX System! It is strongly recommended that you install TeX and Ghostscript as administrator or power user and thus allow the installations to initialize the required registry keys and environment variables.

If you have any doubts about the PATH settings, start the Command Prompt from the Windows Start menu or WinEdt's Accessories menu (or WinEdt's toolbar button) and type the command:

  echo %PATH%

This displays the value of your current PATH environment variable.

If you have a good reason to put any folder on your Windows PATH, you can do so by changing the Windows environment variable PATH. This is done through the Windows Control Panel (System -> Advanced -> Environment Variables). Details depend on your version of Windows and are explained in Windows help. You should not expect extensive support from the WinEdt Team when it comes to configuring your Windows.

Changes to the PATH variable made through WinEdt's PATH page in the Execution Modes interface affect only WinEdt and applications launched from it. In most cases, this is exactly what one wants. By default, you'll find something like this:

WinEdt inserts its own root folder %B to the PATH; this makes it possible to launch WinEdt from other applications (launched from it) without specifying the location of WinEdt.exe. For example, YAP's inverse search command can be manually defined in its Options dialog as:

  WinEdt.exe "[Open(|%f|);SelPar(%l,8);]"

If necessary, you can add additional folders that will be inserted to the PATH variable. For example:

  %B;C:\My TeX\Win32\Bin;C:\My Accessories\Bin

By default, WinEdt also detects the TeX and Ghostscript bin folders (or you can specify them manually in the Execution Modes interface). Unless these folders are already included in the PATH variable, WinEdt will insert them, thus making it easy to launch TeX executables (such as latex.exe) and GS's gswin64c.exe/gswin32c.exe, which is used for ps -> pdf conversion...

In the above example, MiKTeX's bin folder got included to the PATH during MiKTeX's installation, while the GS folder had to be added by WinEdt...

Note: Many users believe that putting some folder on their PATH will allow LaTeX to find ".sty" or ".cls" files in that folder. Wrong! TeX does not search the Windows PATH for any of its input files. TeX uses its own FNDB (for good reason) and you should consult your TeX manual to learn about where to place such files and how to properly install them! Windows PATH only allows WinEdt (or other programs, including the Command Prompt) to launch an executable with its name rather than full specification, which isn't known in advance, and which depends on where you have installed your accessories. If, after the executable is launched, it fails to perform the task, the PATH (or WinEdt) usually has nothing to do with the problem and you should focus on other reasons (including possible errors in your document – read the error message or log file produced by the accessory in question)...

WinEdt itself does not use any environment variables. However, applications that are launched from WinEdt may depend on them. In particular, TeX accessories can use such variables to obtain a list of additional directories where they search for input files, bibliography databases, etc... The documentation that comes with your TeX System or any other accessory describes the rules. You should consult this documentation in order to determine if using environment variables is the best solution, or whether there are faster alternatives available.

Environment variables can be set and inspected through the Windows Control Panel (System -> Advanced -> Environment Variables). Details depend on your version of Windows.

For an application launched from WinEdt it is also possible to set such values locally inside WinEdt because WinEdt's environmental block is inherited by them (when they are launched from WinEdt). This can be done by adding such definitions in the Variables page in the Execution Modes interface. Up to six such variables can be maintained through this page; a variable is enabled when the corresponding checkbox Var is checked.

For example, suppose that you want MiKTeX to search for input files in some non-standard fixed locations, e.g. C:\MyCurrentTeXProject and C:\MyTeXFiles and all subfolders inside this one, while your bibliography (.bib) files are stored in C:\MyTeXFiles\Bib directory. After consulting MiKTeX's help, you decide that you want to accomplish this by defining the appropriate environment variables TEXINPUTS and BIBINPUTS (even though this is not a recommended method as it can slow down the compilation). In this page define and enable the variables:

  BIBINPUTS
    .;C:/MyTeXFiles/Bib;

  TEXINPUTS
    .;C:/MyCurrentTeXProject;C:/MyTeXFiles//;

The list of folders is separated by a semicolon, and "//" at the end indicates that all subfolders should be searched as well. Even though latest MiKTeX and TeX Live allow Windows-style specification of folders in environment variables, it is best to use UNIX-style (TeX usually expects and prefers directories to be separated by "/" rather "\" because the backslash is its control character). Furthermore, "//" at the end cannot be substituted with "\\".

The initial dot "." is an instruction to search first in the current folder. The trailing semicolon ";" means a search in the TeX root if nothing is found in the specified folders. While not necessary when using MiKTeX, these are absolutely required when using TeX Live (otherwise, the current folder isn't searched and files in root folder won't be found)!

Recursing through directories with many files can be pretty slow: you should consider faster alternatives (e.g. registering your own root directory) as described and recommended in MiKTeX's manual. But this is certainly not a WinEdt issue...

Alternative method

WinEdt's Macro Manual (among other things) explains how to use the SetEnvVar and GetEnvVar macro functions, should you require more information. And instead of using the Variables interface of the Execution Modes dialog, it is possible to add code directly to WinEdt's Local Startup macro (accessible through the Advanced -> Event Handlers section of the Options Interface):

  SetEnvVar("BIBINPUTS",".;C:/MyTeXFiles/Bib;");
  SetEnvVar("TEXINPUTS",".;C:/MyCurrentTeXProject;C:/MyTeXFiles/"+"/;");

After adding the above lines to WinEdt's Local Startup macro, execute the command Run Startup Macro from the Macros menu. That's all. If you now launch a compilation from WinEdt, the accessories will use the modified variables.

When in doubt about the value of any environment variable, you can use the command Define and Run Macro found in the Macros menu and execute the macro:

  Prompt("%@('Environment Variable');");

Note: This is where WinEdt's involvement with environment variables ends (you can set and inspect them through WinEdt's macros or through this interface). The meaning of such variables is described in the documentation that comes with your accessories or TeX System (e.g. MiKTeX's manual). Whether or not they work as you expect depends on your TeX System (but not on WinEdt!). Contrary to what many users believe, neither WinEdt's nor the Windows PATH variable have anything to do with where TeX is searching for its input files!

WinEdt displays crucial information about your TeX System and accessories in this page. If you encounter problems with launching a certain accessory, this report can be used to see if the application is installed and if it can be found. If the problem is only with detecting the executable, then the information in the Troubleshooting section should guide you in manually fixing the problem. If, on the other hand, the executable can be located but it does not run properly, it means that there are some problems with it (or your document source) outside WinEdt. WinEdt cannot detect and fix this kind of problem and you'll have to consult the documentation pertaining to that accessory or TeX System.

If WinEdt cannot find any trace of your TeX System or other accessories, it is likely that they are not properly installed. Reinstalling the problematic software and restarting WinEdt after that might be by far the best way to resolve the situation. This allows for smooth upgrades while manual corrections may have to be maintained when you upgrade your TeX System or accessories such as Ghostscript or Adobe Reader.

If a problem with any external accessory appears all of a suddenly, the reason is almost certainly that your registry no longer contains the required information that would allow WinEdt to automatically detect the application. This can happen if you performed a registry cleanup to remove a virus or correct some other problem. Registry keys may also get "lost" during Windows upgrades or major updates and, in some cases, during software installation or removal...

In such a case, reinstalling the problematic accessory and letting its installer update the registry might be the easiest way to fix the problem. It is important that you use a power (or administrator) account when installing applications: otherwise the registry update may fail due to access restrictions. If you are not an experienced user, let the programs install with their defaults and allow the application (such as Adobe Reader) to start after successful installation. WinEdt has to be restarted before it can properly detect newly installed accessories. Reinstalling WinEdt is not necessary and does not improve detection of external applications (although, for some reason, this is exactly what many users try first)...

If you are not sure whether or not an application or a TeX System has been successfully installed, check the Windows Start menu. You should be able to launch it from there!

Below is an example of a healthy MiKTeX installation. No manual corrections were required and all accessories are detected on the PATH or in Windows registry. Note that WinEdt detected MiKTeX's bin folder, Ghostscript's bin folder and inserted its own root folder to its private PATH, which is also used by applications launched from within WinEdt. If your report significantly differs from this one, you should consider reinstalling the problematic accessories or your TeX System. In particular, if some executables are missing, you have no choice but to (re)install them. MiKTeX users can use the MiKTeX Package Manager to install additional components (assuming that the core of the MiKTeX System is properly installed).

  --------------------------------------------------------------------------------

  File: "C:\Users\xxx\AppData\Roaming\WinEdt Team\WinEdt 10\TeX.log"
  Date: Monday, May 7, 2018  13:49

  Summary :-)
  ===========

  Your TeX installation appears to be fine. If you experience problems after an
  application has been launched this usually isn't a WinEdt-related matter. In such
  case, you should test a problematic application from the Command Prompt, consult
  the documentation that comes with your (TeX) software, and try to locate the real
  source of your problem...
  ________________________________________________________________________________

  WinEdt 10  (v. 10.3)  [Build: 20180507 - 64-bit

  Caption: WinEdt 10.3
  Default Mode: TeX
  Default Type: .tex
  Default Path: %P

  *** Account (UAC) Status: Restricted User
  *** Configuration: Default:MiKTeX
  *** TeX System: MiKTeX
  *** User Profile: Enabled
  *** %B: C:\Program Files\WinEdt Team\WinEdt 10
  *** %b: C:\Users\xxx\AppData\Roaming\WinEdt Team\WinEdt 10

  *** WinEdt  PATH:
  "C:\Program Files\WinEdt Team\WinEdt 10;
   C:\Program Files\MiKTeX 2.9\miktex\bin;
   C:\texlive\2016\bin\win32;
   C:\Program Files\Embarcadero\RAD Studio\14.0\bin;
   C:\Users\Public\Documents\RAD Studio\14.0\Bpl;
   C:\Windows\system32;
   C:\Windows;
   C:\Windows\System32\Wbem;
   C:\Windows\System32\WindowsPowerShell\v1.0\;
   C:\Program Files\MiKTeX 2.9\miktex\bin;
   C:\Users\xxx\AppData\Roaming\MiKTeX\2.9\miktex\bin\"

  *** Windows PATH:
  "C:\texlive\2016\bin\win32;
   C:\Program Files\Embarcadero\RAD Studio\14.0\bin;
   C:\Users\Public\Documents\RAD Studio\14.0\Bpl;
   C:\Windows\system32;
   C:\Windows;
   C:\Windows\System32\Wbem;
   C:\Windows\System32\WindowsPowerShell\v1.0\;
   C:\Program Files\MiKTeX 2.9\miktex\bin;
   C:\Users\xxx\AppData\Roaming\MiKTeX\2.9\miktex\bin\"

  ________________________________________________________________________________

  Searching for Executables:
  ==========================

  WinEdt will try to locate external executables based on the PATH Environment
  Variable and Windows Registry. If some components are not found follow the
  instructions. Some applications such as, for example, GS or GSView are optional;
  you can safely ignore any messages about the "missing" accessories that you are
  not intending to use...


  TeX-Root: OK
    C:\Program Files\MiKTeX 2.9
  TeX-Bin:  OK
    C:\Program Files\MiKTeX 2.9\miktex\bin

  TeX-Help Folder: OK
    C:\Program Files\MiKTeX 2.9\doc

  DVIView: OK (PATH yap.exe)*
    C:\Program Files\MiKTeX 2.9\miktex\bin\yap.exe

  TeX-Bin (TeX.exe): OK*
    C:\Program Files\MiKTeX 2.9\miktex\bin\tex.exe
  TeX-Bin (LaTeX.exe): OK*
    C:\Program Files\MiKTeX 2.9\miktex\bin\latex.exe
  TeX-Bin (PDFTeX.exe): OK*
    C:\Program Files\MiKTeX 2.9\miktex\bin\pdftex.exe
  TeX-Bin (PDFLaTeX.exe): OK*
    C:\Program Files\MiKTeX 2.9\miktex\bin\pdflatex.exe
  TeX-Bin (BibTeX.exe): OK*
    C:\Program Files\MiKTeX 2.9\miktex\bin\bibtex.exe
  TeX-Bin (dvips.exe): OK*
    C:\Program Files\MiKTeX 2.9\miktex\bin\dvips.exe
  TeX-Bin (ps2pdf.exe): OK*
    C:\Program Files\MiKTeX 2.9\miktex\bin\ps2pdf.exe
  TeX-Bin (dvipdfmx.exe): OK*
    C:\Program Files\MiKTeX 2.9\miktex\bin\dvipdfmx.exe
  TeX-Bin (mf.exe): OK*
    C:\Program Files\MiKTeX 2.9\miktex\bin\mf.exe
  TeX-Bin (mpost.exe): OK*
    C:\Program Files\MiKTeX 2.9\miktex\bin\mpost.exe

  MiKTeX-Bin (TeXify.exe): OK*
    C:\Program Files\MiKTeX 2.9\miktex\bin\texify.exe

My question is: Should I put the PATH in WinEdt or in Windows? Or in ConTeXt? 

$TEXROOT/tex/texmf-$ARCH/bin/lib/luametatex/zint

Many thanks

Uschi