Mc: no edite los archivos de configuración del usuario sin notificar al usuario/confirmación

@atomi Gracias por archivar este problema. Cambiará el comportamiento para pedir confirmación antes de agregarlo.

Esto es muy molesto: cada ejecución functional-tests.sh agrega mc nuevos a mi .bashrc @vadmeste

Esto es muy molesto: cada ejecución functional-tests.sh agrega mc nuevos a mi .bashrc @vadmeste

oh, ya veo ... porque mc está en una ubicación diferente cada vez que ejecutas funcional-tests.sh

@kannappanr , ¿obtuvimos alguna confirmación de que debemos agregar un indicador para habilitar/deshabilitar la finalización de bash?

Sí, lo hacemos @vadmeste , debemos avisar si aún no está instalado.

Deberíamos tener una opción para deshabilitar el aviso de modo que no se agregue automáticamente.

Sí, lo hacemos @vadmeste , debemos avisar si aún no está instalado.

Deberíamos tener una opción para deshabilitar el aviso de modo que no se agregue automáticamente.

Creo que es feo que un usuario agregue una bandera para evitar el aviso si simplemente no le gusta instalar la finalización, por lo que en realidad necesitamos guardar la elección del usuario en config.json,

Hablemos de esto lo antes posible

Puede agregar un subcomando para completar la instalación.

Esto también es cierto para bash_profile y fish/completions/mc.fish. Si tiene terminaciones, distribúyalas usando el método estándar. Para homebrew en Mac OSX eso es:

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

Para ver un ejemplo, consulte brew info hub que se instala en las tres ubicaciones.

La línea ofensiva está en main.go:
https://github.com/minio/mc/blob/88a3c2b1e1916d0347b74da5746a766f8c570cbb/cmd/main.go#L199 -L200

Supongo que es un efecto secundario de usar el paquete https://github.com/posener/complete . Lo mejor sería obtener algún tipo de parche en sentido ascendente, pero hasta entonces podría agregar una bandera para generar las finalizaciones. Aún mejor sería hacerlo durante el empaquetado y enviar los archivos resultantes para agregarlos a las carpetas mencionadas anteriormente (o equivalente para su plataforma favorita).

Lo hablamos internamente. Creemos que auto-completion es útil para la mayoría de los usuarios.

Por lo tanto, proporcionaremos a los usuarios avanzados una opción para no configurar la finalización automática cuando se ejecute mc .

Agregaremos una opción llamada --no-complete , similar a --no-color . Cuando ejecuta mc con esta opción, no modificará el archivo de configuración del usuario.

Si este indicador no está configurado, le notificaremos al usuario que auto completion se ha habilitado para mc .

Entonces, ¿debo incluir esa bandera para cada invocación? Si es así, ¿podría sugerir agregarlo también como una opción de configuración?

Además, estoy totalmente a favor de la finalización automática, solo que no modifico los archivos de configuración del usuario ¹ . Hay formas de distribuir secuencias de comandos de finalización para los tres shells que se enumeran anteriormente, lo que sería excelente, ya que también permite la finalización automática en la primera invocación, no en la segunda.

¹ Tengo un repositorio dotfiles, lo que significa que estas modificaciones aparecen como archivos sucios en git. Esto se siente extraño, ya que no edité nada, pero una breve búsqueda más tarde encontré este problema que explica por qué.

Esperando una respuesta aquí para evaluar nuestras opciones: https://github.com/posener/complete/issues/89

PR enviado a upstream https://github.com/posener/complete/pull/94

¿Alguna solución hasta ahora?

Sí aquí #2812

¡Ah gracias!

¿No sería mejor hacerlo al revés? Es decir, no modifique el .bashrc del usuario de forma predeterminada y agregue un indicador explícito --configure-autocompletion a mc en su lugar.

Siento que la mayoría de los usuarios no esperarían que una utilidad de línea de comando intente modificar su .bashrc cuando la ejecutan por primera vez. Nunca antes había visto ningún otro programa (excepto los instaladores) haciendo algo como esto.

Tener una forma explícita de habilitar el autocompletado para mc también facilita el mantenimiento de una instalación en todo el sistema que ya se ocupa de la función de autocompletado, sin modificar los scripts de inicio de sesión de cada usuario individual.

Hice PR #2814 para poder deshabilitar la instalación usando una variable ambiental. Tal vez no sea lo ideal, pero definitivamente es mejor que requerir una bandera para cada invocación.

El comportamiento predeterminado será instalar, es conveniente para nuestros usuarios. Si no te interesa siempre está la bandera.

En lugar de la variable de entorno, es posible hacer alias mc="mc --no-autocompletion"

Como dije en PR, también es malo obligar al usuario a definir un alias solo para poder usar el software sin que arruine sus archivos de puntos. Las variables ambientales se pueden configurar de varias maneras, y para algunas conchas como los peces, se pueden conservar entre sesiones.

Además, el uso de env vars es común entre servidores/contenedores para proporcionar configuraciones/secretos básicos. Heroku y Docker son un par de ejemplos de estos. Aquí, el uso sería asegurarse de no contaminar accidentalmente el servidor/contenedor, ya que _cualquier_ cambio puede generar errores divertidos .

Básicamente, tenerlo configurable de varias maneras le permite al usuario usar la herramienta de configuración más adecuada para su entorno, ya sea un alias, una variable ambiental o un archivo de configuración.*

*_Sería lindo tener esto, pero me conformaré con un env var cualquier día_

No creo que sea inconveniente para los usuarios ejecutar algo como mc --enable-autocompletion una vez, para habilitar el autocompletado. Como dije antes: tener una utilidad de línea de comandos que intenta modificar los scripts de inicio de sesión del usuario simplemente ejecutándolos es un comportamiento muy inesperado.

@kbg, este es un lugar en el que no estaremos de acuerdo, el valor predeterminado será agregar el autocompletado automáticamente.

Para usuarios avanzados, tomaremos el ENV PR enviado por @maxnordlund y la opción de línea de comando que ya existe.

Hemos quitado ahora su bandera mc --autocompletion que instala la función de autocompletar como opt-in, no como predeterminado.

Cerrando este tema.