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)
Alacritty terminal used with Bash, Tmux, Vim, Mutt, Lynx, etc. and the many different additions added to each configuration file

Alacritty terminal used with Bash, Tmux, Vim, Mutt, Lynx, etc. and the many different additions added to each configuration file

Carter 19 Aug 24, 2022
nbcommands bring the goodness of Unix commands to Jupyter notebooks.

nbcommands nbcommands bring the goodness of Unix commands to Jupyter notebooks. Installation You can simply use pip to install nbcommands: $ pip insta

Vinayak Mehta 181 Dec 23, 2022
Python commandline tool for remembering linux/terminal commands

ehh Remember linux commands Commandline tool for remembering linux/terminal commands. It stores your favorite commands in ~/ehh.json in your homedir a

56 Nov 10, 2022
Lsp Plugin for working with Python virtual environments

py_lsp.nvim What is py_lsp? py_lsp.nvim is a neovim plugin that helps with using the lsp feature for python development. It tackles the problem about

Patrick Haller 55 Dec 27, 2022
A Reverse Shell Python Packages

A Reverse Shell Python Packages

1 Nov 03, 2021
This is a CLI utility that allows you to view RedFlagDeals.com on the command line.

RFD Description Motivation Installation Usage View Hot Deals View and Sort Hot Deals Search Advanced View Posts Shell Completion bash zsh Description

Dave G 8 Nov 29, 2022
Execute shell command lines in parallel on Slurm, S(on) of Grid Engine (SGE), PBS/Torque clusters

qbatch Execute shell command lines in parallel on Slurm, S(on) of Grid Engine (SGE), PBS/Torque clusters qbatch is a tool for executing commands in pa

Jon Pipitone 26 Dec 12, 2022
A command line tool that creates a super timeline from SentinelOne's Deep Visibility data

S1SuperTimeline A command line tool that creates a super timeline from SentinelOne's Deep Visibility data What does it do? The script accepts a S1QL q

Juan Ortega 2 Feb 08, 2022
Plumbum: Shell Combinators

Plumbum: Shell Combinators Ever wished the compactness of shell scripts be put into a real programming language? Say hello to Plumbum Shell Combinator

Tomer Filiba 2.5k Dec 28, 2022
PyWordle: A Python-made wordle manual solver

PyWordle: A Python-made wordle manual solver How to use it Start the program with python3 pywordlesolver.py. How it works The program has a simple 5-l

Federico Torrielli 5 Nov 24, 2022
Textual: a TUI (Text User Interface) framework for Python inspired by modern web development

Textual Textual is a TUI (Text User Interface) framework for Python inspired by

17.1k Jan 04, 2023
A minimal and ridiculously good looking command-line-interface toolkit.

Pyceo Pyceo is a Python package for creating beautiful, composable, and ridiculously good looking command-line-user-interfaces without having to write

Juan-Pablo Scaletti 21 Mar 25, 2022
Code for the Open Data Day 2022 publicbodies.org Nepal data scraping activities.

Open Data Day Publicbodies.org Nepal We've gathered on Saturday, 5th March 2022 with Open Knowledge Nepal in order to try and automate the collection

Augusto Herrmann 2 Mar 12, 2022
Official AIdea command line tool

AIdea CLI Official AIdea command line tool for https://aidea-web.tw. Installation Make sure you have installed both Python 3 and pip package manager.

AIdea 5 Dec 15, 2021
Objexplore is an interactive Python object explorer for the terminal.

Objexplore is an interactive Python object explorer for the terminal. Use it while debugging, or exploring a new library, or whatever! 9D1FAC73-B2A5-4

kylepollina 249 Dec 23, 2022
Gitfetch is a simple tool to get github user details

Gitfetch Just a (cli?) tool to get github user details 🙂 Installation 📂 Install Gitfetch via pypi pip install gitfetch or pip install git+https://g

I'm Not A Bot #Left_TG 7 Jan 23, 2022
uploadgram uses your Telegram account to upload files up to 2GiB, from the Terminal.

uploadgram uploadgram uses your Telegram account to upload files up to 2GiB, from the Terminal. Heavily inspired by the telegram-upload Installing: pi

Shrimadhav U K 97 Jan 06, 2023
CLI/library to control FNIRSI DC Power Supply (DC-6006L, etc)

dc6006l - CLI/library to control FNIRSI DC Power Supply (DC-6006L, etc) What is this? FNIRSI DC6006L is a programmable DC power supply that is quite c

Taisuke Yamada 7 Sep 25, 2022
tox-server is a command line tool which runs tox in a loop and calls it with commands from a remote CLI.

Tox Server tox-server is a command line tool which runs tox in a loop and calls it with commands from a remote CLI. It responds to commands via ZeroMQ

Alexander Rudy 3 Jan 10, 2022
A command line tool to query source code from your current Python env

wxc wxc (pronounced "which") allows you to inspect source code in your Python environment from the command line. It is based on the inspect module fro

Clément Robert 13 Nov 08, 2022