Blendfile management for command-line junkies

Note: If there’s a better place for this post please let me know.

Quick Pitch

Since this is a relatively long message here’s a quick summary to help you decide if it’s worth reading:

I’m trying to figure out whether I should share with a wider audience the scripts I and a couple others use to manage Blender files. They’re suitable for a relatively niche crowd, i.e. people who are a command-line focused and for whom at least one of these apply:

  • I have a lot of blendfiles.
  • I work on multiple blendfiles most days.
  • I use multiple Blender versions (e.g. alpha, beta, stable, e-cycles).
  • I see occasional Blender crashes and benefit from the blendfile recovery feature.
  • I occasionally forget where I put a blendfile.

The tools solve problems that arise from working under these conditions.


I’m a heavy command-line user for all manner of tasks and managing the work/play I do in Blender is no exception. I have a large number of blendfiles and I often work in multiple different files per day. Though the files are somewhat organized and in a single, dedicated tree I still can lose track of where a particular file is or what I worked on on a given date if enough time has passed. Thanks to the Blender team’s rapid development pace, I bounce between several different versions of Blender itself as I like to use alpha and beta builds as well as a stable build, depending on the project.

To help with all this I use shell scripts that have evolved over time to become really useful to me and a couple buddies. I got to wondering if anyone else out there has work habits like mine and would benefit if they were shared more widely.

To be honest I’m skeptical that there will be a lot of demand because, really, how many command-line oriented, Blender “power users” (without similar scripts of their own) can there be? Or maybe someone already released some good tools that do similar things. No harm in asking, though.

The Tools

Here’s a quick rundown of the tools as they are now. They are written in Bash and will work for Linux and Windows with Cygwin as long as essential coreutils tools like find, sed, sort and cut are available.

Quick Summaries

  • blend_run (my alias: br) : locate a blendfile by path, full or partial name, or pattern and open it with the appropriate version (see below) of Blender
  • blend_locate (bl) : interactive or read-only listing of blendfiles that match a pattern. “Interactive” means you can select files to be opened (via br).
  • blend_active (ba) : like bl but search by “modified in last N days”
  • blendutils (bu): dispatcher; single point of entry for br, bl and ba (see below)
  • blender_vers (bv) : manage different Blender versions/builds. Takes a downloaded zip/xz file, unpacks and promotes/demotes installatios by way of symlinks. (Less refined than the other scripts but evolving.)
  • blend_console (bc) : rudimentary script to launch Blender so it’s output goes to the current console (Cygwin only…need to check whether it’s useful for Linux)

Nice Features

Those are fairly simplified descriptions but there’s quite a bit going on under the hood (the ‘br’ script alone is over 500 lines long). Here are a few more details that include some of the more useful features:

  • When you launch from an interactive list, the tools will check whether you have an autosave that’s newer than the blendfile itself. If found you are given a few choices including automatic recovery of the auto save or launching the original blendfile.
  • When a blendfile is selected for opening the tools will scan it to determine what version it was last saved with and attempt to open it with that version.
  • Simple rules can be setup if you want to, say, open all files saved with versions 2.90-2.92 using version 2.93.
  • Tools support wildcard/glob or regex patterns.
  • “Auto-globbing”. You can optionally have both ends of a search term automatically wildcarded. Simply specifying ‘foo’ will find, for example, both ‘foo.blend’ and ‘bazfoobar.blend’. (This behavior can be disabled with a flag or in config.)

Single Launch Point

While it’s possible to invoke the scripts directly most are intended to be run via a dispatcher script called blendutils (and that’s how I’d refer to the complete set of scripts for now). You can do, for example, blendutils active 5 to run blend_active with N=5 (days). With an alias, alias bu='blendutils ', and the abbreviated form of the command name it becomes bu a 5. Add a second alias, alias ba='bu a', and you just need ba 5 and now you’re cooking with gas. :sunglasses: (And this is exactly how I use it.)

Wrap Up

If you think you might be able to make use of these tools or you have any questions let me know. Note that the tools are constantly evolving and I’d be open to some suggestions for additional functionality.


1 Like

This looks great, and I’d definitely be interested in taking it for a spin.

What I’d personally be interested in would be a way to open obj/fbx/etc. from the command line(or ranger in my case). I want to do this all the time, but can’t.
Should be possible by passing a simple import script, but I haven’t gotten around doing that myself yet. Maybe an idea :slight_smile:

1 Like

I think you underestimate to number of technical artists that would be very interested in these tools. Especially those working on larger studio projects. A lot of studios are picking up blender in their pipeline and are desperate for better tools to handle this sort of thing.

Please don’t be reluctant to share :slight_smile:

Only good can come from open sourcing them and throwing them up on a repo somewhere.

1 Like

If the author of MACHIN3tools, which I get a lot out of, is interested that carries a lot of weight. It’s looking like I’m going to proceed so stay tuned here.

Regarding obj/fbx/etc if that’s possible and I can find the python fragment to do it I can easily integrate it as I’m already doing something similar to launch autosave files. This will, of course, have to come after the general things I need to do first to open the repo to everyone but I will look into it.


1 Like

Thanks for the feedback!

While the tools, at their core, are solid and used daily there’s a pretty long list of peripheral items (user friendliness, portability, corner case testing, etc.) that I would want to put a dent in before going wide with this. That’s why I put out this post as a feeler first rather than just diving into the work.

That being said, you make good points and even though just a couple replies have come in I think it’s worth it to proceed. More to come in this space in the near future.