If install_hermes_memory_tencentdb.sh is invoked directly by the root
user (e.g. fresh server with root SSH login), the prior logic:
USERNAME=$(whoami) # → "root"
if [ "$(id -u)" -eq 0 ]; then
su - $USERNAME -c "bash $TEMP_SCRIPT" # → su - root → root → loops
fi
would spin forever: ``su - root`` enters a fresh root shell that re-runs
the script, which sees EUID=0 again and ``su -``-s itself once more.
Symptom (per issue #20):
[memory-tencentdb] Running as root, switching to root for installation...
[memory-tencentdb] Running as root, switching to root for installation...
... (only Ctrl+C stops it)
Fix:
1. ``USERNAME`` resolution adds two precedence steps before
``$(whoami)`` so admins running ``sudo bash install.sh`` end up
installing for the original user instead of for root:
a. ``INSTALL_AS_USER`` env override (explicit admin choice)
b. ``SUDO_USER`` (sudo's own record of the calling user)
c. ``whoami`` (final fallback)
2. The ``id -u == 0`` branch now skips the ``su -`` step when the
target user is also root — that's the recursion-trigger case. The
script proceeds inline as root for the rest of the install.
3. A new ``elif`` arm logs a clear ``"Running as root; target user is
also root — installing in place."`` so the operator sees what's
happening.
Verified by dry-run simulation of 5 scenarios:
| Case | Branch | USERNAME |
| --------------------------------------- | ------------- | -------- |
| root SSH direct (#20 reproducer) | INLINE | root |
| non-root user direct | NORMAL | <user> |
| sudo bash install.sh from non-root user | SU | <user> |
| root + INSTALL_AS_USER=bar | SU | bar |
| root + INSTALL_AS_USER=root | INLINE | root |
Closes#20.
Signed-off-by: 李冠辰 <liguanchen@xiaomi.com>