ipfs-shell [1] accesses the Command objects directly to construct
requests for an external IPFS daemon API. This isn't a terribly
robust approach, because it doesn't handle version differences between
the version of go-ipfs used to build the daemon and the version used
to build the ipfs-shell-consuming application. But for cases where
you can get those APIs to match it works well. Making these two
commands public allows us to write ipfs-shell wrappers for them.
Until we figure out how to get ipfs-shell working without access to
core/commands, I think the best approach is to make future command
objects and their returned structures public, and to go back and
expose existing commands/structures on an as-needed basis.
In this case, I need the public PublishCmd for the Docker-registry
storage driver, and I made the IpnsCmd public at the same time to stay
consistent for both 'ipfs name ...' sub-commands.
[1]: https://github.com/whyrusleeping/ipfs-shell
License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>
There has been a regression such that ./t0030-mount.sh fails on
'ipfs mount' fails when there is no mount dir
The issue was a change in how fuse errors are reported to the client
process. We have introduced an optimistic categorization that hides
the obscure fusermount error and replaces it with something a bit
more helpful.
License: MIT
Signed-off-by: Juan Batiz-Benet <juan@benet.ai>
Except when there is an explicit os.Exit(1) after the Critical line,
then replace with Fatal{,f}.
golang's log and logrus already call os.Exit(1) by default with Fatal.
License: MIT
Signed-off-by: rht <rhtbot@gmail.com>
WIP: object creator command
better docs
move patch command into object namespace
dont ignore cancel funcs
addressing comment from CR
add two new subcommands to object patch and clean up main Run func
cancel contexts in early returns
switch to util.Key
If no path after `/ipfs/` or `/ipns/` is given, then the daemon will
panic with a slice bounds out of range error. This checks to see if we
have anything after `ipfs` or `ipns`.
Previously we had a confusing situation, with:
* single-arg doc: published name <name> to <value>
* double-arg doc: published name <value> to <name>
* implementation: Published name <name> to <value>
Now we have the uniform:
Published to <name>: <value>
With the following goals:
1. It's clear that we're writing <value> to <name>'s IPNS slot in the
DHT.
2. We preserve the order of arguments from the command-line
invocation:
$ ipfs name publish <name> <value>
Published to <name>: <value>
