`alias rm="rm -i"` считается вредным?
Я прочитал некоторое время назад (не могу найти ссылку), что с использованием такого псевдонима, как alias rm="rm -i"
было очень плохо.
Есть ли историческое свидетельство или здравый смысл объяснения этому факту?
Я полагаю, что это дает пользователю плохую привычку полагаться на запрос подтверждения, чтобы проверить свою команду, что может привести к бедствиям, если он сделает это в другом профиле, у которого нет псевдонима.
5 ответов
Ты прав.
Это плохо, потому что ты привыкла к этому. Если вы находитесь в системе, которая не имеет, и вы rm
, он сразу начинает удалять, и вам интересно, что происходит.
Многие пользователи привыкли использовать SSH в разных системах; поэтому использование множества различных систем, иногда без настройки персонализированных учетных записей пользователей (включая псевдонимы), довольно распространено.
Вместо этого используйте, например, alias rmi='rm -i'
и научиться использовать это. Если это не установлено в другой системе, вы случайно не удалили файлы и всегда можете вернуться к вводу полной команды.
Как сказал @Daniel, это не вредно само по себе, кроме обучения, чтобы вы ожидали, что оно будет там. Фактически, это установка по умолчанию на CentOS (и, я полагаю, расширение RHEL - прошло слишком много времени с тех пор, как я ее использовал), и это огромная боль в туху. Для остальной части моего времени на этом выступлении я набрал /bin/rm, чтобы избежать настройки "Linux для людей, у которых не должно быть root-доступа".
Я думаю, что большая опасность состоит в том, что люди могут полагаться на что-то подобное, чтобы фильтровать шар. Представьте, что вы хотите удалить некоторые изображения из каталога, но не все из них:
rm -i pics/*.jpg
Вы можете использовать это для фильтрации глобуса вручную, что было бы вполне разумно. Но, если вы использовали псевдоним и использовали rm
и случилось, что приземлился в оболочке без этого псевдонима и попробуйте... вы просто удалили все свои фотографии, упс!
Лично я также считаю, что этот псевдоним вреден для моего кровяного давления;). Но это только я.
В дополнение к тому, что сказал Дэниел Бек, я обнаружил, что использую -f
обойти -i
, что потенциально опасно, так как это приводит к использованию rm -f
а также rm -rf
без необходимости. Как-то связано: способ предотвратить rm -rf
проблема заключается в том, чтобы создать файл с именем "-i", как это было указано в ответе на этот вопрос: как предотвратить случайный запуск команды rm -rf /*?,
Но опять же, если бы этого псевдонима не было, я бы не использовал -f, и все это не будет проблемой.
Это гораздо менее вредно, основываясь на моем опыте работы с сотнями пользователей в прошлом:
rm () # must be a function, must require single answer for all targets
{
ls -FCsd "$@"
local reply ; echo -n 'remove[ny]? ' ; read reply
if [ "_$reply" = "_y" ] ; then
/bin/rm -rf "$@" ; else echo '(cancelled)'
fi
}
- Пользователи обучены правильному использованию подстановочных знаков, а не только "*", а затем полагаются на подсказки y / n для выбора файлов
- Условие использования правильных подстановочных знаков часто спасало от катастрофы, когда они использовали
rm
в каком-то другом контексте, где не хватало ни этой функции, ниrm -i
псевдоним. - Я потратил меньше времени на восстановление файлов, где пользователь вводил "у" слишком много раз
- Пользователи должны ответить только один раз, предоставив им четкую положительную обратную связь.
- Control-c прерывает работу и сообщает, что ничего не делает
- Не сценарий, так что настоящий
rm
остается нетронутым, оставляя другие программы без изменений.
Стиль кода в основном sh-совместим (кроме использования echo .... | tr -d '\012'
для оболочек до bash), не стесняйтесь сделать свой собственный более специфичный для bash. Я пишу не для того, чтобы делиться кодом, а для того, чтобы поделиться с ним изменениями в пользовательском опыте.