Прикол с «exit 0»

Закономерный итог использования башпортянок.

минимальный воспроизводимый пример

$ echo 'exit 0' > exit0.sh
$ . exit0.sh

Это не прикол, а непонимание того, что ты делаешь.

Вопрос-то в чём?

Ну классно.

Не ошибается тот, кто ничего не делает.

Когда ты логинишься, скрипты из profile.d выполняются в текущем интерпретаторе с помощью команды source. По сути все команды выполняются в текущем интерпретаторе, и exit завершает его выполнение.

Патамушта такое надо было не в профиль пихать, а, например, в крон по reboot. (Дээ маркдаун меня победил, прости, регистрант 😆 @reboot в кроне исполняется при каждом старте системы)

Мамин какир…

Все эти profile.d, образно говоря, склеиваются в один скрипт и если он завершается, то завершается и сессия его инициировавшая. Но это сильно упрощённый рассказ.

Теги: жж, тупняк

Добавлю ещё что строчка #!/bin/bash в начале файла это в большинстве случаев признак нубства. Конкретно тут шебанг вообще не нужен, никакой, а в других файлах, где он таки нужен (это файлы chmod +x которые запускаются как проги) там надо писать #!/bin/sh

Ну тут вопрос неочевидный. sh это sh, а bash это bash. Если тебе не хватает возможностей sh и тебе не нужна переносимость sh, использовать bash вместо него - нормально. Те же массивы сильно упрощают некоторые нюансы. Да что - массивы, i + 1 на sh вычислить - уже задача.

А ещё добавлю, что правильней писать #!/usr/bin/env sh. К примеру в макоси есть /bin/bash древней версии, а когда юзер ставит новую версию через brew, то она ставится куда-то в /opt. Кажется правильней дать пользователю возможность выбирать тот интерпретатор, который будет использоваться для запуска скрипта, а не хардкодить его по определённому пути.

#!/usr/bin/env sh

Конкретно так смысла не имеет, а вот #!/usr/bin/env bash — вполне правильный шебанг, если у тебя скрипт не полностью POSIX-совместимый, а с башизмами.

Ты хочешь логировать, когда входишь в систему. Всё уже сделали за тебя. man last

Кажется правильней дать пользователю возможность выбирать тот интерпретатор, который будет использоваться для запуска скрипта, а не хардкодить его по определённому пути.
/usr/bin/env

по хорошему и env не надо хардкодить. но, к сожалению, Linux так не умеет.

Это минимальный общий делитель среди плюс-минус всех актуальных posix систем. Хорошо бы его в стандарт принести вместе с наличием /bin/sh.

какой нафиг делитель? с чего env обязательно в /usr/bin/ должно быть?

Если тебе не хватает возможностей sh и тебе не нужна переносимость sh, использовать bash вместо него - нормально.

Если не хватает sh то надо писать не на шелле. Пхп/питон, ну и Си в итоге.

А ещё добавлю, что правильней писать #!/usr/bin/env sh. К примеру в макоси есть /bin/bash древней версии, а когда юзер ставит новую версию через brew, то она ставится куда-то в /opt.

Причём тут баш и его версия? #!/bin/sh означает что это скрипт для posix-шелла, он должен работать на любом posix-совместимом шелле любой версии. Если ты начинаешь пользоваться какими-то нестандартными фичами - см. выше, надо целиком менять язык а не искать другой шелл.

Кажется правильней дать пользователю возможность выбирать тот интерпретатор, который будет использоваться для запуска скрипта, а не хардкодить его по определённому пути.

Пользователь всегда может написать /opt/local/bin/exotic_sh /path/to/script если ему надо выбрать интерпретатор. А то, что написано для sh, должно быть совместимо с любым posix sh.

правильней писать #!/usr/bin/env sh

А да, ещё оно совершенно без нужды сломается с неподмонтированным /usr. При том что самому sh /usr для работы не нужен и твоему скрипту может быть тоже не нужен.

правильней писать #!/usr/bin/env sh. К примеру в макоси

Вот ещё, ради маргинальной ОС уродовать скрипты

А что ты ожидал? Ну если это прикол, то я должен посмеяться, но мне вот не смешно. Спасибо. Продолжай наблюдения. Используй systemd пользовательские сервисы. Там в скриптах, запускаемых через ExecStart можно использовать exit 0.

А что, ласты уже не работают? И почему файл называется ″comp_start.log″, если там время логина пользователя?

Не ошибается тот, кто все автоматизировал!

Надо, потому что

echo $PATH
/home/user/.cargo/bin:/home/user/anaconda3/bin:/home/user/anaconda3/condabin:/home/user/.cargo/bin:/home/user/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/user/.dotnet/tools

а пойдёт на улицу гулять

Блажен, кто верует. Школьник ни гулят, ни компы ломать не будет, в смартфон залипнет и всё.

Надо

Надо что? Хардкодить /usr/bin/env? Хардкодить /bin/bash? Что вы там не захардкордите, пользователь с консоли введёт sudo или ещё какую команду и всё. Если в его bin-каталог понапихано вредоносных программ, ничего не поможет. Особенно с разрабами дистра, которые пользовательские bin-каталоги в начало PATH ставят, а не в конец.

ору с этого башпердолинга

это что-то вроде пердолинга с микропроцессорами не поддерживающими умножения и прочим маразмом

В папке /etc/profile.d/ у меня в моей EndeavourOS (arch based) есть файлы «gradle.sh», «locale.sh» которые начинаются с «#!/bin/sh» Эти файлы не мои, они установлены самой ОС. Тоже нубы их туда пропихнули???

Да.

А где я писал что /bin/sh нуб пишут? Конкретно это там про другой шелл было сказано.