do not edit user configuration files without notifying user/confirmation

[atomi]

Expected behavior

don't edit user configuration files without explicit confirmation

Actual behavior

adds

autoload -U +X bashcompinit && bashcompinit
complete -o nospace -C /home/atomi/go/bin/mc mc

to .zshrc

Steps to reproduce the behavior

run mc

mc version

• (paste output of mc version)

System information

guys this is no bueno.

[kannappanr]

@atomi Thanks for filing this issue. Will change the behavior to ask for confirmation before adding it.

[harshavardhana]

This is super annoying - each functional-tests.sh run is adding new mc into my .bashrc @vadmeste

[vadmeste]

This is super annoying - each functional-tests.sh run is adding new mc into my .bashrc @vadmeste

oh I see.. because mc is in different location each time you run functional-tests.sh

@kannappanr did we get any confirmation that we should add a flag to enable/disable bash completion ?

[harshavardhana]

Yes we do @vadmeste, we need to prompt if not installed already.

We should have an option to disable the prompt such that it doesn't add automatically.

[vadmeste]

Yes we do @vadmeste, we need to prompt if not installed already.

We should have an option to disable the prompt such that it doesn't add automatically.

I think it is ugly for a user to add a flag to avoid the prompt if he just doesn't like to install the completion, so we actually need to save the user choice in config.json,

Let's discuss this ASAP

[vooon]

You may add subcommand to install completion.

[maxnordlund]

This is also true for bash_profile and fish/completions/mc.fish. If you have completions, distribute them using the standard method. For homebrew on Mac OSX that is:

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

For an example see brew info hub that installs in all three locations.

The offending line is in main.go:

mc/cmd/main.go

Lines 199 to 200 in 88a3c2b

	// Install mc completion, ignore any error for now
	_ = completeinstall.Install("mc")

I guess it's a side effect of using the https://github.com/posener/complete package. The best would be to get some sort of patch upstream, but until then you could add a flag to generate the completions. Even better would be to do so during packaging, and ship the resulting files to be added to the folders mentioned above (or equivalent for your favorite platform).

[kannappanr]

We talked about it internally. We feel that auto-completion is useful for most of the users.

So, we will provide advanced users an option to not set auto completion when mc is run.

We will be adding an option called --no-complete, similar to --no-color. When you run mc with this option, it will not modify user configuration file.

If this flag is not set, we will notify the user that auto completion has been enabled for mc.

[maxnordlund]

So I need to include that flag for every invocation? If so, might I suggest to add it as a config option as well.

Also, I'm totally for auto-completion, just not modifying user config files¹. There are ways to distribute completion scripts for the three shells as listed above, which would be great, since it also enables auto-completion on the first invocation, not the second.

¹I have a dotfiles repo, which means these modifications show up as dirty files in git. This feels weird, as I didn't edit anything, but a short search later I found this issue explaining why.

[vadmeste]

Waiting for an answer here to evalute our options: posener/complete#89

[vadmeste]

PR sent to upstream posener/complete#94

[xoxys]

Any solution so far?

[harshavardhana]

Yes here #2812

[xoxys]

Ah thanks!

[kbg]

Wouldn't it be better to do it the other way around? I.e. don't modify the user's .bashrc by default and add an explicit --configure-autocompletion flag to mc instead.

I feel like most users would not expect that a command line utility is trying to modify their .bashrc when running it for the first time. I've never seen any other program before (except installers) doing something like this.

Having an explicit way of enabling autocompletion for mc also makes it easier to maintain a system-wide installation that already takes care of the autocompletion feature, without modifying the login scripts of each individual user.

[maxnordlund]

I made PR #2814 to be able to disable the installation using an environmental variable. Maybe not ideal, but definitely better then requiring a flag for every invocation.

[harshavardhana]

Default behavior will be to install, it is convenient for our users. If you are not interested there is always the flag.

[vadmeste]

Instead of the environment variable, it is possible to do alias mc="mc --no-autocompletion"

[maxnordlund]

As I said in the PR, it's also bad to force the user to define an alias just to be able to use the software without it messing up your dotfiles. Environmental variables can be set in a number of ways, and for some shells like fish, they can be persisted between sessions.

Also, using env vars is common among server/containers to provide basic settings/secrets. Heroku and Docker are a couple of examples of these. Here the use would be to make sure you don't accidentally taint the server/container, as any change can lead to fun bugs.

---

Basically, having it configurable in multiple ways allows the user to use the most appropriate config tool for their environment, whether that be an alias, environmental variable or config file.*

*This would be sweet to have, but I'll settle for an env var any day

[kbg]

I don't feel like it is unconvenient for users to run something like mc --enable-autocompletion once, in order to enable autocompletion. As I said before: Having a command line utility trying to modify the user's login scripts just by running it, is a very unexpected behavior.

[harshavardhana]

@kbg this is somewhere we will disagree, the default will be to add autocompletion automatically.

For advanced users we will take the ENV PR sent by @maxnordlund and command line option which already exists.

[harshavardhana]

We have moved away now its mc --autocompletion flag which installs the autocompletion as opt-in not as default.

Closing this issue.