readlink has no -e option on busybox/alpine, realpath has no options at all

[pawamoy]

The resolve_link functions do not work on Alpine / Busybox (Alpine uses Busybox), because
Busybox's realpath has no option at all and its readlink just has the following (not -e):

BusyBox v1.28.4 (2018-07-17 15:21:40 UTC) multi-call binary.

Usage: readlink [-fnv] FILE

Display the value of a symlink

	-f	Canonicalize by following all symlinks
	-n	Don't add newline
	-v	Verbose

So I guess we'll have complexify the function a bit. Also I noticed you did not update the resolve_link function in basher, it still uses greadlink.

Here is a first draft:

resolve_link() {
  if type -p realpath >/dev/null; then
    realpath "$1"
  elif type -p readlink >/dev/null; then
    readlink -f "$1"
    # -e is actually not mandatory for our use-case, but -f is, to resolve . and ..
  # else ??
  fi
}

[juanibiapina]

Maybe just:

resolve_link() {
  if type -p realpath >/dev/null; then
    realpath "$1"
  else
    readlink -f "$1"
  fi
}

I didn't update resolve link in the binary file because it's copied over from rbenv and if it matches their use case, it should match ours.

[pawamoy]

I didn't update resolve link in the binary file because it's copied over from rbenv and if it matches their use case, it should match ours.

Yep I saw that while experimenting, it shouldn't be changed indeed 🙂

I like defaulting to readlink. I can open a PR if you want! We only need to update the function in basher-link and basher-link.bats

[pjeby]

FYI, bashup/realpaths has a well-tested ultraportable microlibrary for handling symlink resolution that requires only readlink with no args, and supports both OS X and busybox. It's CC0 so you can literally copy and paste whatever you want from it, and for your usecase you only need the first 31 lines (or just the first 20 if you don't care about absolute paths).

[pawamoy]

It's up to @juanibiapina. Using your library can be a good idea for portability reasons. Though we would have to decide how we use it (copy/paste in two files? share code in one file and source it from elsewhere?) and I'd leave that design decision to @juanibiapina too 🙂

Also, could be nice to update the Travis config to test on different distributions!

[juanibiapina]

For now I'd say to go with the simpler solution. If we ever need even more portability, we can revisit this decision.

The major difficulty I see is how to include dependent code in basher itself without complicating the installation process. I've tried this before and couldn't find a good way. We could always copy the code, but then this create other kinds of problems.

[pjeby]

I've got a solution for that, too. 😉

The way my projects do dependencies like that, is that during development, dependencies are checked out in a project-local, git-ignored basher directory (.deps/), and then any needed files are copied by a build script to the distribution directories and saved in revision control. To update a dependency, you just check out and build the project, then commit the copied file(s). This means that a plain checkout is still a valid, ready-to-use distribution, without needing --recursive. But you can still easily update the dependency.

The bashup/.devkit toolset makes this whole process easy to do; in fact it's a big part of what it was made for. A project using .devkit that needed to add realpaths would just add this to package.sh:

# BUILD_DEPS is a :-separated list, can use '@ref' to pin a branch or tag
# These projects' files can then be accessed under .deps/, and their BINS under .deps/bin
BUILD_DEPS=bashup/realpaths

And this to the end of .dkrc:

# Copy updated dependency to libexec
on build cp .deps/bin/bashup.realpaths libexec/

And then anybody who checked out the package could update the dependency by running script/build in a fresh checkout, and committing the change. In this way, your existing distribution process isn't affected, but you're not reliant on manual copy-paste to follow changes. You can also use script/clean at any time to get rid of cached dependencies and force an update.

Of course, you don't need .devkit in order to do all that; you can just add stuff to your makefile to do the same things!

The real point is just that this overall approach lets you bundle dependencies in git, without needing to copy-and-paste the updates, and without needing --recursive checkouts. Someone who only needs to use basher can still clone basher and run it; the dependency-fetching and copying would only happen when someone is developing basher, and they run the appropriate makefile target or .devkit script/.

[juanibiapina]

I like some of the ideas there. I'll keep that in mind!

[kadaan]

@juanibiapina What about falling back to perl for at least the osx (or any system with perl) case...

resolve_link() {
  if type -p realpath >/dev/null; then
    realpath "$1"
  else
    directory="$(readlink -f "$1" 2>&1)"
    if [ "$?" -ne "0" ] && [ "${directory#*readlink: illegal option -- f*}" != "$directory" ]; then
      if type -p perl >/dev/null; then
        perl -MCwd -le 'print Cwd::abs_path shift' "$1";
      else
        echo "$directory"
      fi
    else
      echo "$directory"
    fi
  fi
}

Might even be able to just try perl if the readlink -f call fails without checking for the failure message readlink: illegal option -- f. That would probably be fine, but might slow things down for readlink -f calls that were already returning errors other than illegal option -- f.

[pawamoy]

Well, perl is not available in official Bash Docker images 😕

[kadaan]

@pawamoy but in that case, readlink -f will work. And if not, the type -p perl will fail and the current behavior (failing tests...) will occur.

[pjeby]

True, but if you're writing that much code you might as well use something like:

resolve_link() {
	local target srcdir resolved
	while [[ -L "$1" ]] && target="$(readlink -- "$1")"; do
		srcdir="$(dirname "$1")"
		# Resolve relative to symlink's directory
		[[ $srcdir != . && $target != /* ]] && resolved=$srcdir/$target || resolved=$target
		# Break out if we found a symlink loop
		for target; do [[ $resolved != "$target" ]] || break 2; done
		# Add to the loop-detect list and tail-recurse
		set -- "$resolved" "$@"
	done
	cd "$(dirname "$1")" >/dev/null
	echo "$PWD/$(basename "$1")"
}

which isn't much bigger and only needs readlink.

[kadaan]

Nice code. In this case you would need a lot more tests. An alternative to add OS X support easily is to check for greadlink, that way I can install core utils with brew and things will just work. I might be wrong, but it looks like that is what bats does.

[pjeby]

The code I posted is a rip-off of realpath.follow from realpaths, which has a rather thorough test suite. So copying the original code instead of using the ripped-off version would also work, without requiring brew.

Conversely, checking for a bunch of different alternatives to readlink means tests need to be run on those OSes, but plain readlink -- X is the same everywhere you go, even OS X without homebrew.