`alias rm =" rm -i "` считается вредным?

Question

Я прочитал некоторое время назад (не могу найти ссылку), что использование такого псевдонима как alias rm="rm -i" было очень плохо.

Есть ли историческое свидетельство или здравый смысл объяснения этому факту?

Я полагаю, что это дает пользователю плохую привычку полагаться на запрос подтверждения, чтобы проверить его команду, что может привести к бедствиям, если он сделает это в другом профиле, у которого нет псевдонима.

Answer 1

Ты прав.

Это плохо, потому что ты привыкла к этому. Если вы на системе , которая не имеет, и вы rm он сразу же начинает удалять и вам интересно , что происходит.

Многие пользователи привыкли использовать SSH в разных системах; поэтому использование множества различных систем, иногда без настройки персонализированных учетных записей пользователей (включая псевдонимы), довольно распространено.

Вместо этого используйте, например, alias rmi='rm -i' и научитесь использовать его. Если это не установлено в другой системе, вы случайно не удалили файлы и всегда можете вернуться к вводу полной команды.

Answer 2

Как сказал @Daniel, это не вредно само по себе, кроме обучения, чтобы вы ожидали, что оно будет там. На самом деле, это установка по умолчанию на CentOS (и, я полагаю, расширение RHEL - прошло слишком много времени с тех пор, как я ее использовал), и это огромная боль в туху. Для остальной части моего времени на этом выступлении я набрал /bin /rm, чтобы избежать настройки «Linux для людей, которые не должны иметь root-доступ».

Answer 3

Я думаю, что большая опасность состоит в том, что люди могут полагаться на что-то подобное, чтобы фильтровать шар. Представьте, что вы хотите удалить некоторые изображения из каталога, но не все:

rm -i pics/*.jpg

Вы можете использовать это для фильтрации глобуса вручную, что было бы вполне разумно. Но, если вы использовали псевдоним и использовали rm и оказались в оболочке без этого псевдонима и попробуйте ... вы просто удалили все свои фотографии, ой!

Лично я также считаю, что этот псевдоним вреден для моего кровяного давления;). Но это только я.

Answer 4

В дополнение к тому, что сказал Дэниел Бек, я обнаружил, что использую -f для обхода -i , что потенциально опасно, так как приводит к ненужному использованию rm -f и rm -rf . Как-то связано: способ предотвратить проблемы с rm -rf состоит в том, чтобы создать файл с именем "-i", как это было указано в ответе на этот вопрос: как предотвратить случайный rm -rf /*? ,

Но опять же, если бы этого псевдонима не было, я бы не использовал -f, и все это не будет проблемой.

Answer 5

Это гораздо менее вредно, основываясь на моем опыте работы с сотнями пользователей в прошлом:

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. Я пишу не для того, чтобы делиться кодом, а для того, чтобы поделиться с ним изменениями в пользовательском опыте .