I would like to make my installer silent. I would like to have flexibility to make installer silent or not depending on a command line option. In doc, I have found this to launch NSIS script compilation:
"C:\Program Files\NSIS\makensis.exe" "D:\Produts\folder\Install\nsis\MyApp.nsi"
this is working. By default, this is generating a non silent installer. To have a silent installer (with a command line option only), i tried this
"C:\Program Files\NSIS\makensis.exe" \S "D:\Produts\folder\Install\nsis\MyApp.nsi"
but \S is not a recognized option. How can i make installer silent with command line option?
I can find this in doc
4.8.1.36 SilentInstall
normal|silent|silentlog Specifies whether or not the installer should
be silent. If it is 'silent' or 'silentlog', all sections that have
the SF_SELECTED flag are installed quietly (you can set this flag
using SectionSetFlags), with no screen output from the installer
itself (the script can still display whatever it wants, use
MessageBox's /SD to specify a default for silent installers). Note
that if this is set to 'normal' and the user runs the installer with
/S (case sensitive) on the command line, it will behave as if
SilentInstall 'silent' was used. Note: see also LogSet.
See section 4.12 for more information.
so that i feel abused
Or should some instruction be added to NSIS script, so that compilation is receptive to /S option ?
Tried it with -S and not working either.
Thanks and regards
/S option is available for your installer, not the makensis.exe. So you can run the installer in silent mode from commandline:
MyApp.exe /S
In case you want to build installer to be always silent, you can use following technique:
In the .onInit function:
Function .onInit
!ifdef IsSilent
SetSilent silent
!endif
FunctionEnd
And then build the installer with /D option to define the IsSilent constant:
makensis.exe /DIsSilent MyApp.nsi
That means, in case you build with /D option like above, the installer will be always silent; without /D option your installer will be non-silent by default and still you can run it from commandline MyApp.exe /S to be silent.
If you want to COMPILE the NSI script silently from a command line, that is not the same as having the installer run silently.
In my compile batch scripts, I use:
c:\progra~1\nsis\makensis /V0 .\sample.nsi | findstr /b /r /c:"YouCantFindMe"
The /V# option suppresses all output but still includes a ribbon/banner when the compiler starts (see NSIS command line option documentation. Piping all output through "findstr" suppresses that output as well.
Related
So, I want to make a script that will execute 2 .bat files and start some .exe files.
However, the .bat files are supposed to keep running.
I have something like this :
pushd tools\wamp64
start wampmanager.exe
pushd ..\..\server\login
call startLoginServer.bat
pushd ..\test
call startTestServer.bat
start "C:\DEV\P2\Test\client" P2.bin
The problem is that call startLoginServer.bat will not exit and therefore, I'm stucked here.
How can I run my 2 .bat files and let them keep running.
(Ideally, I want them to run in 2 different command prompt windows)
Also, there is probably a better way to handle relative path than using pushd if you can correct me on this.
Thanks
You could use:
start "Wamp Manager" /B /D "%~dp0tools\wamp64" wampmanager.exe
start "Login Server" /B /D "%~dp0server\login" startLoginServer.bat
start "Test Server" /B /D "%~dp0server\test" startTestServer.bat
start "Text Client" /B /D "%~dp0" "C:\DEV\P2\Test\client.exe" P2.bin
Run in a command prompt window start /? for help on this command explaining the options.
"..." ... title for new console window which is optional, but must be often specified on program to start is or must be enclosed in double quotes. The START command in last command line in batch file code in question interprets C:\DEV\P2\Test\client as window title. It is also possible to use an empty window title, i.e. "" which is best if the started application is a Windows GUI application on which no console window is opened at all.
/B ... run without opening a new window, i.e. in "background". This option can be omitted to see what the started applications and batch files output to console if the executables are not Windows GUI applications.
/D "..." or also /D"..." defines the directory to set first as current directory before running the command specified next. %~dp0 references the directory of the batch file containing these commands. This path always ends with a backslash. Therefore no backslash must be added on concatenating the directory of the batch file with a file or folder name or path.
Run in a command prompt window call /? for help on %~dp0 explaining how arguments of a batch file can be referenced from within a batch file.
See also the answer on How to call a batch file that is one level up from the current directory? explaining in total four different methods to call or run a batch file from within a batch file.
Finally read also the Microsoft documentations about the Windows kernel library function CreateProcess and the structure STARTUPINFO used by cmd.exe on every execution of an executable without or with usage of its internal command start. The options of start become more clear on having full knowledge about the kernel function and the structure used on Windows to run a program.
I'm trying to run a daemon in the scala console in the background. I can get it to run the program but it locks the console window when it is running, and therefore forces me to use a separate window to stop the daemon to unlock the original console. I'm running the scala console in a windows powershell through sbt.
I can use the command prompt to successfully run the program in the background using: start /b program, but running ("start /b program").! in the scala console fails.
This will run the program in scala console but will lock the window:
("cmd /c start program").!
How can I get the program to successfully run in the background so I still have access to the current console?
I've been fiddling with /E:ON using /b as an extension of start to no avail.
These are results from cmd /?
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\>cmd /?
Starts a new instance of the Windows XP command interpreter
CMD [/A | /U] [/Q] [/D] [/E:ON | /E:OFF] [/F:ON | /F:OFF] [/V:ON | /V:OFF]
[[/S] [/C | /K] string]
/C Carries out the command specified by string and then terminates
/K Carries out the command specified by string but remains
/S Modifies the treatment of string after /C or /K (see below)
/Q Turns echo off
/D Disable execution of AutoRun commands from registry (see below)
/A Causes the output of internal commands to a pipe or file to be ANSI
/U Causes the output of internal commands to a pipe or file to be
Unicode
/T:fg Sets the foreground/background colors (see COLOR /? for more info)
/E:ON Enable command extensions (see below)
/E:OFF Disable command extensions (see below)
/F:ON Enable file and directory name completion characters (see below)
/F:OFF Disable file and directory name completion characters (see below)
/V:ON Enable delayed environment variable expansion using ! as the
delimiter. For example, /V:ON would allow !var! to expand the
variable var at execution time. The var syntax expands variables
at input time, which is quite a different thing when inside of a FOR
loop.
/V:OFF Disable delayed environment expansion.
You should use forking in SBT, that's exactly what it is for.
For your case set this setting in your SBT build:
fork in run := true
By default stdin will not be connected to your forked process, to enable it do:
connectInput in run := true
Figured it out thanks to #som-snytt's link to #michael.kebe's answer on this SO entry: How does the “scala.sys.process” from Scala 2.9 work?
val pb = Process("""program""").run
Does exactly what I wanted
I have a program which requires Administrative privileges that I want to run from a batch file. What command can I run from command line will run my program with administrative privileges? I'm okay with the pop-up window asking for permission. Additionally, the file needs to be able to run from anywhere on a computer so additional files are run from ./src. The problem is that if I right-click and choose "run as administrator" it changes my current directory so ./src no longer works. If I disable UAC on my machine then everything runs fine. Thank you!
Look here: https://superuser.com/a/269750/139371
elevate seems to be working, calling
C:\Utils\bin.x86-64\elevate.exe -k dir
executes dir in the "current directory" where elevate was called.
This is tough, Microsoft provides no utility to do this (mostly because giving a batch file that ability breaks security), except for RunAs, and that requires that the Administrator account be activated.
There IS a JScript program that can do something similar, by using SendKeys to open the Start menu and type cmd[CTL]+[SHIFT]+[ENTER] which will launch a Command-Line shell.
Save the following as as .js file, like StartAdmin.js:
var WshShell = WScript.CreateObject("WScript.Shell");
WshShell.SendKeys("^{esc}cmd^+{ENTER}"); The equivilent of [CTRL]+[ESC] cmd [CTRL]+[SHIFT]+[ENTER]
To run StartAdmin.js from a batch file, you will need the following line:
wscript StartAdmin.js
To launch from a particular directory and launch a batch file, change line 2 in StartAdmin.js to something like:
WshShell.SendKeys("^{esc}cmd /C "cd %userprofile% & batchfile.bat"^+{ENTER}");
/C switch tells it to run the commands, then close the command-line window.
/K would leave the command window open after it exited the batch file.
To help you understand the SendKeys commands:
+=[Shift Key]
^=[Control Key]
{esc}=[Escape Key]
{enter}=[Enter Key]
To learn more about using CMD.EXE, type CMD /? at the command prompt.
This is a very untidy and ugly way to do it, but it's the only way I know how using only the tools that come with Windows.
Is there a command line syntax in which returns the Image Path / Location of the *.exe on the task manager?
I'm using Windows XP Professional Service Pack 3, I'm aware of the tslist(tasklist) command, but I only get all running *.exe files.
There is no way from XP's Task Manager to get this info (Vista on up, however, can show this info). Other apps, like MS/SysInternals' "Process Explorer" GUI can show you the full path of all exe's.
Alternatively, a built-in process called WMIC, which uses WMI, can give you this info as in Ramesh's answer:
WMIC PROCESS get Caption,Commandline,Processid
Or, to output to a file and not the command prompt window:
WMIC /OUTPUT:C:\ProcessList.txt PROCESS get Caption,Commandline,Processid
Note: the command prompt will need to have admin rights to launch WMIC.
The commands above will show you output like the following, which includes the PID, process name, full path, and switches passed to the command:
Caption CommandLine
ProcessId
System Idle Process
0
helpctr.exe "C:\WINDOWS\pchealth\helpctr\binaries\helpctr.exe" -mode hcp://system/sysinfo/msinfo.xml
4852
helpsvc.exe "C:\WINDOWS\PCHealth\HelpCtr\Binaries\HelpSvc.exe" /Embedding
1908
cmd.exe "C:\WINDOWS\system32\cmd.exe"
4308
cmd.exe "C:\WINDOWS\System32\cmd.exe" /k cd c:\ && color 71 & & title Admin Command Prompt - %username%
You can open the system information tool under Accessory/system tools to see the actual image path along with its PID.
This may be useful for you: http://www.raymond.cc/blog/determine-program-path-from-task-manager-for-each-program-in-windows-xp-windows-server-2003/
When I invoke my Perl scripts in the Windows environment without invoking perl first, the parameters are not passed to my script.
For example,
C:\> C:\my-perl-scripts\foo.pl bar
invokes foo.pl but doesn't recognize bar as a parameter (#ARGV is empty). However,
C:\> perl C:\my-perl-scripts\foo.pl bar
works as expected.
Is this a configuration issue?
Ideally, I'd like to be able to distribute some perl scripts, have the user add C:\my-perl-scripts\ to the path and then just be able to invoke foo.pl from anywhere while running cmd.
If they have to specify perl first, then they'll always have to give a complete path.
Any ideas or recommendations?
Edit: To show that the assoc and ftype are correct on my system, I executed the following commands.
C:\>assoc .pl
.pl=Perl
C:\>ftype Perl
Perl="C:\Perl\bin\perl.exe" "%1" %*
C:\>more t.pl
print "'$_'\n" for #ARGV;
C:\>t a b
C:\>perl t.pl a b
'a'
'b'
C:\>t.pl a b
C:\>
I included both the output of t and t.pl to show it's not a %PATHEXT% problem. Both outputted nothing as originally described whereas invoking perl first gave the expected response.
I'm not sure where to look next, but thanks for the suggestions so far. They have been very helpful.
Edit 2: The problem appears to be on my vista business box. On my xp pro box, it works as expected. Both have ActivePerl 5.8.9. I have another vista home box that I have not yet tried yet. I'll post back if I discover anything.
Edit 3: I found the answer (posted below). I found it by running a registry cleaner, removing perl, running the registry cleaner again. On 2nd cleaning, only one invalid entry remained - the one that was causing the problem (probably left over from a previous installation).
I found out what the problem was. Although the ftype and the assoc values were set as suggested, the actual behavior on my system seems to be determined by the registry key
HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command
It should have a (Default) string value of "C:\Perl\bin\perl.exe" "%1" %*
When I found this entry, it was set to "C:\Perl\bin\perl.exe" "%1". Changing it immediately fixed the problem.
Why it was set that way in the first place? I don't know. Maybe from a previous installation?
Anyway, thanks for the suggestions, and I hope this answer helps someone else, too.
Hmmm... sounds like the file association for *.pl is messed up somehow. I'm not on a Windows box, so I can't test this. You can check the file association stuff with either the ASSOC or FTYPE command on the command-line. IIRC, "ASSOC .pl" should tell you what the file type is and "FTYPE filetype command" tells the shell what to do with a Perl script. Try something like:
C:\> ASSOC .pl=perlscript
C:\> FTYPE perlscript=C:\Perl\bin\perl.exe %1 %*
From the looks of one of the command references that should do the trick. My guess is that the current association is not passing the parameters along to the script. You should be able to check that by using ASSOC .pl to figure out what the name of the file association is and then using FTYPE to print out the command that the shell is going to execute.
Update
I found an interesting thing that I want to note for posterity. I started seeing exactly this problem on a friends machine at work with respect to some Python scripts. ASSOC and FTYPE resulted in the expected output but the parameters were still not being passed along - exactly what was originally reported.
After a little digging, I found that the registry settings were created somewhere along the line as REG_SZ values. I deleted them and re-created them using ASSOC and FTYPE and everything started working... looking at the registry gave me the answer the new values were created as REG_EXPAND_SZ! These worked exactly as expected.
Update: Given that the following is correct, the only thing left to make sure is that command extensions are not turned off. Try:
cmd /e:on
on the command line before you run your tests. See also Windows XP cmd documentation:
Enabling and disabling command extensions
Command extensions are enabled by default in Windows XP. You can disable them for a particular process by using /e:off. You can enable or disable extensions for all cmd command-line options on a computer or user session by setting the following REG_DWORD values:
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\EnableExtensions\REG_DWORD
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\EnableExtensions\REG_DWORD
Set the REG_DWORD value to either 0x1 (that is, enabled) or 0x0 (that is, disabled) in the registry by using Regedit.exe. User-specified settings take precedence over computer settings, and command-line options take precedence over registry settings.
E:\Temp> assoc .pl
.pl=Perl
E:\Temp> ftype Perl
Perl="C:\opt\Perl\bin\perl.exe" "%1" %*
E:\Temp> #echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PL;.PLX;.WPL;.py;.pyw
E:\Temp> cat t.pl
print "'$_'\n" for #ARGV;
E:\Temp> t a b c d e f g h j
'a'
'b'
'c'
'd'
'e'
'f'
'g'
'h'
'j'
I have used pretty much every ActiveState Perl distribution since 2004. These settings are enough to make it work.
To sum up.
ftype is old and cmd.exe doesn't care whatever it says.
The real deal is the HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command thing.
Just run: reg add HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command /ve /d "C:\strawberry\perl\bin\perl.exe \"%1\" %*" /f
and everything will be ok. (* given that "C:\strawberry\perl\bin\perl.exe" is the exact path to your perl installation.*)
/ve is meant to work on de “(Default)” REG_SZ value
/d is to assign “data” to the “value”
/f to force substitution (or overwriting) of the preexisting value
In fact, if assoc .pl=Whatever and ftype Whatever doesn't exist (never assigning a value to it, or doing ftype Whatever= to unassign), the scripts could still be invoked without prepending perl.exe.
So, if using Windows >= 6.0 (Vista, 2008, 7, etc.) just forget that the commands assoc and ftype exist at all. Don't bother. Go reg.exe!
I tried updating and associating .pl with the many different PERL entries in the registry that others have tried (.pl, Perl, PerlScript, pl_auto_file, Applications\perl.exe) and none of these worked. I'm running AS Perl 5.14.2 on Windows 7. I then noted that there was an entry for \Applications\perl5.14.2.exe in the registry and it was set to:
"C:\Perl\bin\perl5.14.2.exe" "%1"
Added the %* to this and then I was able to see data in #ARGV.
I also noted that on some of these entries I had a command path entry of "C"\Perl64\..." from a previous 64 bit PERL that I'd installed earlier and uninstalled when I found out that 64 bit PERL isn't as nice with IIS 7 as 32 bit PERL is. So there are dangling installation remnants that are probably affecting things too.
So the answer here is probably not a short one and is in simple words... "It depends..." (on your system and installation).
After fixing file association problem could not pass parameters. A user I support mistakenly associated .pl file extension with notepad after trying to run script from (Windows 7 Professional) command line for first time. Tried all the file association tricks and environment variable fixes to no avail. Uninstalled and reinstalled and tried 32 bit and 64 bit installations. Issue was only present on users profile.
Finally went into the registry and simply deleted the key from
HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command
and added back via
reg add HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command /ve /d "C:\strawberry\perl\bin\perl.exe \"%1\" %*" /f
started passing parameters again Thanks "lucretius"
I found this additional location in the registry that had to be updated before it would work for me. Note: The name after HKEY_USERS may be different on your machine.
Add %* to default string:
HKEY_USERS\S-1-5-21-1399284159-2775065347-350672949-4058_Classes\pl_auto_file\shell\open\command
"D:\Perl\bin\perl.exe" "%1" %*
Original author answer works. Here's a complete registry file for manually installing PERL on Windows, just add to PATH environment variable: ";C:\PERL\bin;" and make a perl.reg file with notepad containing this:
Windows Registry Editor Version 5.00
[-HKEY_CLASSES_ROOT\.pl]
[HKEY_CLASSES_ROOT\.pl]
#="Perl"
"PerceivedType"="text"
[HKEY_CLASSES_ROOT\.pl\Perl]
[HKEY_CLASSES_ROOT\.pl\Perl\ShellNew]
[HKEY_CLASSES_ROOT\.pl\PersistentHandler]
#="{5e941d80-bf96-11cd-b579-08002b30bfeb}"
[HKEY_CLASSES_ROOT\Applications\perl.exe]
[HKEY_CLASSES_ROOT\Applications\perl.exe\shell]
[HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open]
[HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
[HKEY_CLASSES_ROOT\Perl]
[HKEY_CLASSES_ROOT\Perl\shell]
[HKEY_CLASSES_ROOT\Perl\shell\Open]
[HKEY_CLASSES_ROOT\Perl\shell\Open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
[HKEY_CLASSES_ROOT\pl_auto_file]
#=""
[HKEY_CLASSES_ROOT\pl_auto_file\shell]
[HKEY_CLASSES_ROOT\pl_auto_file\shell\open]
[HKEY_CLASSES_ROOT\pl_auto_file\shell\open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
[HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe]
[HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe\shell]
[HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe\shell\open]
[HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe\shell\open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
[-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pl]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pl]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pl\OpenWithList]
"a"="perl.exe"
"MRUList"="ab"
"b"="NOTEPAD.EXE"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pl\OpenWithProgids]
"pl_auto_file"=hex(0):
"Perl"=hex(0):
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl\shell]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl\shell\Open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl\shell\Open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\pl_auto_file]
#=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\pl_auto_file\shell]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\pl_auto_file\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\pl_auto_file\shell\open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
[HKEY_LOCAL_MACHINE\SOFTWARE\Perl]
#="C:\\PERL\\"
"BinDir"="C:\\Perl\\bin\\perl.exe"
I installed Perl 5.24.3 on Windows2016 and found the JAMS scheduler Agent Shell ignored the .pl extension as if it did not exist. All good from DOS desktop.
The same config on Winows2008 worked fine.
The registry entries created by that ActiveState Perl Install, matched Lucretius Post above, but do not apply globally to all users. Not the default system user for example.
Logging in as the user the Shell will run as, and making the association helped.
Ideally there would be a registry twig to make .pl assoc global ?