As you are starting to read about compiling/interpreting, you should know that programmers usually count from 0 instead of 1 -- that's why the number of this section is 4.0 instead of 4.1 :) But let's proceed.
So, you want to compile or run something using NppExec. Great, that's the purpose of this plugin. But, before you start to do it, you must understand the principles of NppExec. Let's refer to the section [1.3] of this manual:
NppExec is not a compiler. NppExec allows you to use external tools and compilers to process/compile your current file, but it has no ability to do it by itself. No magic here :)
This is the basic idea of advanced usage of NppExec. Whatever source file you want to compile or run - whether it be C, or C++, or Java, or Python, or Perl, etc., etc. - you always need to specify two things:
If you specify only WHAT to compile or run, NppExec will tell the system exactly the same: run this file. And the system most likely will answer: I don't know how to run this file.
If you specify only WHO will do it, NppExec will run the specified interpreter/compiler - but it will not interpret/compile anything because you did not specify WHAT to interpret or compile.
Let's repeat it again: NppExec itself does not know anything about your source file and does not make any assumptions regarding it. NppExec just does exactly what you tell it to do - and that's all.
OK, but you may ask: why, for example, when I'm double-clicking my GhostScript file (or NSIS file, or Python file, or JavaScript file, whatever) in Windows Explorer, it becomes to be executed - but it does not happen in NppExec? The system seems to know how to run the file, right? - so why isn't it executed from within NppExec?
The answer is simple: double-clicking a file in Windows Explorer is not the same as trying to run this file directly. Let me explain: when you double-click a file, Windows Explorer tries to run it using the system file associations. For example, when you double-click a .doc or .docx file, Windows Explorer detects that this file is associated with Microsoft Office - and asks Microsoft Office to open this file. In the same way, if Python files are associated with some Python IDE, Windows Explorer will try to run or open these file using Python IDE.
On the other hand, when you want NppExec to run a file, it tells the system: run this file as if it can be executed by itself (without any associated program). That's the difference. The system file associations are not used in this case.
But NppExec also has the ability to run a file using the system file associations. I'm talking about "NPP_RUN <file>". In this case NppExec will tell the system: run this file using the system file associations. It will have the same effect as double-clicking in Windows Explorer. The very same effect - so you will not have any output in NppExec's Console because the file will not be executed inside the Console in this case. Refer to the section [3.3] for more details.
Now I guess it's time to rephrase the basic idea of advanced usage of NppExec:
Let's name the WHAT thing as <file> (because it's your source file) and the WHO thing as <tool> (because it's the tool which will interpret or compile your file). According to this, you need to specify the following generic command to interpret/compile/run any source file:
<tool> <file> <arguments>
We have one additional thing here: <arguments>. This thing refers to the tool-specific command-line arguments which may (or may not) be needed to interpret/compile/run the source file. I can't give you more information here because this part really differs for different compilers/interpreters. You need to read the compiler/interpreter's documentation regarding this. In some cases you may need to specify additional arguments before the source file name:
<tool> <arguments> <file>
Phew! It was a long way so far, isn't it? ;) But let's proceed.
Now you already have (or at least I hope so) a general vision regarding what's needed to interpret/compile/run your source file.
Let's take into account one more thing: NppExec is NOT cmd.exe. NppExec allows you to run something and see the console output, but it is NOT a system's command interpreter (cmd.exe) itself and DOES NOT invoke cmd.exe if you did not call it explicitly. (Note: NppExec ver. 0.6 RC3 introduces a new advanced option "ChildProcess_RunPolicy" that allows to modify this behavior. Refer to [4.4] for more details.) Thus you may encounter different behaviour of NppExec's Console and the system's console (cmd.exe). Refer to the section [1.3] for more details.
Anyway, you can "ask" cmd.exe to do something for you by calling it from NppExec explicitly. Refer to the section [4.4] for more details.
So, what's next? Did I tell you everything you need or is there something left? Maybe, enough talking - and let's see some examples? Yes, let's have some practice.
So, you want NppExec to do something. You open NppExec's Console and type: "something". Then you press Enter. Here is what you see in the Console:
something CreateProcess() failed with error code 2: The system cannot find the file specified.
What the hell happened? Help!
Let's analyze. You tried to run "something". What is "something"? It seems to be an executable file because you specified it without extension. And what do you have as result? You have "The system cannot find the file specified". So, nothing magical: you tried to run a file which does not exist.
Let me write some comments here. When you type "something" and press Enter, it means the following: run an executable file "something" ("something.exe") from current directory or a directory mentioned in %PATH%. This is what the system tries to do. And if you do have "something.exe" in the current directory or somewhere in %PATH%, this file ("something.exe") will be executed and you will not have the error code 2.
You can have the very same error when the name of an executable was specified incorrectly. For example:
%systemroot%\notepad.exe CreateProcess() failed with error code 2: The system cannot find the file specified.
What the hell happened? Help!
As I already wrote, NppExec is NOT cmd.exe. What does it mean? It means that NppExec, in particular, does NOT know what is %systemroot%. But cmd.exe knows it, right? So you can type the following:
cmd /c %systemroot%\notepad.exe
and Notepad will be run for you by cmd.exe (while cmd.exe itself is executing in NppExec).
I hope these basic examples were useful, but our goal is to compile/interpret/run something, isn't it? So we want to see an example of something like "<tool> <file> <arguments>", don't we?
OK, let's take some source file and try to run it. As I said, we could take any source file - it does not matter what language you are using. But, just for the example purposes, let's assume we have an .awk file with the following text:
BEGIN {
print "Hello!"
}
Did you hear something about AWK or do you know something about it? No? That's great, because NppExec also does not!
Now I want to repeat: it does not matter what language you are using - it could be Pascal, Java, PHP, Ruby and so on, and so on - but the principle remains the same. NppExec DOES NOT know anything about this language and DOES NOT make any assumptions regarding it. You should exactly specify WHAT to interpret/compile/run (the source file) and WHO will do it (the interpreter/compiler).
So, we are assuming we have an opened file "program.awk" with the following text:
BEGIN {
print "Hello!"
}
and we want to run it. Right now we are able to specify WHAT we want to run: it's our source file "program.awk". Notepad++ and NppExec provide the following variables which contain the current file name:
Now, if you type "$(FULL_CURRENT_PATH)" and press Enter in NppExec's Console, you will see something like the following:
$(FULL_CURRENT_PATH) C:\Documents and Settings\User\My Documents\program.awk CreateProcess() failed with error code 193
If you search Google (or Bing, whatever) for "error code 193", you will find the following description: "%1 is not a valid Win32 application". This is exactly what we have discussed before: the system does not know how to run this file. So, it's our responsibility to specify a valid compiler/interpreter which is able to run it.
In our case of an .awk file, we should use ether GAWK or AWK95 interpreter. (In case of another file -- such as .cpp, .java, .php and so on -- you should use appropriate compiler/interpreter.) Let's assume you have downloaded the latest GAWK package and unpacked it to "C:\tools\GAWK". So the path to GAWK executable is "C:\tools\GAWK\gawk.exe".
Let's try to run it without parameters:
C:\tools\GAWK\gawk.exe Process started >>> Usage: gawk [POSIX or GNU style options] -f progfile [--] file ... (...) <<< Process finished.
So, what do we see? We see that we should specify "-f" between "gawk.exe" and the .awk source file.
Now let's try to run our file:
C:\tools\GAWK\gawk.exe -f $(FULL_CURRENT_PATH) C:\tools\GAWK\gawk.exe C:\Documents and Settings\User\My Documents\program.awk Process started >>> gawk: fatal: can't open source file `C:\Documents' for reading (No such file or directory) <<< Process finished.
What the hell happened? Help!
Well. If we look at the file pathname "C:\Documents and Settings\User\My Documents\program.awk", we can observe spaces there. What does it mean? According to default system behaviour, ALL file names with spaces should be enclosed in double quotes. Otherwise the system does not understand where is the end of file name and treats spaces as dividers between several file names.
So, let's try again:
"C:\tools\GAWK\gawk.exe" -f "$(FULL_CURRENT_PATH)" "C:\tools\GAWK\gawk.exe" -f "C:\Documents and Settings\User\My Documents\program.awk" Process started >>> Hello! <<< Process finished.
Success! We have successfully run our .awk program using gawk.exe. This illustrates our general principle which could be applied to ANY language: specify WHAT to run (the source file) and WHO will run it (the interpreter or compiler). Additional argument ("-f" in our case) included.
The path to the interpreter was also enclosed in double quotes because, in general, it also may contain spaces. Thus I'd recommend to always enclose paths to interpeter/compiler and source file in double quotes.
Phew!.. Are you still here, with me? ;)
What else to say?.. Not much, actually. Often it's better to write some NppExec's script [3.7] for running/compiling purposes, because a lot of actions (commands) may be required for this. You can see several examples under the sections [4.6] and [4.7].
And here is one more useful advice. Starting from NppExec v0.4.2, you can use run-time variables in your command aliases. For example, you can define the following alias:
npe_cmdalias g = "C:\tools\GAWK\gawk.exe" -f "$(FULL_CURRENT_PATH)"
Once you did it, you can type just "g" to run your current file using gawk.exe. Type "help npe_cmdalias" in NppExec's Console to learn more about the command aliases.