On macos, having run `brew install coreutils`, which installed GNU version of `printf`, this script/completion would sometimes complain about the (now missing) `-v` option usage.
This change set ensures the `-v` option is available where needed.
Note: there is a precedent of qualify which tool to run e.g. `command find ...`, `command dirname ...`, etc, so hopefully `builtin printf ...` should not cause any offense.
When users define custom _fzf_compgen_path or _fzf_compgen_dir functions,
FZF_COMPLETION_PATH_OPTS and FZF_COMPLETION_DIR_OPTS were not applied
because the options were only computed inside the walker fallback branch.
Close#4592
We have been checking the mawk version by extracting <x>, <y>, <z>,
and <d> part from "mawk <x>.<y>.<z> <d>" in the output of the "mawk -W
version" and testing <x>, <y>, <z>, and <d> using an arithmetic
evalaution. However, <d> is ensured to be an integer only in "x.y.z
>= 1.3.4". Otherwise, it may cause a syntax error in the arithmetic
evaluation. The mawk started to include the date as an integer in the
<d> position only from mawk-1.3.3-20090721. We should first check
that "x.y.z >= 1.3.4" and then check the value of "d". In case, "mawk
-W version" produces a completely different text, we should also
redirect stderr of the arithmetic commands to /dev/null.
For the line "Host host1 # this is a comment", the current
implementation generates words in an inline comment as hostnames.
This patch removes the comment before generating the hostname.
In ~/.ssh/config, "=" can also be used as a separator between the
field name and the value. The current master does not properly handle
this and generate a hostname "=" or one starting with "=". This patch
correctly handles it.
Comments are anyway removed in the subsequent call to `sub(/#.*/,
"")`, and it becomes a blank line. Blank lines do not have fields, so
they are ignored in the next for-loop.
In the current implementation, any hostnames in /etc/hosts containing
"0.0.0.0" as a part (such as "110.0.0.0" would be excluded. "0.0.0.0"
should be checked by the exact match.
An entry of the form `[example.com]:port,192.168.0.1 ...` in
~/.ssh/known_hosts are not properly processed. The current
implementation gives up the matching on the first occurrence of `]`,
the subsequent 192.168.0.1 would not be extracted. This patch
continues the analysis and removes "]" together with "[".
This patch also removes the ":port" part from the hostnames in
~/.ssh/known_hosts. One cannot use the form "hostname:port" in the
arguments to the ssh command anyway.
Solaris awk at /usr/bin/awk is meant for backward compatibility with
an ancient implementation of 1977 awk in the original UNIX. It lacks
many features of POSIX awk. To use a standard-conforming version in
Solaris, one needs to explicitly use /usr/xpg4/bin/awk.
macOS awk is a variant of nawk, but it contains a unique patch for the
UTF-8 support. However, this patch causes the problem. If the input
contains any non-UTF-8 data, macOS awk stops processing and does not
do anything, instead of ignoring the unrecognized data and continue
the processing. However, the contents of the ssh configuration and
/etc/hosts is not under the control of fzf, so we cannot fix the input
when those files contain non-UTF-8 data. To work around this
behavior, one can set the locale to LC_ALL=C to treat the input data
with the plain 8-bit encoding.
And remove the short preview window for showing the whole command.
Because it is important to be able to see the whole command before
deciding to kill it.
