Episode: 2145
Title: HPR2145: Daily notes and todo list with markdown
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2145/hpr2145.mp3
Transcribed: 2025-10-18 14:53:42

---

This is HPR episode 2,145 entitled, daily notes, and to do list with Markdown, it is hosted
by Norrist and is about 25 minutes long.
The summary is how I use Markdown and get to keep up with what I do.
This episode of HPR is brought to you by an Honesthost.com.
Get 15% discount on all shared hosting with the offer code HPR15, that's HPR15.
Get your web hosting that's Honest and Fair at An Honesthost.com.
I'm going to record an episode about about a method I use, note, and keep up with what
I've done for the day, have something to look back on, and also to kind of keep a simple
to-do list, it's not like a to-do manager, a list of it, and I want to put somewhere,
then I'll forget.
Fundamental to the way I take notes and the way I keep my lists is that I use Markdown
to do it, and I know Markdown has been discussed on the show before, specifically when it comes
to like, I remember discussions about Markdown and use Markdown, I'm not going to do a whole
show.
What Markdown is, but I'll talk a little bit about, I will talk a little bit about
syntax, Markdown syntax that I use, and I will say this, Markdown is what I like about
Markdown is that it's syntax is simple and it doesn't get in your way, you can write
something without being distracted by, so just as a quick aside, one of my previous jobs
is I had to write some documentation, I had to write a lot of docs, and I did it in Microsoft's
Word, and it would get so caught up in like, what bullets and font sizes, how many tabs
I would get so frustrated with myself, because I know I'm like, why can't I just sit down
and write stuff?
So, I didn't know about Markdown at the time, it may not have even at the time, but I knew
I wanted Markdown, I just didn't know what it was, now that I have it, I use it just about
anywhere I can, especially when it comes to documentation, like it was just made for
writing documents.
But also, you know, like this whole episode is about, I use it note-taking, it's sort
of another, it's not quite a central part of this, is that I use Git along, in this process
I use to store my documents that way, I can store my lists and my notes that way I have
a record, you know, I can look back on, but also if you use something like GitHub or Git
Lab or whatever your web base Git repository of choice is, it probably, as far as I know,
most of them render Markdown into some nice looking HTML, so what I'll do is, if I need
to look back on my notes or read something or read my to-do list, I don't normally open
up these text documents that I'm going to talk about in a few minutes, normally I look
at the Git repository web page, it's easy to read, another big advantage of Markdown is
that it's legible and pretty easy to look at inside GitHub, so a few reasons I really
like Markdown, if I haven't already talked enough about it, I know I've already said
it's distractionless, the syntax simple and easy to remember, with some Markdowns you have
to, like if you're making a header, you have to make the header syntax before and after the
line and you have to match them up, you know, if you make like a, whatever it is, you know, say for
like a wiki Markdown, you have to make, you know, some weird syntax thing at the beginning
and at the end of the line to make a proper header, but with Markdown, you just make, you put
a single hashmark at the beginning, that's H1, and when I say hashmark, I mean like the Tiktok
sign or the Octo Thorpe or whatever, whatever you won't call it, I'm going to call it a hashmark.
And if you want to make H3, you know, you do three hashmarks, my point is it's simple syntax,
you don't have to think much about it, I don't catch myself having to go back to the documentation,
I have to remember how to do it, it's easy to get the hang of. Another good thing about Markdown
is that it's human readable even in its unrendered form, so the Markdown syntax is kind of out of the
way, so even if you're looking at the playing Markdown unrendered, it's still easy to read and
nice to look at, you know, I said, I'll look at when I'm going to review something, I'll look at
the rendered page on GitHub, but that's just because, I mean a lot of that is just because it's in
my browser, it's open, I've got a bookmark for it, it's not too difficult to go back and grab
the individual file. You can embed in line HTML if you want to, so if you've got some images,
something else that you want to put inside the Markdown, you can just put an image tag or a code tag,
whatever HTML tags you want, normally when you view Markdown document after it's been converted to
any HTML you put in the Markdown will be outputted HTML, and speaking of that, the last advantage I
have down using Markdown is that it's really easy to convert from Markdown to another format. I
know Markdown was sort of created to have an easy way to write HTML, and most of the Markdown tools
available are just taking your Markdown and converting it to HTML, especially if you use
something like PanDoc, which I feel like has been mentioned on the show before, but if you haven't
looked at PanDoc and you do anything with documents at all, you need to stop what you're doing right
now, go look at PanDoc, it is some amazing software, but if you use something like PanDoc with Markdown,
you can convert Markdown into anything you can think of. I'm not even going to begin to list,
look at PanDoc, it's so enough about the wise, let's talk a little bit about the how.
So the first thing I do is I have a document just called todo.md or todo.mark.
At the top of it, I've got a single hashmark and the word to do, so I know I've got a big header
at the top of the page that says this is your to-do list, and then I divide it up into things I can do now
and things later that are maybe a week away, and then I've got sort of at the bottom, I've got
something long-term or projects that are the things that I probably can't do anything about
today, but just sort of a list of things that I don't want to lose track of, and the things I can do
now, the things I can do in a little bit in the long-term project, each one of those sections has
a H3 or three little hashmarks. At the beginning of the section, and then for each item underneath it,
I use the bullets, which in markdown is an asterisk or star-sunt, whatever you want to call it,
and that, you know, for each item, I just have a asterisk, what I need to do, and then, you know,
I can add to it or take away from it, or if there's something, if there's something that I've done,
but I want to maybe still remember it for a day or two. Markdown has a pretty simple syntax for
strikeout, so instead of just deleting the line, I'll mark it with the strikeout symbols, which is
a couple of tildes, and that'll mark the line at a strike-through, or I'll just, you know, if I just
mark something down, so I'll remember it, and then I did it, and I don't care about anymore, I'll just,
so that's the to-do page, that's pretty simple, I know there wasn't anything revolutionary there,
anybody who's ever made it to-do list has probably done something very similar, even in markdown.
Okay, so sort of the key to this process, and the only reason that I can remember to use this with
any regularity, is I have a launcher that sits on my desktop, and then when I click it,
it automatically opens my editor with today's page for notes, so I have a different page
for a different page of notes for every day, so when I click on this launcher, if today's page
of notes doesn't exist, it will create it for me, and I'll also fill it out a little bit,
so just sort of as a skeleton blank daily note document, I have a divided up into three sections,
well first I have the date at the top with a single hash mark, so it's in a, when it's rendered,
it's H1 tag with today's date, and then I have three separate sections, each section has hash marks
in front of it, so the sections are projects, and this is like any sort of long-term project I'm
working on, but I did something with that project today, I'll record it somewhere under the project
et cetera, I have one for tickets, so we have like at work, we have a ticket tracking system,
and I don't do a lot of stuff with our ticket system, but I do two or three things a day,
and so whenever I do something in there, I just like to keep up with it,
mostly because someone's going to come back later and ask me about it, and I want to have
if I want to have something to jog my memory about what I did, and I feel like too, I can keep a
little, I can keep more personal notes in that my daily task tracker, then I can in the
ticketing system, so in the ticketing system when I do something, I'll put a note in there, but
because a lot of times those tickets get seen by customers, managers, I don't always,
I can't always put all the details that I might need to come back to it, so section one project,
section two tickets, and the last section is for walk-ups, so a big part of what I do,
unplanned and unscheduled, and if it weren't for this it would be untracked, so this is just someone
sent me an email or walking up to my desk or sent me an IAM saying, asking me a question about
something, how does this work, or where did this go, or why is this broken, or can you do this from
me, can you fix this from me, can you complete this task, and if it's, if it's something big, I'll say
I want to go back, make a ticket, and I'll answer to the ticketing system, but a lot of times it's
something small, so I'll just go and do it for them, but again I want a record of it just for a
lot of the same reason, I'll mark it down on walk-ups, and I'll keep the tasks similar to I did
to do page, so under eat section, I'll just make a bullet with the asterisk, what I did, and then
sometimes I don't do this every day, but sometimes if there's something that doesn't fit well,
in those three I'll add a fourth section at the bottom, or if it's something that I want to take
sort of more extensive notes on, and not necessarily clutter up one of the other sections in there,
I'll do that, just as an example, we have a development environment that I wanted to make,
some changes to, and you know, change, you know, three or four different IP addresses,
I wanted a place that I could sort of write the old ones and the new ones down, and have a place
I could always go back and look, and that didn't really fit anywhere in the other three sections,
so I just kind of made a chart down at the bottom, you know, whatever day I did this, I made a chart
like down at the bottom of, you know, the old addresses, you get the idea. Okay, so I've mentioned
the launcher, and I'm going to talk a little bit through how the launcher works, but I'll also
have some show notes, written in, mark down, that I'll upload with the show, so you can kind of see,
I know, it doesn't really always, it's not always helpful to hear someone read out a script,
so I'm not going to do that, I'll kind of talk through it, and some of the different parts of it,
but I'll put the whole thing in this, go back and look at those. Now one little caveat before I get
started, working on the script is that if you primarily work on Linux, this script may look a
little weirdy, and that's because I use a Mac at work, it's just, it's what we use, it's what we're
given, it makes a lot of things easier, there's stuff like email, and some other apps that we
need that won't work on Linux, but still, if you're not familiar with Macs, it comes with
a free BSD runtime, so you can open a terminal, and most of the stuff you're used to be in their
own Linux, on a Mac, some of the commands are a little different, which is why I'm bringing this up,
but there's nothing in here that you couldn't do on a Linux system, and there's so many different
desktop, environment, terminals, and editor, there's no way for me to make a script that would work,
for everybody, but if this is something you're interested in using, it wouldn't be too hard to
modify, the launcher where you put it, how you launch it, the specific commands in it, so anyway,
if you have a Mac, this will probably work, you'll have to change a few paths, a few paths,
fit your user instead of mine, but so the first thing that the script does is sets up some variables,
the first one names the daily file, so I said I've got a different file, a task for every day,
so the first one says okay, today's file should be named this, the second thing is it sets
paths, so where all these files are stored, the to-do file and all of these daily files are stored
in place, so there's a variable called daily path that says where that is, I have a lock file variable,
so when I first started doing this, I would catch myself launching the script multiple times,
and that kind of messed up, one of the steps in it, I'll tell you about in a second,
as the last step is it spell checks everything, so if I launched it one time and I launched it a second
time, it would just kind of mess up the spell check step, and sometimes I would end up if I close
them out of order, I would lose some work, so what I did was I made a lock file, so if I,
if the script is launched, it writes a lock file, if I try to launch it again, it'll say hey,
there's a lock file, we'll get to that part in a second, but there's of the four variables that
are in the beginning of the script, the third one is what the lock file should be, and the fourth one
is the to-do file, so the first document I talked about to-do.md, so the first part of the script
is pretty is for the lock file, and this is pretty basic 90% sure if you just search for
bash lock file, you'd come across the same code that is, so I just, I found it somewhere
in out mirrorware, I copied it, it works, but it says there's a, if the lock file exists,
then echo, the lock file is present, do you want to continue, press yes or no, press yes, it
continues, if you press no it exits, that's pretty, and then if the lock file doesn't exist,
when you start the script, if the lock file doesn't exist, it will create a lock, and I know a lock
file isn't the 100% best way to ensure a script doesn't run multiple times, and a lot of use cases,
I wouldn't recommend a lock file, there's better ways to do it, but in this particular case,
since it's just me doing it, and I'm probably not, probably not going to miss this up, so lock file is
okay, so after we checked for the presence of the lock file, we checked for the presence of the
daily, so if the file, if the file for today's task doesn't exist, if it does exist, it just moves on,
if it doesn't exist, it will create sort of a skeleton for me, and I've already talked, sort of talk
through what that is, you know, it's the date, and then a header for each thing I want to work on
that day, and it builds it just by, you know, echoing something with a double redirects on to the
daily file variable, so just a series of echo statements that builds out the skeleton of what I'd
like to do for the day, okay, so once, so far in the script, we check for a lock file, and we check
for the daily task file, and if it doesn't exist, the next step is we open the daily task file on our
editor, on the Mac, I use a program called Text Wrangler, you can probably do this when you text
editor, one thing that if you use a different editor, with Text Wrangler, the command is user local
bin edit, and then I give it the dash w flag, and what that does is that makes, a lot of times when
you open a program from, when you open a GUI program from the command line, it'll just open the program,
and then return you back to the shell, and that's what edit does by default, but I don't want that,
I won't, any, when this script opens the editor, I want the script to stop until the editor closes,
because there's some things that are going to happen after I close the editor, I don't want them to
happen until I close, so if you use a different editor, that's just some, you need to figure out that
step, and it may happen by default, not every GUI program does, you know, does, does that where it,
you know, when you launch, most GUI programs, when you launch it, it'll hold the shell open,
and won't continue with the script until you close whatever, and that's the behavior you.
So I'll click on the launcher, it'll run through this script, it'll launch the editor, I'll do whatever,
you know, I'll type, sometimes I'll leave it open for a while, sometimes I'll open it, type one
thing in it, and close it, but either way, whenever I'm done with it, I'll press the X, it closes,
and then it continues in the script, so after the line in the script to open the editor,
it's spell checks to document with a spell, that's ASP, and if you don't, this is another,
just like PandaC, I'm gonna say, I'm not gonna do an episode on PandaC, I'm not gonna do an
episode on ASP, but if you do not know what ASP is, you start what you're doing right now,
and go check it out, it is by far the best spell check, and I'm a terrible
Speller, if it wasn't for a spell check, I would look like I hadn't been to school, I cannot
spell at all, and with a lot of programs, like I can misspell something so badly, that the spell
checker doesn't know how to fix it, it is very rare that I spell something so badly that ASP
doesn't know how to fix it, like if I misspell a word and it doesn't recognize, it'll give me like
10 different things, did you mean this, you know, and 99% of the time what I actually meant
is in the list, and with ASP you can add, you know, it can learn words, if you have, like I have a lot
of sort of jargon, only I would use or only use in my company or sort of industry, that I don't
want to, I don't want it to trip on, and so you can add that, and ASP is probably just as key
to this whole process, anything else I've talked about, so when I close the document, ASP
checks the daily file, it also checks the to-do file, now I don't have the script automatically
open the to-do file, every time I launch it, but I say probably 10 or 15% of the times when I do
launch this script, I go ahead and open up the to-do file anyway, either, you know, maybe in another
editor or in the same editor in the same window or something, but it's frequent enough that I have
the to-do file open, then I'll spell check it in this process, so once I've done the spell check,
we'll remove the lock file, and then I'll remove the readme, and I haven't talked about the readme yet,
so this is probably going to be, so I'll stop right here and kind of say what the read, if you've
ever looked at a project on GitHub or in GitLab or whatever, usually when you open up the project page,
you'll see a list of files, and then underneath it there'll be some word describing what that
file is, so what most of the web-based Git repositories do is if you have a file in that repository,
in the root of it, that's called readme, and readme.md, or there's some other formats that it can do,
whenever you open that up, it'll automatically display the readme as HTML, even though it's marked down,
so what I do, and I'll walk through the steps in a second, is every time I close this script,
I rebuild the readme file by echoing the to-do list, the to-do.markdown at the top, and then all the
daily files, so if you look at the readme file, the first thing you'll see is the to-do.markdown,
and then in order, start today going back in time until the beginning, you'll see all of my
daily notes, so I've got separate to-do document, I've got separate documents for every day,
but all of those are combined in a way that works good for me into a single readme document,
so most of the time when I want to go back, and look, I have this readme document bookmark,
it's one of the, you know, few bookmarks I actually have in my browser, I'll just click on that,
it opens the readme page, it's all right there, so after that diversion, we'll come back to the script,
so we do the editing, we do the spell checking, we remove the lock file, and then the first part
of building that big readme is I need to delete the older readme, so I arm the readme,
then I cat the to-do file to the readme, and then I have a for loop where it lists all the
markdown file, and then it cats them to the read, and then there's an echo at the end of that,
they just put them blank line, so this one kind of weird thing about markdown is that
sometimes I find myself having to add some extra empty lines to make it render correctly,
and this is one that you'll see, if you ever see just an echo going directly, if you ever see
just a command that's just echo redirecting to a file, that's what it's doing in this script,
it's just making it, so the last part of this script is that the get check-in process, so I use
get, but if you have another, if you want to use a carry-all or CVS or whatever, or nothing,
but I like using get for a handful of reasons that I've talked about before, but there's just the
last line in the script is CD into the folder where all the stuff is, doing a get add, which adds
any new files, so every day I create a new file you're going to add, get add command and get commit,
get commit command, and usually with a get, when you do a commit, you want to have something
useful in the commit message, but when you automate get commits like this, you get a little harder
to do, so both of the time when I automate a get commit, I just have the commit message be the time
stamp, and I do that in this case with a date commit, so get commit and then a get push origin master,
you know, pushes everything I just did, including the brand new markdown file up to get server,
so I'm going to summarize all this one more time, because I know I'm like a lot,
but, you know, again, too, I'll have some, so just to summarize the script, first thing it does is
set up a few variable names, the next part, it checks for a log file, if it exists, delete it,
move on, or if it doesn't exist, it just keeps on going, and create a log file, the next part of
the script looks for the daily file, if it is there, it moves on, if it's not there, it sort of builds
out a skeleton daily file for me, then it opens the daily file, and then when I'm done with that,
I close the editor, spell checks, the daily file, and the to do file, then it removes the lock file,
and then we rebuild the readme, the first step of rebuilding the readme old readme,
you can't the to do file to the read, all the daily files to check it in to get, it's as simple as that,
that's all I got for today, you guys have a good
you've been listening to Hacker Public Radio at Hacker Public Radio dot org,
we are a community podcast network that releases shows every weekday, Monday through Friday,
today's show, like all our shows, was contributed by an HBR listener like yourself,
if you ever thought of recording a podcast, then click on our contributing,
to find out how easy it really is, Hacker Public Radio was founded by the digital dog pound
and the infonomicon computer club, and it's part of the binary revolution at bnref.com,
if you have comments on today's show, please email the host directly, leave a comment on the website
or record a follow-up episode yourself, unless otherwise status, today's show is released on
creative comments, attribution, share a life, 3.0 license.
