Skip to content

Instantly share code, notes, and snippets.

@ruario
Last active March 24, 2024 22:20
Show Gist options
  • Save ruario/9ff920e1e5a89036463d418e1c7bb470 to your computer and use it in GitHub Desktop.
Save ruario/9ff920e1e5a89036463d418e1c7bb470 to your computer and use it in GitHub Desktop.
This script creates a directory named with the current date, followed by the current Swatch .beat (down to "decibeat" level, which gives ≈ 9 seconds of time resolution)

This is a short shell script to make date named directories.

#!/bin/sh
a=`TZ=UTC-1 date +%y%m%d-%T`;b=${a#*-};c=${b#*:}
mkdir -v ${a%-*}`printf %04d $(echo "((${b%%:*}*60+${c%:*})*60+${c#*:})/8.64"|bc)`|grep -Eo \[0-9]+

Usage

Just run the script and it will create the directory and print back the name. If you run it in very quick succession (within a 9 second window) you may get an error back stating that the directory already exists. For human activity (rather than automation) this is typically good enough and keeps the name shorter. If you need an additional directory, just wait a few seconds and try again. 🤷🏼

ℹ️ If you want to create and switch to a directory in one go, issue cd `mdd` (where "mdd" is the script name).

What is the point?

I often make directories during the day named things like, "temp", "test" or "deleteme". This can get annoying when I forget to cleanup and then find myself reissuing mkdir and trying to make "temp2", "test13", etc. … or I end up just smashing the keyboard to create directories named like "jhjkdsh". 😆 [And, yes I know about about mktemp]

This script should work better for my use case as it will create a date named directory and print the name back to me. Later when looking on disk it also gives me some quick context of when I made this directory, without having to look at extended meta data (i.e. I can see when I made a directory via a simple ls rather than having to issue ls -l [which could be different anyway as that reports modification time, not creation time]). It also helps should I want to do any mass cleanup, due to predictable naming.

But why .beats rather than traditional time?

I am using Swatch .beats [actually I am using "decibeats", i.e. .beats to one decimal place or a tenth of a full .beat] rather than traditional hour, minute and seconds because it is super nerdy 🤓 and keeps the filename short.

ℹ️ If .beats are too wierd for you, just remove the TZ=UTC-1 part from the script and you can read the last four digits as the percentage of day complete (to two decimal places), in your local timezone. This is slightly easier for most people to relate to, for example:

  • 0% [midnight] → 25% [06:00] is early morning
  • 25% → 48% [11:31] is late morning
  • ≅ 50% lunch time
  • 52% [12:28 (PM)] → 75% [18:00 (6PM)] is afternoon
  • Over 75% is into the evening and night

Alternative options

Alternatively you could replace the entire script with mkdir -v $(date '+%y%m%d%H%M'). The names will remain equally concise but the last four digits are now simply the hour and the minute. However, you will only get a single minute resolution for time creation, which might be annoying for creating many directories back to back. Or perhaps you might want to use UNIX times via mkdir -v $(date '+%s')? Here the downside being that this time format is incomprehensible at a glance to all but ultra geeks [that is not an insult, congrats to you if you can!].

And finally of course there is the classic from coreutils mktemp -d but by default the folder will be randomly named (and longer), get stored within "/tmp" on Linux and have "700" (drwx------) permissions.

[Although much of this is configurable with various options (which you can make permanent via a shell alias), it still isn't quite what I personally want. I do not want random naming of any kind, as it is easier for me later with the context of the date stamp should I do choose to keep these around for a bit and in my workflow, I sometimes do. Twisting mktemp to do exactly what I need becomes more convoluted than just using mkdir directly with my script.]


And other fixed locations on different *nix variants like macOS.

@Cqoicebordel
Copy link

Two things :

  1. As you said, decibeat is a bit too long and so, it can create conflicts. Especially with automated systems. Using millibeats would be much better, and would follow more closely the HHMMSS system.
  2. Your script isn't futur proof, and there will be issues in 2100. Having the year on 4 digits is a no brainer ;)

@ruario
Copy link
Author

ruario commented Mar 24, 2024

@Cqoicebordel

  1. This is for human use, not automation. I would prefer keep the numbers short and folder name wieldy. If I was automating stuff and needed something along these lines, I would adjust it. This is for me, day-to-day.
  2. While my health is good, I am pretty sure I will not last another 76 years and if I do I doubt some ramdom temp directory I created now will still be around and relevant. Four digits for this use case, is excessive! 😆

@ruario
Copy link
Author

ruario commented Mar 24, 2024

Actually I had even considered dropping the YYMMDD altogether and just doing a day count over the course of a single year (%j), i.e. today would be 084. I considered this because these folders would never be around for an entire year (I am only considering my own use cases because depsite the long README I doubt anyone else will ever use this besides me). In the end however, it is just easier to remember when I made something with a date like YYMMDD so I left it like that. 🤷🏼

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment