The test suite does set -o posix for some reason. It does flag up a few problems (esp. if you disable the &>/dev/null when sourcing dynamic loaded completions). I think some variable names that included a -, and a process substitution.
I see this has already come up, as https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=314720&group_id=100114 I was going to use readarray -t COMPREPLY < <( compgen ... ) in something, but set -o posix disables <(process substitution) (http://tiswww.case.edu/php/chet/bash/POSIX). So my code wouldn't work with the testsuite. So do we want to just use x="$( compgen ... )" readarray -t COMPREPLY <<< "$x" as our idiom of choice, like a bunch of functions already do? That writes to a tmpfile in /tmp, then redirects the input of readarray from that. Redirecting from a process substitution is about the same overhead as a pipe. compare strace -e trace='!rt_sigprocmask,rt_sigaction' -f bash -c 'readarray -t ARR < <(exec echo)' strace -e trace='!rt_sigprocmask,rt_sigaction' -f bash -c 'x=$(exec echo); readarray -t ARR <<< "$x"' <<< has to statfs('/tmp'), which seems silly, as well as a bunch of other overhead. readarray -u <(cmd) didn't seem to work. I guess builtin commands don't work right with the /proc/pid/fd/number filenames that process substitution generates? Redirecting from a process substitution elides opening of /proc/pid/fd, and just does the usual pipe thing, so it's actually more efficient. Unfortunately we can't just pipe into readarray, because that would put readarray in a subshell that didn't affect the main script's env. (Thanks Eduardo Bustamante for reminding me about Wooledge's site, http://mywiki.wooledge.org/BashFAQ/001 pointed me towards readarray and process substitution.) http://unix.stackexchange.com/questions/136206/readarray-or-pipe-issue points out that there is a shopt -s lastpipe to let shopt -s lastpipe ( echo a; echo b; echo c ) | readarray arr work. Tempting, but setting and unsetting it on enter/leave progcomp is prob. more trouble than the readability of other ways of feeding readarray Also, thoughts on using readarray to replace loops in existing code? There are a few cases of loops like while read -r tmp; do toks+=( "$tmp" ) done <<< "$x" _filedir_xspec() has some REALLY ugly loops, like loop over the output of compgen, and expose it to glob expansion for quote removal I guess? Capturing it with toks=( $( compgen | while read ...; do printf ...;done ) ) But that's a separate issue; readarray can only replace loops that AREN'T treating data as shell code. I think if we want to be fully safe with filenames that include a *, we'll need to replace every COMPREPLY+=( $( compgen ... ) ) with a readarray (or equivalent while read loop, if we need compat with older bash, but I'd vote that we use readarray for speed and readability. http://wiki.bash-hackers.org/commands/builtin/mapfile says that readarray was buggy until bash 4.1 beta, and I think we only support bash >= 4.1.) And to get back to where I started, IMO we don't need to support set -o posix. Does anyone use that in interactive shells? progcom isn't really essential, IMO, so people can get by on just filename completion in the rare cases where they need to set -o posix in an interactive shell. -- #define X(x,y) x##y Peter Cordes ; e-mail: X(peter@cor , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC _______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel