X-Git-Url: https://zdv2.bktei.com/gitweb/EVA-2020-02.git/blobdiff_plain/ceb6d15e2f20de620fcbd6c2ddbca5eaeb914296..9d51b1df34711cc609040c0a849bc983155d9b22:/exec/bklog-plan.org?ds=inline

diff --git a/exec/bklog-plan.org b/exec/bklog-plan.org
index 597f653..3b7f5f5 100644
--- a/exec/bklog-plan.org
+++ b/exec/bklog-plan.org
@@ -1,5 +1,6 @@
 * bklog task list
-** TODO Adjust filename duration dynamically
+** DONE Adjust filename duration dynamically
+   CLOSED: [2020-07-14 Tue 22:17]
 2020-07-12T21:17Z; bktei> Currently, the "duration" component of the
 output filename for a given chunk is calculated from the ~bufferTTL~
 variable which does not necessarily reflect the amount of buffer lines
@@ -53,7 +54,11 @@ in seconds between ~bufferTimestampOld~ and ~bufferTimestampNew~ may
 be calculated and an appropriate duration string generated from the
 ~timeDuration()~ function.
 
-** TODO Update ~SECONDS~ variable during while read loop
+2020-07-14T22:17:16Z; bktei> Initial adjustment of SECONDS
+implemented. Ongoing monitoring of end time of each buffer round
+~while read~ loop checked.
+** DONE Update ~SECONDS~ variable during while read loop
+   CLOSED: [2020-07-14 Tue 16:22]
 2020-07-14T00:58Z; bktei> The starting timestamps of each output file
 still drifts against system time. Although the ~while read~ loop does
 not lose data, the drift causes the output files to be named weirdly.
@@ -67,11 +72,34 @@ number of lines being read in each buffer round should be tracked and
 a modulus comparison may be implemented within the ~while read~ loop
 so that a correction is made after some fraction of the expected lines
 to be read are read.
+
+2020-07-14T16:21Z; bktei> I ran a test to see if SECONDS drifts and it
+does not. The lag is caused by other synchronous commands. The
+solution will be to adjust the variables against which SECONDS is
+compared.
 ** TODO Account for "early-exit" bug in input script
-2020-07-14T03:00Z; bktei> What happens if the script piping its stdout
-into ~bklog~ immediately exits without providing any stdout (ex: a
-python script with a missing module)? ~bklog~ should be able to detect
-the latest exit code and exit early. It should also be able to detect
-if the incoming pipe is closed.
+*** 2020-07-14T03:00Z; bktei>
+What happens if the script piping its stdout into ~bklog~ immediately
+exits without providing any stdout (ex: a python script with a missing
+module)? ~bklog~ should be able to detect the latest exit code and
+exit early. It should also be able to detect if the incoming pipe is
+closed.
+
+*** 2020-07-14T22:25Z; bktei> 
+Possible solution using ~dd~, ~od~, and ~if [ -z string ]~ [[https://unix.stackexchange.com/a/33055][here]].
+** TODO Support configuration file for storing options
+*** 2020-07-15T23:48Z;bktei>
+Support storing options in a ~$HOME/.config/bklog/options.conf~ file
+so individual calls to ~bklog~ don't have to be so long. Aliases can
+be used instead to make ~bklog~ calls shorter, but cron jobs don't
+necessarily source alias files. Explicitly reading options from a
+configuration file would be more reliable, although it complicates
+usage of ~bklog~.
+*** 2020-07-20T01:45Z; bktei>
+It should be possible to specify options via a configuration file
+stored within a ~~/.config/~ directory instead of specifying options
+each time ~bklog~ is called. This feature would simplify use of
+~bklog~ in situations where specifying options is tiresome and only
+quick / one-off use of ~bklog~ is needed.
 * bklog narrative