I have zip file containing my installation files. I'm extracting this zip and copying these files into installation directory with the script shown below:
ZipDLL::extractall "$OUTDIR\demo.zip" "C:\myapp\demo\"
if I remove zip file from $OUTDIR than installer is not able to find zip file as expected. What I want to do is embedding this zip or its extracted folders into exe itself. I added
File -r "$OUTDIR/demo"
but this script didn't worked as well.
When you use the ZipDll plugin, you are referring to the file you want to process (demo.zip) by using its place at run time: along the installer.exe.
When you use the File statement to embed some files into the produced installer, you need to refer to the files by using their place at compile time.
Replace the $OUTDIR in the File statement by the path relative to the .nsi script.
BTW, you should take the habit to check at the compilation log, NSIS probably tells you about that kind of problem when paths are incorrect at compile-time.
Related
I am zipping the .xctest file from Plugins folder inside the .app target generated by building my app. I have a build phase script that runs last in my test target to copy this file over. I use the following script to do the zipping:
XCTEST_FILE=${TARGET_BUILD_DIR}/${TARGET_NAME}.xctest
XCTEST_ZIP=${TARGET_BUILD_DIR}/../../${TARGET_NAME}.xctest.zip
zip -jr ${XCTEST_ZIP} ${XCTEST_FILE}
This gives me TestTarget.xctest.zip file. But it unzips differently based on these 2 methods,
unzip TestTarget.xctest.zip
-TestTarget
-CodeResources
-Info.plist
Double clicking TestTarget.xctest.zip in finder
-TestTarget.xctest
--TestTarget
--CodeResources
--Info.plist
Why is unzip going to the innermost node and extracting all the files? I want the unzip command to give me the .xctest directory. I tried renaming the zip file to TestTarget.zip and it still behaves similarly.
I was initially zipping using zip -r ${XCTEST_ZIP} ${XCTEST_FILE}, but the problem with this was it would retain the entire folder structure from root (\) when I double clicked to unzip the file. A post recommend using the -j flag instead of -r. But just -j led to no zip file being generated. Another comment recommend -jr which created a zip that generated output I expected when double clicking it. But I guess the unzip command does stuff differently.
Similar Question: MacOs zip file - different result when double click and running unzip command
The cause for error here was very different,
The problem was when the file was created. It was not related to MacOs issue but with certain path length known issue in windows
Based on How to zip folder without full path, I had to update my script to first cd into the TARGET_BUILD_DIR before generating the zip. I also had to remove the -j flag so the local folder structure was retained on running unzip.
cd ${TARGET_BUILD_DIR}
XCTEST_FILE=./${TARGET_NAME}.xctest
XCTEST_ZIP=../../${TARGET_NAME}.xctest.zip
zip -r ${XCTEST_ZIP} ${XCTEST_FILE}
Compressing a folder into a .zip file is a common way to treat a folder as file, for example, uploading a folder. Is there a faster way to "pack" the contents of a folder into a file (without taking the time to compress)?
You should use a tarfile. In unix or mac, its the tar command. On Windows there is a tool called 7-zip.
You can see more details here.
I have a .bin file that will comprise of 3 files
1. tar.gz file
2. .zip file
3. install.sh file
For now the install.sh file is empty. I am trying to write a shell script that should be able to extract the .zip file and copy the tar.gz file to a specific location when the *.bin file is executed on an Ubuntu machine. There is a Jenkins job that will pull in these 3 files to create the *.bin file
My Question is how do I access the tar.gz and .zip file from my shell script ?
There are two general tricks that I'm aware of for this sort of thing.
The first is to use a file format that will ignore invalid data and find the correct file contents automatically (I believe zip is one such format/tool).
When this is the case you just run the tool on the packed/concatenated file and let the tool do its job.
For formats and tools where that doesn't work and/or isn't possible the general trick is to embed markers in the concatenated file such that the original script ignores the data but can operate on itself to "extract" the embedded data so the other tool can operate on the extracted contents.
I'm trying to get a Perl script (.pl) out of an executable (.exe) file. The .exe file was originally coded in Perl but the .pl file was not kept. Is there a quick way to do this? I'm using Strawberry Perl for windows.
Thanks
Rename .exe to .zip and check if files can be extracted
From the PAR FAQ:
How do I extract my script out of packed executable?
In other words, "I did a `pp foo.pl' and I lost foo.pl, how do I get it back?".
The answer is to just use unzip/winzip/winrar/whatever to decompress the executable, treating it like a normal Zip file. You may need to rename the executable into a .zip extension first.
pp relies on PAR to create the executable. PAR relies on Archive::Zip, so at some level the file contains zipped copies of the perl scripts used to create the executable.
Typically, these programs attach a loader to the front of a zip archive which unzips the files to a temporary directory and invokes the script indicated as the program's entry point.
I'd try two things:
root around in all the typical Temp directories (\Users\Username\AppData\Local\Temp for instance) for a directory containing your script and it's prerequsites.
try to uncompress the exe as a zip, possibly removing the loader from the start of he program first, using a byte editor.
I created a simple program that takes the path of a directory as an input, creates an archive of that directory (converting it into a single file), adds a shebang to that file (so that the contents of the file can be easily extracted), and writes the file to the base directory of the specified path.
The problem is that the file does not extract itself when I double click on it. Instead the operating system (I'm using Ubuntu 11.10) tries to open it with gedit. This obviously shows the shebang, random gibberish, and the contents of the archived files.
I made the file executable, first by using chmod +x; and when it still didn't work I tried chmod 777. However it still refuses to execute the file with the shebang when I double click on it. Perhaps this is because it's not a pure text file.
Interestingly when I try to execute the file directly from command line it reads the shebang and extracts the contents of the archive properly. So there's nothing wrong with my file format. I don't know much about what operating systems do when you double click on a file but I would sure like to understand.
It surely makes no sense to add a shebang to a file if you still need to manually execute it from the command line. One advantage could be that you don't need to specify the program to open it with but I believe that's hardly an advantage. Any help will be greatly appreciated.
Update 1:
The program that creates the archive is called opm. It can be installed via the node package manager using the following command:
npm install opm
After that you simply use opm to pack and unpack directories for you. For example if I have a directory called test in my home directory then I can open a terminal and execute the following command to pack it:
opm test
This will create an archive of the directory called test.pack in the home directory. The .pack file has the shebang #!/usr/bin/opm. Opening a file with the extension .pack with opm tells it that it's an archive and opm unpacks it in the same directory.
Note: Change the name of the test.pack file if you do not want it to overwrite your existing test directory.
I added the shebang to the .pack file so that it would extract itself when I opened it. However that doesn't seem to work. Nevertheless if I run one of the following command then it works:
./test.pack
You may check my source code and make any modifications to the program as you may wish to.
Update 2:
Alright I created the following .desktop file for opm and stored it in the $HOME/.local/share/applications/ directory:
[Desktop Entry]
Type=Application
Version=1.0
Encoding=UTF-8
Name=OPM
GenericName=Object Packer and Minifier
NoDisplay=true
Comment=JavaScript Package Manager
TryExec=opm
Exec=opm %f
Terminal=false
MimeType=application/opm
Now I was able to associate .pack files with opm by right clicking on a .pack file, going to the Properties window, the Open With tab, and setting opm.desktop as the default application. Now I am able to unpack a .pack file by simply opening it.
However I would like to know how to associate .pack files with the mime type application/opm. Currently the .pack files are associated with application/x-java-pack200. How do I do so? Is it better if I use a different extension (e.g. .opm)? By associating the packed archives with the mime type application/opm will the OS open them with opm by default without having to explicitly set a default application from Properties > Open With?
If there's already a MIME-type associated with .pack then you'll want to use a different extension (.opm) to associate with your MIME-type (application/opm). The way you automatically associate a program that opens files of a specific MIME-type is with xdg-mime .
Alternatively,
Edit ~/.local/share/applications/mimeapps.list and put your MIME/application combo under [Default Applications] like so:
[Default Applications]
application/opm=opm.desktop;
Place your opm.desktop file in ~/.local/share/applications/ folder. (You've already done this)