I am trying to use the NsUnzip plugin with v3.08 of NSIS, but I keep getting a result code of 9 on all calls used in the "nsUnzipTest.nsi" when I use v3.08. I added the DLL file to both the "z86-ansi" and "x86-unicode" folders. I even tried adding the "Unicode true" to the NSI script, and it still gave a result code of 9. Since a code of 9 is "The specified zipfile(s) was not found", I went ahead and added a FileOpen and FileClose using the same path. FileOpen worked fine.
I changed back to NSIS 2.46 and the plugin worked without issue.
What could I be missing?
It does not look like that plug-in supports Unicode. In NSIS 3 you would have to add Unicode False to the top of your .nsi.
You could try re-compiling the plug-in yourself or try contacting the author...
Related
Here is a weird problem i'm facing; after updating Joomla to the latest version, website failed to up load but, as i've made a backup manually from these folders:
administrator
bin
cli
components
includes
layouts
libraries
modules
plugins
yt-assets
and all the root files, after restoring the backup still the website is not loading and just says
"Fatal error: Cannot redeclare jblogerror() in on line 0" !
Any suggestion? Thank you.
Apparently, the version of jBlog you are using is loading its attempting to load its own classes twice.
Let's assume the jBlog developers already fixed it and you carelessly ignored the warning to ensure all your extensions are compatible before updating.
Are you able to access administrator? Simply go there and upgrade jBlog including any modules.
Else, the issue lies within a plugin. In order to access the administrator and perform the update, you will need to manually disable the offending plugin.
A simple way is to rename its folder: start from plugins/system then plugins/content hopefully you'll have spotted it by then. Look into the subfolders of each and spot any that may be relevant to jBlog (or grep through the folder to locate the specific string)
If you have console access, simply run
# grep -rl jblogerror plugins/system
and you should see all the files that include such string, just rename their main plugin folder. But you could also do all this through ftp and guessing.
(Before downvote im aware how to do this using code thats inline to this command but not how to do it using a file that uses the --app="data:text/html,<sometags></sometags>)
How would I open a local html (mar.html) file using this command
C:\'Program Files (x86)'\Google\Chrome\Application\chrome.exe --profile-directory="Default" --app=
Specifically, the issue is my lack of familiarity with the --app flag
I tried
C:\'Program Files (x86)'\Google\Chrome\Application\chrome.exe --profile-directory="Default" --app="mar.html"
C:\'Program Files (x86)'\Google\Chrome\Application\chrome.exe --profile-directory="Default" --app="file:///mar.html"
Both don't work.
Giving me the error
Your file was not found
It may have been moved or deleted.
ERR_FILE_NOT_FOUND
You almost got it. The file descriptor path must be absolute and encoded.
Encoding the path correctly with cli tools like "urlencode"(gridsite-clients) did not work for me.
If you have NodeJS installed and would use a linux machine, you could use this command.
chromium --app=`node -e "console.log('file://'+encodeURI(process.argv[1]))" "$(realpath "/path/of/your/file.html")"`
This works also fine with relative paths.
For windows you have to rewrite this yourself.
I'm new here so I apologize if this question is breaking some rule or something. But this is becoming a problem for me. I downloaded Intellij and downloaded the lua plugin for it. Well, now I'm trying to configure lua sdk but everytime I put in the location for it, it says "The selected directory is not valid home for Lua SDK"
What is the valid home? What am I doing wrong?
The problem might be that your lua.exe file is actually named luaXX.exe where XX is the version.
In my case it was lua53.exe. I renamed just the lua53.exe file to lua.exe; I didn't rename the rest.
So at first I had:
lua53.dll
lua53.exe
luac53.exe
wlua53.exe
After renaming the file I have:
lua53.dll
lua.exe
luac53.exe
wlua53.exe
With this changed, the Intellij plugin detected the folder as a valid home.
When I create exe within the C:\Program Files\dotNetInstaller\bin folder, and run it, it works perfect, install perfect, but when I try to install that exe from any other location/path, the error appears "The installation package could not be opened. Verify that the package exists and that you can access it. etc....."
I created an exe and moved to another XP system, on that system, it again gives me error ?
whats the solution ? Is there any admin rights issue ?
I have tried with both TRUE and FALSE of Administrator_Required option.
any idea how can I solve this issue ?
The issue is resolved now.
I should have written #CABPATH\ in the MSI->Package field. Before I was writing #TEMPPATH\
I think you can should add the location:
C:\Program Files\dotNetInstaller\bin
in the PATH environment variable. Follow the steps: Go to
My Computer->Right click->Properties->Advanced System Settings
->Click Environmental Variables. Now click PATH and then click EDIT.
In the variable value field, go to the end and append ';' (without quotes) and then add the above path.
I am using WiX 3.5 and making an installer. I have used heat.exe to bundle all the files.
It produced a WiX file. I referred in main wxs files as componentgroup ref. When I build my installer, it throws the following exception.
light.exe : error LGHT0103 : The system cannot find the file
'..........\target\tmp-release\jboss-eap-5.0\jboss-as\server\all\deploy\httpha-invoker.sar\invoker.war\WEB-INF\classes\org\jboss\invocation\http\servlet\ReadOnlyAccessFilter.class'
with type ''.
It is able load many files from this location, except the above file, even though the file is present.
Looks like you've hit the linker bug. As far as I can see, it was already reported to the WiX team, and was scheduled for v4.0. The comment to the issue states the path is more than 255 characters, so a possible workaround for you is to re-work the files/folders layout to avoid the paths of that length.
Hope this helps.
The answer of Ravz1234 works ! I used it with a environment variable e.g. env.SourcePath.
1) Set an environment variable to show on your Source Dir e.g. C:\SourceDir
2) On heat.exe add the argument -var env.SourcePath along with the other arguments
I used the variable for the directory, sys.SOURCEFILEDIR, and it worked well.