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.

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.

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.

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.

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.

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.

./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

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

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

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?

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.

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 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.

Scenario:

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.

One Possible Solution:

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.

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

More generally, there is no documentation on writing the startup script.

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?

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!

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.

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.

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.

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 got a few cases where the --license option won't work because of invalid or incompatible characters in the EULA document.

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\""

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

I'd like to be able to pass args to my packaged scripts at runtime, not buildtime. Is it possible?

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.

1. 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"

2. 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.

1. If a user manually runs sudo update-desktop-database from an interactive terminal after install, the Mimetype is registered properly, every single time.
2. To revert the mimetype installation for subsequent testing, remove /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.

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.

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.

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?

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.

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.

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?

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 writing a maven plugin to wrap this and noticed base64 arg is listed twice on the readme. Can you take a look at that?

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.

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.

sudo ./myCoolApp.run --target myCoolTmp

leaves the directory myCoolTmp when the installation is complete. I think this is only supposed to happen with --keep ?

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"

Following my comment on 48304a7

Could you revert it?

'eval' is called on the launched script without any inspection to see if the target $tmpdir is executable.

makeself-header.sh

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.

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'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?

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.

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

(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

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
1 source-files
me@ubuntu:/devshare/someplace/install/SXI-Linux$ ls -l --block-size=K source-files
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

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).

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.

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.

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.