When I use a installation directory ending with backslash to install something in unattended mode on Windows system
example.exe -q --sys.installationDir="C:\Program Files\test\" ....
, nothing get installed without any prompt.
But when I remove the trailing backslash, it works correctly.
example.exe -q --sys.installationDir="C:\Program Files\test" ....
It's weird that the directory ending with backslash works well for GUI mode on windows system.
Is there any requirement that the installation directory can't end with backslash for unattended mode on Windows system?
Why are there different requirements for directory formats between unattended mode and GUI mode for windows system?
Do not quote like this:
param="value"
but like this:
"param=value"
Also, the command line option for setting the installation directory is "-dir":
example.exe -q - dir "C:\Program Files\test"
Related
I have an Ubuntu-18.04 WSL instance installed and have a large set of scripts installed in it at /home/username/bin/scripts.
I have also updated the $HOME/.bashrc, $HOME/.bash_profile, /etc/bash.bashrc, /etc/profile and /etc/environment files to update $PATH to include /home/username/bin/scripts in the path.
*I'm well aware i only usually need it in my $HOME/.bash_profile, lots of places from experimenting
Say I have a script called sampleScript in /home/username/bin/scripts, when i try to run the command:
wsl sampleScript
It gives the error: /bin/bash: sampleScript: command not found
If I open up wsl in interactive mode I can run it just fine, but I would like to be able to expose the script to not be run in interactive mode.
I've tried making an environment variable SPATH='/home/username/bin/scripts' and setting WSLENV=SPATH/p, but it also does not show up if i do wsl echo $PATH.
*I'm doing this all in command line instead of powershell b/c powershell doesn't appear to be able to do wsl echo $PATH at all, it just returns empty
I have also tried: wsl -u username sampleScript; with no luck
Is there a way to customize the PATH for wsl interop mode or am i doing something incorrectly with WSLENV?
I tried to run script in git bash command line and I saw:
"use: command not found"
When I changed sh file from
'./clean_translations.pl' to 'perl ./clean_translations.pl'
After that script works.
I have win 8.1. Path is as in other PC (win 7).
What should I change to works without 'perl'?
Edit: echo $PATH:
/c/Users/PBI/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin:/c/Users/PBI/bin:/c/usr/bin:/c/strawberry/c/bin:/c/strawberry/perl/bin:/c/straw
berry/perl/site/bin:/c/strawberry/c/lib:/c/strawberry/perl/site/lib:/c/strawberr
y/perl/lib:/c/Program Files (x86)/ActiveState Komodo IDE 8:/c/instantclient_12_1
:/c/Program Files/Java/jdk1.8.0_91/bin:/c/Program Files/Java/jre1.8.0_91/bin:/c/
Program Files (x86)/Intel/iCLS Client:/c/Program Files/Intel/iCLS Client:/c/Wind
ows/system32:/cmd:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/Window
sPowerShell/v1.0:/c/Program Files/Intel/Intel(R) Management Engine Components/DA
L:/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/DAL:/c/Prog
ram Files/Intel/Intel(R) Management Engine Components/IPT:/c/Program Files (x86)
/Intel/Intel(R) Management Engine Components/IPT:/c/Program Files (x86)/ATI Tech
nologies/ATI.ACE/Core-Static:/c/Program Files (x86)/GitExtensions:/bin:/mingw64/
bin:/usr/bin/vendor_perl:/usr/bin/core_perl
You need to use a shebang.
Add this as the first line of the script:
#!/usr/bin/env perl
This conveys that the script should be run using Perl interpreter.
If you are running the script on windows shebang is not parsed. The file extension(.pl) is used to decide the interpreter. In a bash shell shebang is necessary.
I want my Perl scripts to behave just like any other executable (*.exe file).
When I double-click on myscript.pl I want it to execute instead of opening in a text editor.
I want to run myscript.pl instead of perl myscript.pl.
I really want to run myscript instead of myscript.pl.
I want to run program | myscript instead of program | perl myscript.pl.
I want to be able to run my script via drag & drop.
There are a number of changes you have to make on Windows to make all of
these things work. Users typically stumble upon things that don't work one at
a time; leaving them confused whether they've made an error, there's a bug in
Perl, there's a bug in Windows, or the behavior they want just isn't possible.
This question is intended to provide a single point of reference for making
everything work up front; ideally before these problems even occur.
Related questions:
How do I make Perl scripts recognize parameters in the Win32 cmd console?
Running a perl script on windows without extension
Perl execution from command line question
How can I read piped input in Perl on Windows?
Perl on Windows, file associations and I/O redirection
How do I create drag-and-drop Strawberry Perl programs?
Note: The actions below require administrative privileges. For
steps utilizing the command prompt it must be launched via "Run as
administrator" on Windows Vista / Windows 7.
Associate *.pl files with perl
Run the following commands at a shell prompt:
assoc .pl=PerlScript
ftype PerlScript=C:\bin\perl.exe "%1" %*
Replace C:\Perl\bin\perl.exe with the path to your Perl installation. This
enables you to run myscript.pl instead of perl myscript.pl.
Default install locations are:
ActivePerl: C:\Perl
Strawberry Perl: C:\Strawberry
Add .PL to your PATHEXT environment variable.
This makes Windows consider *.pl files to be executable when searching your
PATH. It enables you to run myscript instead of myscript.pl.
You can set it for the current cmd session
set PATHEXT=%PATHEXT%;.PL
To set it permanently (under Windows Vista or Windows 7)
setx PATHEXT %PATHEXT%;.PL
Under Windows XP you have to use the GUI:
Right-click My Computer, and then click Properties.
Click the Advanced tab.
Click Environment variables.
Select PATHEXT, then click Edit.
Append ;.PL to the current value.
Make I/O redirection work
I/O redirection (e.g. program | myscript) doesn't work for programs started
via a file association. There is a registry patch to correct the problem.
Start Registry Editor.
Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
On the Edit menu, click Add Value, and then add the following registry value:
Value name: InheritConsoleHandles
Data type: REG_DWORD
Radix: Decimal
Value data: 1
Quit Registry Editor.
Warning: In principle, this should only be necessary on Windows XP. In my experience it's also necessary in Windows 7. In Windows 10 this is actively harmful—programs execute but produce nothing on stdout/stderr. The registry key needs to be set to 0 instead of 1.
See also:
STDIN/STDOUT Redirection May Not Work If Started from a File Association
Perl Scripts on Windows 10 run from Explorer but not Command Prompt
If patching the registry isn't an option running program | perl -S myscript.pl
is a less annoying work-around for scripts in your PATH.
Add a drop handler
Adding a drop handler for Perl allows you to run a Perl script via drag & drop;
e.g. dragging a file over the file icon in Windows Explorer and dropping it
there. Run the following script to add the necessary entries to the registry:
use Win32::TieRegistry;
$Registry->Delimiter("/");
$perlKey = $Registry-> {"HKEY_CLASSES_ROOT/Perl/"};
$perlKey-> {"shellex/"} = {
"DropHandler/" => {
"/" => "{86C86720-42A0-1069-A2E8-08002B30309D}"
}};
Convert your perl scripts into batch files using pl2bat once they are ready to be run by users.
The trick works through the perl -x switch which, according to perldoc perlrun, makes Perl search for the first line looking like #!.*perl.
After following the instructions in the accepted answer, a double click still led to .pl files opening with Notepad in Windows 10 — even when perl.exe was set as the default file handler.
After finding Jack Wu's comment at ActivePerl. .pl files no longer execute but open in Notepad instead I was able to run perl scripts on double-click as such:
Select and right-click a .pl file
Use the "Open With" submenu to "Choose another app"
Select "Always use this app to open .pl files" (do this now – you won't get the chance after you have selected a program)
Scroll to the bottom of the "Other options" to find "More apps", and select "Look for another app on this PC"
Navigate to C:/path/to/perl/bin/ and select Perl5.16.3.exe (or the equivalent, depending on which version of Perl you have installed: but not Perl.exe)
Then the Perl icon appears next to .pl files and a double-click leads to them opening in Perl every time, as desired.
I tried the assoc and ftype methods and they didn't work for me.
What worked was editing this registry key:
Computer\HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe\shell\open\command
It was set to:
"C:\Perl64\bin\perl.exe" "%1"
When it should be:
"C:\Perl64\bin\perl.exe" "%1" %*
It is the same content as the ftype, but for arcane windows reasons, I had to set it there too.
Like some others, I had set 'assoc' and 'ftype', but also had set Notepad text editor via the GUI, and when I tried to execute a script via the command line, Windows invoked Notepad to edit the script instead of running my script.
Using the GUI to instead point the .pl file association to the script-running executable was not much of an improvement, since it would invoke the executable on my script, but would pass no command-line arguments (even when I invoked my script from the command line).
I finally found salvation here which advised me to delete some registry keys.
Key quote:
"The problem is that if you have already associated the program with the extension via the Open With dialog then you will have created an application association, instead of a file extension association, between the two. And application associations take precedence."
In my case, following the instructions to use RegEdit to delete
HKEY_CLASSES_ROOT \ Applications \ perl.exe
where perl.exe is the name of my Perl executable, and then also deleting:
HKEY_CLASSES_ROOT \ .pl
seemed to solve my problem, and then (after re-executing 'assoc' and 'ftype' commands as shown in other answers) I could then execute scripts from cmd.exe and have them run with access to their command-line parameters.
Some other related information here.
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.
I wrote a perl script which uses some linux commands (grep, ls etc..). I can successfully run this from Cygwin or Linux. I want this task to be run periodically on a Windows Server which has Cygwin installed. I was planning to use Windows task scheduler. But I am not sure how to specify in a Windows bat file, that my perl script needs to be called in Cygwin mode?
EDIT: I tried the command by Glenn. When I tried running the perl script, it doesn't seem to respond. So I tried with a sample script: test.sh, which has the following two lines:
ls -l
cd ..
Here is the screen capture of what I am getting:
I'm not a great fan of cygwin and personally prefer natively compiled versions of the GNU tools, e.g. GnuWin32.
I also wonder why you would be using grep, ls etc. from a Perl script. Most of that functionality can be handled natively by Perl and this usually results in much better portability and robustness.
Perhaps (untested): c:\cygwin\bash.exe -c /path/to/your/script.pl
UPDATE:
The last error message reveals one problem: your script is a DOS format file (CRLF line endings), while cygwin looks for UNIX format (LF line endings). The stray carriage returns at the end of each line is the problem. For example, there's no directory named "..\r"
Use a text editor where you can specify the line endings to use. In a bash shell, you can do dos2unix test.sh
The ls error indicates that /bin and /usr/bin are not in your bash environment's $PATH -- is that true?
Just add cygwin to your path before running perl. For example, I often run find in a dos shell, but get the rather horrible message FIND: Parameter format not correct. Bah! Instead I have to run find via a dos cmd file cyg.cmd:
c:> find . -iname interesting.txt
FIND: Parameter format not correct
c:> cyg find . -iname interesting.txt
sub/sub/interesting.TXT
c:> type bin\cyg.cmd
setlocal
PATH=c:\Progs\Cygwin\bin;%PATH%
%1 %2 %3 %4 %5 %6 %7 %8 %9
endlocal
The important bit here is the PATH=c:\Progs\Cygwin\bin;%PATH%.
BTW, I much prefer the cygwin versions of the tools rather than their MinGW equivalents—the environment is much closer to Mac/Linux, and portability is important after all.
You run cygwin bash, but you still have to setup your PATH. Unless you set it in your profile, but initialize the profile then with bash -i.
Either specify the full path to cygwin commands needed, like /bin/ls, /bin/grep,
or add c:\cygwin\bin and maybe other paths to your PATH beforehand.
2nd preferred. Like
schedule.bat:
PATH=C:\cygwin\bin;%PATH%
sh -c ./schedule.sh
schedule.sh:
#!/bin/sh
ls ...
grep ...
perl ...
schedule.sh gets the environment with the PATH from the parent process sh.exe, which inherits it from your bat.
Seperating shell scripts from batch files just for easier testing. You can call most cygwin programs from cmd.exe also.
You cannot set /usr/bin in your DOS PATH, DOS will not have a c:/usr directory. And it only works if you are in C: