Please describe the problem.
I did manage to reach the rabbit hole bottom in the troubleshooting of my unique inability to use argcomplete for shell completion in datalad: datalad issue argcomplete issue
And the bottom looked liked:
$> IFS=$'\013' /usr/lib/git-annex.linux/git-annex version
[1] 1040489 segmentation fault (core dumped) IFS=$'\013' /usr/lib/git-annex.linux/git-annex version
$> IFS=$'\013' /usr/lib/git-annex.linux/git version
[1] 1040532 segmentation fault (core dumped) IFS=$'\013' /usr/lib/git-annex.linux/git version
whenever stock git is ok
$> IFS=$'\013' /usr/bin/git version
git version 2.27.0
most likely it is just a matter of sanitizing this variable in runshell or alike.
unsetting
IFSat top ofrunshell"fixes" it but IMHO would not be proper since shell completion etc tools relying on passing it into calls of git etc would be effected.bashsomehow seems to be also avoiding the segfault:runshell(etc) shims within standalone need to sanitize IFS only when they invoke some tools they use and which rely on IFS, but pass IFS as is into the actual call. It seems that the following patch does the trickand it seems that git shell completion then still works fine
Hmm, that patch looks pretty good, but contains a bashism in the
${IFS:-}and I don't actually understand what the point of that is, if seems to say it should expand to "" if IFS is not set, but it would expand to that anyway.Applied a version of the patch without the :- , although it seems the :- is not a bashism after all. It still makes no sense to me unless there's some other setting that might make the shell blow up when IFS isn't set.
set -uto my scripts, so they would fail if variable is undefined. Indeed in the default mode of operation it isn't needed.