Mc: не редактировать файлы конфигурации пользователя без уведомления пользователя/подтверждения

@atomi Спасибо за регистрацию этой проблемы. Изменит поведение, чтобы запросить подтверждение перед его добавлением.

Это очень раздражает - каждый запуск functional-tests.sh добавляет новый mc в мой .bashrc @vadmeste

Это очень раздражает - каждый запуск functional-tests.sh добавляет новый mc в мой .bashrc @vadmeste

о, понятно.. потому что mc находится в другом месте каждый раз, когда вы запускаете функциональный-tests.sh

@kannappanr получили ли мы какое-либо подтверждение того, что мы должны добавить флаг для включения/отключения завершения bash?

Да, мы делаем @vadmeste , нам нужно подсказать, если он еще не установлен.

У нас должна быть возможность отключить подсказку, чтобы она не добавлялась автоматически.

Да, мы делаем @vadmeste , нам нужно подсказать, если он еще не установлен.

У нас должна быть возможность отключить подсказку, чтобы она не добавлялась автоматически.

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

Давайте обсудим это как можно скорее

Вы можете добавить подкоманду для завершения установки.

Это также верно для bash_profile и fish/completions/mc.fish. Если у вас есть доработки, раздайте их стандартным способом. Для доморощенного на Mac OSX это:

Bash completion:
  /usr/local/etc/bash_completion.d

zsh completions:
  /usr/local/share/zsh/site-functions

fish completions:
  /usr/local/share/fish/vendor_completions.d

В качестве примера см. brew info hub , который устанавливается во всех трех местах.

Оскорбительная строка находится на main.go:
https://github.com/minio/mc/blob/88a3c2b1e1916d0347b74da5746a766f8c570cbb/cmd/main.go#L199 -L200

Я предполагаю, что это побочный эффект использования пакета https://github.com/posener/complete . Лучше всего было бы получить какой-то патч вверх по течению, но до тех пор вы можете добавить флаг для генерации завершений. Еще лучше было бы сделать это во время упаковки и отправить полученные файлы для добавления в папки, упомянутые выше (или эквивалентные для вашей любимой платформы).

Мы говорили об этом внутренне. Мы считаем, что auto-completion полезен для большинства пользователей.

Таким образом, мы предоставим опытным пользователям возможность не устанавливать автозавершение при запуске mc .

Мы добавим опцию под названием --no-complete , похожую на --no-color . Когда вы запускаете mc с этой опцией, он не будет изменять файл конфигурации пользователя.

Если этот флаг не установлен, мы уведомим пользователя о том, что auto completion включен для mc .

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

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

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

Жду ответа здесь, чтобы оценить наши варианты: https://github.com/posener/complete/issues/89

PR отправлен в апстрим https://github.com/posener/complete/pull/94

Любое решение до сих пор?

Да вот #2812

А, спасибо!

Не лучше ли сделать наоборот? Т.е. не изменять пользовательский .bashrc по умолчанию и вместо этого добавлять явный флаг --configure-autocompletion в mc .

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

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

Я сделал PR # 2814, чтобы иметь возможность отключить установку с помощью переменной среды. Может быть, не идеально, но определенно лучше, чем требовать флаг для каждого вызова.

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

Вместо переменной окружения можно сделать alias mc="mc --no-autocompletion"

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

Кроме того, использование env vars распространено среди серверов/контейнеров для предоставления основных настроек/секретов. Heroku и Docker — пара таких примеров. Здесь использование будет заключаться в том, чтобы убедиться, что вы случайно не испортите сервер/контейнер, поскольку _любое_ изменение может привести к забавным ошибкам.

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

*_Это было бы здорово, но я соглашусь на env var в любой день_

Мне не кажется неудобным, чтобы пользователи запускали что-то вроде mc --enable-autocompletion один раз, чтобы включить автозаполнение. Как я уже говорил: наличие утилиты командной строки, пытающейся изменить сценарии входа пользователя, просто запустив ее, является очень неожиданным поведением.

@kbg здесь мы не согласимся, по умолчанию автозаполнение будет добавляться автоматически.

Для опытных пользователей мы возьмем ENV PR, отправленный @maxnordlund , и параметр командной строки, который уже существует.

Теперь мы убрали его флаг mc --autocompletion , который устанавливает автозаполнение по умолчанию, а не по умолчанию.

Закрытие этого вопроса.