1. A running IPFS Node (`ipfs daemon`)
2. The CID(s) that you want to pin
Let’s start with the simple pin command:
$ ipfs pin add <cid>
While the command above does its job, the UX it provides isn’t necessarily the best, since it doesn’t give any feedback to the end users. If you pin a large file/directory, the command will just sit there for minutes, if not hours, until it has finished pinning the content.
To improve the pinning experience, we can add the progress flag at the end to view the pinning progress in the terminal:
$ ipfs pin add --progress <CID>
With the new flag, the terminal will now print out a “status” of the pin:\
$ ipfs pin add --progress <CID> Fetched/Processed 47 nodes
Here comes another issue: What if you want to assign a name/label to the pinned CID? Without the associating labels, we can’t tell them apart!
Luckily, IPFS Kubo provides just the command we need out of the box:
$ ipfs files cp /ipfs/<CID> /"image of a cat"
Now let’s combine the 2 commands and run them at once:
$ ipfs files cp /ipfs/$(ipfs pin add --progress <CID> | cut -f 2 -d ' ') /"image of a cat"
The command ipfs files cp takes in a parameter which is the CID that we want to pin.
To retrieve that CID “programmatically”, we need to process the output of the command ipfs pin add <CID> —progress
Here are some examples of how the output of the pin command would look like:
pinning <CID> recursively queued <CID> recursively pinning <CID> done
As you can see, the CID that we need is always at the second field/slot of the output string. Hence, the command
cut -f 2 -d ' ' can be understood as: outputString.split(’ ’).