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.
ASCII hyphens (U+002D HYPHEN-MINUS) in the option names (e.g. -x and
--extended) and the code examples in the man pages should be escaped
as \- (e.g. \-x and \-\-extended) to prevent them being converted to
Unicode hyphens in some environments.
For example, in openSUSE Tumbleweed, the raw ASCII hyphens in the
man-page sources are configured to be the Unicode hyphen (U+2010
HYPHEN). This makes it impossible to search the option name in the
man page by e.g. /--extended[RET]. A problem also arises in copying
and pasting option names and code examples from the man page. It
appears to be the normal ASCII hyphens by appearance (in typical
terminal fonts) but are not recognized as the ASCII hyphens by the
`fzf` command.
In the current codebase, for the original completion settings, the
pieces of the codes to determine the variable name and to access the
stored data are scattered. In this patch, we define functions to
access these variables. Those functions will be used in a coming
patch.
* This patch also resolves an inconsistent escaping of "$cmd": $cmd is
escaped as ${...//[^A-Za-z0-9_]/_} in some places, but it is escaped
as ${...//[^A-Za-z0-9_=]/_} in some other places. The latter leaves
the character "=" in the command name, which causes an issue because
"=" cannot be a part of a variable name. For example, the following
test case produces an error message:
$ COMP_WORDBREAKS=${COMP_WORDBREAKS//=}
$ _test1() { COMPREPLY=(); }
$ complete -vF _test1 cmd.v=1.0
$ _fzf_setup_completion path cmd.v=1.0
$ cmd.v=1.0 [TAB]
bash: _fzf_orig_completion_cmd_v=1_0: invalid variable name
The behavior of leaving "=" was present from the beginning when
saving the original completion is introduced in commit 91401514, and
this does not seem to be a specific reasoning. In this patch, we
replace "=" as well as the other non-identifier characters.
* Note: In this patch, the variable REPLY is used to return values
from functions. This design is to make it useful with the value
substitutions, a new Bash feature of the next release 5.3, which is
taken from mksh.
