Merge pull request #114 from kellyjonbrazil/dev

Dev v1.15.0

.github/workflows/pythonapp.yml

@@ -18,6 +18,12 @@ jobs:
 
     steps:
     - uses: actions/checkout@v2
+    - name: "Set up timezone to America/Los_Angeles"
+      uses: szenius/[email protected]
+      with:
+        timezoneLinux: "America/Los_Angeles"
+        timezoneMacos: "America/Los_Angeles"
+        timezoneWindows: "Pacific Standard Time"
     - name: Set up Python ${{ matrix.python-version }}
       uses: actions/setup-python@v1
       with:

CHANGELOG

@@ -1,5 +1,36 @@
 jc changelog
 
+20210407 v1.15.0
+- Add acpi command parser tested on linux
+- Add upower command parser tested on linux
+- Add /usr/bin/time command parser tested on linux and macOS
+- Add dpkg -l command parser tested on linux
+- Add rpm -qai command parser tested on linux
+- Add finger command parser tested on linux and macOS
+- Add dir command parser tested on Windows 10
+- Update date parser: complete rewrite (v2.0) providing many enhancements:
+    - Make weekday numbering ISO 8601 compliant
+    - Add a calculated naive timestamp field
+    - Add a calculated UTC timestamp field (only if date output is in UTC)
+    - Add several fields, including: hour_24, utc_offset, day_of_year, week_of_year, iso, and timezone_aware
+- Update uptime parser to add uptime_days, uptime_hours, uptime_minutes, uptime_total_seconds, time_hour,
+      time_minute, and time_second fields
+- Update last parser to use new timestamp function
+- Update stat parser to add access_time_epoch, access_time_epoch_utc, modify_time_epoch, modify_time_epoch_utc,
+      change_time_epoch, change_time_epoch_utc, birth_time_epoch, birth_time_epoch_utc fields
+- Update timedatectl parser to add epoch_utc field
+- Update who parser to add epoch field
+- Update dig parser to add when_epoch and when_epoch_utc fields
+- Update ls parser to add epoch and epoch_utc fields
+- Add -h option to display the help text. Piping errors no longer show the help text.
+- Add -v option to display version information.
+- Add contributing information to project root
+- Make all external python library dependencies optional: pygments, ruamel.yaml, xmltodict
+- JSON output now supports unencoded unicode characters
+- JSON output is now more compact unless the -p (pretty) option is used
+- Developer scripts added and enhanced to automate documentation and man page creation
+- Enhanced man page
+
 20210305 v1.14.4
 - Packaging fix only for binaries and RPMs hosted on https://github.com/kellyjonbrazil/jc-packaging.
   Packages from PyPi and OS repositories are not affected. This fixes an issue that kept the YAML

CONTRIBUTING.md

@@ -0,0 +1,83 @@
+# Contributing to jc
+We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
+
+- Reporting a bug
+- Discussing the current state of the code
+- Submitting a fix
+- Proposing new features
+- Proposing a new parser
+
+## We Develop with Github
+We use github to host code, to track issues and feature requests, as well as accept pull requests.
+
+## We Use Github Flow, So All Code Changes Happen Through Pull Requests
+Pull requests are the best way to propose changes to the codebase (we use [Github Flow](https://guides.github.com/introduction/flow/index.html)). We actively welcome your pull requests:
+
+1. Open an issue to discuss the new feature, bug fix, or parser before opening a pull request. For new parsers, it is important to agree upon a schema before developing the parser.
+2. Fork the repo and create your branch from `dev`, if available, otherwise `master`.
+3. If you've added code that should be tested, add tests. All new parsers should have several sample outputs and tests.
+4. Documentation is auto-generated from docstrings, so ensure they are clear and accurate.
+5. Ensure the test suite passes.
+6. Make sure your code lints.
+7. Issue that pull request!
+
+## Parser Schema Guidelines
+- Try to keep the schema as flat as possible - typically a list of flat dictionaries
+- Keys should be lowercase, contain no special characters, and spaces should be converted to underscores
+- Keys should be static, if possible. If they have to be dynamic, then they should not contain lists or dictionaries
+
+This will make it easier to use tools like `jq` without requiring escaping of special characters, encapsulating key names in [""], keeps paths predictable, and makes iterating and searching for values easier.
+
+**Examples**
+
+Bad:
+```
+{
+  "Interface 1": [
+    192.168.1.1,
+    172.16.1.1
+  ],
+  "Wifi Interface 1": [
+    10.1.1.1
+  ]
+}
+```
+Good:
+```
+[
+  {
+    "interface": "Interface 1",
+    "ip_addresses": [
+      192.168.1.1,
+      172.16.1.1
+    ]
+  },
+  {
+    "interface": "Wifi Interface 1",
+    "ip_addresses": [
+      10.1.1.1
+    ]
+  }
+]
+```
+
+## Any contributions you make will be under the MIT Software License
+In short, when you submit code changes, your submissions are understood to be under the same [MIT License](http://choosealicense.com/licenses/mit/) that covers the project. Feel free to contact the maintainers if that's a concern.
+
+## Report bugs using Github's Issues
+We use GitHub issues to track public bugs. Report a bug by [opening a new issue](https://github.com/kellyjonbrazil/jc/issues); it's that easy!
+
+## Write bug reports with detail, background, and sample code
+**Great Bug Reports** tend to have:
+
+- A quick summary and/or background
+- Steps to reproduce
+  - Be specific!
+  - Give sample code if you can.
+- What you expected would happen
+- What actually happens
+- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
+
+## Use a Consistent Coding Style
+* 4 spaces for indentation rather than tabs
+* Use a Python linter that will enforce PEP 8 and other best practices