Run ssh with -n whenever input is not being piped into it

... to avoid it consuming stdin that it shouldn't.

This fixes git-annex-checkpresentkey --batch remote, which didn't output
results for all keys passed into it.

Other git-annex commands that communicate with a remote over ssh may also
have been consuming stdin that they shouldn't have, which could have
impacted using them in eg, shell scripts. For example, a shell script
reading files from stdin and passing them to git annex drop would be
impacted by this bug, whenever git annex drop ran git-annex-shell
checkpresent, it would consume part/all of the stdin that the shell script
was supposed to consume.

Fixed by adding a ConsumeStdin parameter to Annex.Ssh.sshOptions, which
is used throughout git-annex to run ssh (in order for ssh connection
caching to work). Every call site was checked to see if it used
CreatePipe for stdin, and if not was marked NoConsumeStdin.
This commit is contained in:
Joey Hess 2017-02-15 15:08:46 -04:00
parent a0222ea7eb
commit f07af03018
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
14 changed files with 99 additions and 40 deletions

View file

@ -59,3 +59,5 @@ Arch Linux (installed from 'community')
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
I only find (what I think are) bugs because I use it and I use it because I like it. I like it because it works (except for when I find actual bugs :]).
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,26 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2017-02-15T18:04:29Z"
content="""
I am able to reproduce this, and it only happens when the remote being
checked is a ssh remote, not a local directory.
So, presumably something in the verification that the remote has the
content is sometimes consuming the rest of stdin.
The different numbers processed each time are probably due to buffering. If
the command feeding the list of keys takes a while to print them all, and
parts of its output are being thrown away, then that would explain the
different numbers processed.
Using ssh -n to run git-annex-shell checkpresentkey avoids the problem.
This could also impact git-annex being used in some script, when the script
is intended to consume stdin, but git-annex runs ssh, which consumes it
instead. Other commands like `git annex drop` could be affected
too in such situations.
I've put in a comprehensive fix to all of git-annex's calls to ssh
that don't provide some other stdin.
"""]]