unix-common: move applicable common/a*.md files

[cyqsimon]

This is the first PR out of 27 (26 letters + 1 for numbers) that starts the work on #1868. I feel like instead of talking for another 6 years we might as well start doing it. So please feel free to still discuss whether this is a good idea or not.

To make things easier, I wrote a little script to automate things a bit:

# in /pages/common/
for FILE in a*; do
  bat $FILE
  read -r -p "Move? [y/N] " response
  if [[ "${response,,}" == y ]]; then
    mv $FILE ../unix-common/
    echo "Moved common/$FILE to unix-common/$FILE"
  else
    echo "Skipped common/$FILE"
  fi
done

Then I used this script to apply those moves to all languages:

# in /
pushd pages/unix-common/
TO_MOVE=(*)
popd

for LANG in pages.*; do
  if ! [[ -d "$LANG/common" ]]; then
    continue
  fi
  mkdir -p "$LANG/unix-common"
  pushd "$LANG/common"
  for FILE in "${TO_MOVE[@]}"; do
    if [[ -f "$FILE" ]]; then
      mv "$FILE" ../unix-common/
      echo "Moved $LANG/common/$FILE"
    else
      echo "$LANG/common/$FILE does not exist"
    fi
  done
  popd
done

[cyqsimon]

Damn sorry for the mass ping. I didn't foresee that happening.

Codeowners of various languages, please ignore this review request. All changes here are simple moves.

[sebastiaanspeck]

All changes here are simple moves.

But the move introduces a new "platform". IFAIK we need to make more changes to introduce a new platform besides only creating a new folder

[kbdharun]

Thanks for your contribution,

The current common directory is already used to document POSIX UNIX commands and has a tracking issue for it. For Windows commands, most of them have additional or different options so we always create a new page along with links to Microsoft Learn links for documentation.

Personally, I wouldn't suggest making major architectural changes like this without discussion with client authors, etc that's why this change/old discussion has still been stale even after 4-6 years (as all of the page resolver code needs to be modified, and we already have a major transition going on currently with change of cache source, so the priority is to update clients for this within the next year or 2) as there are people both supporting it's addition/opposing it both here and in the previous chatroom (unindexed Gitter chatroom, which is still present if you scroll long enough through the Element one).

This linked proposal afaik was written before another issue where we decided to document POSIX commands in common so let's discuss this again, before starting with any changes.

---

Also, for #1868. Clients like tlrc, etc print a message before the page contents, when displaying it from common on other platforms like Windows, etc this way users using WSL and Docker containers can still access the POSIX variant of the page in host and if present then platform specific variants gets resolved with higher precedence in the current directory structure.

Note: this isn't documented yet as it is only done by a few clients, but I could propose it as an addition (as suggestion) for a future client specification.

[gutjuri]

Also, for #1868. Clients like tlrc, etc print a message before the page contents, when displaying it from common on other platforms like Windows, etc this way users using WSL and Docker containers can still access the POSIX variant of the page in host and if present then platform specific variants gets resolved with higher precedence in the current directory structure.

Note: this isn't documented yet as it is only done by a few clients, but I could propose it as an addition (as suggestion) for a future client specification.

+1

Afaik all platforms we currently support (apart from windows) are unix-like (see: https://en.wikipedia.org/wiki/Unix-like). So from my perspective, a unix-common directory would be the same as the already existing common directory, since we already put pages in the common directory that are only available on a subset of the supported platforms.

[sebastiaanspeck]

IMO this PR could be closed without merging, hence the discussion above

[spageektti]

Separating unix-common from common makes no sense to me and I agree with sebastiaanspeck.

[cyqsimon]

Shall we close #1868 too then?