megastep / makeself Goto Github PK
View Code? Open in Web Editor NEWA self-extracting archiving tool for Unix systems, in 100% shell script.
Home Page: https://makeself.io
License: GNU General Public License v2.0
A self-extracting archiving tool for Unix systems, in 100% shell script.
Home Page: https://makeself.io
License: GNU General Public License v2.0
Is there a way to simply extract the files distributed with a .run file without without executing it? Implementing such a function would be nice, something like makeself --extract installer.run
I need a way to determine in my startup script from what directory the archive script was called. I need to know the original working directory, if you will. As far as I can tell there's not a way to do this currently.
My archive script is located at /home/scott/deploy.run
. I need to passthrough a --configFile
argument to my startup script. My config file is located at /home/scott/config.yml
.
It's perfectly reasonable for the person executing my archive script to expect to pass a relative config file path, like so:
./deploy.run -- --configFile config.yml
When that command is executed, my archive is extracted to /var/folders/wm/_blahblah/T/selfgz1234
, which is what my startup script sees as the working directory.
The problem is that my startup script has a config file value of 'config.yml', but has no way to know the archive script was called from /home/scott
. I need to be able to determine that original working directory so I can resolve the fully qualified path of the config file.
I've worked around this in my project by modifying makeself-header.sh to export a MAKESELF_PWD environment variable. My startup script uses that variable to resolve file paths. I suppose the original working directory could also be passed as an argument to the startup script, but that might not be backward compatible.
I'd be glad to put together a pull request if others agree this would be a useful addition, and there's consensus on the best solution.
sudo ./myCoolApp.run --target myCoolTmp
leaves the directory myCoolTmp when the installation is complete. I think this is only supposed to happen with --keep ?
Since commit 842dedf, makeself sets a very restrictive umask 077 on the files that it unpacks. This is especially bothersome when building archives with --notemp and --target to specify the location of the extracted archive, with the expected permissions.
Is it possible to override the umask through some additional option set at packaging-time?
I'm writing a maven plugin to wrap this and noticed base64 arg is listed twice on the readme. Can you take a look at that?
Hello,
I created archive with simple command from examples but start of script has lines:
No LSM. EOLSM exit 0
Which basically means unless I provide LSM file I cannot create archive. The manual points to LSM as being option.
du is an estimate of the size of the files. (man du).
This estimate can vary greatly from run to run, and thus provide different results when trying to get a reproducible build.
USIZE=du $DU_ARGS "$archdir" | awk '{print $1}'
should be changed to use stat instead.
Hi!
Firstly, I want to thank you for your work :)
I'm making a makeself archive with this command line:
makeself.sh \
--notemp \
--bzip2 \
"files/" \
"my_archive.bz2.run" \
"Hello" \
./setup.sh "some-arguments"
When I run my installer with the --check argument, no problem:
sh my_archive.bz2.run --check
Verifying archive integrity... 100% MD5 checksums are OK. All good.
When I run my installer without argument, the installation is done right:
sh my_archive.bz2.run
Creating directory files
Verifying archive integrity... 100% All good.
Uncompressing Hello 100%
But when I run my installer with the --quiet argument, a problem occurs:
sh my_archive.bz2.run --quiet
Error in MD5 checksums: d41d8cd98f00b204e9800998ecf8427e is different from 09d483a36f78a640666b9e3ff19503af
The various files making up makeself have mixed tabs and spaces for indentation, as well as random trailing whitespace.
It would be useful to convert all tabs to spaces (or vice versa) - pick one and document it, please!
Also, remove all trailing whitespace.
Another one - header file is listed twice. The first one I assumed was to have file afterwards. The second one confirms that assumption.
As I get a little deeper into building a maven plugin around this I'll start looking in the source. At the moment, I have the baseline working and I'm just in the process of building out support for all elements.
If an argument passed to my script contains spaces, even if the argument is quoted, my script receives each space-separated segment as a separate argument.
Ordinarily I would backslash-escape the spaces, but I'm running this self-contained .run file from an installer tool that doesn't give me that option.
Please update makerun to support script arguments with spaces, so I can e.g., pass in file paths with spaces in them and actually use makerun in my installer :)
I expect it's as simple as wrapping each argument in quotes inside $SCRIPTARGS
?
/tmp/mkselftest 11:29:46 spiffytech@spiffywork _
$ cat src/echotest.sh
#!/bin/bash
echo $1
echo $2
echo $3
echo $4
/tmp/mkselftest 11:29:49 spiffytech@spiffywork _
$ makeself-2.2.0/makeself.sh src test.run "Multi-arg test" './echotest.sh'
Header is 498 lines long
WARNING: Overwriting existing file: test.run
About to compress 8 KB of data...
Adding files to archive named "test.run"...
./
./echotest.sh
CRC: 1342037018
MD5: 974773a52a5dc2a1614ef9ba8a80eeef
Self-extractable archive "test.run" successfully created.
/tmp/mkselftest 11:29:59 spiffytech@spiffywork _
$ ./test.run One "Two Args" Three
Verifying archive integrity... All good.
Uncompressing Multi-arg test 100%
One
Two
Args
Three
/tmp/mkselftest 11:32:01 spiffytech@spiffywork _
$ ./src/echotest.sh One "Two Args" Three
One
Two Args
Three
This is pretty serious, apparently the code in MS_dd_progress()
doesn't get handled well on HP-UX, as it makes the entire extraction process fail. It works fine if using --noprogress
when extracting.
The symptom is that the update-desktop-database
utility is not working properly with makeself
on Ubuntu 14.04. What does that have to do with makeself? I'm not entirely sure, but please read on...
This is an extremely strange bug and I'd like some help isolating the cause. I'll start by explaining my use-case... and the downstream bug report.
Script echos a foo.desktop
file to /usr/share/applications/foo.desktop
foo-install.sh
#!/bin/bash
# CREATE MIMETYPE FILE
echo "[Desktop Entry]
Type=Application
Name=Foo
Exec=x-terminal-emulator
Path=/
Icon=utilities-terminal
MimeType=application/x-foo;x-scheme-handler/foo;
Terminal=false
Comment=Foo Comment" > /usr/share/applications/foo.desktop
chmod 755 /usr/share/applications/foo.desktop
# REGISTER MIMETYPE FILE
update-desktop-database
... then...
makeself . foo-1.0.0.run "Foo Installer" "./foo-install.sh"
Test results
xdg-open foo:bar
Ubuntu Version | Makeself Version | Test Results |
---|---|---|
12.04 x64 | 2.1.5 | ✅ Pass |
14.04 x64 | 2.2.0 | ⛔ Fail |
Now I've tried many, many different test scenarios, such as using install
, nohup
, spawning a new process, etc, but the only thing that seems to fix the bug is to build the .run
package from Ubuntu 12.04.
The expected behavior is that xdg-open foo:bar
attempts to open x-terminal-emulator
with the parameter bar
, which is a registered URI/Mimetype for a web browser to use (similar in how Ubuntu registers apt://
for the Software Center).
The actual behavior is that the update-desktop-database
command executes properly (I can pipe its output to a file and see it is executing) but the Ubuntu desktop doesn't register the command properly.
sudo update-desktop-database
from an interactive terminal after install, the Mimetype is registered properly, every single time./usr/share/applications/foo.desktop
and run update-desktop-database
again which will unregister the foo:
mimetype.So my question is... how does one begin troubleshooting a bug like this?
Again, the packages created on 12.04 don't experience this problem, even when being run on 14.04, so this leads me to believe it is a packaging bug somewhere, but I'm not sure how to debug further.
Any idea why I get a Permission denied error when trying to execute the .run program made with makeself:
./compile/exe/linux/test.run
Verifying archive integrity... All good.
Uncompressing Installer for test software.....
./compile/exe/linux/test.run: 1: eval: ./post_extract.sh: Permission denied
post_extract.sh contains just an echo
#!/bin/sh
echo "foo"
If I execute the .run file from terminal it's ok.
But if I execute it from Node.js under my Ubuntu machine it pops up a terminal window and says "Press return to close this window...".
I tried the nowait parameter but seems it isn't doing anything.
Prooflink: https://github.com/megastep/makeself/blob/master/makeself.sh#L239
If I execute a regular .sh script from Node.js it executes fine.
Is there a solution to this issue?
attempting to decompress a base64 encoded file results in an error on macOS 10.12:
Uncompressing /Users/[me]/Desktop/bytes/install.shbase64: invalid option -- d
Usage: base64 [-hvD] [-b num] [-i in_file] [-o out_file]
-h, --help display this message
-D, --decode decodes input
-b, --break break encoded string into num character lines
-i, --input input file (default: "-" for stdin)
-o, --output output file (default: "-" for stdout)
100%
replacing base64 -D -i
with base64 -d
in the decompression script seems to work.
This is probably just an OS X thing... FYI.
I like to create source distributions with git archive
which knows to exclude some files based on .gitattributes
. Is there a way to pass the script an extant archive rather than having it create one for you from a directory?
I see there is support for encrypting an archive with gpg or ssl, but I would like to add on a digital signature that the script verifies before unpacking.
Hi.
FYI, with master revision, the --append option seems to be breaking the archive integrity. When trying to open the resulting file, we get an MD5 checksum error.
It's ok with the 2.2.0.
When creating a makeself archive of the current dir '.' and then extracting this, the chown and chmod apply to '.' - which means anything already in the current dir where the archive is extracted get chown / chmod'd as well (and all their descendants) as it is done recursively.
I'm quite impressed with makeself
, it's a perfect solution for its use-case, and I'm also glad that it's available in Ubuntu repositories.
But... latest version is 2.1.5, he same as in... Ubuntu 10.04! 3 years! That a long time for no releases. I assumed project was dead, but github shows otherwise: it's alive and healthy, constant updates, many pulls, and new features.
I specially liked the option to encode in base64, introduced an year ago. Keeping it ASCII-only is nice!
So... when can we expect a new release? Is there any reason (instability, insecure) for not making the new features official?
Thanks!
With the busybox tools on Linux:
-the ibs, obs and sync options to dd are optional, and must be enabled at compile time. They aren't enabled on OpenWRT 8.09 for example, so makeself won't work on my router
-df command does not support the '-P' option
On Solaris 10:
-the 'df' command in /usr/bin does not support the '-P' option. Makeself also checks for binaries in /usr/xpg4/bin, but those are only available if the SUNWxcu4 package is installed. Script fails with a syntax error
-id/chgrp/chmod also fail because of unsupported options, but the script keeps going on
I'm trying to fix the df bug at the moment.
The dd bug would require to rely on if/of/bs/count/skip/seek only, or by removing dd altogether.
I've been testing makeself version 2.2.0. I noticed that --info always shows "Uncompressed size: 1 KB", no matter how much stuff is in the source directory. I added set -x and set -v to makeself.sh and saw that "du -sk " was returning 1. Running by hand does the same. The problem appears to be that I am building on a net-mounted filesystem, and du doesn't seem to get accurate block count for directories in that case. Moving off the net seems to fix it.
In the first example below note that "ls -l --blocksize=K" gives accurate block sizes for files on the net mount, but incorrectly gives 0 as the total size. "ls -ld --blocksize=K" gives "1" as the directory size, which matches the "du -sk" value, but disagrees with "ls -ld" on a non-net mount.
In the second (non-net) example the "du -sk" value is - correctly - the sum of the "ls -l" and "ls -ld" values. So, on my net mount both "du" and "ls -ld" return bogus total sizes, but "ls -l" can be relied on to return valid file sizes that can be added up. I don't know how to get a good directory sizing on the net mount.
Full disclosure: the filesystem is shared between VMWare VMs on a MacBook Pro, over localhost. Since the underlying medium is SSD, and the blocksize is virtualized, this may affect behavior.
Here's what I get on the net mount:
me@ubuntu:/devshare/someplace/install/SXI-Linux$ du -sk source-files/devshare/someplace/install/SXI-Linux$ ls -l --block-size=K source-files
1 source-files
me@ubuntu:
total 0K
-rwxr-xr-x 1 501 dialout 6K Aug 6 14:57 config.sh
-rwxr-xr-x 1 501 dialout 7K Aug 3 19:20 isysvd
-rwxr-xr-x 1 501 dialout 142K Aug 3 14:53 pqos.exe
-rwxr-xr-x 1 501 dialout 1K Aug 3 12:09 pqosSvc.env
-rw-r--r-- 1 501 dialout 7K Aug 3 12:09 README
me@ubuntu:~/devshare/someplacel/SXI-Linux$ ls -ld --block-size=K source-files
drwxr-xr-x 1 501 dialout 1K Aug 6 14:57 source-files
Here's what I get on a non-net-mount:
me@ubuntu:/tmp$ du -sk source-files
176 source-files
me@ubuntu:/tmp$ ls -l --block-size=K source-files
total 172K
-rwxr-xr-x 1 me me 6K Aug 6 16:33 config.sh
-rwxr-xr-x 1 me me 7K Aug 6 16:33 isysvd
-rwxr-xr-x 1 me me 142K Aug 6 16:33 pqos.exe
-rwxr-xr-x 1 me me 1K Aug 6 16:33 pqosSvc.env
-rw-r--r-- 1 me me 7K Aug 6 16:33 README
me@ubuntu:/tmp$ ls -ld --block-size=K source-files
drwxr-xr-x 2 me garybjerke 4K Aug 6 16:33 source-files
(from a fresh pull on github...)
Trying to debug an issue with small .run files, I made a very small run file, with only a simple small setup.sh in there.
./makeself creates the .run file successfully.
Header is 498 lines long
About to compress 20 KB of data...
Adding files to archive named "/home/erikb/Desktop/ok.run"...
./
./setup.sh
CRC: 1463274277
MD5: 9ecfdabf8e98605753dea465bd67aa6b
Self-extractible archive "/home/erikb/Desktop/ok.run" successfully created.
However, when I try to run the resultant .run....
Verifying archive integrity... All good.
Uncompressing OKTHEN 100%
gzip: stdin: unexpected end of file
Extraction failed.
Signal caught, cleaning up
Hello,
First of all, I always appreciate to you.
I request one additonal feature.
That is for multiple volumn file.
For example, if the outfile of makeself script is very large size, it might not be transferred via ftp in very slow or weak environment.
So, I kindly request you to support multiple volumn file.
Thank you.
May I suggest to implement a new option to suppress output from tar -cvf
but keep other useful message such as Self-extractable archive "foo-1.0.bin" successfully created.
?
Currently option 'v' for tar is enabled by default and can be disabled by option --quiet
but that also suppress other useful message.
I cannot get --tar-extra
to work.
Could you please add a usage example to your README.
I have a tried simply ...
makeself --tar-extra --preserve-permissions etc etc
... but the result is a new archive created called --preserve-permissions
and the following error :
tar: -: Cannot stat: No such file or directory
tar: ./--preserve-permissions: file is the archive; not dumped
tar: Exiting with failure status due to previous errors
I am trying to patch up nixstaller which uses makeself to produce unix installers. However the issue I am now running into is that with LARGE games (1+GB sh archives) the amount of tmp space required is getting to be a problem. So my thinking is to modify makeself such that it ONLY extracts out some of the file contents (e.g the installer executable and configuration) and leaves the game install archive (the 1.7GB portion in one example) in the ".sh" archive. Then somehow pass the path to where the SH file is originally locate to the startup script so that the installer can locate and simply extract the archive directly from the original SH file.
Any suggestions/ideas on how to modify makeself to accomplish this would be greatly appreciate. I am perfectly find with modifying and submitting a pull-request. I just would like your thoughts on how to attack this issue cleanly.
Hello! I think Makeself has been really great, but I really think there should be some way to extract the files without executing the installer.
I did some Googling and I couldn't find anything, except for this: #37 but they apparently had a different issue since —noexec helped them. I agree however that there should be something like makeself --extract installer.run
Is there some simple-ish script I can use to extract the contents of the installer without having to execute it? I'll be working on a script in the meanwhile and I'll post it here if I get there first, but help would be nice! I also think implementing a makeself --extract
option would be great.
Thanks :)
I got a few cases where the --license option won't work because of invalid or incompatible characters in the EULA document.
Hi,
The COPYING file contains outdated information, you can get the latest license here:
https://www.gnu.org/licenses/gpl-2.0.txt
The terms of the license haven't changed but a few administrative informations have.
Best Regards,
Dridi
Would there be any opposition to me filing a pull request for an extra option to filter some of the data included in the --info
field that is included in the final output (ie: my_installer.run
)? One thing I'd like to remove is the fields showing the full command used to generate the installer, which includes the full path to the source locations (ie: my home folder). I'd like to strip those out of "production" installers. In my case, I'd like to prevent the following from appearing in a production installer:
echo Built with Makeself version 2.3.0 on
echo Build command was: "./makeself.sh \\
\"/home/ford_prefect/installer\" \\
\"/home/ford_prefect/installer.run\" \\
\"42\" \\
\"./42.sh\""
When the tar command cannot pack a file and exits with 1 during the build step, makeself.sh ignores that and says "Self-extractable archive "..." successfully created." Errors of the tar in the pipe can be caught by replacing
OLD: ( tar $TAR_EXTRA -$TAR_ARGS - . | eval "$GZIP_CMD" >&3 )
with
NEW: ( tar $TAR_EXTRA -$TAR_ARGS - . | eval "$GZIP_CMD" >&3 && test $PIPESTATUS = 0 )
BTW: makeself is a great tool and I love it!
I'm using makeself in a situation where I'd only like warnings and errors printed to console like -q when executing the outputted binary and not the
Verifying archive integrity... All good.
Uncompressing *
text currently present. This would allow piping the output of binaries to other commands/text files the same as if the startup_script
has been run by itself. It would also imply the --noprogress flag. Is this something others would be interested in?
Hello Stephane,
thanks for your great job done the last years. We would like to use makeself to install our software on embedded systems and while testing the setup natively on the boxes eval has been marked as missing.
I will asked the boxes distributor to add all missing dependencies. Do you have a list of them? Checking them on a debian derivate only shows bzip2 as a dependency. Eval as a part of bash which means bash is required at all?
Best regards,
Erik
makeself --target /home/Install ./Install ./latest "nstaller" ./latest
when I run ./latest it works fine and when i try sh latest, it does not work
I need to install it by http url -> curl -o latest -L http://example.com/latest && sh latest
what wrong with above and how can i fix it.
I'd like to be able to pass args to my packaged scripts at runtime, not buildtime. Is it possible?
I would like to suggest adding an option to allow to check that the user is "root", either because using "sudo" or actually root, before performing any kind of copying/extracting.
In fact, if the installer requires root privileges, but those are not available, this could save quite some time if the installer is big.
Version 2.2.0 was released 4 months ago but the web site says the latest version is 2.1.5 and only mentions github as a source of development versions.
Hi,
I've noticed that extraction is intermittently failing on VFAT (FAT32) and NTFS file systems when started from Linux. I've tried on both ARM and x86 architectures - sometimes it deadloops and sometimes it does extract the files (not sure if their integrity is good), but fails with the following message:
Verifying archive integrity... All good.
Uncompressing FW v1.0........Extraction failed.
Terminated
Are NTFS and/or FAT going to be supported in the future?
Change 436cf30 added a call to "id -u", which is not supported in Solaris 10. The /usr/xpg4/bin/id binary does support the "-u" option, but that's not called explicitly.
This may be bypassed, of course, by fiddling with $PATH order. Unfortunately, pure-Bourne shell doesn't populate the $UID variable, so it seems the right answer will be slightly more complex than I'd wish.
More generally, there is no documentation on writing the startup script.
A few minutes ago my system became practically unusable due to the fact that "chown/chmod" changed permissions on every file on my system. I needed to extract files to a particular location in /etc directory. When I ran the test script with sudo permissions I expected the sudo to be used for writing to the target directory, not to change ownership of files completely unrelated to what I was doing. I suggest to change the default behavior of the script to NOT change ownership of any files unless the user sets a flag to do that explicitly.
./makeself.sh /home/joev/mysrc code.sh "Test archive" echo "Hi"
Header is 458 lines long
About to compress 8 KB of data...
Adding files to archive named "code.sh"...
./
./super.txt
CRC: 347548649
MD5: b447088cd980784c585516967ff30f86
Self-extractible archive "code.sh" successfully created.
~/makeself $ ./code.sh
Verifying archive integrity... All good.
Uncompressing Test archive./code.sh: 435: cursor[0]=\055: not found
./code.sh: 435: cursor[1]=\134: not found
./code.sh: 435: cursor[2]=\174: not found
./code.sh: 435: cursor[3]=\057: not found
100%
gzip: stdin: unexpected end of file
Extraction failed.
Signal caught, cleaning up
'eval' is called on the launched script without any inspection to see if the target $tmpdir is executable.
In cases where (.e.g) /tmp is a ext3 filesystem mounted with noexec, which is frankly not uncommon, we see errors such as.
$ ./s.sh
Verifying archive integrity... All good.
Uncompressing Application App version other........................
./s.sh : line 387: ./installer.sh: Permission denied
At the very least, it should trap a more indicative error.
Thanks for useful project, is there any ideas to check minimum requried libc version via custom command ? Im not good at bash scripting or is this could be considered as feature request?
many thanks.
It seems that the method makeself.sh uses to find md5sum, md5 or digest is not working correctly if which
is not present. It falls back to type
, which can output a human-readable message ("md5sum is /some/path/to/md5sum") rather than a path, which then gets passed to test -x
. This means makeself prints "none, MD5 command not found" even though md5sum is available.
Replacing this snippet...
MD5_PATH=`exec <&- 2>&-; which md5sum || type md5sum`
test -x "$MD5_PATH" || MD5_PATH=`exec <&- 2>&-; which md5 || type md5`
test -x "$MD5_PATH" || MD5_PATH=`exec <&- 2>&-; which digest || type digest`
...by this snippet...
MD5_PATH=`command -v md5sum 2>/dev/null`
test -x "$MD5_PATH" || MD5_PATH=`command -v md5 2>/dev/null`
test -x "$MD5_PATH" || MD5_PATH=`command -v digest 2>/dev/null`
...seems to fix the issue on my machine (ref).
Is there any way to make the resulting file executable by piping to sh? Some tools use the following style command for running scripts and it would be really nice to be able to send in a makeself archive to those tools.
curl URL | sh
I zeroed out the checksums, but the script still seems to reference $0. I know arx can do it, but I imagine it combines the binary data with the shell script differently.
Following my comment on 48304a7
Could you revert it?
MD5 has been widely considered unsafe for use for the past 15-20 years, and as of today it provides absolutely no security at all.
I would strongly recommend switching to SHA256 (command sha256sum
instead of md5sum
) to verify the integrity of files, since MD5 is very easily falsified.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.