I am in favor of a multi-line string syntax; this keeps coming up. I'm torn between triple-quotes and here documents (#540). HereDocs are objectively disgusting but very widely supported; I lean towards them for that reason.

Changelog fix for #9699

In fish 3.6.1 as well as 3.3.1 at least, when running as root, commands (scripts or binaries) that are in $PATH, not owned by user root and/or group root, and are not world-executable will not be offered as completions, even though they are executable by root. This appears to affect Enterprise Linux (RHEL, CentOS, and Oracle Linux) 7 and 8, but does not affect macOS (any version). This happens whether ssh-ing to the Linux system via Apple Terminal or connecting directly to the machine's console. Running without third-party customizations does not affect the behavior.

How to reproduce:

1. Ensure your user account on the Linux system can sudo to root and that /usr/local/bin is in your $PATH
2. Create /usr/local/bin/testprog, using sudo if needed, containing something that could execute. An example:

#!/usr/bin/env fish
echo "Hello World"

3. Set the owner and group of testprog to something OTHER than root:root. For full effect, make sure your user account is either the owner or belongs to the group.
4. Set the permissions of testprog to 0550, 0750, or 0770
5. Attempt to auto-complete or tab-complete the command testprog (without typing it fully) and notice that fish will happily
6. Change to a root session running fish and ensure that /usr/local/bin is in your path as root
7. Attempt to auto-complete or tab-complete the command testprog (without typing it fully) and notice that fish will not
8. Run the command testprog (notice that fish will color the command as valid once it's typed fully)
9. Attempt to auto-complete or tab-complete the command testprog (without typing it fully) and notice that fish will now suggest it, since it's in your command history, but will not tab-complete it.
10. Switch to a root shell running bash
11. Attempt to tab-complete the command testprog (without typing it fully) and notice that bash will happily
12. Do any one of the following: change the owner of testprog to root, change the group of testprog to root, or set testprog's permissions to 0555, 0750, 0775, or 0777
13. Switching back to a fish root prompt, try tab-completing testprog again. Note that fish will happily tab-complete it now.

What should happen:

• If a command is executable at all, it's executable by root, and should be offered as a completion

What does happen:

• Fish only seems to offer commands for completion when the following are true: it is executable by anyone OR it is executable specifically by you OR it is executable by a group you belong to OR it's in your command history

Upon reflection I think 0b55f08de23f818cc4d839dace6926d30cf941dc cannot be saved; for example it doesn't consider ACLs, plus the "Cache a list of our group memberships" is suspect as this may change during a shell session. We should not be second-guessing the kernel in this way.

Reverted in c67d77fc1887eb7b5cd070630a59abe12d24a22e. Thank you for the outstanding bug report.

cc @mqudsi ; I don't think 0b55f08de23f818cc4d839dace6926d30cf941dc can be saved but maybe you have other ideas.

Revert "Speed up executable command completions"

This reverts commit 0b55f08de23f818cc4d839dace6926d30cf941dc.

This was found to have caused regressions in completions in #9699

Add Zabbix completions (#9647)

Add Zabbix completions

Description

Adds completions for Zabbix commands

TODOs:

• [ ] Changes to fish usage are reflected in user documentation/manpages.
• [ ] Tests have been added for regressions fixed
• [ ] User-visible changes noted in CHANGELOG.rst

@zanchey I wanted to merge this for 3.6.2 but I'm not clear on whether or not that ship has sailed?

Thank you for the detailed reproduction steps. I was able to reproduce this on Linux.

This bisects to 0b55f08de23f818cc4d839dace6926d30cf941dc. The issue is replacing the call to waccess with a call to fast_waccess which does a bunch of somewhat sketchy looking stuff, but mostly it tries to figure out if access would succeed without actually invoking access. I am tempted to revert.

In fish 3.6.1 as well as 3.3.1 at least, when running as root, commands (scripts or binaries) that are in $PATH, not owned by user root and/or group root, and are not world-executable will not be offered as completions, even though they are executable by root. This appears to affect Enterprise Linux (RHEL, CentOS, and Oracle Linux) 7 and 8, but does not affect macOS (any version). This happens whether ssh-ing to the Linux system via Apple Terminal or connecting directly to the machine's console. Running without third-party customizations does not affect the behavior.

How to reproduce:

1. Ensure your user account on the Linux system can sudo to root and that /usr/local/bin is in your $PATH
2. Create /usr/local/bin/testprog, using sudo if needed, containing something that could execute. An example:

#!/usr/bin/env fish
echo "Hello World"

3. Set the owner and group of testprog to something OTHER than root:root. For full effect, make sure your user account is either the owner or belongs to the group.
4. Set the permissions of testprog to 0550, 0750, or 0770
5. Attempt to auto-complete or tab-complete the command testprog (without typing it fully) and notice that fish will happily
6. Change to a root session running fish and ensure that /usr/local/bin is in your path as root
7. Attempt to auto-complete or tab-complete the command testprog (without typing it fully) and notice that fish will not
8. Run the command testprog (notice that fish will color the command as valid once it's typed fully)
9. Attempt to auto-complete or tab-complete the command testprog (without typing it fully) and notice that fish will now suggest it, since it's in your command history, but will not tab-complete it.
10. Switch to a root shell running bash
11. Attempt to tab-complete the command testprog (without typing it fully) and notice that bash will happily
12. Do any one of the following: change the owner of testprog to root, change the group of testprog to root, or set testprog's permissions to 0555, 0750, 0775, or 0777
13. Switching back to a fish root prompt, try tab-completing testprog again. Note that fish will happily tab-complete it now.

What should happen:

• If a command is executable at all, it's executable by root, and should be offered as a completion

What does happen:

• Fish only seems to offer commands for completion when the following are true: it is executable by anyone OR it is executable specifically by you OR it is executable by a group you belong to OR it's in your command history

No worries — it makes sense to me. I appreciate the response!

To keep Vi and non-Vi modes consistent, does it make sense that the default fish behavior is to not send any escapes when Vi mode is enabled?

No. The very point of the cursor shaping is to indicate the vi-mode (as in "insert" or "normal"), so this is a vi-specific thing, and the only way we can sensibly indicate it by default, given that we don't have a way to query your cursor shape, is to set a cursor shape.

Thank you for the quick response and the patch to not send the escape at all.

To keep Vi and non-Vi modes consistent, does it make sense that the default fish behavior is to not send any escapes when Vi mode is enabled?

I've now added a commit that will make it ignore (as in not send the escape at all) any cursor shape it doesn't know about, so you can just set the relevant cursor variables to e.g. empty.

set -g fish_cursor_unknown
set -g fish_cursor_insert

As an aside, I discovered that when any echo -en "\e[… q" escape control sequence is invoked, that will always take precedence no matter what the iTerm2 settings are changed to for existing interactive shells.

Yes, that is how these are supposed to work.