Что не так с этим сценарием?

Поскольку McLovin говорит, автоматически набор, только для чтения UID (и EUID) переменная является специальной функцией bash (и некоторые другие оболочки). Это не стандартно для оболочек стиля Границы и sh как может предполагаться, не устанавливает эти переменные. В частности, sh в Ubuntu (в настоящее время, по умолчанию) dash, который не устанавливает их.

У Вас есть две опции:

1. Заставьте свой сценарий быть выполненным bash вместо sh.
2. Измените свой сценарий, таким образом, это более портативно и не требует bash.

Запущение Вашего скрипта с bash

Вы не сказали нам название своего сценария (который является хорошо). Я собираюсь назвать его cleanup, поскольку это - название подобного сценария в руководстве, Вы работаете от.

Обратите внимание в особенности, что я не называю его чем-то как cleanup.sh. Это вызвано тем, что я не рекомендую назвать его с a .sh суффикс:

• A .sh суффикс предполагает, что это совместимо с sh!
• Большинству сценариев не дают суффикс вообще, и имеющий a .sh или .bash суффикс может даже быть интерпретирован, поскольку предложение Вашего файла является "библиотекой", а не "высокоуровневым" сценарием. Таким образом, то, что это предоставляет код, который будет получен другими сценариями (например, с . встроенный), а не на самом деле выполненный непосредственно.

Однако включая a .sh суффикс не будет влиять на техническое поведение Вашего сценария всегда. Нет никакого технического преимущества или недостатка, связанного с выполнением так.

Добавьте hashbang строку как самую первую строку Вашего сценария: #!/bin/bash

Сделайте свой исполняемый файл сценария с chmod +x cleanup.

Теперь можно запустить скрипт путем выполнения команды:

• ./cleanup, когда это находится в текущем каталоге. (Особенно при сценариях для образования, исследования, тестирования, забавы или другого ограниченного или одноразового использования, это - возможно, наиболее распространенный способ.)

• /path/to/cleanup, в целом. Если первая команда содержит a / это интерпретируется как путь к исполняемому файлу. (Это - причина вышеупомянутого ./ синтаксис, как . означает текущий каталог.)

  Первым словом я имею в виду команду до, но не включая ее первое незавершенное пространство или вкладку:
  foo-bar/baz первое слово foo-bar/baz qux, в то время как spam\ ham первое слово spam\ ham eggs потому что пространство прежде ham оставлен с обратной косой чертой.

• cleanup, если это находится в каталоге в Вашем PATH (и никакой каталог не перечислил, сначала имеет исполняемый файл того же имени, и оно не заменяется встроенной оболочкой, функция или псевдоним).

Независимо от действительно ли сценарий cleanup имеет a #!... строка hashbang или что говорит та строка:

• sh cleanup будет все еще (попытаться к), выполняет его с sh как интерпретатор.
• bash cleanup будет все еще (попытаться к), выполняет его с bash как интерпретатор.

Это вызвано тем, что в тех случаях Вы на самом деле выполняете интерпретатор (sh или bash) и передача названия сценария к интерпретатору, чтобы быть выполненным. Много программ принимают, что названия файлов открываются на командной строке и оболочках как sh и bash следуйте этой конвенции.

Создание Вашего портативного сценария

Если Вы хотите сделать свой сценарий портативным, самый простой путь не состоит в том, чтобы использовать $UID вообще, и вместо этого используйте некоторое средство, доступное всем оболочкам стиля Границы.

В целом нет никакого встроенного средства оболочки для определения идентификатора пользователя. Но можно использовать id. Это - внешняя программа, а не встроенная оболочка, но как cat и ls, разумно ожидать, что это будет присутствовать.

id отдельно производит набор информации, но id -u дает просто эффективный идентификатор пользователя.

Таким образом вместо if [ "$UID" != "$ROOT_UID" ], можно использовать:

if [ "$(id -u)" != "$ROOT_UID" ]

Технически, это не эквивалентно. $UID в bash дает идентификатор реального пользователя, и id -u действительно соответствует bash $EUID. Если Вы действительно хотите UID а не EUID, использовать id -ru.