1

Shell scripts often have to depend on tools that may not be installed on the users' computer. To circumvent this problem, many scripts have multiple fallbacks.

IMO doing such things only leads to complex code, and it is not uncommon to find a large chunk of the script just devoted to compatibility reasons.

Why couldn't be the dependencies just be included in the script? The script could include these programs (as an appended compressed section, like makeself does), and simply use them while running?

To clarify, of course this does not apply to things like wget and curl; the code for each would be minimal in that case. I'm talking about scripts that involve GUIs, and there's a lot of code to support such programs (zenity/yad/xdialog etc.), which involve wildly different syntaxes.

Is there a reason why the above isn't done?

4
  • 5
    For one, because I probably wouldn't use your shell script if it came as a 300MB download.
    – terdon
    Jul 14, 2014 at 16:53
  • @terdon, well, I think such an approach wouldn't give me a script any larger than 5MB. You would get an smallish distro in even 30 MB :)
    – user48923
    Jul 14, 2014 at 17:20
  • So some additional lines of shell script checking the existence of common utilities is more "complex" than having to download a GUI?
    – jasonwryan
    Jul 14, 2014 at 17:27
  • 1
    My point is that it depends on what you want to include with it. It also depends on how you would include it. As source? As packages? For which distribution? Which version? Will the libraries you bundle be compatible with what is installed? If you include the programs already compiled, your script is no longer portable. Basically doing this defeats the purpose of using a shell language in the first place. If you really need to do something like that, it's a good indication that your script is getting too complex and you should probably look into a different approach.
    – terdon
    Jul 14, 2014 at 17:28

1 Answer 1

5

Is there a reason why the above isn't done?

Shell scripts are portable because they use a runtime interpreter. The tools you've used as examples, in particular GUI tools, are not. This means you will have to have a separate version for Linux/x86, Linux/x86-64, Linux/armel, Linux/armhf, OSX/x86-64, OpenBSD/mipsel, and whatever other platform you hope to run this on.

Further, the normal compiled version of such things depend on shared libraries. If you really don't want to have to worry about dependencies but you want to include SomeGUIApp, you'll either need a statically compiled version of it, or else (6 == 2 * 3) to include those dependencies, and their dependencies, and...1 Either way, this is the point at which you will realize what you thought was "only 5 mb" is going to end up as hundreds. Have a look at your memory consumption right now; if it's a normal GUI desktop doing normal-ish things, the bulk of that is those GUI libs, etc.

As a long term linux user, I generally deplore stuff that includes binaries because of all the mistakes that can be made with generically compiled things. I'll only actually use them if there is no other choice (or, of course, they came from the distro).

Now imagine if everyone did this. Do I need 15 copies of SomeGUIApp on my system? It's much better to list things as a prerequisite -- if I don't have it, I can get it -- that to provide me with yet another copy of something I already have.

1. Perhaps the point is: you have to draw the line somewhere, so why not draw it at what's original in the package?

You must log in to answer this question.