eselect editor only list and set EDITOR env variable from available targets. It would be nice if gentoo also installed a link to /usr/bin/editor This command can be specified everywhere in the documentation and in free communication and don't call holivars because of user preference. I've definitely seen this in Debian (https://wiki.debian.org/DebianAlternatives): root@v:~# update-alternatives --config editor There are 2 choices for the alternative editor (providing /usr/bin/editor). Selection Path Priority Status ------------------------------------------------------------ * 0 /bin/nano 40 auto mode 1 /bin/nano 40 manual mode 2 /usr/bin/vim.tiny 15 manual mode Press <enter> to keep the current choice[*], or type selection number: ... root@v:~# ls -l /usr/bin/editor lrwxrwxrwx 1 root root 24 Apr 27 2021 /usr/bin/editor -> /etc/alternatives/editor root@v:~# ls -l /etc/alternatives/editor lrwxrwxrwx 1 root root 9 Apr 27 2021 /etc/alternatives/editor -> /bin/nano Then you can use this in examples like: > $ editor /etc/hosts Reproducible: Always
I don't really see a point to this. I am aware of software that respects the EDITOR environment variable. I have never seen anything that calls /usr/bin/editor.
Because it is found in instructions and documentation. Where, instead of a snippet with the path to the file and the signature "edit this file in your preferred editor", it can only contain the exact command "editor /path/to/file". I always use this in documentation myself and want to see this approach in other distributions. Unfortunately, standards are accepted in our sweety world only "de facto". Support this convenient innovation in Gentoo as well (first as a command line, and then as a standard for wiki and documentation). Thank you.
A nicer approach than a symlink might be to install a shell script that calls "exec ${EDITOR}", with a fallback list if EDITOR is unset.
(In reply to Mike Gilbert from comment #3) > A nicer approach than a symlink might be to install a shell script that > calls "exec ${EDITOR}", with a fallback list if EDITOR is unset. app-misc/editor-wrapper does exactly that, "exec ${EDITOR}" and fallback to the definition in the system profile if the EDITOR variable is unset. The decision at the time (2009) was to place the wrapper script in /usr/libexec instead of /usr/bin.
(In reply to Ulrich Müller from comment #4) > The decision at the time (2009) was to place the wrapper script in > /usr/libexec instead of /usr/bin. Maybe it's time (2022) to add this to the standard paths?
No, /usr/libexec is intended for "binaries that are not intended to be executed directly by users or shell scripts". See the FHS: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html Closing.
(In reply to Ulrich Müller from comment #6) > No, /usr/libexec is intended for "binaries that are not intended to be > executed directly by users or shell scripts". > See the FHS: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html > > Closing. Of course! That's why I asked to move executable from /usr/libexec to $PATH in app-misc/editor-wrapper. /usr/libexec not is stardart $PATH so users cannot call "editor" directly
(In reply to Vladimir Varlamov from comment #7) Same reasoning. The wrapper script is in /usr/libexec because it is not intended to be executed by users directly. (Also, this is the first request since 12 years to move the wrapper out of the libexec location, from which I would conclude that it cannot be completely wrong.) (In reply to Vladimir Varlamov from comment #2) > Because it is found in instructions and documentation. Where, instead of a > snippet with the path to the file and the signature "edit this file in your > preferred editor", it can only contain the exact command "editor > /path/to/file". What would be the problem with "${EDITOR} /path/to/file" instead?
Because it is considered good form to indicate commands in the documentation, howtos, on stackoverflow and eth. Using editor command, and not something else. It is good practice for all distributions to switch to this notation. And this is understandable to users. This is not an indicator that no one has proposed this in 12 years. I suggested it because I have been actively working with many distributions as a system administrator for the last 8 months and I do not find in gentoo some of the conveniences that are taken as a standard in other distributions. Just don't talk about gentoo! Over 18 years of using it, I saw love and hate. This is not necessarily a localhost installation that has been customizable for years, no, this includes a hot boilerplate for anything. So these little things should be included in the base, like the color in the console, for example, which no one talks about because it is convenient.
