Can I know what are the differences between each Exec, ExecWait, ExecShell, nsExec::Exec, nsExec::ExecToLog, nsExec::ExecToStack, ExecDos and ExecCmd, as in when to use which?
I 've posted the various execute calls I know. I am trying to make a comprehensive list, so that it helps future visitors..
Exec: Plainly execute the called string, be it some application, console or file.
ExecWait: Executes like Exec but waits till the process exits.
ExecShell: What is it for?
nsExec::Exec: Just like Exec or ExecWait but only for command prompt and that too without opening the console window. I am unsure if it waits for process to exit. Does nsExec::Exec wait for child process to exit?
nsExec::ExecToLog: The documentation says ExecToLog is similar to plain nsExec but it outputs to log window. What does that mean, what is a log window?
nsExec::ExecToStack: The documentation says ExecToStack is similar to plain nsExec but it pushes output to stack. I get that.
ExecDos: Same as nsExec::ExecToStack but it additionally (Is it not?)
a. takes string parameter that serves as stdin for running application.
b. works in both sync/async mode.
c. it works out of section - for .onInit check outs.
ExecCmd: Same as ExecDos but it doesn't require these
ExpandEnvStrings $3 %COMSPEC%
ExecDos::exec /C
parts. Am I correct?
1) 2) 3)
Exec and ExecWait use CreateProcess internally and can only start programs and batch files.
ExecShell uses ShellExecute which means that it can also launch any registered filetype (.txt .chm etc) and URLs. It should also be used if the program you are starting needs to elevate with UAC.
4)
nsExec redirects stdout so a console window is not visible when the child process executes. And yes, it waits.
5)
The log window on the instfiles page.
7)
Yes, both ExecDos and ExecCmd are more advanced versions of nsExec.
8)
Correct
ExecWait waits and thus can return stuff! docs.
ExecShell is also able to hide the output window. docs
ExecCmd is considered outdated and superseded by ExecDos. both are extra plugins for NSIS that are not shipped by default. docs
Related
Program called to run via wine within a node.js script freezes as soon as it starts to do it's task.
This is the top output:
It runs fine and display the cli's header if I call it without parameters.
But if use it with arguments it hangs as soon as it starts to display progress and continuous stdout (eg: the ones where the only thing that is updated in the screen is the percentage of the current task)
Tried with exec, execSync, spawnSync, spawn.
Also tried to spawn and spawnSync a .sh file calling it (with and without & disown)
I think it has something to do with some child_process or even environment limitations, because I was able to do it by calling wine from a new gnome-terminal with parameters. But then I get an extra terminal window popping up, and no control whatsoever about the task conclusion.
Does anyone have a solution or a workaround for this?
It was related to stdio
No idea why, but setting
{stdio: ['inherit', 'pipe', 'pipe']} to .spawn() for Ubuntu and OSX did the trick.
I am on windows machine, when I temporarily change to console using :sh then back to vim with exit command and then again back to console and it starts over. this causes me to lose my previous directory. Is there other way returning back to vim won't start the shell over?
Not really
https://stackoverflow.com/a/12089631/1427295
GVIM does not retain a "handle" to the shell that launched it in a way
that allows it to send commands back to it. Because of they
synchronous execution, you also cannot launch a shell from GVIM, keep
feeding it commands while also continue working in GVIM.
I'm afraid you have to use the functionality of your window manager to
launch (and then later re-activate) a shell window, and send the
commands as keystrokes to it. On Windows, this can be done (e.g. in
VBScript) via WshShell's Run(), AppActivate() and SendKeys() methods;
there are probably similar mechanisms for window control on Linux,
too.
If you don't mind having that shell inside your GVIM (emulated, with
all its drawbacks), though, there are plugins that enable that.
https://serverfault.com/a/95405
The Windows command interpreter ("cmd.exe") doesn't provide any
support for saving/exporting/keeping history, of, if it does,
Microsoft didn't document it and nobody was ever able to find it. You
can of course try to work around that, like Sean suggested, but
there's (or does appear to be) no built-in support for this
You may be able to output your command history using echo %cd% > prev_dir.txt then create a script that cds to the directory in prev_dir.txt, but you'd still have to remember to save your directory to the file before you exit the shell each time.
I have an installer working with NSIS that I'm updating at the moment. At several points, the installer needs to configure packages by replacing paths or values inside configuration files. Those configuration files have placeholders in them that are replaced by whichever deployment tool I'm using (NSIS for this specific case).
Scripts are mostly PHP scripts written to do some simple tasks that would have been excruciatingly complex in NSIS. For some reason though I keep going back to making my PHP scripts replace the placeholders by themselves instead of doing it in the NSIS script, which just isn't right.
My code looks like:
nsExec::ExecToStack '"$INSTDIR\Php\php.exe" "$INSTDIR\Apache\tools\findport.php"'
pop $1 ; return code
pop $2 ; port number
!insertmacro _ReplaceInFile "Apache\conf\httpd.conf" "APACHE_PORT" "$2"
The _ReplaceInFile macro comes from http://nsis.sourceforge.net/ReplaceInFile and works just fine if I use $INSTDIR instead of $2 in the above example. Showing $2 in a MessageBox shows the port number just fine.
I guess I'm doing something wrong but I can't figure out what it is, and debugging is a pain with NSIS.
Thanks,
I guess the lesson is to always verify paths before blaming the utility functions (Using Process Monitor is a good idea so you can tell if file-system redirection is getting in the way)
I would also like to add that using $instdir to hold anything other than a path is not a good idea since it will strip away invalid path characters behind your back. Use a normal register or a custom variable...
I've noticed that sometimes commands can be tab completed.
e.g. the xm command in xen.
you type xm[space][tab] and it prints out the valid options
which are:
addlabel destroy info network-attach resume sysrq vnet-delete
block-attach dmesg labels network-detach rmlabel top vnet-list
block-detach domid list network-list save trigger vtpm-list
block-list domname loadpolicy new sched-credit unpause
cfgbootpolicy dry-run log pause sched-sedf uptime
console dump-core makepolicy reboot serve vcpu-list
create dumppolicy mem-max rename shutdown vcpu-pin
debug-keys getlabel mem-set resources start vcpu-set
delete help migrate restore suspend vnet-create
That's pretty slick!
How can I implement my own tab command completion in Linux?
This is a pretty broad question, but the general idea is that you register something with the either the compgen or complete builtin. They're both documented in the manual. The previous section documents the general topic of programmable completion, going through how completion attempts are processed.
For a whole ton of examples, see /etc/bash_completion, which provides all the default completion that comes with bash (beyond the totally built-in stuff like filename completion). For even more examples, see anything in /etc/bash_completion.d; those are automatically sourced by /etc/bash_completion as a way of extending the default completion.
This is done via the shell through the use of the GNU Readline library in the case of bash
bash's smart completion is handled by a series of scripted bash functions. On Debian, probably Ubuntu, and maybe other Linux distributions, you can find your system's installed completions in /etc/bash_completion.d.
The official documentation on this mechanism is at http://www.gnu.org/software/bash/manual/bash.html#Programmable-Completion
See this:
How does bash tab completion work?
and this:
http://www.debian-administration.org/articles/316
I have an linux app that uses cups for printing, but I've noticed that if I print and then quit my app right away my printout never appears. So I assume that my app has to wait for it to actually come out of the printer before quitting, so does anyone know how to tell when it's finished printing??
I'm using libcups to print a postscript file that my app generates. So I use the command to print the file and it then returns back to my app. So my app thinks that the document is off to the printer queue when I guess it has not made it there yet. So rather than have all my users have to look on the screen for the printer icon in the system tray I would rather have a solution in code, so if they try and quit before it has really been sent off I can alert them to the fact. Also the file I generate is a temporary file so it would be nice to know when it is finished with so I can delete it.
As soon as your CUPS web interface (localhost:631) or some other thing to look at what CUPS sees shows you that CUPS received the job, you can quit the application.
How about using a print spool service like lpr & lpq?
You certainly do not need to wait till the paper is out of the printer. However, you need to wait until your temporary file is fully received by cupsd in its spooling aerea (usually /var/spool/cups/).
If you printed on the commandline (using one of the CUPS lp or lpr commands) you'd know the job is underway if the shell prompt returns (the command will even report the CUPS job ID for the job sent), and if the exit code ($?) is 0.
You do not indicate which part of libcups and which function call you are using to achieve what you want. If I'd have to do this, I'd use the IPP function cupsSendRequest and then cupsGetResponse to know the result.
Your app likely hadn't finished printing yet when you quit it. If you're using evince to print a PDF or other document, this is a known bug--there is no visual confirmation that the printing operation is underway. If the print job has been submitted, a printer icon will appear in your system tray until the actual printing has finished. You can click on the printer icon in the system tray and see what jobs are currently running and pending.