Create and Repair Symlinks with sln

sln exists for the moment your shared libraries break so badly that even ln refuses to run. Unlike ln, sln is statically linked, so it works even when the dynamic linker itself is broken, which makes it the tool you reach for when a library symlink is the actual problem. Allow about ten minutes for a one-off repair, plus time to check the paths. This guide describes Linux man-pages 6.7, dated 31 October 2023. The manual is installed here as package manpages 6.7-2, but the sln executable is not installed on this machine, so the command examples must be run on a system that provides the binary.

Prerequisites: a shell, a source path that should be the link target, and a destination path where the new link should live. Creating a link in a directory you own is an ordinary user operation. Repairing a system library link usually needs root privileges, and should be done from a maintenance shell with a recovery path.

1. Confirm that the binary is available

The manual page can be present without the executable. Check both before planning a repair:

$ command -v sln
/usr/sbin/sln
$ man sln

• Path is an example. The one printed by command -v above is illustrative, not a promise about your system.
• No output means stop. Do not substitute ln silently: it is a different program with different failure and option behaviour.
• Find the package. Check your distribution's package records for whatever supplies sln, then install it through your normal change process. The local manpage does not name that package itself.

Checkpoint: Continue only when command -v sln returns an executable path.

2. Create one symbolic link

The simplest form takes exactly two arguments: the source path to store in the link, then the destination path to create. Use a disposable directory for a first test:

$ work=/tmp/sln-test
$ mkdir -p "$work"
$ printf 'sample\n' > "$work/source.txt"
$ sln "$work/source.txt" "$work/current.txt"
$ readlink "$work/current.txt"
/tmp/sln-test/source.txt

sln creates current.txt as a symbolic link to source.txt; it does not copy the file contents. The readlink check shows the link text, which is the quickest way to catch a mistyped source or destination.

Do not use sudo for this test. For a system location, first inspect the existing destination and its parent directory:

$ ls -ld /path/to/parent /path/to/destination
$ readlink /path/to/destination

If the destination already exists, stop and decide whether replacing it is authorised. A failed repair is easier to recover from than an overwritten link or file. Take a backup or record the existing target before making a privileged change.

3. Create links from a file list

The second form accepts one file-list path. Each line contains a space-separated source and destination pair. It behaves as though sln had been run once for each line:

$ cat > /tmp/sln-links.list <<'EOF'
/tmp/sln-test/source.txt /tmp/sln-test/one.txt
/tmp/sln-test/source.txt /tmp/sln-test/two.txt
EOF
$ sln /tmp/sln-links.list
$ readlink /tmp/sln-test/one.txt
/tmp/sln-test/source.txt
$ readlink /tmp/sln-test/two.txt
/tmp/sln-test/source.txt

The file-list syntax is deliberately narrow: paths are separated by spaces. A pathname containing a space cannot be represented safely by simply quoting it inside this list, because the list is not described as a shell command file. Use paths without spaces, or create that link with the two-argument form after checking the exact command.

Review a generated list before running it. One swapped pair can create a link in the wrong place, and every line is an operation. Keep the list in a directory with suitable permissions while it is being reviewed.

4. Understand the no-options rule

The Linux man-page documents no command-line options for sln. Its interface is either sln source dest or sln filelist, full stop. Do not assume that familiar ln switches such as -s, -f or -v are accepted. If you need those behaviours, stop and consult the installed sln documentation rather than adding flags from memory.

This also makes argument mistakes easy to miss in scripts. Validate the number and contents of your source and destination arguments before invoking the command. Use absolute paths for recovery work so that a changed working directory cannot redirect the operation.

5. Verify or recover the change

Check each destination with readlink, then check the link itself with test:

$ readlink /tmp/sln-test/current.txt
/tmp/sln-test/source.txt
$ test -L /tmp/sln-test/current.txt && echo 'symbolic link exists'
symbolic link exists
$ test -e /tmp/sln-test/current.txt && echo 'target resolves'
target resolves

test -L checks the directory entry is a symbolic link. test -e checks that its target currently resolves. A broken symbolic link can pass the first check and fail the second, which is useful evidence during recovery.

Recovery: If you created only the disposable example, remove the link and temporary files with an explicit, reviewed command when you have finished. To undo a link in a real destination, use unlink /path/to/link only after confirming that the path is a symbolic link, not a regular file or directory. Never use a wildcard for recovery, and do not remove the source target as an attempted undo. If a service depends on the link, restart it only according to that service's runbook and maintenance window.

Done means

• Binary confirmed. command -v sln found the intended executable.
• Right form used. You used either two paths or a reviewed space-separated file list.
• Destination checked first. The destination was inspected before any privileged repair.
• Target verified. readlink shows the expected target for every link.
• State confirmed. test -L and, where appropriate, test -e confirm the resulting state.
• Undo path is precise. You have not confused removing a link with removing its target.