summaryrefslogtreecommitdiff
path: root/doc/bugs/ipfs_initremote_failing_with___34__unable_to_parse_command__34__/comment_1_f1da699581e72aad0c3433d8fc02ce9c._comment
blob: c8b248fdcbb0586886ac094973e6df6838b9c246 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
[[!comment format=mdwn
 username="joey"
 subject="""comment 1"""
 date="2015-11-18T16:09:03Z"
 content="""
It works here, no problem. And, the ipfs special remote does not actually
use ipfs at all when initremote is run, so there's no possibility of some
change in ipfs versions having broken it.

My best guess is something in your shell or environment is making the
git-annex-remote-ipfs script not work right, and apparently output an extra
newline. I can reproduce that error message from git-annex if I modify
git-annex-remote-ipfs to echo a blank link on startup. I can't see any
way that shell script could output an extra newline normally however.

Passing --debug will cause the protocol output to be dumped, which could
help debug this. All I'd expect to see in the protocol dump is
git-annex sending "INITREMOTE" and git-annex-remote-ipfs responding
with "INITREMOTE-SUCCESS". So another way to see what's going wrong with
the script's output is this:

	# echo INITREMOTE | git-annex-remote-ipfs 
	VERSION 1
	INITREMOTE-SUCCESS
	#

And if that outputs an extra newline as I hypothesize, this should help
pinpoint what line of the script is doing that:

	# echo INITREMOTE | sh -x $(which git-annex-remote-ipfs)
"""]]