docs(README): improve autotools/cmake recommendation

[nurupo]

The previous recommendation to use pkg-config variables resulted in
autotools and cmake ALWAYS installing bash-completion files system-wide,
e.g. /usr/share/bash-completion/completions. It didn't respect the
installation prefix user specifies via ./configure --prefix=<path> in
autotools or cmake -D CMAKE_INSTALL_PREFIX=<path> in cmake. It also
didn't respect autotools and cmake defaulting to install into
/usr/local. This is, frankly, ridiculous. User's/packager's choice of
prefix must be respected.

That FAQ recommendation was very unhelpful. Had to go through this while adding bash-completion to tox-bootstrapd.

[nurupo]

Changed to WIP for now, i.e. not ready to review, as I want to restore part of the deleted section.

[nurupo]

Nevermind. I wanted to preserve the information about pkg-config variables in the FAQ, but after thinking how to present it, I couldn't find a reason why anyone would want to use them. I don't want to tell anyone to use them in their autotools/cmake build systems as those variables don't respect the prefix, so there needs to be some other reason to mention them and I couldn't come up why anyone would want to use them for anything.

[nurupo]

There, ready for review.

[akinomyoga]

This PR is, frankly, totally ridiculous.

First of all, that answer in README explains how to hook up with the existing installation of bash-completion. The installation prefix specified to ./configure of the host application is the installation prefix of the host application but is not the installation prefix of the existing bash-completion that the user uses.

In the updated answer and in the PR TokTok/c-toxcore#2007, you seem to try to copy completion files to the location that no one searches (unless some bash-completion is installed with the same prefix, and the user uses that version of bash-completion). I don't have an idea what you are trying to do by creating garbage files that no one can find.

The previous recommendation to use pkg-config variables resulted in autotools and cmake ALWAYS installing bash-completion files system-wide, e.g. /usr/share/bash-completion/completions.

So you don't know how to properly set up pkg-config. You should learn how to use the environment variable PKG_CONFIG_PATH.

I think we should describe in our README how to properly set PKG_CONFIG_PATH up for those who install custom bash-completion.

[nurupo]

First of all, that answer in README explains how to hook up with the existing installation of bash-completion.

That's undesirable. You want all files to be installed into the installation prefix. If your prefix is /usr or /usr/local, then bash-completion will pick them up. However, if you tell the build system to installing the software into /home/nurupo/my-build, you want everything to be installed into /home/nurupo/my-build, you don't want some files to be written to /usr, nor will you even have permissions for that as a non-root user -- using the pkg-config suggested path will make the installation fail due to missing permissions.

So you don't know how to properly set up pkg-config. You should learn how to use the environment variable PKG_CONFIG_PATH.

I think we should describe in our README how to properly set PKG_CONFIG_PATH up for those who install custom bash-completion.

I'm aware of PKG_CONFIG_PATH, I have done a fair amount of cross-compiling with CMake for many years now. Also, my issue has nothing to do with a custom install of bash-completion.

[akinomyoga]

Yeah, I can understand the current recommendation in README is not a perfect one and doesn't always work (particularly for pre-compiled packages or for cross-compiling where the deployed host and the package building environment can be different), but the suggested change to README seems to be worse than the current one.

Just a naive idea, but maybe we can suggest in README adding a configure option (such as --with-bash-completion={no,yes,BASHCOMP_PREFIX}) to specify the prefix of bash-completion for completion scripts. When no is specified, the completion scripts will not be installed. When yes is specified, an existing bash-completion is detected using pkg-config. When a path is specified, it is treated as the prefix for bash-completion.

P.S. And, when the automatically determined location is not writable with the current permission, we may fall back to the user's directory ${XDG_DATA_HOME:-$HOME/.local/share}.

[nurupo]

Yeah, I can understand the current recommendation in README is not a perfect one and doesn't always work (particularly for pre-compiled packages or for cross-compiling where the deployed host and the package building environment can be different)

I didn't mention it in the PR, but the README recommendation doesn't work even for the general case of an existing bash-completion installation. README suggests to install into completionsdir, which typically is /usr/share/bash-completion/completions. Don't you see any problem with installing things into /usr? /usr should be used only for the files that are part of the Linux distribution. Only distro's package manager (e.g. apt, yum, etc) should be allowed to mess with /usr. One should not install, delete or modify the files in there directly, bypassing the package manager. If a user builds some software that wants to install a completion script, it should get installed into /usr/local instead. In fact not just the completion script, but the whole software the user/administrator builds should be installed into /usr/local, not into /usr. It's the common convention to use /usr/local for manually built software, FSH talks about it and CMake makes CMAKE_INSTALL_PREFIX default to /usr/local. Yet bash-completion's pkg-config files don't provide a variable for the /usr/local path or its equivalent, so it's not possible to install completion scripts in a sane manner. You can only install them into /usr, which you shouldn't be doing.

[akinomyoga]

Yeah, I can understand the current recommendation in README is not a perfect one and doesn't always work (particularly for pre-compiled packages or for cross-compiling where the deployed host and the package building environment can be different)

I didn't mention it in the PR, but the README recommendation doesn't work even for the general case of an existing bash-completion installation. README suggests to install into completionsdir, which typically is /usr/share/bash-completion/completions. Don't you see any problem with installing things into /usr?

I here just repeat that we know that the current recommendation in README is not a perfect one, but that can't be the reason to merge this broken PR as is. This is not the place where one repeatedly and verbosely accuses like a broken record how "insane" the current implementation is. The improvements are always welcome. Why don't you update the PR? If you have any questions or discussions on how the PR should be improved, please let us discuss it here. I have already pointed the present problem of the PR and suggested a few ideas about updating README, to which I currently don't see any reply from you. If you think the current PR should be applied as-is, please provide us with convincing reasons (for which I currently hardly think there is any).

Another thing is that the commit message shouldn't include subjective and inappropriate words, which makes the PR look like spam. I hardly think these are needed information in the commit message.

[nurupo]

I here just repeat that we know that the current recommendation in README is not a perfect one, but that can't be the reason to merge this broken PR as is. This is not the place where one repeatedly and verbosely accuses like a broken record how "insane" the current implementation is.

With my last comment I wanted to establish that the current README recommendation is broken also for the general case of a user having distro-installed bash-completion building and installing some software that provides a completion script. I wasn't sure if you were aware of that or not, since I haven't pointed that out before and:

Yeah, I can understand the current recommendation in README is not a perfect one and doesn't always work (particularly for pre-compiled packages or for cross-compiling where the deployed host and the package building environment can be different)

made it sound that you thought that it's broken only for my uncommon edge cases of cross-compilation and such, but not for the general case.

I have already pointed the present problem of the PR and suggested a few ideas about updating README, to which I currently don't see any reply from you.

That was also my reply to your suggestion. Not sure why you didn't see it as such. You are suggesting to introduce --with-bash-completion={no,yes,BASHCOMP_PREFIX} flag, which when set to yes uses completionsdir variable from pkg-config, but that's a no-go since that variable contains a /usr path, not /usr/local, so something should be done about that. One solution to that would be having bash-completion add a new variable to its pkg-config file, pointing to a path under /usr/local, e.g. /usr/local/bash-completion/completions and having --with-bash-completion use that.

Anyway, let's put the discussion of --with-bash-completion aside for a moment.

Could you explain why someone would want to have the completion script picked up by bash-completion when installing into, say, /home/nurupo/my-build-prefix? You are calling this a broken behavior in the c-toxcore PR, but that's actually the desired behavior for us.

If the installation prefix is /home/nurupo/my-build-prefix, we want the file to be installed as /home/nurupo/my-build-prefix/shared/bash-completion/completions/my-completion. It obviously won't be picked up by bash-completion, but we never intended for it to be picked up by it, since that's the consequence of setting a prefix to such a directory, it's not a directory bash-completion checks for completion files. Neither will the binary /home/nurupo/my-build/prefix/bin/my-binary appear in $PATH on its own, nor will man pages from /home/nurupo/my-build/prefix/man be available to man, nor will gcc pick up header files from /home/nurupo/my-build/prefix/include by default, and so on. Believe it or not, they all get installed into /home/nurupo/my-build-prefix when you specify it as the prefix, they are not put into /usr or /usr/local or wherever else. There are also no --with-bash-completion={no,yes,BASHCOMP_PREFIX} configure options for man pages, include files and everything else a software build might install that is intended to be read by some other program. So why do you think should the completion script be unique in that regard?

I hope that the parallel between binary files, manual pages and include files made you realize why I find your insistence that completion script has to be be installed into completionsdir or else it's broken -- silly. Nothing behaves like what you want the completion script installation to behave, such behavior breaks prefix installation expectations. The completion script should be installed under the prefix and that's it, no extra checks and conditions, no extra configure options -- exactly what this PR does. I don't think there is anything to improve on in this PR, but I'm open to suggestions if you have any, maybe there is something I have missed.

Another thing is that the commit message shouldn't include subjective and inappropriate words, which makes the PR look like spam. I hardly think these are needed information in the commit message.

There are no inappropriate words in the commit message, I'm not swearing or cursing, and the current recommendation being ridiculous or broken is not subjective but objective -- installing into /usr despite the prefix being set to elsewhere is objectively broken as it doesn't respect the prefix option. The commit message even says as much.

[nurupo]

Shortened the commit message and fixed a reference to the now deleted section in a FAQ entry above.

[nurupo]

I have considered adding a boolean option, something like --enable-bash-completion or --with-bash-completion, which is enabled by default, and when disabled would not install the completion files, but it sounds rather unnecessary. The installation is just cp src dest. When you disable things, you often do so because you want to save build time on something you don't need, or don't want to install extra deps for a thing you don't need. With the installation being just a cp with no extra deps, you don't really save much by using such an option, and keeping the examples brief and simple in the FAQ is rather nice. It also wouldn't bother me personally if the projects I use didn't have an option of disabling completion script installation.

What's do you think?

[akinomyoga]

I wasn't sure if you were aware of that or not, since I haven't pointed that out before and:

Yeah, I can understand the current recommendation in README is not a perfect one and doesn't always work (particularly for pre-compiled packages or for cross-compiling where the deployed host and the package building environment can be different)

made it sound that you thought that it's broken only for my uncommon edge cases of cross-compilation and such, but not for the general case.

I did recognize the problem but just didn't enumerate every possible case that the current configuration causes the problem. You have mentioned /usr/local in the first post, which was enough for me. I'm not a native English speaker so unsure what would be the subtle nuance of words, but does "particularly" mean "only" in this context? Yeah, I think that's possible, seriously. Anyway, what I wanted to convey is that I agree that it doesn't make any sense to detect bash-completion of the building system for pre-compiled packages and cross-compiling. On the other hand, a completion script installed to /usr/share/bash-completion/completions does practically "work" until a system administrator installs both the distro version and the local version of the same application to a single system.

The thing that I didn't like about your comment is that it is written with a certain exaggeration or tries to give a wrong impression to the third person (though I guess you don't even aware of it by yourself). It is written as if installing scripts to /usr/share/bash-completion will never work, but real conflicts with the distributed package arise only when both versions are installed. It is written as if the current recommendation messes up /usr unlimitedly, but the change is actually limited in /usr/share/bash-completion. I agree that these are indeed the problems of the current recommendation in README, but you don't have to make up the impact unnecessarily disastrous.

I am actually kind of agree that we should probably shift to /usr/local, but I can't fully agree that the current strategy of installing completions into /usr/local /usr has been totally wrong. As you have pointed out, there are already several standard/semi-standard directory structures like bin, lib, include, share/man, lib/pkgconfig along with the environment variables PATH, {LD_,}LIBRARY_PATH, *_INCLUDE_PATH, MANPATH, PKG_CONFIG_PATH, but not every application provides extensions with this approach. I think there has been historically many cases the application dynamically modifies its data directory such as /usr/share/emacs/site-lisp, /usr/share/texlive/texmf-local, /usr/share/fonts, and other /usr/share/APP/site-* subdirectories, etc. I believe they are now gradually moving to /usr/local/* but I don't think the authors of these packages were "insane" or "silly". Then, /usr/share/bash-completion/completions (which mixes up the completions from distro packages and local installations) might not have been a very good idea, but the distro version of bash-completion installed with --prefix=/usr has control over the contents of /usr/share/bash-completion after all and free to designate completions/ as the place to (not smartly) put everything.

I have already pointed the present problem of the PR and suggested a few ideas about updating README, to which I currently don't see any reply from you.

That was also my reply to your suggestion. Not sure why you didn't see it as such.

You should have made it explicit. Unless you explicitly mention --with-bash-completion, I cannot conclude whether you agree or disagree with it or are just avoiding the discussion. Also, the discussion is not just agreeing/disagreeing all or nothing. The point you have raised about /usr vs /usr/local is orthogonal to the option --with-bash-completion, i.e., the option can also be used with /usr/local being defaulted.

You are suggesting to introduce --with-bash-completion={no,yes,BASHCOMP_PREFIX} flag, which when set to yes uses completionsdir variable from pkg-config, but that's a no-go since that variable contains a /usr path, not /usr/local, so something should be done about that. One solution to that would be having bash-completion add a new variable to its pkg-config file, pointing to a path under /usr/local, e.g. /usr/local/bash-completion/completions and having --with-bash-completion use that.

Yeah, these replies are exactly what I expected from you, which are clearly different from your previous "reply to my suggestions about README". I agree with the issue about /usr and /usr/local and also think the solution with a new pkg-config variable is a valid one.

Could you explain why someone would want to have the completion script picked up by bash-completion when installing into, say, /home/nurupo/my-build-prefix?

I don't understand what makes you believe that no one wants to make the completion script recognized by bash-completion. We write completion scripts to make it work with bash-completion, isn't it already an answer? Maybe you are actually talking about something slightly different.

When one is installing the package inside their home directory (like you said /home/nurupo/my-build-prefix), I agree that installing the completion script to /usr/share/bash-completion/completions doesn't make sense, but the install location is a separate issue from whether we make it visible to bash-completion or not. Also, the user directories are not the only places to which the installation prefix is set, e.g., consider /opt/PKGNAME/x.y.z in which case we in fact want to put a completion script in some places (probably better to be under /usr/local) that the system-wide bash-completion can find.

You are calling this a broken behavior in the c-toxcore PR, but that's actually the desired behavior for us.

OK, now I understood that you actually don't intend to make the completion script visible to bash-completion. Then, that's fine. It's not broken as that is your intent.

However, a question here is why you have been looking at that particular Q&A, to begin with. The question in README reads

**Q. I author/maintain package X and would like to maintain my own
   completion code for this package. Where should I put it to be sure
   that interactive bash shells will find it and source it?**

Have you been only looking at the answer and didn't notice the question at all while editing README and checking and submitting the PR? I'm now actually starting to suspect that, consciously or unconsciously, you are making a story for yourself on the fly, and your subconscious is not smart enough to make a consistent story. You are tricked by your subconscious.

Anyway, the entry in README is for those who want to make it sure that their completion script is found by bash-completion. It's not the explanation of how to install completion scripts that will never be found by bash-completion when the prefix is neither /usr nor /usr/local.

There are also no --with-bash-completion={no,yes,BASHCOMP_PREFIX} configure options for man pages, include files and everything a program might install that might be accessible by some other program. So why do you think should the completion script be unique in that regard?

(1) As I have written above, I'm not sure if it's fair to compare it with bin/, lib/, include/ or share/man/. These are standard/semi-standard ones with an established extension method and just adopt a different approach using the environment variables or configuration. (2) As I have written "just a naive idea", I'm actually not sure if this is a good idea. I just proposed it because I thought that it possibly satisfies your needs. To be honest, when we make packages, it is not rare that we need to adjust the installation by post-install hooks (e.g. to create users and groups, register systemd services, and other integrations of different packages). The package maintainer finally needs to adjust it anyway, and I'm not sure whether we should take care of them in the original packages. Anyway, I thought it might be nicer to provide options for the package maintainers. (3) Saying that "No other extension mechanisms are doing it in that way" seems like an indirect reason. Is there any direct reason that we shouldn't do that? I'm not talking about installing them to /usr but about providing the configure option. I agree with /usr/local after all.

There are no inappropriate words in the commit message, I'm not swearing or cursing,

Then, why you have inserted the adverb "frankly", which implies that it's actually subjective. I don't think there is "frankly" or "not frankly" about the objective facts. The adverb implies that you cannot say it if you are not frank.

and the current recommendation being ridiculous or broken is not subjective but objective

These two words "ridiculous" and "broken" are not interchangeable. The word you used is "ridiculous". I cannot stop thinking that the reason that you added "or broken" is that you subconsciously know that "ridiculous" is not appropriate.

[akinomyoga]

I have considered adding a boolean option, something like --enable-bash-completion

Yeah, I think a boolean option is reasonable.

When you disable things, you often do so because you want to save build time on something you don't need, or don't want to install extra deps for a thing you don't need.

I think these are just a part of possible reasons for the configure options. We may use a configure option to choose an underlying library and a version that has several options (this is actually the most frequent reason I specify configure options as I sometimes have several versions of libraries and packages in my machines). We may use a configure option to switch the behavior for compatibility. We may use a configure option to turn on an experimental feature, etc. By the way, isn't requesting an existing installation of bash-completion considered a dependency?

keeping the examples brief and simple in the FAQ is rather nice.

This is also a good point because I also had that concern about --with-bash-completion that I suggested (It'd be too complicated).

[nurupo]

It is written as if installing scripts to /usr/share/bash-completion will never work, but real conflicts with the distributed package arise only when both versions are installed.

Of course it will work, but only distribution's package manager software should be adding/removing files from /usr/share/bash-completion. Modifying anything in /usr, aside from things in /usr/local, is just asking for trouble, and as such should not be done, due to conflicts between user-installed files and files installed by the package manager and due to modifications breaking package manager's expectations.

It is written as if the current recommendation messes up /usr unlimitedly, but the change is actually limited in /usr/share/bash-completion.

I guess there was some sort of miscommunication then, because that's not what I was saying.

Could you explain why someone would want to have the completion script picked up by bash-completion when installing into, say, /home/nurupo/my-build-prefix?

I don't understand what makes you believe that no one wants to make the completion script recognized by bash-completion. We write completion scripts to make it work with bash-completion, isn't it already an answer? Maybe you are actually talking about something slightly different.

I see we are still not on the same page here. We seem to have some sort of a disagreement, or perhaps a misunderstanding, of how software installation is expected to work. Not sure if it's a language barrier, general misunderstanding of file system hierarchy or maybe both. Let's give it one more try.

How things work is you build a software, e.g. with GNU Autotools is something along the lines of:

./configure [--prefix=/some/path]
make
make install

• If you want the self-built software to get integrated into your system: with binaries, man pages, pkgconfig files, etc. becoming available as if they were installed from your distro's package manager -- you have to install the software into /usr/local. You don't even need to specify --prefix to ./configure, it should generally default to /usr/local, unless the software maintainer somehow screwed up.
• If you don't want the self-built software to get integrated into your system, you just want the software to be put into some directory because, for example, you are just developing/testing the said software, or need it for cross-compilation, or want to tar/zip it and distribute, or for any other reason -- you install the software somewhere else, for example /home/nurupo/foo, /tmp/test, /home/nurupo/git/my-project/windows-cross-compile-deps/libcurl, /opt/firefox, etc.

The expectation is that make install would put all the files into the prefix dir using the usual prefix file hierarchy: bin, lib, include, share and so on. However, you are proposing to not put the completion files into prefix but instead put them somewhere else, where bash-completion would see them. That's a problem. Technically nothing stops you from doing that, you can do that if you want to, but you shouldn't be doing that. It's expected that make install has no side-effects on the rest of the system aside from the prefix dir, but by putting the completion script somewhere outside the prefix dir this introduces such a side-effect. So given this, the only time when the bash-completion would pick up the completion scripts is if the software is installed into /usr/local (or $HOME/.local), because the prefix coincides with where bash-completion would search for completion scripts.

Now, in the quoted example I say that the software is installed into /home/nurupo/my-build-prefix. It's installed in there rather that /usr/local because the intent was not to integrate the software with the rest of the system. Whoever installed it in there doesn't want bash-completion or anything else (man pages, pkg-config, etc.) picking the installed software up. If they wanted that, they would have installed it into /usr/local instead (or $HOME/.local, but let's ignore $HOME/.local for now, it's kind of a mess because it's not as ubiquitous as /usr/local so not all software looks into there by default).

Q. I author/maintain package X and would like to maintain my own
completion code for this package. Where should I put it to be sure
that interactive bash shells will find it and source it?

Anyway, the entry in README is for those who want to make it sure that their completion script is found by bash-completion. It's not the explanation of how to install completion scripts that will never be found by bash-completion when the prefix is neither /usr nor /usr/local.

Because it makes zero sense that a software installed outside /usr and /usr/local would be integrated with the system, i.e. that it would have its completion scripts integrated with the bash-completion, allowing the interactive bash shells find it and source it, it's natural to assume that the question asks about the bash shells finding the completion scripts only in the cases of when the software is installed into /usr and /usr/local. After all, having software installed outside those two directories suddenly be integrated into the system would be weird. Again, it can be done, nothing technically prohibits that, but that's a very unusual thing to do.

If the question meant to ask this regardless of the prefix, then perhaps it should have explicitly clarified that. Something like "Where should I put it to be sure that interactive bash shells will find it and source it no matter the installation prefix of my package?" would make it clearer. However even with it being clearer, the question itself is an odd one. It's unusual to want a software be integrated into the system no matter where it's installed. Do we really want to have such a question in FAQ? Has anyone else, aside from the person who originally committed that question, asked it before?

I also assume that by "I author/maintain package" the question means something along the lines of "I maintain a software project", e.g. a project on GitHub, instead of an actual distribution's package, like a Debian package, right? Because if it means distribution's package, that changes the question, as the assumption would be that it's always installed into /usr.

[akinomyoga]

Of course it will work, but only distribution's package manager software should be adding/removing files from /usr/share/bash-completion. Modifying anything in /usr, aside from things in /usr/local, is just asking for trouble, and as such should not be done, due to conflicts between user-installed files and files installed by the package manager and due to modifications breaking package manager's expectations.

It is written as if the current recommendation messes up /usr unlimitedly, but the change is actually limited in /usr/share/bash-completion.

I guess there was some sort of miscommunication then, because that's not what I was saying.

I have to repeat that we know that the current configuration is not the perfect one. I was talking about the way how you are unconsciously trying to mislead the readers. I'm not saying you are telling lie or something wrong, but intentionally obscuring the actual impact of the problem. I have a doubt about the word choice of "mess". When one just says "A messes up B", it may be possible that it means only a part of B is affected by A, yes. However, the natural recognition or primary impression by readers is, I guess, "A will cause problems in B here and there", so you appear to be unconsciously choosing the words that lead to the misunderstanding useful for you.

The expectation is that make install would put all the files into the prefix dir using the usual prefix file hierarchy: bin, lib, include, share and so on.

I guess this is the point that we do not agree with. How strict is that expectation commonly considered to be?

This is the fourth time, but I repeat that I agree that the current recommendation (of automatically installing completion scripts in a place of the detected bash-completion) is not a perfect one. To put it more explicitly, I personally do not think the current approach is a preferable one so would never design it in a current way if I was to make it from scratch (I actually personally prefer a perfect solution no matter how it is complicated, but we need to find an equilibrium point between the perfectness and the simplicity). It's evident the current recommended configuration is not at all clean and causing problems theoretically. For this point, I think we can agree with each other.

But the things have been worked in a current way for a long time in bash-completion although it might have caused problems now and then in the user's environment (but we haven't received any significant issues particularly about this one until now). However, you are actually just trying to make it stop working in this PR for the reason that it's not expected by autotools/cmake. In addition, this PR looked like "Hey, I was troubled by your README. You are doing something "ridiculous". You are "insane". You are "silly". It makes "zero sense". It's not expected and shouldn't be done, so I have broken the current mechanism for you!" We cannot accept this kind of destructive PR lacking calm.

If you think the PR should be merged as-is, the discussion that I expect from you is whether it's worth making the external completion configuration stop working for the reason that the current approach is not expected by autotools/cmake, i.e., (1) assessment on the impact of changing the recommendation (and thus making completion scripts inactive by default for custom installation), (2) how much we benefit from the changing or how many real issues (not conceptual issues) will be solved by the change, and (3) comparisons. However, it is generally difficult to correctly evaluate the impact of breaking changes, which is the reason we are forced to be somewhat conservative.

But I'd like to seek a constructive solution. I initially expected you could improve the PR in a constructive direction, but maybe that was an over-expectation. I'm actually thinking that we may introduce in bash_completion the same mechanism as man to find a corresponding file under the installation prefix of each binary. In particular, we may generate the list of possible paths of ${path%bin}/share/bash-completion/completions from PATH. Then, this PR will just work as I expect (though you don't seem to agree with making bash-completion automatically detect them in this way). One problem is that it takes a very long time for the distributed versions of bash-completion in wild to be completely replaced by the updated versions. I estimate it is about ten years or at least several years.

[nurupo]

I'm abandoning this PR as I don't have time on all this discussion. I expected it to be a straightforward change that would get merged fairly quickly, but turns out it's not and it has exceeded the amount of effort I'm willing to put into this. It's also rather hard and unpleasant to talk with you with the amount of language bikeshedding and various accusations coming from you.

I see that you recognize that there are issues with the current FAQ recommendation and you have some ideas on how this could be fixed, so there is hope it gets fixed in the future.

[akinomyoga]

I think I have subconsciously judged from your username and the initial commit messages that you would be used to and endurable against this kind of conversation (though now I become unsure whether you precisely know about from what kind of community the word nurupo came out. It was exactly the place where people talked in that way, and every response from you seemed to be also in line with it.), and also thought that you wouldn't improve the PR without strong words and tried to change your mind. But now I'm actually not sure how I should have behaved. I think I need to apologize for that point. I have again looked at the changes of this PR, but the quality just doesn't warrant merging (even without the conflicts in the conversation). At least, the PR should be largely updated, but I still feel you wouldn't have changed the essential part of the PR even if I responded in a tolerant way. Maybe I should have just created another PR with an alternative solution queitly.

I see that you recognize that there are issues with the current FAQ recommendation and you have some ideas on how this could be fixed, so there is hope it gets fixed in the future.

I'm recently busy, but I will make a PR in near future. I'm not sure if you can still take my words literally, but thank you for raising the issue.

[scop]

I'm sorry I didn't have time to read this discussion until now. The general tone of it and a quite a bit of its content is not welcome here. In that sense, no matter the technical content of the PR, it's good that it's closed now, and we take a step away at this point. We can come back to the topic later in a more respectful and constructive mood if someone wants.

Having said that, I'm also aware that the instructions are not perfect. I'm also aware that it's a hard problem to tackle, and I to date I haven't seen anything that would be definitely better than what we have now, just problematic in different ways. And to be honest, I'm not convinced it can be fixed in a way that would work great for every scenario out there. There are aspects in here that are highly dependent on opinions, which doesn't help.

If anyone wants to continue discussing the topic, I suggest taking a deep breath and letting it sit for a week. If you still would like to discuss it, then start a thread in the project discussions, and keep it to the point, open, respectful, and constructive. I suggest doing that before spending time constructing another related PR.

In any case, do refrain from posting further comments in this issue, including replying to this one. Thank you.

[nurupo]

@akinomyoga thank you for incorporating parts of this commit into #696 👍

[akinomyoga]

@nurupo I would like to thank you too for bringing up the discussion! Maybe you already noticed if you checked the introduced changes, but now we can just put the completion files in the same prefix as the executable file. Maybe there are still some cases that bash-completion fails to find the completion file, but I think now it is much better than the previous behavior. This is all realized since you have raised the issue. Thanks!