JD command line bits

J.D Concepts 31 Apps and utilities
1

ITT I will document useful command line things that make JD workflows a little easier for me (and that are good candidates for scripts living in my 00).

I’m currently using Fish as a shell, hopefully anything I post should be easily reapplicable anywhere *nix.

Show inboxes with files in them

Having set things up recently, I have a lot of inboxes to clean! This presents all of them and sorts them by size:

find ~ -maxdepth 3 -path ‘Inbox’ -type d -not -empty | xargs -d “\n” du -hd 0 | sort -h

my output rn is:

20K	00-09 Knowledge, organization, writing, notetaking, learning, education, classification/00 Management of Area 00-09, meta-organization, general utilities/00.01 Inbox
24K	90-99 Digital devices/93 Current personal e-reader/93.01 Inbox for Current personal e-reader
52K	90-99 Digital devices/91 Current personal laptop/91.01 Inbox for Current personal laptop
30M	20-29 Being a musician/24 Music software and technical resources/24.01 Inbox for Music software and technical resources
94M	10-19 Bureacracy and accounting/10 Management of Area 10-19/10.01 Inbox for Area 10-19
641M	80-89 Digital media/84 Pictures/84.01 Inbox for Pictures
2.1G	80-89 Digital media/83 Video/83.01 Inbox for Video
2.7G	80-89 Digital media/80 Management of Area 80-89/80.01 Inbox for Area 80-89
6.7G	20-29 Being a musician/23 Recordings/23.01 Inbox for Recordings
6 Likes
2

An excellent idea revealing your inboxes. Thanks for sharing – this type of post isn’t very discoverable at the moment (my fault, not yours) but I have a plan to fix that.

3

here’s another one I’ve been enjoying recently:

report JDEX files modified since last timestamp

The goal here is to try to follow the principle of ‘all work starts and ends in the jdex’. I therefore keep a simple timelog in a file, in which I enter a timestamp when I start work: 12h17. Then, at natural intervals, I run the following command to find files which have been changed since then, paste the result into that file, and add a new timestamp following.

fd --type f --changed-after '2026-02-05 12:17:00'

[Edit: add explanation of command above]

fd drop-in for find command
--type f only files
--changed-after ... only files modified since …

You can pipe that to your clipboard (xsel -i on my system), or create a shortcut in your shell or your text editor to call this with the current time, or read the last timestamp from the logfile, or whatever.

If I stick to this practise, then I achieve the following constraint: if my activity [since last timestamp] did not result in a change to a JDEX entry, it is as if it didn’t happen.

This is incredibly focusing. I often go back and add some notes to a file if the work I was doing was on paper, or in my head, or outdoors. This means my logs are more up-to-date! (in a pinch, I’ll even just touch fileX, for example if I have a good enough log of the work in a different Well-Known Location, but usually I feel compelled to add at least a few words in the JDEX file).

Keeping a timelog finally feels doable and worthwhile. I just paste the output of the above command in the file, and add notes if necessary. And the possibilities for improvement are obvious: format the output as a hyperlink to that file, for example.

I should note that I’m mainly interested in having a timelog that I can parse by machine later, to create a log for tax purposes with minimal effort. But this way it’s also starting to feel like a useful temporal index to my JDEX. an index to an index, hmmm… And yes, there are programs to do this all automatically, but they all feel way too heavy and/or invasive for my needs, or require so much configuration up front as to not feel worth it.

1 Like
4

Neat! A lot more rigorous than my method, which I’m using for the same reasons: I want to ensure JDex-first.

I’ve got a note 00.15 Work logs, by the day and it just contains each date as a header. I add these manually each day. Its purpose is purely as an aggregator of backlinks.

Then when I start some work, in a ## Work log section, I have a bullet list. At the top, I add a new entry. I have a Raycast snippet:

[[00.15 Work logs, by the day#{date format="yyyy-MM-dd"}|{date format="yyyy-MM-dd hh:mm"}]]

– bound to ;;worklog. So I add a bullet, hit the snippet, return, tab, and start typing. I end up with something that looks like:

## Work log
- 2026-02-05 17:02 // this is a wiki-link to 00.15
  - Did blah and blah.
  - And this and that.
- 2026-02-04
  - Yesterday's blah blah.
  - I tend to fold away older entries.

Also when I’m finished work on this item, I add a bullet above the latest entry with any next steps I want to remember.

## Work log
- Next
  - Do the x and the y.
- 2026-02-05 17:02
  - …

Pretty manual, but it’s getting the job done.

5

Ah, yes. Does Obsidian provide link previews of those back links? Then I guess you can really quickly see what you did on each day, from that collector file.

6

Yep! And you can filter the list by date if you want to see a specific day.

I don’t really look at this list. I don’t think I ever will. But something about having it as a formal link is keeping me honest.

Gonna build this into JDHQ soon so you can check-in/check-out of a thing and have it capture timestamps for you…

1 Like
7

sweeeeeet …

8

Collaborating with hardlinks, softlinks, and Syncthing

This hack isn’t strictly ‘CLI’ – it’s a feature of the filesystem you’re using. However I thought it would be something people interested in this thread would be interested in.

In short: if you have a personal system, and one you’re sharing with someone, you can on the one hand transparently mirror shared files into your personal system with hardlinks, and on the other hand, share the existence/location of files using softlinks AKA symlinks.
Unfortunately it’s a bit hands-on. And it’s only tested with Syncthing – I don’t know how other file-sharing services handle links. But if you’re comfortable with the command-line, this works well.

long rambling description of why and how

Inspiration: Back in the workshop videos, where Lucy and Johnny are evaluating how the process went, Lucy says something like that she envisions having a shared system and personal system, and ‘reaching out’ from her system and ‘pulling’ something over from the shared system. This really resonated with me because I feel like it captures something about how human brains work that is difficult to express in binary logic-based networked computer systems. To the extent that fluent computer users might have a blind spot from being so immersed in how computers work, including me perhaps.

philosophical side-track: When you have a collaborative project that works well, if you break it down, I hypothesize that there would turn out to be very clear distinctions between the parts that belong primarily to each participant. The idea of putting everything in real-time collaborative writing/issue tracking/notification-of-what-everyone-is-doing systems sounds empowering in theory, but I wonder if it actually muddies the water quite a bit. If only because it would activate the “I’m being watched” networks of the brain, inhibiting creativity and focus. I think this is related to Cal Newport’s observations in Deep Work about the physical environments of really creative and productive people, e.g. open-plan vs private offices, the hub-and-wheel model, etc. Sharing ideas and private labor are both important but cannot be mixed.

In practise: Hardlinks are transparent to Syncthing. On a given filesystem, hardlinks are basically multiple names for the same file. Syncthing will sync the file’s contents to another filesystem, using the name it has inside the synced folder. So, if I create a file in my personal sync folder called article-collab-with-jane.md, it will sync to my other devices with that name. Then, on my laptop, I go over to the folder that I’m sharing with Jane, and I create a hardlink to the file and call it shared-article-draft-hans.md. The contents of the file syncs to Jane’s computer with that name. Now the file is in three ‘named’ locations, and if it is changed in any of those locations, it changes in all three. You can think of it like this: the filesystem is ‘syncing’ the two local copies, from the user’s point of view[1], whereas Syncthing is taking care of syncing across the network.

The cool thing is that this is completely transparent to Jane. She doesn’t have to know about hardlinks and how they work. I can rearrange our shared files however I want in my personal system without affecting her organisation. Conversely, the shared sync folder could be used to share only those parts pertaining to the collaboration, extracted from each collaborator’s larger work. You don’t have to sync entire folders of unrelated data, eating up disk space on each others’ computers!

In real life, I’ve been using this for specific files from the system I share with my wife. It has no ‘technical’ merit, but I feel it has dissolved a friction I’ve often felt between computer files and how my brain wants to arrange things. In certain cases, I’m fine with going over to the shared system to edit files. In other cases, I feel a strong desire to ‘pull it over’ and rename it and have it be alongside some other related files which I don’t need to share. For example, drafts and calculations and scripts for creating the shared files, which I don’t need to bother my wife with. Note that this is more work for me, as I add new names for existing files, but I feel like this is an example of that extra work/friction is part of what makes the work better. It’s helping me to structure my work and thinking better.

Symlinks, on the other hand, are synced as symlinks. The use case could be syncing the locations and names of large files kept outside the synced folder for space reasons. The collaborator can see that those files exist, and access them via other means or otherwise request them to be copied on demand.

  1. from the computer’s point of view, the user is creating two names for the data container stored at a single disk address. ↩︎

9

Interesting. I love the idea of symlinks/hardlinks, and know they’re first-class features of the OS … but oh boy they make me nervous!

10

Yeah, me too. weird, eh. Hardlinks sound scarier but I’ve realized they actually add little risk that you don’t already have. In fact they’re a sort of safety net: if you’re worried you’re going to delete a file carelessly, add another reference to it elsewhere in the FS.
I’ve read interesting tricks like: while a media file is downloading and still called .part, add a hardlink called .mp4 so your media player can start playing it already. I suspect this is less useful these days, but it did help me see the 'first-class’ness of hardlinks.

What actually makes me the most nervous is that I can never figure out what people mean by ‘source’ and ‘target’, ‘from’ and ‘to’. With symlinks too: are you linking ‘from’ the original ‘to’ the link, or the other way round? That’s where I’m always scared I’ll act on the wrong location, especially with symlinks, where you could actually do damage to the only real copy.

11

Yes! I never ever remember which way round to put those two.

But yeah, hard links are really safe. Nothing to be worried about at all. For people who don’t know what we mean: you have some.txt file in your Documents folder.

Now you can ln some.txt /other/folder/different-name.txt and what you’ve basically created is another link to the file in a different folder. Different from an ‘alias’ that your OS can create. As far as your OS is concerned, they’re the same file. They point to the same bits on disk.

Even that is misleading. There’s no ‘as far as your OS is concerned’. It’s deeper than that. They are the same file. It’s that simple.

Now deleting some.txt does not cause different-name.txt to be deleted. It still exists. Until you delete it, and now your OS realises that nothing points to the data on the disk any more, and it’ll use that space for something else.

Really cool stuff and mostly under-used.