search

jrnl-org / jrnl

Collect your thoughts and notes without leaving the command line.
https://jrnl.sh
GNU General Public License v3.0
6.46k stars 523 forks source link

Application hooks #921

Open nicolaiarocci opened 4 years ago

nicolaiarocci commented 4 years ago

Feature Request

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 commented 4 years ago

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 commented 4 years ago

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

There are some issues to iron out when implementing:

50ten40 commented 4 years ago

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 commented 4 years ago

I’ve implemented something similar for my workflow

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

micahellison commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

wren commented 3 years ago

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

KarimPwnz commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

KarimPwnz commented 3 years ago

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 commented 3 years ago

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 commented 11 months ago

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 commented 8 months ago

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

Linking #455 for posterity.