Hacker News Reader

Comment by otabdeveloper | Hacker News Reader

Seems unnecessarily complicated.

A script like this gets you 95% of the way there:

  mkdir AppDir
  mkdir AppDir/bin
  mkdir AppDir/data
  
  cp $INSTALLDIR/app AppDir/bin
  cp -r $INSTALLDIR/data AppDir
  cp `ldd AppDir/bin/app | grep -o '\W/[^ ]*'` AppDir/bin
  
  cat << "EOF" > AppDir/app
  #!/bin/bash
  SCRIPT_PATH=$(dirname $(readlink -f $0))
  $SCRIPT_PATH/bin/ld-*.so.2 --library-path $SCRIPT_PATH/bin $SCRIPT_PATH/bin/app $* 
  EOF

(Sometimes I wonder if people make a big mystery of Linux app distribution on purpose, to discourage distribution outside of proper, secure channels.)

View on HN

Yes, except that you might want to be a bit more selective in which parts you use from the base system and which parts you want to bundle - some people might not want to have e.g. glibc in each app bundle. This is where it starts to become a little more complicated than the above, see https://github.com/probonopd/AppImageKit/wiki/Creating-AppIm...

If you don't have glibc in each app bundle, it won't run everywhere. Different distros have different versions of glibc and it's very easy to end up in a situation where you use some symbol that's not defined in the system one.

Which is why you want to build on a system that is using an older version of glibc than the systems you want to run your software on. Assuming that glibc does't break backward compatibility, which it really shouldn't (and in practice, rarely ever did). Or use https://github.com/probonopd/AppImageKit/tree/master/LibcWra...

This makes a mockery of shared libraries. The technical debt will accrue and run unfathomably deep. Security failures due to currency issues are simply the most obvious. The insoluble mystery bugs of mismatched dependencies will plague application developers that choose this distribution strategy.

Yay for hyperbole ;)

Shared libraries are most useful when matched within a specific distribution's package/version chain.

Tying a third-party distributed package to a given shared library, on the other hand, is less helpful than just supplying the expected, tested, and supported library upfront and still let knowledgeable operators do what they will on their chosen platform.

No technical debt is accrued if the libs are truly interchangeable anyway, but especially if they are not, this stands a better shot at fixing it.

Your suggestion amounts to advocacy of tight coupling, which massively dilutes the long-term benefit of shared libraries and leads developers under pressure of expediency into a tangled thicket of anti-patterns. This is an illustration of how technical debt is accrued, and I've seen it umpteen times, never to the good.

If you don't have Linux in each app bundle, it won't run everywhere. Linux breaks userspace ABI sometimes.

Everything seem complicated when you dont properly understand the problem.

That's a really interesting thought, because everything also seems simple when you don't properly understand the problem.

("Let Apple open the damn back door, let the FBI know what's on the phone, then close it again. This isn't difficult." — Piers Morgan)

you two are discussing separate sides of the same coin. or to clarify:

people with a naive understanding of a problem will always feel like people who don't design solutions that are overly complex.

people with a deeper understanding of a problem will always feel like people who don't design solutions that are overly simplistic.

I've successfully refactored way too much code that was needlessly complex to agree. Better understanding of a problem frequently leads to simpler solutions. It doesn't always lead to more complexity.

Whether people who are bad at programming, or at least inexperienced, write overly complicated code or not has got nothing to do with what I said.

Except that there's word-choice correlation.

That depends on your target user. I can't imagine asking my parents to run your script (even if it was packaged up as a single file), but I'd like to think that they could run something like AppImage without too much problem.

What happens if the app forks a child process? Chrome, for example, starts nacl_helper and chrome-sandbox. Is there a straightforward way to get those children to inherit the dynamic loader and library path?

I think you meant "$@" rather than $*

(The quotes in "$@" are important.)

Also, your script will fall over if any of the paths have spaces in them, such as INSTALLDIR.

You should use lowercase for variable names like SCRIPT_PATH. Uppercase is for exported variables.

readlink -f $0 breaks on OS X. You must do both readlink -f $0 and readlink $0 in order for it to work everywhere.

Shell scripting isn't easy. It took a year to understand these nuances to the point that they're second-nature, and I'm still discovering new ones. Anything that improves this situation would be a welcome change in my opinion.

EDIT: cat<<'EOF' is necessary here. cat<<"EOF" will interpolate variables.

To elaborate, the GP should have put quotes around command arguments that included variables. For example:

  cp $INSTALLDIR/app AppDir/bin

Should be:

  cp "$INSTALLDIR/app" AppDir/bin

> Shell scripting isn't easy. It took a year to understand

That might make it seem like too hard for some people. It's really not that bad. These particular mistakes were beginner's mistakes.

But it is tricky! I usually try to tell people to avoid writing shell scripts until you've at least read the "Bash Beginners Guide" or something similar. It's comparably short (remember, you're learning a new language and an arcane one at that) but at least lets you avoid the easy traps. Also, indent and comment. Surprisingly many people seem to think hygiene is somehow less important outside their main language.

On a side note, what's up with not reading manuals these days? When I am tasked with something new, no matter how trivial, my first step is to at least skim the manual get a feel for what the problem domain looks like and how you are supposed to wield the tool I am about to use. Turns out nobody does that anymore. Zero, out of over a dozen people in my closest (java, web) team have read the documentation for the product we build on. I find it unprofessional, but I realize I'm the strange one and it's probably just me getting older.

> On a side note, what's up with not reading manuals these days?

The difficulty of finding manuals, and when you do, they're badly written in such a way that they assume all sorts of contextual knowledge based around the sorts of problems the author of the software was trying to solve in 1986 or whatever year. Manual writing is at least 1000x more difficult than bash scripting, because you have no way of knowing up front how the target "machine" is going to interpret your "script".

And of course that's all assuming a manual even exists at all.

Some commands that can help with nuances of shell:

Check syntax:

sh -n myscript

Check for bash-specific syntax:

checkbashisms myscript

Check for various gotchas:

shellcheck myscript

Check for style:

bashate myscript

Check for badness:

grep -rE '(wget|curl).\|( sudo)? *(ba|z|)sh' myscript

> A script like this gets you 95% of the way there

Ohhh, but that five percent!

Don't steal my code, please. Don't bundle my open library with your proprietary app without my written permission.

Ohh, yeah, so you force everybody to understand the command line when something does not work as expected.

95% of the way means it is not finished. When I buy a car the seller better does not say that the car works 95% of the time.

Installing something in millions of computers is hard. We do it. Being able to install something on one computer with a person that is a computer programmer with 20 years experience with the command line is completely different from making it to just work for millions of people.

Apple actually makes it work for millions of people in a very simple and elegant way. As a geek I could use homebrew or any other system in Linux if I want, but Apple's system works great for most people.

Reply on news.ycombinator.com