You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
POSIX declares the results unspecified when NUL is on the stdout within a command substitution. So either it might be ignored, or it might terminate the string or... whatever. Not using --print0 causes an undesired newline to be added in fzf’s output, which is however anyway stripped because of (1).
this doesn't work anymore, when -m multiple elements are selected, either because of (2) or, if --print0 is not used, because the separator would again be newline, which would be indistinguishable from newlines in the elements.
i=0
find . -mindepth 1 -maxdepth 1 -type d -print0 | fzf -m --read0 --print0 | \
while true; do
eval "var=$(printf_from_stdin)"
if [ -z "${var}" ]; then
break
fi
printf ':%s:%s::\n' "${i}" "${var}"
i=$(($i+1))
done
(with some sugar for display purposes)
Main problems with that:
a. Works only in bash (POSIX’ read doesn't have the -d and -u options)
b. Using that is rather ugly ^^
So the idea of this feature request would be that fzf gets a function similar to ls’ --quoting-style=-option, but specifically for output, so that one could e.g. do something like.
$ ls -al $(find . -mindepth 1 -maxdepth 1 -type d -print0 | fzf -m --read0 --print0 --output-quoting-style=shell-escape)
Assuming that shell-escape is a schema that escapes in such a way that it's re-usable as input to the shell.
Of course one could have various quoting styles, e.g. for other shells that are not POSIX compatible. Also, current POSIX doesn't support $'…'-style quoting (but the next upcoming issue of POSIX will), so it might make sense to add a style for old POSIX,... or perhaps one for fish (if that's special in that regard - I don't know).
Cheers,
Chris.
The text was updated successfully, but these errors were encountered:
Also note, that for such functionality to be useful in the way I propose, it would be crucial that the escaping is done right, so that and arbitrary input string is quoted in a manner so that it can really be safely re-used as input (e.g. in eval) without any expansions/substitutions/etc. happening.
man fzf
)Feature Request
This is a companion to #3493, with the difference that here it's about a quoting style for the (selected) output of
fzf
.I would say that
fzf
is quite often used from shells. But there, any meta-characters or other "strange" can easily cause problems.Further, I'd say that often, the elements are pathnames (which may contain everything except for
NUL
).A typical use-case seems to be e.g.:
or:
The
NUL
-delimited versions of these would be:or:
There are three problems here:
NUL
is on the stdout within a command substitution. So either it might be ignored, or it might terminate the string or... whatever. Not using--print0
causes an undesired newline to be added infzf
’s output, which is however anyway stripped because of (1).-m
multiple elements are selected, either because of (2) or, if--print0
is not used, because the separator would again be newline, which would be indistinguishable from newlines in the elements.One workaround in
bash
(only) is something like:together with:
after which
var
may hold e.g.'k'$'\n\n'
respectively (for the
fzf -m
case):(with some sugar for display purposes)
Main problems with that:
a. Works only in
bash
(POSIX’read
doesn't have the-d
and-u
options)b. Using that is rather ugly ^^
So the idea of this feature request would be that
fzf
gets a function similar tols
’--quoting-style=
-option, but specifically for output, so that one could e.g. do something like.Assuming that
shell-escape
is a schema that escapes in such a way that it's re-usable as input to the shell.Of course one could have various quoting styles, e.g. for other shells that are not POSIX compatible. Also, current POSIX doesn't support
$'…'
-style quoting (but the next upcoming issue of POSIX will), so it might make sense to add a style for old POSIX,... or perhaps one forfish
(if that's special in that regard - I don't know).Cheers,
Chris.
The text was updated successfully, but these errors were encountered: