I plan to reinstall the operating system on my secondary computer but don't want to lose the entire current file associations open with 2 programs are Notepad++ and Winrar because I have added quite a few other file extensions opened with these 2 programs.
I tried to follow the instructions Export or Import Default Application Associations with the command line:
Dism /Online /Export-DefaultAppAssociations:"C:\AppAssociations.xml"
But it was the command line designed on Windows 10 and above, I received an error after trying it on Windows 7:
Error: 87
The export-defaultappassociations option is unknown. For more information, refer to the help by running DISM.exe /?.
I also tried exporting the FileExts key (at HKCU/Software/Microsoft/Windows/CurrentVersion/Explorer/FileExts) and then merging after installing the operating system but nothing changed, still unable to restore the file association data.
I plan to export all current data via the ftype and assoc commands, however, the data returned by these 2 commands has the following problem:
With the assoc command: Only the default file extension data is associated with Winrar, there are no custom file extensions added by me and opened with Winrar, and there is no file extension data opened with Notepad++.
With the ftype command: I see 3 results with Winrar:
WinRAR="C:\Program Files\WinRAR\WinRAR.exe" "%1"
WinRAR.REV="C:\Program Files\WinRAR\WinRAR.exe" "%1"
WinRAR.ZIP="C:\Program Files\WinRAR\WinRAR.exe" "%1"
And there is absolutely no notepad++.exe in the output.
So I need a method (command line, software,...) that can help me export/import current file associations data (at least of 2 programs Notepad++ and Winrar).
I will appreciate the method you give.
Related
I am trying to install a program silently (the program is old, has InstallShield v7.00). However, every time I run the command, it does nothing and the setup.log file states "ResultCode=-8".
That ResultCode indicates that an invalid path to the InstallShield Silent installation script file was specified (which I am assuming to be the response file I generated earlier, which is named setup.iss).
Setup.exe and setup.iss are both in the same folder. I tried specifying the exact path to both files, and not, as seen in the list of commands I have tried below:
"C:\Test\setup.exe" /s /f1"C:\Test\setup.iss"
setup.exe /s /f1 setup.iss (CMD directory is in C:\Test)
setup.exe /s (Thought it would just find the setup file automatically as they are in the same folder)
I am trying to install EPSON OPOS ADK, for which the installation manual states the exact commands I am using are correct.
There is no MSI file contained in the EXE file (or, if there is, I cannot extract it with WinRAR and I could not find it in ProgramData while the setup was running).
Does anyone know what I am doing wrong or what I can do?
EDIT: Below is the contents of my setup.iss file:
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-DlgOrder]
Dlg1={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdWelcome-0
Count=7
Dlg2={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdLicense2-0
Dlg3={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdSetupType-0
Dlg4={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdStartCopy-0
Dlg5={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-AskOptions-0
Dlg6={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdFinish-0
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdWelcome-0]
Result=1
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdLicense2-0]
Result=1
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdSetupType-0]
szDir=C:\Program Files (x86)\OPOS\Epson2
Result=301
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdStartCopy-0]
Result=1
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-AskOptions-0]
Result=1
Sel-0=1
Sel-1=0
Sel-2=1
Sel-3=0
[Application]
Name=EPSON OPOS ADK
Version=031.000.01000
Company=SEIKO EPSON CORPORATION
Lang=0009
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdFinish-0]
Result=1
bOpt1=0
bOpt2=0
EDIT 2:
So I ran the recording for the .iss file again, but this time instead of just doing "setup -r", I did "setup -r f1"C:\"" instead. This should make no difference other than telling it where to save the recording. However, I got a different .iss file out of it. Here it is:
[InstallShield Silent]
Version=v7.00
File=Response File
[File Transfer]
OverwrittenReadOnly=NoToAll
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-DlgOrder]
Dlg0={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-Uninstall-0
Count=7
Dlg1={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdWelcome-0
Dlg2={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdLicense2-0
Dlg3={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdSetupType-0
Dlg4={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdStartCopy-0
Dlg5={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-AskOptions-0
Dlg6={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdFinish-0
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-Uninstall-0]
Uninstall=0
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdWelcome-0]
Result=1
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdLicense2-0]
Result=1
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdSetupType-0]
szDir=C:\Program Files (x86)\OPOS\Epson2
Result=301
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdStartCopy-0]
Result=1
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-AskOptions-0]
Result=1
Sel-0=1
Sel-1=0
Sel-2=1
Sel-3=0
[Application]
Name=EPSON OPOS ADK
Version=031.000.01000
Company=SEIKO EPSON CORPORATION
Lang=0009
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdFinish-0]
Result=1
bOpt1=0
bOpt2=0
I was very happy when I saw it was different, and figured my issue would be solved. Well, not exactly.
Now, instead of getting ResultCode = -8, I am getting ResultCode = 0. A code of 0 indicates there was a successful installation. However, the program did NOT install. Nothing was touched. I noticed this before even looking at the code because it finished "installing" almost immediately after running the command, with no loading icons or anything.
So now, InstallShield is reporting that the program was successfully installed but it, in actuality, was not. I tried re-recording the .iss file numerous more times but I am just getting this same file now. The file is likely no longer the issue. However, I am at a loss for what the issue could be now.
Setup.iss: I guess the real problem might be that there is an error in your setup.iss file. Can we see its content? Maybe the setup.iss you are using is for another Setup.exe entirely? Try re-generating a new one?
UPDATE: Maybe have a look here as well: Epson OPOS ADK for .NET drivers for Windows 7
That silent.iss response file seems to lack a header section when compared with this documentation: Performing Silent Installations and Uninstallations (PDF, section "InstallScript Installations" page 3 onwards).
Setup.exe Extract: Maybe also make sure that this is not an MSI setup after all:
Short version: Programmatically extract contents of InstallShield setup.exe
Long version: Extract MSI from EXE
And:
Extracting from an MSI (administrative installation).
How to deploy the Installshield MSI without having to run Setup.exe
Sample Setup.exe Command Lines: For inspiration an ancient Itninja / AppDeploy PDF with sample Installshield setup.exe commands (I think the last few entries in the document were never finished, they just all say Setup.exe /uninst - so just ignore them). Did you try the /SMS parameter? I don't see how that would solve your particular problem, but you should know about the switch anyway.
Some Links:
InstallShield Error Codes (Setup.log)
InstallShield Setup Silent Installation Switches
Performing Silent Installations and Uninstallations (PDF)
EPSON OPOS ADK for .NET Manual (PDF)
Installshield 2018 Help File:
Setup.exe and Update.exe Command-Line Parameters
Advanced UI and Suite/Advanced UI Setup.exe Command-Line Parameters
Setup.exe (InstallScript Projects)
I've installed ActiveState Perl on my new Windows 10 PC. I've installed the same exact version of Perl on several of my own PC's, and it's installed on 100's of other users' PC's in my company. Same exact install, created by me.
This is the first time trying this on Windows 10. The basic actions of double-clicking a Perl script (*.pl) in Explorer cause a console window to open and Perl to run the script.
Also, in Windows Command Prompt, I can type perl.exe script.pl, and the script runs fine. But, when I just type script.pl, nothing happens. No output, no errors, no perl.exe processes visible in Task Manager.
The first time I ran a Perl script (from Windows Command Prompt, I believe, using just the script.pl syntax), Windows popped up a window asking me what program I wanted to use to open this file. Perl was the default, and I clicked OK.
I've never seen that window in Windows 7 or 8, so I'm thinking it's something specific to Windows 10, and that it's the thing that's somehow preventing me from just typing script.pl. Because, when launching script.pl, I'm requiring the file associations to pick the right program, but when I type perl.exe script.pl, perl.exe is being launched directly. But, that Windows 10 "pick your default program" thing is getting in the way when running from the command prompt by messing up the file associations.
Not 100% sure why it works from Explorer, though, but I'm pretty sure that I need to clear that default program thing. I removed the registry entry for .pl files under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts, but that didn't help.
This seems to be a more generic problem with Windows 10, or possibly just my installation of it, or a Group Policy I'm not aware of.
The following commands (run in a Admin command prompt) work fine in Windows 8.1 but not Windows 10:
assoc .foo=Foobar
ftype Foobar=C:\WINDOWS\system32\foo.bat %1
echo #echo off > foo.bat
echo echo The filename is %1 >> foo.bat
echo hi > foo.foo
foo.foo
The result should be the output:
The filename is C:\WINDOWS\system32\foo.foo
But Windows 10 does nothing. It seems to only allow built-in apps to be associated in this manner, and not BAT scripts of downloaded/installed EXEs.
Turns out that Microsoft reversed the polarity of a Registry setting in Windows 10, and this is biting other Perl programmers too. The solutions is to set HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\InheritConsoleHandles to "0".
MSDN post here: https://social.msdn.microsoft.com/Forums/en-US/f19d740d-21c8-4dc2-a9ab-d5c0527e932b/nasty-file-association-regression-bug-in-windows-10-console
Make sure your PATHEXT environment variable has .pl in it.
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 got some strange behaviour when executing a powershell script.
When I run my script using the ISE it works just fine.
When I open Powershell.exe and run my script it works just fine.
When I open cmd, and start my script using powershell.exe -noexit
./myscript.ps1, myscript works just fine.
When I double-click myscript however, powershell opens for some milliseconds, I see that it shows some error (red font) and the powershell window closes. I'm unable to track down the error causing this problem since the powershell windows closes to fast.
I even tried one single big try-catch block around my hole script, catching any [Exception] and writing it down to a log file. However: the log file is not generated (catch is not called).
How can I track that issue? What could possibly be causing the trouble?
Please note that my execution-policy is set to unrestricted.
Before trying the suggestion invoke this to see your current settings (if you want restore them later):
cmd /c FType Microsoft.PowerShellScript.1
Then invoke this (note that you will change how your scripts are invoked "from explorer" by this):
cmd /c #"
FType Microsoft.PowerShellScript.1=$PSHOME\powershell.exe -NoExit . "'%1'" %*
"#
Then double-click the script, it should not exit, -NoExit does the trick. See your error messages and solve the problems.
But now all your scripts invoked "from explorer" keep their console opened. You may then
remove -NoExit from the above command and run it again or restore your
original settings.
Some details and one good way to invoke scripts in PS v2 is here.
Unfortunately it is broken in PS v3 - submitted issue.
by default, for security reason when you double clic on a .ps1 file the action is : Edit file, not Run file .
to execute your script : right-click on it and choose run with powershell
I also wasn’t able to run a script by double clicking it although running it manually worked without a problem. I have found out that the problem was in the path. When I ran a script from a path that contained spaces, such as:
C:\Users\john doe\Documents\Sample.ps1
The scipt failed to run. Moving the script to:
C:\Scripts\Sample.ps1
Which has no spaces, solved the problem.
This is most likely an issue with your local Execution Policy.
By default, Powershell is configured to NOT run scripts that are unsigned (even local ones). If you've not signed your scripts, then changing your default double-click 'action' in Windows will have no effect - Powershell will open, read the execution policy, check the script's signature, and finding none, will abort with an error.
In Powershell:
Help about_execution_policies
gives you all the gory details, as well as ways to allow unsigned scripts to run (within reason - you'd probably not want to run remote ones, only ones you've saved onto the system).
EDIT: I see at the tail end of your question that you've set Execution Policy to 'unrestricted' which SHOULD allow the script to run. However, this might be useful info for others running into execution policy issues.
If you would catch the error you will most likely see this
The file cannot be loaded. The file is not
digitally signed. The script will not execute on the system. Please
see "Get-Help about_signing" for more details.
Because you are able to run it from the shell you started yourself, and not with the right mouse button click "Run With PowerShell", I bet you have x64 system. Manually you are starting the one version of PowerShell where execution policy is configured, while with the right click the other version of the PowerShell is started.
Try to start both version x64 and x86 version and check for security policies in each
Get-ExecutionPolicy
I was in exactly the same situation as described in the question : my script worked everywhere except when double-clicking.* When I double-clicked a powershell windows would open but then it will close after a second or so. My execution-policy is also set to unrestricted.
I tried the selected answer concerning FType Microsoft.PowerShellScript.1 but it didn't change anything.
The only solution I found was a work around: create a bat file which start the powershell.
Create a file, copy this and modify the path : powershell.exe -File "C:\Users\user\script\myscript.ps1"
Save it as a .bat
Double-click the bat
I also used .ahk to start my powershell with a shorcut and it didn't work when pointing directly to the powershell. I had to point to the .bat
During an install of PostgreSQL 9.1.2 on my Windows 7 64-bit Home Premium box, the installation hung. After a long furious search I discovered the problem was that an installer VB Script was hung waiting for a batch file to complete in a hidden window.
I isolated the problem to the following line of code:
Dim objShell
Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run "hello.bat", 1, True
(where 1 sets WindowStyle to Visible and True waits for completion). The Run call had launched the command prompt but was not executing the batch file. Thus, it would never complete.
I solved the problem by launching cmd.exe instead of the batch file directly, according to numerous online sources:
objShell.Run "%COMSPEC% /c hello.bat", 1, True
Since the fix is buried in the PostgreSQL installer (and I've submitted a bug report), I can only work around the problem unless the installer is modified.
But my main questions are:
Why does the first call hang?
Why use %COMSPEC% instead of calling the batch directly?
In regards to #2, could this be because executing a .bat directly makes an assumption that the default action associated with a .bat file is to execute it? I've in the past (on other machines) changed this default action to 'Edit'. And if I'd done that, I would have hung the PostgreSQL installer as well! (I imagine)
The batch file executes normally on other machines. So there is something weird on this one laptop. So in regards to #1, I need to figure out why this one laptop is different. I should note that there are some weird behaviors with batch files on this machine (one which I just noticed):
The context menu actions contain only "Open" and are missing "Edit", "Run", "Run As"
Double-clicking a batch file opens a command prompt but does not execute the batch file
I just noticed #2 while writing this. Clearly the default action for .bat is messed up. Yesterday I nearly bricked my computer removing Context Menu Handlers from my registry as recommended by several sites trying to restore my "Edit", "Run", etc. entries.
Any advice on questions 1 and 2 would be appreciated.
Thanks,
Eric
The problem was an HKCU override on .bat which created an association to cmd.exe, as noted on this wonderful post. Additional help was found here.
My registry looked like this:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.bat
\OpenWithList
(Default) REG_SZ (value not set)
a REG_SZ NOTEPAD.EXE
MRUList REG_SZ a
\OpenWithProgids
(Default) REG_SZ (value not set)
batfile REG_NONE (zero-length binary value)
\UserChoice
(Default) REG_SZ (value not set)
Progid REG_SZ (Applications\cmd.exe)
Removing the entire .bat entry fixed everything. All context menu items were restored properly (Open, Edit, Print, Run as Administrator, and Troubleshoot Compatability) and double clicking on the batch file executed the batch.
The .bat key re-generated automatically sometime after I deleted it and double-clicked my test batch file. This automatically generated entry was:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.bat
\OpenWithList
(Default) REG_SZ (value not set)
\OpenWithProgids
(Default) REG_SZ (value not set)
batfile REG_NONE (zero-length binary value)
Ultimately it was the \UserChoice key that was causing my problem. So I'm all cleared up now. My test scripts run properly and I re-installed PostgreSQL from scratch and the install went smoothly.
E
The 1st call launches a window that remains open until something tells it to close. Prsumably hello.bat terminates with an EXIT command, which would of course close the window, and your installation can then continue on its way.
But hello.bat fails to run on your one machine, so of course the window never closes, and your installation hangs.
The 2nd call through %COMSPEC% is opening a window and running CMD.EXE with the /C "command" option. The specifiation for the /C option states that CMD.EXE will terminate once the "command" completes (or fails). Your "command" is "hello.bat". Closure of the window is no longer dependent on an EXIT command in the hello.bat file. The window will close even if hello.bat fails to run.