Use Symlinks to Handle Command Aliases

[znarfm]

As discussed in #19136 (comment), there is a conflict between discoverability and usability. We want users to be able to find a page using an alias, but doing so clutters the namespace and makes tab completion difficult for commands with many subpages like npm.

I propose we use symlinks to represent aliases.

For example, to create the alias npm i for the npm-install page, we would have:

1. The real page: pages/common/npm-install.md
2. A symlink: pages/common/npm-i.md -> npm-install.md

This would be good as the page content only exists in one file. There will be no need for duplication or writing alias pages manually, we can just show the original non-aliased command page.

Trying it out

Here, I tried to create a symlink for npm install as npm i using ln -s npm-install.md npm-i.md.

tldr npm i now shows the original documentation for npm install:

Tab completion also seems to not capture any entry of npm-i:

Potential challenges

1. Contributors using Windows: I don't know anything about symlinks in Windows. In Linux, it's just easy to use ln -s.
2. Maintenance: If the original page is removed or renamed, of course the symlink will break. We also need another way to check if symlinks are pointing to a valid target.
3. Tab Completion: I don't know if this varies per tldr client. But the symlink does not show up in my tab completion. Or maybe it is because I am just modifying the local copy pages/ dir. Maybe tldr clients can adapt and add another config option to avoid or use symlink files for tab completions?

[ivanbaluta]

This is an interesting idea, but symlinks on Windows are problematic for cross-platform projects.
Historically, creating them required admin rights. While Developer Mode in modern Windows allows it, we can't assume users have it enabled. By default, Git on Windows often checks out symlinks as small text files containing the target path, which would break the functionality.