In my product we are using winzipCLI to zip packages. After a long time i seeing an issue not able to resolve it. A evaluation acceptance message is thrown in CLI which is causing my build system to fail. I found the issue by manually running the winzip cli and below the evalution question asked ....How to suppress it? Any options? or any script? or...etc?
C:\Program Files\WinZip>WZZIP.EXE -a test.zip *.txt
WinZip(R) Command Line Support Add-On Version 4.0 32-bit (Build 10480)
Copyright (c) 1991-2013 WinZip International LLC - All Rights Reserved
THANK YOU FOR TRYING WINZIP COMMAND LINE ADD-ON
This is a fully functional version for EVALUATION USE ONLY
This notice is not displayed with registered Standard and Pro editions of
WinZip.
Please go to www.winzip.com to order WinZip.
(press any key to continue (Ctrl-C to quit))
Yes, buy a license for WinZip.
(Stack Overflow is not the place to ask questions like "How can I avoid paying for this piece of commercial software?" If in fact you have bought a license and you're still getting that message then I apologise for misjudging you and you should take it up with WinZip tech support.)
Related
I'm looking to convert a PS1 file to an .exe file so I can roll it out to less technical users.
I believe it'll be much easier for them if all they need to do is double-click it vs explaining how to run through PowerShell.
How can I achieve this?
Use PS2EXE instead of this online tool that forces you to upload your script and creates a security breach if you have confidential information inside your script.
There is a GUI mode available; to learn more, see the GitHub repository.
You have a few paid and unpaid solutions. I agree with last answer, do not use online tools unless you are sure they are not keeping your code and you trust them.
There are two free ones that come to mind:
PS2EXE-GUI
PS1 To EXE by F2KO (Make sure t it is the local install command line interface, not the web one)
The Paid ones are:
PowerShell Studio
ISE Steroids 2.0 Enterprise
Noted: I think the free ones should be fine for most uses. I do like PowerShell Studio though.
An update to PS2EXE tool (all versions are open-source):
The original script comes from Ingo Karstein, but the development seems to have halted in 2017. You can find his blog here, and his contribution on Microsoft Technet's forums here.
Markus Scholtes has continued the script's development, adding some useful features. You can find his post on Microsoft Technet here, and github repository here.
Powershelling's answer point you to a fork of Markus' project by Stuart Dootson (here and here), which is less maintained. The obvious difference would be the "Added support for scripts that require elevation. This inserts a suitable manifest into the executable produced by the tool. that .exe files built with his version of the script require elevation".
I'd recommend checking out Markus Scholtes' version, but beware (!) (README.md on 3rd Nov 2020):
Attention: Incorrect virus detection of PS2EXE
Some stupid idiot seems to have abused PS2EXE to compile his computer virus script. As a result, a rapidly growing number of virus scanners recognize programs created with PS2EXE as malicious programs and delete them.
There is only one hope to save the PS2EXE project: Please send your (harmless) programs created with PS2EXE via the web forms from the virus scanners' vendors for reporting false positives (I've already done it with some of them, please use only the false positive page)!
If this is not successful, then I will have to quit PS2EXE as nobody can use it anymore.
Thank you for your support
I'm looking to convert a PS1 file to an .exe file so I can roll it out to less technical users.
I believe it'll be much easier for them if all they need to do is double-click it vs explaining how to run through PowerShell.
How can I achieve this?
Use PS2EXE instead of this online tool that forces you to upload your script and creates a security breach if you have confidential information inside your script.
There is a GUI mode available; to learn more, see the GitHub repository.
You have a few paid and unpaid solutions. I agree with last answer, do not use online tools unless you are sure they are not keeping your code and you trust them.
There are two free ones that come to mind:
PS2EXE-GUI
PS1 To EXE by F2KO (Make sure t it is the local install command line interface, not the web one)
The Paid ones are:
PowerShell Studio
ISE Steroids 2.0 Enterprise
Noted: I think the free ones should be fine for most uses. I do like PowerShell Studio though.
An update to PS2EXE tool (all versions are open-source):
The original script comes from Ingo Karstein, but the development seems to have halted in 2017. You can find his blog here, and his contribution on Microsoft Technet's forums here.
Markus Scholtes has continued the script's development, adding some useful features. You can find his post on Microsoft Technet here, and github repository here.
Powershelling's answer point you to a fork of Markus' project by Stuart Dootson (here and here), which is less maintained. The obvious difference would be the "Added support for scripts that require elevation. This inserts a suitable manifest into the executable produced by the tool. that .exe files built with his version of the script require elevation".
I'd recommend checking out Markus Scholtes' version, but beware (!) (README.md on 3rd Nov 2020):
Attention: Incorrect virus detection of PS2EXE
Some stupid idiot seems to have abused PS2EXE to compile his computer virus script. As a result, a rapidly growing number of virus scanners recognize programs created with PS2EXE as malicious programs and delete them.
There is only one hope to save the PS2EXE project: Please send your (harmless) programs created with PS2EXE via the web forms from the virus scanners' vendors for reporting false positives (I've already done it with some of them, please use only the false positive page)!
If this is not successful, then I will have to quit PS2EXE as nobody can use it anymore.
Thank you for your support
In Win7, an old version of Acrobat XI is still showing, but there is no matching MSI file for it to execute, so it can't "uninstall" and I can't delete the entry because MS makes it intentionally difficult.
Normally such things just pile up over time. But Acrobat insists on uninstalling the previous version and will not install until the old one is gone.
How can I remove the entry from the database that "Programs and Features" uses?
The cached MSI file that is supposed to run the uninstall might be missing from the super-hidden MSI cache folder normally found at C:\windows\installer (formally at %SystemRoot%\Installer), or there is a crash in the uninstall sequence. Creating an uninstall log file could help (replace the truncated paths):
msiexec.exe /X "C:\Test.msi" /L*V! "C:\msilog.log"
Uninstall by product code (sample guid):
msiexec.exe /x {11111111-1111-1111-1111-11111111111X} /L*V! "C:\msilog.log"
Please see sections 3, 4 and 12 here for details on how MSI's uninstall works: Uninstalling an MSI file from the command line without using msiexec. This will also tell you how to find the product GUID for Adobe Acrobat XI Pro (use the Powershell command found in section 3, or find the same information and a screenshot here: How can I find the product GUID of an installed MSI setup?).
Before trying anything else, I suppose you can try this uninstall fix tool (fixed broken link, September 2017). It would be interesting with feedback on whether it actually works.
I had similar issues in the past and used ccleaner to clean up entires from "Programs and Features" after an uninstall went wrong. Hope it works for you.
This question is technically off topic as you are a user of the product not a developer of the product setup. Your cached MSI is missing and that's blocking their uninstall (bad design on their part) which occurs during upgrade to the new version. There are several things you can try:
1) Reinstall / Repair the old version and then try to uninstall it.
2) Contact the vendor for support.
3) Reinstall Windows.
4) Use the Windows Installer Cleanup Utility (no longer supported but can be found online ) to whack MSI's knowledge of the product. Note this doesn't actually uninstall the product and can cause all sorts of difficulties that may lead you to back to option 3.
I've been trying for a week to get F# interactive working in Emacs and I haven't been able to.
The problem is that whenever I run "fsi" or "fsharpi" (either using fsharp mode or in a shell buffer), the buffer becomes unresponsive. I check the system monitor and see a mono process using 100% CPU and obviously anything I type doesn't get evaluated.
I've tried this on Emacs 24.1 and 23.2; also on OS X, Linux Mint and Fedora, and all cause the same exact problem.
I've tried different versions of mono (2.10.9, 3.0 and 2.8 on OS X; 2.10.8.1 on Linux Mint, can't remember on Fedora). I've also tried F# 2.0 and 3.0; all with same results.
I've also tried passing in "--no-gui" and "--readline" when launching the interpreter to no use.
Here's basically what happens
bash-3.2$ fsharpi
Microsoft (R) F# 3.0 Interactive version (Mono build)
Copyright (c) Microsoft Corporation. All Rights Reserved.
For help type #help;;
> - 1+2;;
# after waiting for a minute, I kill the mono process
Killed: 9
bash-3.2$ bash: syntax error near unexpected token `;;'
However, the interpreter does work when running it on an "ansi-term" buffer:
bash-3.2$ fsharpi
Microsoft (R) F# 3.0 Interactive version (Mono build)
Copyright (c) Microsoft Corporation. All Rights Reserved.
For help type #help;;
> - 1+2;;
val it : int = 3
I want to use it with fsharp mode so that I can send code to the interpreter easily.
I haven't seen anyone having problems of this kind online, and resolving this would make development so much more convenient.
Any ideas on how to get this working?
Edit: as expected, running it in comint mode also "hangs" (comint is what fsharp mode uses).
What version of fsharp-mode are you using? The last update (v0.3) was just after the release of VS2010 (F# 2.0), and the release notes mention that an infinite-loop bug was fixed in that version.
Another possibility -- the last update to fsharp-mode predates Mono's support for F#, so my guess is that some piece of code in the Intellisense helper project (in the /src folder of the fsharp-mode code) is relying on Windows-specific behavior and breaking when you run it on Mono.
I think your best bet to get this working is to repost your question on the fsharp-opensource mailing list, as a number of people on there are running F# on Mono and might know how to fix the problem.
EDIT: The answer from the mailing list post is to pass in the --readline- flag. The trailing - turns readline off and fixes the problem.
The answer is to run the F# interpreter with the option "--readline-".
It should be solved (no need for this command line argument) in the Github repository https://github.com/fsharp/fsharp
I'm having the strangest issue while trying to build and install muParser on my windows machine. As suggested by the installation guide, I just cd into the build folder, and run
make -f makefile.mingw
This should be all well and good standard procedure. However, I can't make sense of the output from the command:
if not exist obj\gcc_static_rel mkdir obj\gcc_static_rel
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Chase\Desktop\muparser_v2_0_0\muparser_v2_0_0\build>
Now... at this point, I'm really confused. Because according to the title of the command prompt window, I'm still INSIDE the make command. So, I type "exit" at the "prompt"
g++ -c -o obj\gcc_static_rel\muParser_lib_muParser.o -DNDEBUG -O2 -D_WIN32 - I..\include -MTobj\gcc_static_rel\muParser_lib_muParser.o - MFobj\gcc_static_rel\muParser_lib_muParser.o.d -MD -MP ../src/muParser.cpp
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Chase\Desktop\muparser_v2_0_0\muparser_v2_0_0\build>
The command appears to "step" through it's next function. I continue to type exit at the "prompt" and the command appears to continue stepping until it's done. However, after exiting completely, I can't see any results and it appears nothing's actually been done.
Also, this doesn't have anything to do with the command prompt. I even wrote a python script to cd into the directory and call make, and the output still displayed a windows-style command prompt - complete with the copyright Microsoft line etc., and waited for an input. I typed exit the same way until the process exited back to python.
Now, I might be going insane, but I'm really confused. Asking on the forums yielded no help, the only response is that "the windows build should be working."
Does anyone know what's going on???
I downloaded the muParser package and tried to build it. I got the same strange behaviour from make as you did. Then I realised I only had MSYS-make installed, not MinGW-make (the first one is intended for use in the MSYS shell, the second one for use in the Windows cmd shell).
Unfortunately, installing and using mingw32-make gave a different error, but googling that lead me to this page, where it was suggested to rename sh.exe in the MSYS directory. After doing that, running mingw32-make -f makefile.mingw succesfully built (the static version of) the library.
The other method you and shellter are using of running ./configure; make in the MSYS shell, also fails to build the example for me. It does build the dll version of the library in this case, instead of the static version; perhaps this is why the example fails to build.
(You might want to add a tag for 'make' or 'gmake', that should boost the number of eyes looking at your problem).
Looking at the makefile.mingw, I'm surprised to see statements like '-if not exist ..', that is .bat file syntax.
I ran ./configure ; make and it got past the error messages you mention, but I'm seeing a bunch of error messages like undefined reference to mu::ParserError: , so I'm probably missing libraries to make it work completely. I'll have to leave it at that, and hope that it helps you. Note that I didn't use make -f makefile.mingw. After using configure, make just picked up the newly created Makefile, and it worked (excepting the library problems ;-)
(When you say forums, did you mean the mingw forums? If not, try looking around here. The search functionality is pretty good.)
I hope this helps.