Application hooks

[nicolaiarocci]

Feature Request

• What is the motivation / use case for changing the behavior?

I keep a copy of my journal on a private github repository. I have a very simple script in my journal folder that will basically git commit -am "new updates" && git push. It would be great if this script could be executed automatically every time a new entry is saved. Simple Application-level hooks would be ideal (think git hooks.)

[wren]

We're thinking about this. It seems like a good idea, but we'll have to work out some of the kinks in how best to configure it.

[micahellison]

It looks like this has been requested several times over jrnl's history.

There are some issues to iron out when implementing:

• Should this be a global configuration value, or specific to each journal, or both?
• Is any special behavior needed for file vs. directory journals?
• What values should be available to pass to the script/application? For instance: journal file path, journal directory path, journal name, event type (new entry vs. edit), etc.
• What security concerns should be addressed?
• How can all of this be tested automatically?

[50ten40]

Feature Request

• What is the motivation / use case for changing the behavior?

I keep a copy of my journal on a private github repository. I have a very simple script in my journal folder that will basically git commit -am "new updates" && git push. It would be great if this script could be executed automatically every time a new entry is saved. Simple Application-level hooks would be ideal (think git hooks.)

I’ve implemented something similar for my workflow. https://floss.durastudio.com/jrnl-rific

[nicolaiarocci]

I’ve implemented something similar for my workflow

Yeah cronjob is always an option. Configurable hooks would be better IMHO.

[micahellison]

I was just talking with @wren about this feature and how to implement it.

It would be nice for it to check the exit status of the process it calls, so it could report back whether it has succeeded or failed. We wouldn't want someone using this feature while unaware of silent failures. It should also be relatively easy to test this with the behave tests, though we may need to be platform-specific versions of each test.

In terms of what types of data to allow the user to pass to the process, we're thinking that the journal path should be enough. The main use case we can think of is tracking changes with git, and the journal path would be enough for that, whether it's a file or a directory.

Also, as with any new config field, this feature should be released with changes to the documentation so people know how to use it.

[50ten40]

I’ve implemented a version at jrnl-rific that works ok for my needs. https://github.com/Durastudio-FLOSS/jrnl-rific/blob/master/export_jrnl_files.sh

On Sat, Jul 18, 2020 at 2:21 PM micahellison [email protected] wrote:

I was just talking with @wren https://github.com/wren about this feature and how to implement it.

It would be nice for it to check the exit status of the process it calls, so it could report back whether it has succeeded or failed. We wouldn't want someone using this feature while unaware of silent failures. It should also be relatively easy to test this with the behave tests, though we may need to be platform-specific versions of each test.

In terms of what types of data to allow the user to pass to the process, we're thinking that the journal path should be enough. The main use case we can think of is tracking changes with git, and the journal path would be enough for that, whether it's a file or a directory.

Also, as with any new config field, this feature should be released with changes to the documentation so people know how to use it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jrnl-org/jrnl/issues/921#issuecomment-660544236, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD37VWYBGUAA6WNY5HJCYBTR4IG4XANCNFSM4MLWBKJQ .

[KarimPwnz]

Should there be many types of hooks (pre-save, post-save, etc.), or is just a post-save enough? Also, for testing, I was thinking we could run jrnl commands in the hooks so it could be platform-independent. Thoughts?

[wren]

@KarimPwnz We do want multiple hooks, but starting with just one is a great way to incrementally implement this, and post-save seems like a great place to start.

For the tests, I'm not sure what you mean about jrnl commands. Like, running jrnl -3 or something like that in the hook?

[KarimPwnz]

Will start on it then!

For the tests, I'm not sure what you mean about jrnl commands. Like, running jrnl -3 or something like that in the hook?

And yes, this is what I was thinking.

[wren]

How would that work with non-default journals? How would the hook know which journal it is supposed to act on? Are you proposing we pass in the journal name to the hook?

[KarimPwnz]

I am proposing we use jrnl --version or an equivalent—something that is journal and OS agnostic.

[wren]

I'm not clear on how that would be used in a hook. Can you elaborate a bit?

[KarimPwnz]

I want to use jrnl in the test hooks so we can have a universal method. This way, we won't need a test hook for every other OS: jrnl will always be available.

[micahellison]

It's a worthwhile goal. I don't think that jrnl will always be available, though -- for instance, it's not installed in our build environment. However, python ought to be available in every environment. Maybe a quick python --version call could do the trick. This could also be handy for automatically testing failed processes spawned by the hook, such as: python -c "raise Exception('Deliberate error')"

[KarimPwnz]

Ah, fair enough. Using python is a better idea—thanks!

[KarimPwnz]

I think python -c 'import sys; print(sys.argv[1])' is the best test here: it'll print out the first argument—the journal path we pass.

[wren]

I agree that using python is most reliable for this. We should also have a test that mocks the hook to confirm that the expected arguments are being passed (and in the expected order).

[adityaxdiwakar]

This is a bit of an old issue, but for those who come across it and want a quick solution, you can put this in your bash/zsh aliases:

jrnl() {
    command jrnl "$@"
    ~/jrnl/scripts/commit.sh
}

I use ~/jrnl/scripts/commit.sh, but replace it with whatever script you want to run as a post-hook. I don't want to use crontab as it'll have my CPU spin during every interval and I only use jrnl 1-2x per hour, so lots of wasted intervals (and I want high commit granularity).

Note: I redirect stdout and stderr to /dev/null which the above function does not do. If you want that functionality, add > /dev/null 2>&1 to the last line in the function. This will make things silently fail, which is generally bad, but my script aggregates errors so I'm not annoyed when making quick to-do list updates.

[solvaholic]

Thanks for https://github.com/jrnl-org/jrnl/issues/921#issuecomment-1793845901 @adityaxdiwakar! :bow:

Linking #455 for posterity.