I've created a new example script that in addition to showing how to use some of the APIs will display desktop notifications for various incoming events.
I've also done some code cleanup and updated some of the documentation.
Some temp files were still not getting cleaned up when exiting via control
C, so now all of the API functions use bash Here Strings instead of a
temporary file. fixed 0adf244f
Some RPC functions were missing the logic to parse the RPC endpoint, it
would have required editing the functions.sh script directly in order to use
a different endpoint than the default. fixed 0adf244f
Readability:
Replaced jq output piped through cut to strip off quotations by adding the
-r raw option to jq instead.
Updated the README. 3b166f9e.
notify.shI love the console and all things text, but perhaps users might enjoy my API a little more if they saw some graphical ways they could make use of them. So I created the notify.sh script to be that example.
This script will watch any given user's account for incoming comments, votes, rewards, or transfers. Upon seeing any of these it will craft and display a desktop notification. It does require a notification daemon and the notify-send command in order to display the notifications.
Once launched with a specified user name, the script will run until the user kills it, for example, with control+C.
This script forgoes the complex argument parsing logic of the other examples as it only makes use of a single argument. It performs an infinite loop (until killed) with the typical while true ; do ... done loop. In the loop it fetches the latest account event number via a helper method that actually uses the rpc_get_account_history method.
The result of rpc_get_account_history has the following structure:
[
[
1709,
{
"trx_id": "728790ed1ff567bd70bf55d7ccf1934110c86f14",
"block": 19276954,
"trx_in_block": 8,
"op_in_trx": 0,
"virtual_op": 0,
"timestamp": "2018-01-25T04:01:30",
"op": [
"account_witness_proxy",
{
"account": "verasj",
"proxy": ""
}
]
}
],
...
]
This get_event_count method provides a -1 for the starting post number which actually fetches the most recent event. So then it uses jq to pull out the first element of the first result and it returns that number.
The first check in the infinite loop is to see if the last call to get_event_count matches the current one. If it doesn't match, then it computes the difference between the last and the current and fetches all of the missing records.
Next, it loops over those records and pulls out the operation type. It then uses a switch statement to determine what to do with the five different operations that it cares about. The functions it calls all perform a little bit differently, but their purpose is to extract relevant details from the message and then pack those details into a notification message. The message is then displayed with the notify-send command.
The simplest example of this is probably the handle_curation function which is called when there is a curation reward. The (slightly simplified) body looks like this:
These functions all take the current user being watched as teh first argument, and then read the JSON formatted result from get_account_history from standard in. In the code snippet above, the entry from the account history is read into the HISTORY variable using cat. This works because the cat command, when provided no file name, will read from standard in and write to standard out. So this makes an effective means for getting the value from standard in to a variable.
This function sets an icon to be displayed in the notification and then extracts the amount and denomination of the award from the HISTORY variable by way of the jq command. It then extracts the author and permlink from the curation reward so that it can call rpc_get_content on them to get the title of the work that was curated. Then the notify function is called with the icon, the title of "Curation" and a message indicating the amount of the reward and title.
The functionality of calling notify-send is wrapped in the notify function to make it easier to replace with some other form of notification. And here, if notify send fails for some reason, then it will display the title and message content to the console. This way it's still useful for text only systems (don't laugh, I have multiple.)
From the various messages it pulls the following details:
comment
The author of the comment, the title of the post being commented on, and the
text of the comment.
reward
The title of the post that generated the reward and the value of the reward's
SBD, STEEM, and VESTS amounts.
vote
The name of the voter, the weight of the vote, and the title of the post
receiving the vote.
curation
The reward amount of the curation and the title of the work.