Есть ли недостатки настройки `noclobber`?

Учитывая, что zshможет заглушить все файлы, заданные командой:

>*

Я думаю, что установка опции noclobberбыла бы хорошей идеей.

Я всегда могу использовать, >| fileесли я хочу использовать стандартное поведение clobber в bash и zsh. (Zsh также допускает альтернативный синтаксис >!file).

Я предполагаю, noclobberчто по умолчанию не установлен из-за совместимости с POSIX, но просто чтобы быть уверенным:

Есть ли недостатки в настройке noclobber?

Есть ли вообще установить noclobberтолько для интерактивной оболочки?

По noclobberумолчанию причина не установлена ​​- это традиция. Что касается дизайна пользовательского интерфейса, хорошей идеей будет сделать «создание этого нового файла» простым действием и добавить дополнительное препятствие более опасному действию «либо создать новый файл, либо перезаписать существующий файл». Таким образом noclobber, это хорошая идея ( >создать новый файл, >|потенциально перезаписать существующий файл), и, вероятно, он был бы по умолчанию, если бы оболочка была разработана несколько десятилетий спустя.

Я настоятельно рекомендую использовать следующее в вашем файле запуска интерактивной оболочки ( .bashrcили .zshrc):

set -o noclobber
alias cp='cp -i'
alias mv='mv -i'

В каждом случае (перенаправление, копирование, перемещение) цель состоит в том, чтобы добавить дополнительное препятствие, когда операция может иметь побочный эффект удаления некоторых существующих данных, даже если удаление существующих данных не является основной целью операции. Я не помещаю rm -iв этот список, потому что стирание данных является основной целью rm.

Обратите внимание, что noclobberи -iявляются сетями безопасности . Если они сработают, вы сделали что-то не так . Так что не используйте их как оправдание, чтобы не проверять, что вы перезаписываете! Дело в том, что вы должны были проверить, что выходной файл не существует. Если вам сказали file exists: fooили overwrite 'foo'?это означает, что вы допустили ошибку и вам следует чувствовать себя плохо и быть более осторожным. В частности, не заводите привычку говорить, yесли предложено перезаписать (возможно, псевдонимы должны быть alias cp='yes n | cp -i' mv='yes n | mv -i', но нажатие Ctrl+ Cулучшает вывод): если вы действительно хотели перезаписать, отменить команду, переместить или удалить вывод файл и еще раз введите команду.

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

noclobberбудет установлен только для интерактивных оболочек, поскольку .bashrcили .zshrcчитается только интерактивными оболочками. Конечно, вы не должны изменять параметры оболочки таким образом, чтобы это могло повлиять на сценарии, так как это может нарушить эти сценарии.

Установка параметра noclobberоболочки в ~/.bashrc(для bash) или ~/.zshrc(или, точнее $ZDOTDIR/.zshrc, в zsh) сделает его активным в сеансах интерактивной оболочки.

Неинтерактивные оболочки (скрипты) не читают эти файлы.

Параметры оболочки обычно не наследуются от родительских оболочек.

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

Единственный недостаток, который я вижу, это то, что вы будете постоянно забывать, что вы установили опцию, по крайней мере, в начале. Позже, как и все такого рода вещи, вы начнете использовать постоянно >|, даже в тех случаях , когда вы на самом деле не хотите , чтобы затирать файл (так же , как люди с псевдонимами для rm, cpи mvс -iвыбором всегда устанавливается, в конечном счете начинают всегда использовать -fв командной строке).

Недостаток является то, что, если вы привыкаете к тому , noclobberактивным, вы будете один день использовать систему , где это она не активна , и вы будете беспечно выполнять потенциально-опасные команды, ожидая , noclobberчтобы спасти вас ... и это не будет. И тогда вам придется надеяться, что резервных копий достаточно для восстановления уничтоженных данных, поскольку вы предполагали, что сначала вас попросят подтвердить.