Jeffrey’s “Run Any Command” Lightroom Export Plugin
Quick Links
· Latest Download:
· Version History
· Update Log via RSS
· Installation instructions
· “Donationware” Registration Info
· More Lightroom Goodies
· All-Plugin Update Log via RSS
· My Photo-Tech Posts
· My Blog

This plugin for Adobe Lightroom provides four separate (but sort of related) functions:

1) It provides an export filter that allows you to run a command of your choosing with each exported image copy, as part of the export while its going on.

2) In the export filter, you can also apply a command to all exported image copies as a group, after the last one has been rendered.

3) In the export filter, you can also have processed photos added to a normal collection and/or a publish collection, and can optionally invoke a Publish operation on a publish collection or a full publish service.

4) Via a new entry to the File > Plugin Extras menu, it lets you apply a command of your choosing on the master image files selected in Library.

This plugin works in Lightroom 6/CC (and older versions as far back as Lightroom 3, though some features depend on the version of Lightroom).

The same download works for both Windows and Mac. See the box to the upper right for the download link (in orange) and installation instructions.

Export-Filter Features

This plugin includes an export filter that provides access to the rendered copy of an image being exported, during the export. It can be used with any export or publish service, whether built into to Lightroom or provided by a plugin.

The plugin adds a section to the Export/Publish dialog like this:

The top half is for the command to be executed during each image's render, while the bottom box is for the after-all-have-been-processed actions. You can use any or all parts that suit your workflow.

When Things Happen

It's important to understand when during the export/publish operation this plugin's actions are taken, especially in th face of errors downstream from this plugin.

The per-image command, if you have one, is executed during the export operation at the point where it appears in the dialog. In a complex export involving many filters (such as, for example, my Metadata Wrangler and/or LR/Mogrify), the ordering can have a material impact, depending on what you're doing in the command. For example, if you're using the command to send a backup copy somewhere, the copy you're backing up is the pre-Metadata-Wrangler version if this plugin appears in the export dialog above the Metadata Wrangler, and the post-Wrangler version if below.

It's also important to realize that an export can ultimately fail even if it passes this plugin successfully. If the prior example is all within, say, an Export to Facebook operation, the export will ultimately fail if there is no network connectivity. If the commands you had the plugin invoked did things like keeping backups or somehow marking a database, you've now done these things for images that ultimately did not finish exporting. It's an important consideration, depending on the nature of the commands.

In particular, the add-to-collection features happen after this plugin processes the final image of the export, and if the final steps of the export end up failing for some images, those images still remain in the added-to collections. If those collections were intended to be the full set of, say, images uploaded to ...., in the face of such errors you'll end up with images in the collection that shouldn't be there.

So, depending on your workflow, take care with these features when you have export errors.

Command Metasequences

Before a command is actually executed, special token sequences are recognized and replaced by the plugin. For example, the token {desktop} is replaced by the full path to the user's Desktop folder.

The set of tokens recognized depends on the situation.

The per-image Command to Execute command supports all the general tokens of my plugins' preset templates, so you can use image-specific metadata on your command line.

In addition to those tokens, the following are also recognized within this command:

SequenceReplaced By
{FILE}The name of the exported image file, with full path.
{file}The name of the exported image file, without the leading path.
{NAME}The name of the exported image file, with full path, but without the file extension.
{name}The name of the exported image file, without the leading path and without the file extension.
{folder} Full path of the folder that the exported file lies in.
{home} Full path of the user-dependent home folder.
{desktop} Full path of the user-dependent Desktop folder.
{pictures} Full path of the user-dependent picture folder (My Pictures or Pictures).
{documents}  Full path of the user-dependent document folder (My Documents or Documents).
{temp} Full path of a system-dependent temporary folder.

The overall Command to execute upon completion command supports the following tokens:

SequenceReplaced By
{FILES} The full path of all images rendered for the export, each surrounded by double quotes, separated by spaces.
{qFILES} The full path of all images rendered for the export, each surrounded by single quotes, separated by spaces.
{xFILES} The full path of all images rendered for the export separated by spaces.
{COUNT} The count of images rendered for the export.
{MANIFEST} A temporary file that includes the full path of all images rendered for the export, one per line. (The temporary file is deleted by the plugin after the command has executed.)
{home} Full path of the user-dependent home folder.
{desktop} Full path of the user-dependent Desktop folder.
{pictures} Full path of the user-dependent picture folder (My Pictures or Pictures).
{documents}  Full path of the user-dependent document folder (My Documents or Documents).
{temp} Full path of a system-dependent temporary folder.

Command Quoting

You must be very careful about where to quote items in the command lines you enter in the plugin: anything that has a space or other special shell variables must be quoted, but exactly what must be quoted, when, and with what kind of quotes is dependent on the operating system. It's fairly straightforward on a Mac: single quotes will almost always be okay, double quotes probably okay in most cases as well. On Windows, use double quotes and cross your fingers.

Never use smart quotes, like the ones in this sentence surrounding the phrase smart quotes. Only use the old-style ASCII single ( ' ) and double ( " ) quotes.

You'll probably end up using "{FILE}" (or, on a Mac, '{FILE}') in every command.

Here's a concrete example using Phil Harvey's most-excellent exiftool to insert a copyright notice into the jpeg image-comment field. Here it is for Windows:

"C:\path\to\exiftool.exe"   -overwrite_original    "-Comment=Copyright {yyyy} {Artist}"    "{FILE}"

And on a Mac:

'/path/to/my/exiftool'     -overwrite_original     '-Comment=Copyright {yyyy} {Artist}'    '{FILE}'

Each uses the {FILE} token with appropriate quotes, and also two preset-template tokens.


Details about each command executed and its results are kept in the plugin log, which is referenced in the upper-right section of the Plugin Manager.

Collections and Publishing

After the last photo has been processed, you can have all processed photos added to a regular collection and/or a publish collection, and can optionally have a Publish operation invoked on a publish collection.

Take care not to create a never-ending circular publish chain. If you add this plugin to two separate Publish Services, and in each configure this plugin to auto-publish the other publish service, you could destroy the known universe. Please don't do that.

The Plugin-Extras Extras

The plugin provides a way to execute a command with the master image file for currently-selected photos. Select the photos and invoke File > Plugin Extras... and you'll see four options for this plugin:

Initially, only the first has meaning, and it brings up a dialog where you can configure up to three custom commands:

Once a custom command is configured, you can then invoke it through the Plugins-Extra menu.


This plugin is distributed as “donationware”. I have chosen to make it available for free — everyone can use it forever, without cost of any kind — but unless registered, its functionality is somewhat reduced after six weeks.

Registration is done via PayPal, and if you choose to register, it costs the minimum 1-cent PayPal fee; any amount you'd like to add beyond PayPal's sliding fees as a gift to me is completely optional, and completely appreciated.

Note: a Lightroom major upgrade, such as from Lr5 to Lr6, de-registers the plugin in the upgraded version, so if you want to maintain registration, a new ($0.01 if you like) registration code is needed in the upgraded version. It makes for a hassle every couple of years, I know. Sorry. See this note for details.

For details on plugin registration and on how I came into this hobby of Lightroom plugin development, see my Plugin Registration page.

Version History
( Update Log via RSS )


Fixed a bug with the keyword tables in the LUA token.

Added Weekday, Wday, weekday, and wday to the list of template tokens that my plugins understand.

Switch the log-sending mechanism to https.

Added "ISO8601Date" to the template tokens that my plugins understand.

Added the following tokens to the template tokens that my plugins understand/a>: Artworks, ArtworkTitle, ArtworkCopyright, ArtworkSource, ArtworkCreator, ArtworkDateCreated, ArtworkInventoryNum

20160718.86 Oops, new collection/publish stuff added in previous update didn't respect the "enabled" checkbox.

Added the ability to add processed photos to collections, and to publish a collection.

Try to avoid yet another place where Lightroom gets hung because it can't handle certain kinds of dialogs at the same time.

Added Russian-langauge support for the People-Support {People} tag.

Added the following tokens to the templates that my plugins understand: FileModYYYY, FileModYY, FileModMM, FileModDD, FileModHH, FileModMIN, FileModSS, FileYYYY, FileYY, FileMM, FileDD, FileHH, FileMIN, FileSS, {FilenameNumber}.


Fixed how custom {People} formatting works with people keywords that have no birthday associated with them.


Added ChildOf and DescendantOf filters to the {Keywords} and {KeywordsAll} template tokens that my plugins understand.


Added {SpeedKPH} and {SpeedMPH} to the list of template tokens supported by my plugins.

The {People} token wasn't working properly for some keywords without a registered birthday.


Fixed the "SpecPeople:259: attemt to index al nil value" error.


Command wasn't being applied to rendered video files.

On OSX, allow text in the error-report dialog to be selected and copied.


In the POODLE-vunerability dialog, display a raw URL of a page on my site that discusses the issue, so that folks can be independently sure that the dialog is indeed from me and not malware.


Fix to the date_diff() function supported by the LUA template token.

Updated the camera-name code to try to guess the actual camera model of Hasselblad H5D files, since in their infinite wisdom Hasselblad decided to encode three distinct models with the same internal code, making it impossible to know for sure what camera produced a given image file.

20141219.77 Registration was broken on Lr2
20141019.76 Windows Only: Add a one-time check for the POODLE security vulnerability, and alert the user if it exists.
20140923.75 Added the LrMD5, LrLocalization, LrSystemInfo, and LrMath packages to the {LUA} template token.
20140921.74 Added the {MANIFEST} token
20140920.73 Added a rudimentary "apply custom command to selected master image files" functionality. See the File > Plugin Extras > jf Run Any Command menu to configure and launch.
20140902.72 New build system

Made the {GPSAltitude}, {Altitude}, and {GPSCoordinates} tokens subject to the geo-privacy settings like the other geo-related tokens.

20140731.70 Registration fix for Lr5.6
20140729.69 Previous updates broke support on Lightroom 2
20140720.68 More Creative-Cloud support.

Fixed an issue with Creative-Cloud revalidation.


Lr5.5 and later Creative-Cloud installs can now revalidate themselves if needed.

20140710.65 Sigh, had a bug in the Creative-Cloud support.

Now supports Lr5.5+ Creative-Cloud Installs.

20140704.63 Sigh, introduced an error for some folks with the rebuild the other day.
20140630.62 Build-system update

Added date_diff() and raw_time_diff() functions to the special {LUA} token understood by the plugin.


Added new tokens to the template language the plugin understands: LrVersion, LrVersionMajor, LrVersionMinor, LrVersionRevision, LrVersionBuild, Location, CatalogName, CatalogPath, OperatingSystem, OS

Added new token filters: NS and LO

20140423.59 Fix a location-related template-token bug introduced in a recent build.

Fixed a bug in the "smoother revalidation" stuff recently added.


The {Empty} template token wasn't working properly.

Make the revalidation process smoother, especially for folks using Lr5.4 and later.

20130926.56 Oops, fix a bug introduced in the previous update

Added a bunch of tokens to the preset templates supported: ExportFormat, ExportColorSpace, ExportBitDepth, ExportQuality, ExportSharpeningLevel, ExportSharpeningMedia, IpernityUrl, GoogleDriveUrl, and TumblrUrl.

The token-examples dialog had been broken. Also deprecated Folder and Path tokens in preference to FolderName and FolderPath tokens.

Fixed the KW/KWE tables used by the LUA token; they had been broken when using load for the script.

20130613.54 Better support for plugin revalidation.
20130611.53 Yet another Lr5 update
20130524.52 Apparently, a recent change broke things on Lr2, which some folks apparently still use.
20130501.51 Update for Lr5
20130412.50 Build system update.
20130328.49 Fix for the registration system.

Added support for some new template tokens: FlagStatus (requires Lr4.1 or later), and for Lr3 and later, a bunch of IPTC extended metadata: AdditionalModelInfo, CodeOfOrgShown, DigImageGUID, Event, ImageSupplierImageId, MinorModelAge, ModelAge, ModelReleaseID, ModelReleaseStatus, NameOfOrgShown, PersonShown, PlusVersion, PropertyReleaseID, PropertyReleaseStatus, and SourceType.

20130209.47 More build-system maintenance
20130206.46 Tweak for my registration system

Enhance the {EMPTY} template token so that it interrupts the squelching of superfluous joining characters.


Updates to the environment in the {LUA} token (in the template tokens in my plugins) to include photoTime() and currentTime(), and other changes to match the updated docs at that link.

20120608.42 Fix an "attempt to perform arithmetic on field" error.

Update to handle the Mac App Store version of Lightroom.

Tweak for Lr4.1RC2.

Added to the template tokens supported by the plugin: {FullMasterFolder}, {FullExportedFile}, and {FullExportedFolder}, and to match, renamed the recently-added {FullMasterPath} to {FullMasterFile}.


Enhanced the send-log dialog to hopefully make reports more meaningful to me, yielding, I hope, the ability to respond more sensibly to more reports.

Added {FullMasterPath} to the list of template tokens supported by the plugin.

20120330.39 Update to handle 4.1RC.
20120309.38 Had broken registrations in Lr2; Update to the debug logging to better track down timing issues that might arise.

More on the march toward Lr4, including upheaval in the code to handle Lightroom APIs being discontinued in Lr4.

Added the {AspectRatio} token to the token templates understood by the plugin, and added the Length=num filter.

20120114.36 More tweaks for Lr4b

Update for Lr4 beta: explain in the plugin manager that the plugin can't be registered in the beta.


Had issues with the registration button sometimes not showing.

When doing a plugin upgrade, offer the ability to flush all the old copies of the plugin.

Added a system-clock check and reports to the user if the system clock is more than a minute out of date. An incorrect system clock can cause problems with various kinds of communication and authentication with some of my plugins, so I've just gone ahead and added this to every plugin.

20111011.33 The {Path} token wasn't working properly.
20110608.32 In some cases where the command could not be run, the plugin crashed instead of reporting the error.
20110113.31 Added {CroppedWidth} and {CroppedHeight} to the template tokens used by my plugins.
20100829.30 Made the revalidation process much simpler, doing away with the silly need for a revalidation file.
20100820.29 Discovered a bug in my plugin build system that caused horribly difficult-to-track-down errors in one plugin, so am pushing out rebuilt versions of all plugins just in case.

Added code to allow plugin revalidation after having been locked due to a bad Lightroom serial number.

20100723.27 Figured out how to add the ability to run a command after all files have exported.
20100625.26 Yikes, shaking out some more build issues.
20100624.25 Discovered a nasty build bug; pushing a new version in case it affects this plugin.

This version can be registered in Lightroom 3. It can run in Lightroom 2 or Lightroom 3; it does not work in the Lr3 betas.

It uses my new registration system when run on Lightroom 3, which avoids some of the silly issues of the old one. Please take care to note the details on the registration page: use of this version (or later) of the plugin in Lightroom 3 requires a new registration code, even if you had registered some older version of the plugin.

20100516.23 Update for the Lr3 beta.

Added new tokens to the templates that my plugins use, CameraName, IfGeoencoded, Keywords, IfKeyword, IfExportedKeyword, and LUA. See the templates page for details.


Fixed up some issues with the help dialog, and added a warning referring to it if the user command doesn't seem to refer to the exported image.

Changed the semantics of the Places filter (in the tokens understood by the preset templates of my plugins) in two ways: if applied to a string value rather than a number, it works on the first number found in the string. Another is that you can now use something like Places=-1 to round to the 10s, Places=-2 to round to the 100s, etc.


Fixed the {GPSAltitude} template token so that it should now actually work.

Completely changed how the one-click upgrade applies the newly-downloaded zip file, in the hopes that it'll work for more people. Rather than unzipping over the old copy, it now unzips to a temporary folder, then moves the old folder out of the way and the new folder into place. Prior versions' folders are now maintained (with the version number in the folder) in case you want to revert a version; you may want to clear them out from time to time. Of course, it won't take affect until you try to upgrade after having upgraded to or beyond this version.

20100118.18 Added two new template tokens, {DaysSince} and {PhotoDaysSince}. They're a bit tricky, but could be useful.
20091214.17 Added the ability to save command presets.
20091205.16 Minor internal debugging tweaks.
20091118.15 Added an {Altitude} item to the templates understood by the plugin. It's the numeric altitude in meters, as opposed to the {GPSAltitude} item which is a description of the altitude along the lines of 32.7 m. Also updated the Places filter so that it can be used on fields that merely begin with a number.
20091022.14 Added a first draft of some rudimentary support for Lightroom 3 Beta. See this important note about plugin support in Lightroom 3 Beta and Lightroom 3, including future plans for features and my registration system.

Enhanced the one-click upgrade stuff quite a bit, now detecting ahead of time when it will fail because the plugin is installed where Lightroom can't write (if Lightroom can't write to it, it can't update itself). I also added a progress bar, and now download in smaller chunks to avoid 'out of memory' errors on the larger plugins. Do remember that this new functionality becomes available after you upgrade to or past this version, when you then upgrade with it.

20090629.12 Fixed a boo-boo in the help dialog, and added a note that command-line quotes should be ASCII, never "smart quotes".
20090521.11 Fixed a "loadstring" error some users got.
20090510.10 Added a link in the Plugin Manager to the plugin's update-log RSS feed.
20090425.9 Tweaked how the plugin tries to update itself during the one-click upgrade process, to hopefully get things working for those few Windows users that have never had it work. Crossing fingers. We'll see.
20090313.8 It seems that PayPal doesn't give everyone a "Unique Transaction ID" in the registration confirmation mail; some people get a "Receipt Number". So, the registration dialog now accepts that as well.
20090228.7 Fixed a bug that caused a plugin crash if my server couldn't be reached during registration.

NOTE: you may need to restart Lightroom after installing to this (or a later) version from the previous (or an earlier) version. Please try a restart if you get an error the first time you try to use the plugin.

As per the ongoing discussion on my blog, with this version this plugin moves over to a "donationware" model, in which the plugin remains free, but registration eventually becomes required (and an eventual donation hoped for 🙂 ).

For details, see Lightroom Plugin Development: Now With Added Encouragement. (For info about what drove this decision, see What To Do When a Hobby Becomes Work?)

The plugin no longer expires, and correspondingly, I will not pay much attention to reports of bugs that have already been fixed, so please check your version and the version history before submitting bugs or feature requests.

There was a lot of internal upheaval in the code, so I expect that some boo-boos my surface. If something breaks for you with this version, please let me know, but until I fix it, feel free to revert to the previous version.

20090205.5 Bumping expiration into the future.
20090130.4 Oops, forgot to include the unzipper in the plugin, so the automatic upgrade won't work on Windows until after you manually upgrade to this version.
20090129.3 Added an option to ignore errors generated by the command.
20090129.2 Small housekeeping update for the new locales supported by Lightroom 2.3.
20090127.1 Initial public release

The 30 most-recent comments (out of 45; see all), most recent last...

Wow! Fast reply. I guess it is because I’m up at 2:52 a.m. my time, and you are halfway across the world.

I’m in Kyoto. Can’t sleep. —Jeffrey

I know that I can burn CDs from within Lightroom, but it always finalizes the discs. I’d like to process one set of photos and then export them to folders while at the same time queuing the exports up to burn with Win XP’s built-in burner. Then I could process another set of photos and do the same. Once I’m completely done with all the sets of photos I could just hit BURN and have the day’s photos on one disc (that isn’t finalized!!)
I’ll keep digging for now. Thanks so much.

— comment by Matthew Schwarz on May 20th, 2009 at 2:53am JST (7 years, 11 months ago) comment permalink

I have built a simple command-line email sender to use with Lightroom 2. It is fully configurable from the command-line parameters and/or a config file. I use it with this plug-in and love it! Thanks for proving a simple way to do additional processing!

— comment by Andy Miller on July 8th, 2009 at 11:56am JST (7 years, 10 months ago) comment permalink

Hi Jeffrey. NJ here.
I am lost. I have the exporter to Zenfolio which I understand. This run any command has me baffled. My wokflow is simple…

Download into Lightroom 2.4 & edit
Export low-Res Jpegs to desktop folder w/ PP action droplet
PS4 opens file and applies my actions & closes files
I then open Zenfolio and drag them to folder & upload

Now, this takes time and I have to hang around and wait for the export, action apply & uploading. What command would I write to have PS4 open the files and run the actions I designed.

Thanks for your help.


I don’t have any personal experience with photoshop droplets, but I assume that they are files that you can execute, passing image filenames as arguments. In that case, you’d want to put the name of the droplet filename followed by "{FILE}" as the command. You can combine this with my Zenfolio plugin, and have a fire-and-forget solution that does it all…. —Jeffrey

— comment by John @ JargaPix on October 6th, 2009 at 2:26pm JST (7 years, 7 months ago) comment permalink

Hi Jeffrey,

I am trying to create a command with tokens to copy a photo to a sub-folder on my desktop (Mac). That sub-folder should be named to today’s date, in the format of
So for example if I were to run it today, the command would create a folder “8.11.09” on my desktop, and copy the photo to that folder.

Can help me with the syntax? I’m a bit computer challenged…
Many thanks,

It depends on your system (Win? Mac?), but it should be easy to do with exiftool. Check out the renaming examples in particular. —Jeffrey

— comment by nati on November 9th, 2009 at 2:08am JST (7 years, 6 months ago) comment permalink

Ahhhh, now I understand. Did not realize the role of exiftool in your export plugin.
This is wonderful. Many thanks for your help.

It’s not part of the run-any-command plugin…. you have to install it yourself, then refer to it from the command you enter into the plugin. —Jeffrey

— comment by Nati on November 10th, 2009 at 1:07am JST (7 years, 6 months ago) comment permalink

Now I have some Phil Harvey wisdom to read…

— comment by Nati on November 10th, 2009 at 11:35am JST (7 years, 6 months ago) comment permalink

Hello Jeffrey,
I’m from France in Provence 😀

Firstly, thank you for your work.
I need assistance for work by batch with your plugin.

Currently, the plugin work image by image, but I will like that it transmits the whole of the images to be treated.
Could you help me? Thank you.

For this I think you want to use the Post-Processing section of the standard export… —Jeffrey

— comment by Gotcha on January 30th, 2010 at 3:09am JST (7 years, 3 months ago) comment permalink

Hello Jeffrey,

Thank you for your answer.

The standard export command is too basic and I believed that your solution could bring to me of the assistance.
I need to make several operation after for a batch photographs. This batch passed in argument towards other programs.

Best regards.

This plugin can’t do what you want because it has access to the exported images only for a moment during the export of each image, and doesn’t know when the overall export has finished, nor what the final image filenames might be. But the overall Export Action should be able to do what you want, because it will pass all the image filenames to the command you specify. You can make it a batch file (Windows) or script file (OSX), so you can have it do as complex an operation as you know how to program. —Jeffrey

Update July 2010 – I figured out a way process all the files at the end of an export, as of version .27 —Jeffrey

— comment by Gotcha on February 3rd, 2010 at 10:00pm JST (7 years, 3 months ago) comment permalink

Can I use this to ADD keywords to a photo on export? I tried using exiftool with a basic example from the FAQ:

“exiftool -keywords-=one -keywords+=one -keywords-=two -keywords+=two”

But it didn’t add the keywords.

Your command doesn’t actually refer to the exported file (via the {FILE} token). See the help button for info on tokens. I’ve just pushed a new version of the plugin that includes a warning if the command doesn’t seem to refer to the exported image. —Jeffrey

— comment by John Vanderbeck on March 12th, 2010 at 8:43am JST (7 years, 1 month ago) comment permalink

Dear Jeffrey
(This from Sydney, Australia)
Any chance of a run any command on *Import* filter?
Currently I tediously run exiftools on files where LR (or my camera) won’t recognize the lens (such as CV manual focus lenses). What I do is copy new files to disk, run exiftools in the terminal, then import them. Things have got a bit better with the new beta, since updating exifdata didnt’ work relaibly before, I suppose now I could use LR to import, then exiftools then update.

But how cool if there were a way to run extra commands on import!

Not possible yet in LR3 )-: —Jeffrey

— comment by David on March 26th, 2010 at 7:23am JST (7 years ago) comment permalink

Just a quick comment about opening a webpage using this tool as was asked by one of the users.
The proper command for running the default browser is:


— comment by Vit Kovalcik on May 5th, 2010 at 9:32pm JST (7 years ago) comment permalink

I was wondering if this plugin helps you run any command on the image before it becomes JPEG — not sure I described it right, I would like to run a command on the intermediate image (may it be a BMG or TIFF,) sort of pre-processing the image.

You can do that by having Lightroom export a TIFF/PSD, then using the command to do your processing and, finally, if you want a JPEG, have it do that as well. —Jeffrey

— comment by dkwo on August 2nd, 2011 at 11:40am JST (5 years, 9 months ago) comment permalink

Can you specify the source image as a command sequence? I need to pull a maker note field from the original file and add it to the exported jpg.

Sure, you can use any of the template tokens that my plugins support, including {LIBRARYFILENAME}. —Jeffrey

— comment by Jacob on October 10th, 2011 at 12:42pm JST (5 years, 7 months ago) comment permalink

Jeffrey that helps, however when I use the {Path} token it gives the path with “>” not “\” on Win 7.

D: > users > username > path > to > file

Can you specify the “\” character?



Yikes, not sure how that happened, but I’ve pushed a new release that fixes it. —Jeffrey

— comment by Jacob on October 11th, 2011 at 2:11am JST (5 years, 6 months ago) comment permalink

Hello, I am using the Run Any Command plugin to create an animated GIF in ImageMagick. I nearly have it working 100% automatically. I can select my sequence and export and I get an animated gif but the filename is always the same. The actual animateg GIF is created using an ‘execute upon completion’ command and I would like to make the filename unique so if I create several gifs they would not overwrite. Are there any template fields or some other technique available in the post processing step to get an new filename? Thanks.

— comment by Robin Cottiss on February 9th, 2012 at 1:01am JST (5 years, 3 months ago) comment permalink

I have an answer to my own question but if anyone has any better suggestions let me know.

I can use an ImageMagick command to make a unique filename based on the input names. My execute on completion command looks like this:

convert -loop 0 -delay 50 {FILES} -set filename:f “output_%t” “{pictures}\TEST\%[filename:f].gif”

Note the use of the -set to make a filename based n the input. It turns out that IM uses the 1st filename in {FILES} which is perfect for my needs.

It is very cool how you can mix the Plugin template values and IM escape variables in the same command.


— comment by Robin Cottiss on February 9th, 2012 at 1:39am JST (5 years, 3 months ago) comment permalink

For completeness here is what I do for the actual run command step to place a timestamp onto each image so I can see the time of each image in the resulting animation:

mogrify -fill white -stroke black -font Arial -pointsize 36 -gravity SouthWest -annotate 0 “{file} – {T2}” “{FILE}”


— comment by Robin Cottiss on February 9th, 2012 at 1:42am JST (5 years, 3 months ago) comment permalink

i would like to be able to digimarc photos on export using your direct to smugmug plugin (via temporary files). is it possible to do that using a photoshop droplet (app) with your “run any command” post process filter? thank you for your plugins!


Yes, seems reasonable. I’ve heard folks run Droplets from “Run Any Command” successfully. —Jeffrey

— comment by Lee on September 13th, 2013 at 1:56am JST (3 years, 7 months ago) comment permalink

i have tried to do this without success. if someone else has managed to do it on a Mac i would appreciate seeing how your command line was structured. my command line looks like this:

‘/Volumes/MacPro RS2/Documents_RS2/Photoshop Actions/Digi’ ‘{FILE}’

the error result was this


You probably want this:  open -a /Volumes/MacPro RS2/Documents_RS2/Photoshop Actions/Digi' '{FILE}'  —Jeffrey

— comment by Lee on September 13th, 2013 at 12:12pm JST (3 years, 7 months ago) comment permalink

that worked! thank you.

if i understand this “filter” correctly though, the process only happens after the upload to smugmug. is there a way to make it happen to the image before going to smugmug (only choice seems to be to export to disk first — adding the digimarc — then upload to smugmug from the disk copy.


If you use it with the SmugMug plugin, it’ll happen before the upload, but you’ve got to make sure you update the image in place. —Jeffrey

— comment by Lee on September 13th, 2013 at 11:48pm JST (3 years, 7 months ago) comment permalink

Would it be possible to add a feature that would let you run a command after the ENTIRE export is done?

Let say : run a bash script on the folder that ZIP’s everything. Or run a script that would FTP the entire folder?

That’s already there, both in the run-any-command plugin and in the vanilla Lightroom export. —Jeffrey

— comment by Gerard Henninger on October 13th, 2013 at 8:55am JST (3 years, 6 months ago) comment permalink

Does this plugin work with LR Publish Services (such as jf Flickr)? I’m attempting to do some exiftool post-processing on images prior to publishing them to Flickr (e.g. remove/update CreateDate, CreateTime, etc.), but the capture time for the image on Flickr is set to the original photo’s capture time.

Yes, it gets control of the copy of the image that Lightroom creates for the export, before the overally controlling plugin (e.g. Flickr plugin) gets it. —Jeffrey

— comment by Sol on December 12th, 2013 at 6:45am JST (3 years, 4 months ago) comment permalink

From Portugal.

Is there any chance of running a command immediately activated when a shoot if made on studio as the file enters on the LR workspace? A kind of listener ignition to run a command…

I want to do 2 things:

1- on each image raw entered, read some of the xmp properties and compare to the ones approved by me (to detect camera wrong configuration);

2- do the same to small video files (first extract xml with exifTool using command and then reading properties and comparing with the approved ones;

The approved values depend on the studio, and on me and are to loaded from an xml.

At the end of all this, the photographer should be immediately warned if camera is not write configured, avoiding major mistakes that could not be corrected after.

Lightroom offers no on-import hooks for plugins. The only thing I could suggest would be to use my folder-watch plugin along with its method to do automatic export, there having a run-any-command entry check the metadata as you want. Very kludgy, but possible. —Jeffrey

— comment by Pedro Marques on January 18th, 2014 at 6:24pm JST (3 years, 3 months ago) comment permalink


i use the command as shown below, to set the file modified date:

touch -am -t ‘{YYYY}{MM}{DD}{HH}{MIN}.{SS}’ ‘{FILE}’

but this command only works for image file, video files do not take any effect.

do you have any idea to make it works for video files?

thank you.

It seems to work for me. Perhaps send a plugin log for a sample export. —Jeffrey

— comment by cupuno on January 27th, 2015 at 10:22pm JST (2 years, 3 months ago) comment permalink

Can this be used to run a Python script on images after they are exported?

Yes, it can execute anything you can execute from the command line. —Jeffrey

— comment by Paul on January 30th, 2016 at 1:07am JST (1 year, 3 months ago) comment permalink

Hi Jeffrey,

Thanks for the previous answer about using with Python. I am using a Mac with Python 3 but I get ‘sh: python3: command not found’ when I try to run a Python script upon completion. Any idea why?

I tried on two separate Macs but got the same result. However, I don’t get the error with Python 2.7, only with Python 3.



Try using the full paths to the python binary and your script. —Jeffrey

— comment by Paul on January 31st, 2016 at 12:08am JST (1 year, 3 months ago) comment permalink

Is there a way to invoke exiftool through this to write a uuid into a metadata field? For example, select N number of files and make md5 hash from field1, field2, field3. ExifTool has a command “NewGUID”—would that be able to be invoked through this app?

You could use the UUID that Lightroom generates for every photo, via the {UUID} template token the plugin supports, injecting it with ExifTool. I’m not familiar with NewGUID, but it sounds like that’d work out well too. —Jeffrey

— comment by justin on April 19th, 2016 at 6:20am JST (1 year ago) comment permalink

I am registered user using Lightroom CC on Mac OSX El Capitan, I try to run a shell script .sh file with some tasks to run after my export.

My command to execute upon completion is:
sh /Volumes/Macbook13\ 500GB/reportajes/
(I run sh script from terminal and it is running well)

I don’t get any message and I don’t get anything in log or diagnostic messages, but it doesn’t works.
This is my sh file:

#Create csv.csv file with list of jpg exported files.
rm csv.csv
echo “Title,Taxonomy,Path,Price” >> csv.csv;
for f in `ls *.jpg`; do
echo $f”,”${PWD##*/}”,”${PWD##*/}”/”$f”,100″ >> csv.csv;

Thank you Jeffrey

You probably need to put something in there so that your script knows what directory it should work in. When run from Lightroom, you can’t assume you’ll know what directory is the script’s current working directory. —Jeffrey

— comment by David Crespo on June 10th, 2016 at 9:29am JST (10 months, 15 days ago) comment permalink

Hey Jeff, excellent software, I am a big fan.
Would this plugin be able to publish ANOTHER publish service, using the first as a trigger? I find myself in a situation where I want to publish to my hard drive as well as to Cloudspot, without my input. Can “Run Any Command” do this?

Seems like a good idea… I’ve just added it to the version I pushed. I’ve not yet updated the documentation here, though. —Jeffrey

— comment by Aaron on July 12th, 2016 at 7:02am JST (9 months, 13 days ago) comment permalink

Hi Jeffrey, all,

Nice plugin.
However, I am struggling on one point : is there any variable to access the original file ?
In my case, I am trying to run a command like “rm ORIGINAL_FILES” upon completion, basically to export to JPG and delete the NEF file.

Thanks !

Sure, click on the after-processing help link in the plugin and you’ll find it, but wow, it seems scary to delete the master this way. Unless you have copies saved elsewhere upstream in your workflow, considering moving the file rather than deleting, just so you have a chance to recover it if need be, at least until you next clear out the move destination. —Jeffrey

— comment by Flo on July 24th, 2016 at 8:05pm JST (9 months ago) comment permalink
Leave a comment...

All comments are invisible to others until Jeffrey approves them.

Please mention what part of the world you're writing from, if you don't mind. It's always interesting to see where people are visiting from.

You can use basic HTML; be sure to close tags properly.

Subscribe without commenting