jrnl is a simple journal application for the command line.

Overview

jrnl Testing Downloads Version Homebrew Gitter Changelog

To get help, submit an issue on Github.

jrnl is a simple journal application for the command line.

You can use it to easily create, search, and view journal entries. Journals are stored as human-readable plain text, and can also be encrypted using AES encryption.

In a Nutshell

To make a new entry, just enter

jrnl yesterday: Called in sick. Used the time to clean the house and write my
book.

yesterday: is interpreted by jrnl as a timestamp. Everything until the first sentence ending (either ., ?, or !) is interpreted as the title, and the rest as the body. In your journal file, the result will look like this:

[2012-03-29 09:00] Called in sick.
Used the time to clean the house and write my book.

If you just call jrnl, you will be prompted to compose your entry - but you can also configure jrnl to use your external editor.

For more information, please read the documentation.

Contributors

Maintainers

Our maintainers help keep the lights on for the project:

Please thank them if you like jrnl!

Code Contributors

This project is made with love by the many fabulous people who have contributed. jrnl couldn't exist without each and every one of you!

If you'd also like to help make jrnl better, please see our contributing documentation.

Financial Backers

Another way show support is through direct financial contributions. These funds go to covering our costs, and are a quick way to show your appreciation for jrnl.

Become a financial contributor and help us sustain our community.

Comments
  • Homebrew install broken due to using Python 3.8 with outdated jrnl version (v1.9.8)

    Homebrew install broken due to using Python 3.8 with outdated jrnl version (v1.9.8)

    jrnl version 1.9.8 MacOS 10.15.2

    AttributeError: module 'time' has no attribute 'clock'

    The function time.clock() has been removed, after having been deprecated since Python 3.3: use time.perf_counter() or time.process_time() instead, depending on your requirements, to have well-defined behavior. (Contributed by Matthias Bussonnier in bpo-36895.)

    https://docs.python.org/3/whatsnew/3.8.html

    bug :pushpin: 
    opened by ghost 42
  • Archlinux packaging issues

    Archlinux packaging issues

    Bug Report

    Thanks for your time, please keep reading before closing as OS packaging problem, just trying to figure out a solution.

    Environment

    • Jrnl version: 2.4.2
    • Install method: aur / pacman (archlinux package manager
    • OS Linux

    Current Behavior

    System upgrade fails due to jrnl dependency being listed as python-cryptography<3.0

    Expected Behavior

    No problems upgrading, since (AFAIK) there is no (relevant) breaking changes in this library. Tested (loosely) and it worked.

    Repro Steps

    • Install jrnl using arch package manager
    • Try to upgrade (e.g. pacman -Syu)

    Other Information

    The dependency is listed as "cryptography = "^2.7" in pyproject.toml, which seems suspiciously like something poetry would generate. Now, before anything, if there is a reason to limit cryptography version to <3.0 as this would, please close this issue: the solution would be to change OS packaging to use pipx, as discussed by the maintainer here.

    Otherwise, just relaxing this constraint would help us poor arch users. I saw the discussion about loosing up dependency restrictions in some other arch issue, I agree it should be made with caution. On the other hand, when dealing with packages such as this one, the arbitrary constraint will keep bug fixes and security enhancements out of the build, and, well, one can go both ways. Poetry's behavior is understandable, and in this case there are many breaking changes in cryptography 3.0. Version number default semantics justifies it. So, it is a matter of opinion, but an upper limit seems more reasonable when there is a known problem and not as a prophylactic.

    I am just giving some rationalizations here. The real reason is I don't like this behavior, and it has been a pain more than a solution. Feel free to ignore. Also, there is a non trivial chance I am missing something here.

    Workaround

    Uninstall jrnl and reinstall using pipx. Yes, this is the recommended way by the docs. See, I like python, but its dependency hell makes me think it should be named Nachash. :grin:

    support 
    opened by suderio 32
  • DayOne: Editing existing entries with tags removes the tags when saving

    DayOne: Editing existing entries with tags removes the tags when saving

    1. Create a DayOne entry using DayOne.app and add a tag using the tag button at the top of the entry (don't include the tag in the body).
    2. Click save and see that the entry is now tagged.
    3. Close DayOne
    4. Run jrnl dayone -n 1 --edit and edit the entry you just added, and save it.
    5. Open DayOne and note that the latest entry is no longer tagged.
    day one 
    opened by flight16 25
  • Create a homebrew package for jrnl

    Create a homebrew package for jrnl

    Hello,

    first off, jrnl looks great and I could see myself using it.

    This is not necessarily an issue with jrnl itself because sometimes these issues are opened at the homebrew repository but it's probably more appropriate to open it here in case the author wants to add the formula himself.

    I'd love to see a homebrew (http://brew.sh/) package which would make it easier to update jrnl in one go with all your applications/libraries.

    Thanks.

    mac 
    opened by dewey 24
  • Namespace-based Export Plugins

    Namespace-based Export Plugins

    I'm thinking about reworking the export plugin system to be auto-discovered based on the module name. Assuming this works well, it could be expanded to import plugins and possibly the storage backends as well.

    There would be two namespaces: one for internal plugins, and another for external/contributed plugins.

    The usecase would be to solve issues such as #779 where there is a difference of opinion of what the export should look like, or if you have a special format that you need. "Contributed" plugins could also be a way to test out a format before added in to the core of jrnl.

    For myself, I have a "special" plugin that I used as a prep step to feed my jrnl entries into Pelican (a static site generator). It's always seemed like too "special" of a case to submit for the main repo, but it's something I use regularly. With the support and bug fixes to DayOne support, this is probably the only reason I have left to keep a private fork of jrnl.

    In terms of implementation, I'm imagining that each plugin would have five methods:

    • one that returns it's name (e.g. "Markdown Exporter")
    • one that returns it's version (e.g. "2.4.4-beta"; for built-in plugins, this would match jrnl)
    • one that returns a list of "format codes" that it will process (e.g. ["md", "markdown"]; this is was will used by the export command of jrnl)
    • one that is passed a single entry and returns the exported entry
    • one that is passed a journal and returns the exported journal

    I expect that contributed plugins would override the build-in plugins if they defined the same format code.

    By using namespaced plugins, the plugin would be install-able via pip and would require no more configuration or activation beyond being importable by Python.

    I haven't written any code yet (but I've been trying to figure out how to do this for probably 3 years...), but I wanted to get some thoughts on if there was support for this before I spend a bunch of time on it.

    Thanks,

    discussion 
    opened by MinchinWeb 22
  • Add --delete for interactive removal of entries

    Add --delete for interactive removal of entries

    • Add switch for deleting entries. Works with filters, etc.
    • Fix some minor style issues

    Fix #434

    # First, create a journal named "test"
    $ python3 -m jrnl test First entry
    $ python3 -m jrnl test Second entry
    $ python3 -m jrnl test Third entry
    $ python3 -m jrnl test --delete
    

    Checklist

    • [x] The code change is tested and works locally.
    • [x] Tests pass. Your PR cannot be merged unless tests pass
    • [x] There is no commented out code in this PR.
    • [x] Have you followed the guidelines in our Contributing document?
    • [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
    • [x] Have you added an explanation of what your changes do and why you'd like us to include them?
    • [x] Have you written new tests for your core changes, as applicable?
    enhancement 
    opened by alichtman 22
  • Questions on jrnl Installation and Some Errors

    Questions on jrnl Installation and Some Errors

    I'm having problem installing jrnl.

    When i tried doing pip install jrnl it said command not found: pip

    screen shot 2014-07-02 at 1 34 34 pm

    Is there alternate way to install this? or am I missing something?

    Thank you in advance. :-)

    opened by manishsuwal 21
  • External Plugins v2

    External Plugins v2

    (This is a follow up to #1115 because in that one I pushed directly to develop, plus it's been squashed and rebased, and it proved easier in my head to make a new branch.)

    The open "issues" from #1115:

    • [x] Tests: not included yet. Any ideas on how to change the installed Python packages in a "new" testing environment?
    • [x] handling of name conflicts: Running jrnl --version will show you the list of active plugins, include where they came from.
    • [x] display plugin version: Also on jrnl --version
    • [x] documentation: Done!

    Sample jrnl --version output:

    λ jrnl --version
    jrnl version v2.7.2-beta
    
    Copyright (C) 2012-2021 jrnl contributors
    
    This is free software, and you are welcome to redistribute it under certain
    conditions; for details, see: https://www.gnu.org/licenses/gpl-3.0.html
    
    Active Plugins:
        Importers:
            jrnl : v2.7.2-beta from jrnl.plugins.importer.jrnl_importer
        Exporters:
            boxed : v2.7.2-beta from jrnl.plugins.exporter.fancy_exporter
            fancy : v2.7.2-beta from jrnl.plugins.exporter.fancy_exporter
            json : v2.7.2-beta from jrnl.plugins.exporter.json_exporter
            markdown : v2.7.2-beta from jrnl.plugins.exporter.markdown_exporter
            md : v2.7.2-beta from jrnl.plugins.exporter.markdown_exporter
            tags : v2.7.2-beta from jrnl.plugins.exporter.tag_exporter
            text : v2.7.2-beta from jrnl.plugins.exporter.text_exporter
            txt : v2.7.2-beta from jrnl.plugins.exporter.text_exporter
            xml : v2.7.2-beta from jrnl.plugins.exporter.xml_exporter
            yaml : v2.7.2-beta from jrnl.plugins.exporter.yaml_exporter
    

    For documentation, I would love to take insert the sample plugins from external files, and use those same external files as a base for the testing. Is the first part (inserting an external file) possible to MkDocs?

    Also, the template exporter got dropped because I couldn't figure out how to make it work with displaying the version numbers... Is that okay?

    opened by MinchinWeb 20
  • Investigate support/automation for Arch Linux package deployment process

    Investigate support/automation for Arch Linux package deployment process

    A fair amount of users get jrnl from the Arch User Repository package, which is great, but there's a synchronization lag between jrnl releases and updating the package. It would be nice to automate it so Arch users can easily access the latest release right away.

    I'll try to get in touch with the maintainer but wanted to put this issue out there as a starting point since it will probably have some small accompanying CI changes.

    Some history:

    • The AUR package was set up in 2014 (see issue #73) but the original creator isn't the maintainer anymore
    • Some background is explained in the #779 bug report by @griffrawk (thank you!)
    enhancement 
    opened by micahellison 20
  • Can't use Brazilian Portuguese

    Can't use Brazilian Portuguese

    I've tried to write a Jrnl entry with brazilian portuguese, which has accents on some words, and I get the following error:

    Traceback (most recent call last):
      File "c:\python27\lib\runpy.py", line 162, in _run_module_as_main
        "__main__", fname, loader, pkg_name)
      File "c:\python27\lib\runpy.py", line 72, in _run_code
        exec code in run_globals
      File "C:\Python27\Scripts\jrnl.exe\__main__.py", line 9, in <module>
      File "c:\python27\lib\site-packages\jrnl\cli.py", line 194, in run
        journal = Journal.Journal(journal_name, **config)
      File "c:\python27\lib\site-packages\jrnl\Journal.py", line 39, in __init__
        self.open()
      File "c:\python27\lib\site-packages\jrnl\Journal.py", line 108, in open
        journal = f.read()
      File "c:\python27\lib\codecs.py", line 668, in read
        return self.reader.read(size)
      File "c:\python27\lib\codecs.py", line 474, in read
        newchars, decodedbytes = self.decode(data, self.errors)
    UnicodeDecodeError: 'utf8' codec can't decode byte 0xe1 in position 127: invalid continuation byte
    

    The word that is giving the error is "Pará"

    bug windows :pushpin: 
    opened by heitorsilva 20
  • DayOne issue and improvement

    DayOne issue and improvement

    Hi!

    Thanks for the solution with the previous issue! I now manage to list and add entries to the DayOne journal.

    There is an issue however: When a new entry is added a CRLF is added to the entry! DayOne recognizes such entries as headers and display them in bold text! So all entries added with jrnl displays in bold!

    Then I have a feature request! There is a location added to each entry. Obviously jrnl does not implement this but it would be nice if there was an option in the .jrnl_config to set a static location that was added to the entry each time! Parameters to consider is: Administrative area Country Latitude Locality Longitude Place Name

    Code inserted if the parameters exists in then .jrnl_config file:

        <key>Location</key>      
        <dict>
            <key>Administrative Area</key>
            <string>Ostergotlands lan</string>
            <key>Country</key>            
            <string>Sverige</string>          
            <key>Latitude</key>
            <real>58.383400000000000</real>
            <key>Locality</key>
            <string>City</string>          
            <key>Longitude</key>
            <real>15.577170000000000</real>
            <key>Place Name</key>
            <string>Street</string>     
        </dict>
    

    Thanks in advance, Henrik

    day one stale :lock: 
    opened by hs6705gc 19
  • Support Jinja syntax in templates

    Support Jinja syntax in templates

    Use Case/Motivation

    We currently allow the use of a template file to seed a new entry. This file is currently a flat text file and is taken verbatim into the editor when creating a new entry.

    It would be nice to (optionally) interpret this template file using some syntax (like Jinja) to add some functionality to these templates.

    This would allow the use of Jinja syntax in these templates, which would allow things like using custom fields, or making loops in the template.

    Example Usage

    {# templates/some-other-template-to-include.jrnl #}
    
    Hello {{ name }}! This is a template of some sort.
    
    {% if my_field > 32 %}
    Lorem ipsum dolor sit amet.
    {% else %}
    Also, lorem ipsum dolor sit amet.
    {% endif %}
    
    etc
    
    

    Other Information

    It should be a problem, but the ability to discard an entry if the template text didn't change merits some extra consideration with this new feature to make sure nothing breaks.

    enhancement :new: 
    opened by wren 1
  • DayOne journal tag search fails for tags that don't use the first symbol in the config's tagsymbols

    DayOne journal tag search fails for tags that don't use the first symbol in the config's tagsymbols

    Diagnostic output

    jrnl: v3.3
    Python: 3.11.1 (tags/v3.11.1:a7a450f, Dec  6 2022, 19:58:39) [MSC v.1934 64 bit (AMD64)]
    OS: Windows 10
    

    Current Behavior

    Only the first character of the tagsymbols value in the config file is used when searching for tags in DayOne journals. Other journal types are fine.

    Expected Behavior

    Any tag starting with any tag symbol should be searchable in a DayOne jounal.

    Repro Steps

    With my DayOne test journal "dayone", I should be able to run the following:

    jrnl dayone Here is a new entry with a @tag
    

    Then, after running this, I should see that entry:

    jrnl dayone @tag
    

    Debug output

    DEBUG    root         Parsed args: Namespace(debug=True, preconfig_cmd=None, postconfig_cmd=None, filename=None, on_date=None, today_in_history=False, month=None, day=None, year=None, start_date=None, end_date=None, contains=None, strict=False, starred=False, limit=None, excluded=[], edit=False, delete=False, change_time=None, export=False, tags=False, short=False, config_override=[], config_file_path='', text=['dayone', '@tag'])
    DEBUG    root         Reading configuration from file C:\Users\micah\.config\jrnl\jrnl.yaml
    DEBUG    root         Using configuration "{'colors': {'body': 'none', 'date': 'none', 'tags': 'none', 'title': 'none'}, 'default_hour': 9, 'default_minute': 0, 'editor': 'subl -w', 'encrypt': False, 'highlight': True, 'indent_character': '|', 'journals': ********************************** 'dayone': {'journal': 'C:\\Users\\micah\\Documents\\jrnl\\testing\\dayone.dayone'}}, 'linewrap': 79, 'tagsymbols': '#@', 'template': False, 'timeformat': '%F %r', 'version': 'v3.3'}"
    DEBUG    root         Using journal name: dayone
    DEBUG    root         Updating configuration with specific journal overrides {'journal': 'C:\\Users\\micah\\Documents\\jrnl\\testing\\dayone.dayone'}
    ┌────────────────────┐
    │  no entries found  │
    └────────────────────┘
    

    Other Information

    In DayOneJournal.py, the faulty line is:

    self.config["tagsymbols"][0] + tag.lower()
    

    That [0] is grabbing the first of the tagsymbols and ignoring the rest.

    bug :pushpin: ready for pr 
    opened by micahellison 1
  • Don't save templated journal entries if the received raw text is the …

    Don't save templated journal entries if the received raw text is the …

    …same as the template itself

    Checklist

    • [x] I have read the contributing doc.
    • [x] I have included a link to the relevant issue number.
    • [x] I have checked to ensure there aren't other open pull requests for the same issue.
    • [x] I have written new tests for these changes, as needed.

    Issue number #1652

    I did not add tests for this as I wasn't sure if adding a blocking processes for testing the external editor was the correct thing to do. I also noticed there are currently no tests that test templates. Let me know if this is correct and I can add.

    One thing that's not optimised about the PR is that _get_editor_template function, which performs file I/O, is called twice:

    • Once to get the template text (original code)
    • Once again to get the template text and check if its the same as the received raw text (my added code)

    The alternative to calling it twice is changing the _write_in_editor and/or write_mode function(s) to read the template in once at the start and pass it as a variable. I can make this change if necessary but thought it was safer to just check again and allow the duplicate I/O operation.

    opened by Briscoooe 1
  • Templated entries should not be saved if the raw text is identical to the original template

    Templated entries should not be saved if the raw text is identical to the original template

    Diagnostic output

    jrnl: v3.3
    Python: 3.10.9 (v3.10.9:1dd9be6584, Dec  6 2022, 14:37:36) [Clang 13.0.0 (clang-1300.0.29.30)]
    OS: Darwin 21.6.0
    

    Current Behavior

    When you open up a new entry with a template and exit without changing any of the text, it saves the unchanged template as an entry. This is not ideal as if you accidentally open up a template journal by accident, you have to clear the entire template before saving so the entry is considered an empty string.

    Expected Behavior

    It should be considered an empty entry as because the template is unchanged, technically no new text was received

    Repro Steps

    • Configure editor for journal in jrnl.yaml
    • Add template for journal in jrnl.yaml
    • Open up a new entry for this journal in editor mode
    • Save entry without changing anything
    • See Entry added to $journal_name journal message

    Debug output

    DEBUG    root         Reading configuration from file /Users/briscoooe/.config/jrnl/jrnl.yaml
    DEBUG    root         Using configuration "{'colors': {'body': 'none', 'date': 'none', 'tags': 'none', 'title': 'none'}, 'default_hour': 9, 'default_minute': 0, 'editor': 'vim', 'encrypt': False, 'highlight': True, 'indent_character': '|', 'journals': {'default': '/Users/briscoooe/Library/Mobile Documents/com~apple~CloudDocs/Devlog', 'encrypt': True, 'private': {'encrypt': True, 'journal': '/Users/briscoooe/Library/Mobile Documents/com~apple~CloudDocs/JrnlPrivate/journal.txt', 'template': '/Users/briscoooe/Library/Mobile Documents/com~apple~CloudDocs/JrnlPrivate/template.txt'}}, 'linewrap': 79, 'tagsymbols': '#@', 'template': False, 'timeformat': '%Y-%m-%d %H:%M', 'version': 'v3.3'}"
    DEBUG    root         Using journal name: private
    DEBUG    root         Updating configuration with specific journal overrides {'encrypt': True, 'journal': '/Users/briscoooe/Library/Mobile Documents/com~apple~CloudDocs/JrnlPrivate/journal.txt', 'template': '/Users/briscoooe/Library/Mobile Documents/com~apple~CloudDocs/JrnlPrivate/template.txt'}
    DEBUG    root         opened EncryptedJournal with 16 entries
    DEBUG    root         Write mode: starting
    DEBUG    root         Write mode: opening editor
    DEBUG    root         Write mode: loading template for entry
    DEBUG    root         Write mode: template loaded: Testing template:
    
    Hello, world!
    
    DEBUG    root         Write mode: appending raw text to journal "private": Testing template:
    
    Hello, world!
    
    ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
    ┃  Entry added to private journal  ┃
    ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
    DEBUG    root         Write mode: completed journal.write()```
    
    ### Other Information
    
    _No response_
    bug 
    opened by Briscoooe 2
  • Journal Notes before December 4 18:19 CAT Gone.

    Journal Notes before December 4 18:19 CAT Gone.

    Diagnostic output

    jrnl: v3.3 Python: 3.10.8 (main, Nov 1 2022, 14:18:21) [GCC 12.2.0] OS: Linux 5.15.78-1-MANJARO

    Current Behavior

    Journal Notes before December 4 18:19 CAT Gone. I checked the journal.txt file and all the notes dating as far back as June are not here

    Expected Behavior

    That all my notes are kept intact and never go missing

    Repro Steps

    No info for this

    Debug output

    DEBUG root Parsed args: Namespace(debug=True, preconfig_cmd=None, postconfig_cmd=None, filename=None, on_date=None, today_in_history=False, month=None, day=None, year=None, start_date=None, end_date=None, contains=None, strict=False, starred=False, limit=None, excluded=[], edit=False, delete=False, change_time=None, export=False, tags=False, short=False, config_override=[], config_file_path='', text=['lorem', 'ipsum']) DEBUG root Reading configuration from file /home/xord/.config/jrnl/jrnl.yaml DEBUG root Using configuration "{'colors': {'body': 'none', 'date': 'none', 'tags': 'none', 'title': 'none'}, 'default_hour': 9, 'default_minute': 0, 'editor': '', 'encrypt': False, 'highlight': True, 'indent_character': '|', 'journals': {'default': '/home/xord/.local/share/jrnl/journal.txt'}, 'linewrap': 79, 'tagsymbols': '#@', 'template': False, 'timeformat': '%Y-%m-%d %H:%M', 'version': 'v2.8.4'}" DEBUG root Using journal name: default DEBUG root opened PlainJournal with 21 entries DEBUG root Write mode: starting DEBUG root Write mode: cli text detected: ['lorem', 'ipsum'] DEBUG root Write mode: appending raw text to journal "default": lorem ipsum DEBUG root Write mode: completed journal.write()

    Other Information

    No response

    bug needs more info 
    opened by kraithus 1
  • jrnl crashes when adding tag argument after `--change-time`

    jrnl crashes when adding tag argument after `--change-time`

    Diagnostic output

    jrnl: v3.3 Python: 3.10.8 (main, Nov 1 2022, 14:18:21) [GCC 12.2.0] OS: Linux 5.15.80-1-lts

    Current Behavior

    The following command produces an exception:

    $ jrnl -1 --edit --change-time @tag
    ┏━ Error ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
    ┃  TypeError                                                                  ┃
    ┃  '<' not supported between instances of 'datetime.datetime' and 'NoneType'  ┃
    ┃                                                                             ┃
    ┃  This is probably a bug. Please file an issue at:                           ┃
    ┃  https://github.com/jrnl-org/jrnl/issues/new/choose                         ┃
    ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
    

    Expected Behavior

    jrnl should open the most recent entry with @tag for editing, changing the time to the current time. That is to say, it should do the same as this command (which has the same arguments in a different order):

    jrnl -1 @pomodoros --edit --change-time
    

    Else, if that's complicated by looking for an optional argument to --change-time, it should produce a user-accessible error message.

    Repro Steps

    Running

    jrnl -1 --edit --change-time @tag
    

    (See "Current Behavior" above)

    Debug output

    $ jrnl -1 --edit --change-time @tag --debug
    DEBUG    root         Parsed args: Namespace(debug=True, preconfig_cmd=None, postconfig_cmd=None, filename=None, on_date=None, today_in_history=False, month=None, day=None, year=None, start_date=None, end_date=None, contains=None, strict=False, starred=False, limit=1, excluded=[], edit=True, delete=False, change_time='@tag', export=False, tags=False, short=False, config_override=[], config_file_path='', text=[])
    DEBUG    root         Reading configuration from file /home/redacted/.config/jrnl/jrnl.yaml
    DEBUG    root         Using configuration "{'colors': {'body': 'none', 'date': 'none', 'tags': 'none', 'title': 'none'}, 'default_hour': 17, 'default_minute': 5, 'editor': 'emacs -nw', 'encrypt': False, 'highlight': True, 'indent_character': '|', 'journals': {'default': '/home/redacted/journal.txt', 'more_redacted_journals': 'redacted'}, 'linewrap': 200, 'tagsymbols': '@', 'template': False, 'timeformat': '%Y-%m-%d %H:%M', 'version': 'v2.7'}"
    DEBUG    root         Using journal name: default
    DEBUG    root         opened PlainJournal with 89 entries
      File "/usr/lib/python3.10/site-packages/jrnl/cli.py", line 39, in cli
        status_code = run(args)
      File "/usr/lib/python3.10/site-packages/jrnl/jrnl.py", line 72, in run
        search_mode(**kwargs)
      File "/usr/lib/python3.10/site-packages/jrnl/jrnl.py", line 191, in search_mode
        _change_time_search_results(no_prompt=no_change_time_prompt, **kwargs)
      File "/usr/lib/python3.10/site-packages/jrnl/jrnl.py", line 431, in _change_time_search_results
        journal.sort()
      File "/usr/lib/python3.10/site-packages/jrnl/Journal.py", line 194, in sort
        self.entries = sorted(self.entries, key=lambda entry: entry.date)
    ╭────────────────────────────── Traceback (most recent call last) ──────────────────────────────╮
    │ /usr/lib/python3.10/site-packages/jrnl/cli.py:39 in cli                                       │
    │                                                                                               │
    │   38 │   │                                                                                    │
    │ ❱ 39 │   │   status_code = run(args)                                                          │
    │   40                                                                                          │
    │                                                                                               │
    │ /usr/lib/python3.10/site-packages/jrnl/jrnl.py:72 in run                                      │
    │                                                                                               │
    │    71 │   else:                                                                               │
    │ ❱  72 │   │   search_mode(**kwargs)                                                           │
    │    73                                                                                         │
    │                                                                                               │
    │ /usr/lib/python3.10/site-packages/jrnl/jrnl.py:191 in search_mode                             │
    │                                                                                               │
    │   190 │   │   │   no_change_time_prompt = len(journal.entries) == 1                           │
    │ ❱ 191 │   │   │   _change_time_search_results(no_prompt=no_change_time_prompt, **kwargs)      │
    │   192                                                                                         │
    │                                                                                               │
    │ /usr/lib/python3.10/site-packages/jrnl/jrnl.py:431 in _change_time_search_results             │
    │                                                                                               │
    │   430 │   │   journal.entries += other_entries                                                │
    │ ❱ 431 │   │   journal.sort()                                                                  │
    │   432 │   │   journal.write()                                                                 │
    │                                                                                               │
    │ /usr/lib/python3.10/site-packages/jrnl/Journal.py:194 in sort                                 │
    │                                                                                               │
    │   193 │   │   """Sorts the Journal's entries by date"""                                       │
    │ ❱ 194 │   │   self.entries = sorted(self.entries, key=lambda entry: entry.date)               │
    │   195                                                                                         │
    ╰───────────────────────────────────────────────────────────────────────────────────────────────╯
    TypeError: '<' not supported between instances of 'datetime.datetime' and 'NoneType'
    ┏━ Error ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
    ┃  TypeError                                                                  ┃
    ┃  '<' not supported between instances of 'datetime.datetime' and 'NoneType'  ┃
    ┃                                                                             ┃
    ┃  This is probably a bug. Please file an issue at:                           ┃
    ┃  https://github.com/jrnl-org/jrnl/issues/new/choose                         ┃
    ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
    

    Other Information

    No response

    bug :pushpin: ready for pr 
    opened by richardjs 1
Releases(v3.3)
This is a simple Termo application in command line style

my-termo This is a simple Termo application in command line style. This app run a Linux crontab task every day to get a new word. Type termo in your t

Gustavo Soares 1 Feb 14, 2022
A cd command that learns - easily navigate directories from the command line

NAME autojump - a faster way to navigate your filesystem DESCRIPTION autojump is a faster way to navigate your filesystem. It works by maintaining a d

William Ting 14.5k Jan 3, 2023
AML Command Transfer. A lightweight tool to transfer any command line to Azure Machine Learning Services

AML Command Transfer (ACT) ACT is a lightweight tool to transfer any command from the local machine to AML or ITP, both of which are Azure Machine Lea

Microsoft 11 Aug 10, 2022
Ros command - Unifying the ROS command line tools

Unifying the ROS command line tools One impairment to ROS 2 adoption is that all

null 37 Dec 15, 2022
Easily turn single threaded command line applications into a fast, multi-threaded application with CIDR and glob support.

Easily turn single threaded command line applications into a fast, multi-threaded application with CIDR and glob support.

Michael Skelton 1k Jan 7, 2023
Command Line (CLI) Application to automate creation of tasks in Redmine, issues on Github and the sync process of them.

Task Manager Automation Tool (TMAT) CLI Command Line (CLI) Application to automate creation of tasks in Redmine, issues on Github and the sync process

Tiamat 5 Apr 12, 2022
Phishing-Detective is a command line application for Windows 10 built to detect a phishing site from two url's

Phishing-Detective Phishing-Detective is a command line application for Windows 10 built to detect a phishing site from two url's How it works A simpl

null 2 Jun 23, 2022
Rover is a command line interface application that allows through browse through mission data, images, metadata from the NASA Official Website

?? rover Rover is a command line interface application that allows through browse through mission data, images, metadata from the NASA Official Websit

Saketha Ramanjam 4 Jan 19, 2022
A command line application, written in Python, for interacting with Spotify.

spotify-py-cli A command line application, written in Python, for interacting with Spotify. The primary purpose behind developing this app was to gain

Drew Loukusa 0 Oct 7, 2021
Shazam is a Command Line Application that checks the integrity of the file by comparing it with a given hash.

SHAZAM - Check the file's integrity Shazam is a Command Line Application that checks the integrity of the file by comparing it with a given hash. Crea

Anaxímeno Brito 1 Aug 21, 2022
A command line application to analyse reports from TBC Warcraft Logs.

README A command line application to analyse reports from TBC Warcraft Logs. The application was written and tested with Python 3.9. Features Dumps an

null 2 Dec 17, 2021
OneDriveExplorer - A command line and GUI based application for reconstructing the folder structure of OneDrive from the UserCid.dat file

OneDriveExplorer - A command line and GUI based application for reconstructing the folder structure of OneDrive from the UserCid.dat file

Brian Maloney 100 Dec 13, 2022
Python Command Line Application (CLI) using Typer, SQLModel, Async-PostgrSQL, and FastAPI

pyflycli is a command-line interface application built with Typer that allows you to view flights above your location.

Kevin Zehnder 14 Oct 1, 2022
Simple command line tool for text to image generation using OpenAI's CLIP and Siren (Implicit neural representation network)

Simple command line tool for text to image generation using OpenAI's CLIP and Siren (Implicit neural representation network)

Phil Wang 4.4k Jan 9, 2023
A simple command line dumper written in Python 3.

A simple command line dumper written in Python 3.

ImFatF1sh 1 Oct 10, 2021
Simple command-line implementation of minesweeper

minesweeper This is a Python implementation of 2-D Minesweeper! Check out the tutorial here: https://youtu.be/Fjw7Lc9zlyU You start a game by running

Kylie 49 Dec 10, 2022
A simple command line tool written in python to manage a to-do list

A simple command line tool written in python to manage a to-do list Dependencies: python Commands: todolist (-a | --add) [(-p | --priority)] [(-l | --

edwloef 0 Nov 2, 2021
A simple command-line tracert implementation in Python 3 using ICMP packets

Traceroute A simple command-line tracert implementation in Python 3 using ICMP packets Details Traceroute is a networking tool designed for tracing th

James 3 Jul 16, 2022
A simple command line tool for changing the icons of folders or files on MacOS.

Mac OS File Icon Changer Description A small and simple script to quickly change large amounts or a few files and folders icons to easily customize th

Eroxl 3 Jan 2, 2023