Makeself: Make self-extractable archives on Unix | Hacker News Reader

Makeself: Make self-extractable archives on Unix

stephanepeter.com

45 pointsarunc25 comments

https://en.wikipedia.org/wiki/Shar

Funnily enough that Wikipedia page references this "makeself.sh" with a note on how some versions failed with bash 3 - https://en.wikipedia.org/wiki/Shar#cite_ref-3

actually just recently updated my 9menu from 1.8 (released 6/1/04) to 1.9 (released 6/25/15) [0]. Apparently took Mr. Robbins 11 years to fix some compile warnings HA.

It came as a shar. I was dumbfounded for a moment as I had never heard of a shell archive. pretty cool tech actually. I've been into UNIX and such for over five years and had never even come across one. Also came across Generic Window Manager during that time as well, which I had never heard of before. Further reading: [1] and [2].

[0]: ftp://freefriends.org/arnold/Source/

[1]: ftp://ftp.x.org/contrib/window_managers/gwm/

[2]: https://www.sics.se/~aho/gwm/

[3]: http://old.koalateam.com/gwm/

You would have known about shell archives if you'd been on usenet back in the day. Commonly used in news (and in email as well), in the days before MIME attachments.

interesting. I check in on usenet every once in awhile, but mostly just on mozilla/eternal september news servers (primarily for seamonkey/OS X/dr. who-related stuff). Interesting tid-bit. thanks for clearing that up.

Shar has done this for a long time.

http://linux.die.net/man/1/shar

Indeed, and the complete lack of credit for the idea on the makeself page is irritating.

It's written from the point of view of "I invented this neat idea of producing a self-extracting archive that is a shell script".

The opening paragraph desperately needs a sentence which begins like this: "This is similar to the traditional shar that we all know about, but better because ...".

If my history-spelunking is correct, BSD shar is 21 years old and makeself is 17 years old, so the relative difference is not that large.

The Wikipedia page for shar (https://en.wikipedia.org/wiki/Shar) lists a variation on shar being developed for VMS back in 1987 (28 years ago), so shar is older than that.

Hmm, that's true. BSD4.4 seems to have been the oldest version of Unix that included shar, so maybe before that point it was a separately distributed tool?

I guess if the answer is anywhere, it'll be on Usenet, but Google Groups' search-by-date functionality is hopelessly broken.

Earliest known post to Usenet was from Jim Rees in 1982, who credited James Gosling. For his part Gosling thinks it was originally written circa 1979.

https://blogs.oracle.com/jag/entry/shar_a_blast_from_the

Nice job tracking that down!

What value does this provide? It looks like nothing more than a security vulnerability with a new non-standard and crippled interface. Tar is available on all the target platforms, for example.

It's the Windows way: download this setup program and execute it to install on your computer.

In a pithy one liner: it's curl pipe bash for local binaries.

I've run into it when I used to install Virtualbox "Guest Additions" or whenever I'd make the questionable decision to use the latest video drivers during my annual dalliance with desktop Linux a decade ago.

The value it provides is fewer steps in an installation guide for non-power users (or as jakobdabo mentions below, particularly for users coming from the Windows "double click to install" world). It would extract and run a post extract hook. I haven't come across it much in the last few years though.

Self-extraction isn't any sort of additional security vulnerability if what you're using it for is to install a program that you're going to be executing.

(For installing non-executable material, it does elevate the risk.)

Even for an executable, the installation environment may be different from the execution environment (which may be sandboxed, mounted read-only, etc.). Moreover, a tarball gives you a reliable manifest so that you know what will happen before installing. A shell script just does whatever it wants, making it potentially surprising/destructive and difficult to clean up.

True. "Run foo.run thing as root, so it can put stuff in /usr/bin, then switch to your regular account to use it". Oops!

The thing is, that ship has largely sailed, with the proliferation of package management that prompts you for a password to go sudo.

   sudo apt-get install whatever # trust your distro
   sudo ./foo.run # trust foo.run's publisher, a bit worse

> * A shell script just does whatever it wants, making it potentially surprising/destructive and difficult to clean up.*

Just like Windows installers---which is why we need utilities like Revo Uninstaller. This lets us run the application's uninstaller first, then scan the entire filesystem and registry for what looks like bits and pieces that might belong to that program, and let the user select which of them to blow off. I use it quite a bit.

It's actually a reasonable app deployment mechanism for systems where you only have regular-user access. You can bundle up a compiled app, dependencies, and settings, and have a single, repeatable, easy to deploy build.

if the system has a tmpfs/ramdisk mount, it can also extract itself there, and have a no HDD deployment, which can dramatically speed things up too.

Please don't actually use this method to release Linux packages. Put it in a .tar.gz like everyone else. No need for additional complexity.

Actually, there are situations where this approach is very useful, and there /is/ a need for additional complexity

Can you describe them? I'm definitely in favor of just using tar, so I'd like to see what I'm missing.

.tar.xz preferrably

You could just use diff and patch:

   diff -Naur dummy my_project >xx

   patch -p0 <xx

Java for Unix was distributed as a .sh for a while.

Reply on news.ycombinator.com