Updated references to chug.sh and do_process.sh

README.md

@@ -34,7 +34,7 @@ The timestamp is in most-to-least significant units, though any valid date and t
 Certain strings have special meaning to timetracker.py.  The category name in square brackets specifies that the task is related to a specific customer, or should be tracked on a certain item in Clarizen, to make transferring to Clarizen more straightforward.  These can be any string, even with spaces, but beware of using shell special characters.  The names can be anything, so things like `[BB&T]`, `[Citi]`, `[Wells Fargo]`, or `[CS Support]` are perfectly valid.  For the author's most common categories, macros are set up with text string triggers in Keyboard Maestro (more on that below).
 
 ## timetracker.py usage
-The timetracker.py script is the basis, it tallies the time for each task and then outputs a report on how much each task takes to complete.  It takes as its argument one or more text files, the log files in the format above.  It should only report one line item per task, regardless of how many times it appears in the log.  Each task should have a category/tag in square brackets, the behavior of `do_process` (see below) is now undefined if the tag is left out.
+The timetracker.py script is the basis, it tallies the time for each task and then outputs a report on how much each task takes to complete.  It takes as its argument one or more text files, the log files in the format above.  It should only report one line item per task, regardless of how many times it appears in the log.  Each task should have a category/tag in square brackets, the behavior of `do_process.sh` (see below) is now undefined if the tag is left out.
 
 Note that each task now gets rounded **up** to the nearest quarter hour (15minutes), unless the task takes less than 0.08 hours (288 seconds).  Every documented task will take at least 0.08hours/288seconds.  If the task takes 289seconds, it is automatically rounded up to the nearest 15minute increment.  If a task takes 30 minutes plus one second to perform, it's rounded up to 0.75hours.  Management is OK with this rounding scheme, we may revisit it later if it becomes problematic.  
 
@@ -55,9 +55,9 @@ The output looks like this:
 
 Section total:          8.41hrs
 ```
-You may have noticed, the output of timetracker.py is in alphabetical order by category, then by task.  This follows for `./do_process` and `./chug` below.  
+You may have noticed, the output of timetracker.py is in alphabetical order by category, then by task.  This follows for `./do_process.sh` and `./chug.sh` below.  
 
-## `do_process`
+## `do_process.sh`
 This script filters the output of timetracker.py, giving each category (in square brackets) its own section, with its own tallies.  The header is the list of categories and the log file basename (below this is `example`, but would normally be a date such as `2017-12-08`).  After the header, each line of output and sections are designed to be directly transferred to Clarizen manually, and the tally used to verify the daily and weekly totals in Clarizen.  It calculates the time total for each organization/category.  At the end it prints a grand total for the day, which should be used to cross-verify in Clarizen.
 
 ```
@@ -104,19 +104,19 @@ Section total:          0.83hrs
 Grand total:          8.41hrs
 ```
 
-It takes as its argument a filename with the current date (`date +%F` format, such as `./do_process 2020-03-12`), or it assumes the current date log file.  The `.log` filename suffix is assumed (and should not be passed to `./do_process`).  Also, arbitrary filenames can be passed, so `example.log` becomes `./do_process example`.
+It takes as its argument a filename with the current date log (`date +%F` format, such as `./do_process.sh 2020-03-12.log`), or it assumes the current date log file.  Also, arbitrary filenames can be passed, so `example.log` becomes `./do_process.sh example.log`.
 
-Projects in Clarizen are listed alphabetically, so to transfer data from the `./do_process` output you simply copy the data lines from the ouput put, and paste it into the notes section of the Clarizen entry.  Enter the duration of the task at the top of the Clarizen entry, and select the category and subcategory of the entry.
+Projects in Clarizen are listed alphabetically, so to transfer data from the `./do_process.sh` output you simply copy the data lines from the ouput put, and paste it into the notes section of the Clarizen entry.  Enter the duration of the task at the top of the Clarizen entry, and select the category and subcategory of the entry.
 
-## `chug`
-This script is designed to be run on Mondays, after the previous week of log files have been generated and closed out. The standard Monday usage takes no arguments, it expects all log files to be processed to be in the current directory.  It runs `do_process` once for each day of the previous week, cleanly skipping any log files which do not exist.  It pauses after each day report is output, allowing the user to transfer the times manually to Clarizen.  
+## `chug.sh`
+This script is designed to be run on Mondays, after the previous week of log files have been generated and closed out. The standard Monday usage takes no arguments, it expects all log files to be processed to be in the current directory.  It runs `do_process.sh` once for each day of the previous week, cleanly skipping any log files which do not exist.  It pauses after each day report is output, allowing the user to transfer the times manually to Clarizen.  
 
-`./chug` takes a single optional argument, a week offset (in case `./chug` is executed for log files further back than last week).  This uses the GNU date functionality of calculating "last Monday."  On Monday this will be "today - 7 days", but on the following Tuesday this will evaluate to "yesterday".  If Monday is a holiday and you're entering your timesheets on Tuesday you can enter `./chug 1` and it should do the right thing.  If it's the first Monday of the month and you need to process the previous four weeks of logs, use `./chug 4`.  The output of `./do_process` prints the date that is being processed at the top, if your incantation of `./chug` is wrong, you can quit and adjust accordingly.  `./chug` with no arguments is equivalent to `./chug 0`.
+`./chug.sh` takes a single optional argument, a week offset (in case `./chug.sh` is executed for log files further back than last week).  This uses the GNU date functionality of calculating "last Monday."  On Monday this will be "today - 7 days", but on the following Tuesday this will evaluate to "yesterday".  If Monday is a holiday and you're entering your timesheets on Tuesday you can enter `./chug.sh 1` and it should do the right thing.  If it's the first Monday of the month and you need to process the previous four weeks of logs, use `./chug.sh 4`.  The output of `./do_process.sh` prints the date that is being processed at the top, if your incantation of `./chug.sh` is wrong, you can quit and adjust accordingly.  `./chug.sh` with no arguments is equivalent to `./chug.sh 0`.
 
-The output is the output of `./do_process` piped to `less` for each day, pausing so the user can go through that day's output and transfer the items to Clarizen.  If no time was logged for a given day (the file does not exist), `./chug` prints the missing date, but otherwise silently skips it.  All seven days of the week are processed, Monday through Sunday.
+The output is the output of `./do_process.sh` piped to `less` for each day, pausing so the user can go through that day's output and transfer the items to Clarizen.  If no time was logged for a given day (the file does not exist), `./chug.sh` prints the missing date, but otherwise silently skips it.  All seven days of the week are processed, Monday through Sunday.
 
 ## month-pack.sh
-timetracker.py and the related `do_process` and `chug` scripts are designed to have each day with its own YYYY-MM-DD.log file in the current, timetracker directory.  Over time, the log files in this directory can become quite numerous and unwieldy.  To help combat this, `month-pack.sh` takes all the log files from the previous month, adds them to a compressed tarball, and deletes them from the directory.  It is designed to be run once all of the log files for the previous month have been processed into Clarizen.
+timetracker.py and the related `do_process.sh` and `chug.sh` scripts are designed to have each day with its own YYYY-MM-DD.log file in the current, timetracker directory.  Over time, the log files in this directory can become quite numerous and unwieldy.  To help combat this, `month-pack.sh` takes all the log files from the previous month, adds them to a compressed tarball, and deletes them from the directory.  It is designed to be run once all of the log files for the previous month have been processed into Clarizen.
 
 ## year-pack.sh
 In the same vein as month-pack.sh, year-pack.sh tars up all the monthly tarballs (named YYYY-MM.tar.xz), and puts them into a single YYYY.tar file.  It is designed to be run in January when all of the previous December log files have been processed.  All of the YYYY-MM.tar.xz files will be deleted once the YYYY.tar file is created.

chug.sh

@@ -17,8 +17,8 @@ for date in $(date +%F -d "${DATE}") \
     echo $date
 
     if [[ -f ${date}.log ]]; then
-        [[ -n $IGNORE_DO_PROCESS ]] || ./do_process $date | less
-        daily_total=$(./do_process $date | grep -P "Grand total:" | grep -Po "\d+\.\d+")
+        [[ -n $IGNORE_DO_PROCESS ]] || ./do_process.sh $date | less
+        daily_total=$(./do_process.sh $date | grep -P "Grand total:" | grep -Po "\d+\.\d+")
     else
         daily_total=0
     fi

do_process.sh

@@ -7,12 +7,12 @@ declare -A ORGS
 
 #set -x
 if [[ "x${1}" == "x" ]]; then
-    DATE=$(date +%F)
+    DATE=$(date +%F).log
 else
     DATE=$1
 fi
 
-if [[ -f ${DATE}.log ]]; then
+if [[ -f ${DATE} ]]; then
     find_existing_org () {
         for org in ${ORGS[@]}; do
             [[ "${org}" == "${1}" ]] && return 0