summaryrefslogtreecommitdiff
path: root/posts/remember-recall-what-couldve-been-a-command-line-tool.html
diff options
context:
space:
mode:
authorSteph Enders <steph@senders.io>2024-03-07 15:17:29 -0500
committerSteph Enders <steph@senders.io>2024-03-07 15:17:29 -0500
commit1f689fd039533801842ae241671f2437ddbe0044 (patch)
tree50d3db88f2c7e676d6679696a101e6ae2b25448f /posts/remember-recall-what-couldve-been-a-command-line-tool.html
parent80f5dacf988b1cddd04eea6c4a6f70b165376764 (diff)
Copy old files and update build.sh to generate it all!
This is a huge messy commit but :) sue me. I'm not at work I can do git badly for once!
Diffstat (limited to 'posts/remember-recall-what-couldve-been-a-command-line-tool.html')
-rw-r--r--posts/remember-recall-what-couldve-been-a-command-line-tool.html50
1 files changed, 50 insertions, 0 deletions
diff --git a/posts/remember-recall-what-couldve-been-a-command-line-tool.html b/posts/remember-recall-what-couldve-been-a-command-line-tool.html
new file mode 100644
index 0000000..b9ede49
--- /dev/null
+++ b/posts/remember-recall-what-couldve-been-a-command-line-tool.html
@@ -0,0 +1,50 @@
+
+--post-date: 2020-02-16
+--type: blog
+ <article>
+ <h1>remember/recall - what could've been a command line tool</h1>
+ <p>During a meeting at work when I realized I often forget useful
+ commands. So I had the bright idea to create a command line tool that
+ would basically append a file with the command you wanted to remember
+ that you could search over later if you wanted to recall a certain
+ command. I figured I could it could just be a simple bash script that
+ recalls your bash-history and appends it to a file, all things that are
+ incredibly easy to do... or so I thought.</p>
+ <h2>Look before you leap</h2>
+ <p>This article is a reminder to myself to test the core functionality
+ first, before decorating your program/script with all those bells and
+ whistles. While I did learn a lot in the process it is always a good to
+ check the basics first.</p>
+ <h2>What went right</h2>
+ <p>I actually ended up learning a lot during the development of the
+ (never finished) tool. I had never used <code>getopts</code> inside a
+ script before, which turned out to be extremely intuitive. That was all
+ that went right...</p>
+ <h2>What went wrong</h2>
+ <p>Literally, everything else that could&#39;ve went wrong did. The
+ &quot;project&quot; was a single bash script roughly 160 lines long
+ before I found out it wouldn&#39;t work. It was a series of flags that
+ enabled actions that called functions, some of which ended the script
+ either successfully or not. It wasn&#39;t necessarily a mess to read (I
+ tried to make it that every function ended up in an exit so I knew if I
+ entered I would need to assume it terminated) but it was hard to follow
+ when writing. I tried to allow it so you could default an action to make
+ the CLI intuitive which lead to a messy set of if/elses and switch
+ cases.</p>
+ <h3>You can&#39;t access un-committed bash history</h3>
+ <p>History command in a bash shell commits the history at the end of the
+ session. This makes sense once you know this, there are a lot of reasons
+ saving the commands to file after every execution is probably not the
+ best idea. However, it can be enabled with a flag when you enable a shell
+ session. But I didn&#39;t want to build a tool that required me to
+ remember I had to add something to my bash_profile before it would work.
+ I wanted something I could just copy onto a new machine and have access
+ to its functionality.</p>
+ <h2>Lesson learned</h2>
+ <p>While developing a tool to help me remember things, I learned
+ something I cannot forget: Test the core, simplest functionality first.
+ Before you do anything validate what you&#39;re trying to do will work.
+ Because after building all of these fancy bells and whistles, if it
+ can&#39;t do the basics, there is no point.</p>
+ </article>
+