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 Classic 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 Classic, 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 filename of the exported image copy, with full path.
{file}The filename of the exported image copy, without the leading path.
{NAME}The filename of the exported image copy, with full path, but without the file extension.
{name}The filename of the exported image copy, without the leading path and without the file extension.
{folder} The folder part of {FILE}
{ExportedByteSize} The size of {FILE}, in bytes (e.g. 347264)
{ExportedFileSize} The size of {FILE}, in a human-readable way (e.g. 339.1 KB)
{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 Lr10 to Lr11 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 )


Play whack-a-mole with Lightroom's handling of margins in dialogs, trying to avoid having the edge of dialog items cut off.

Change the prose to make it clear that the "add to collection" stuff refers to images selected for output, and not the outputted copies.

Removed a bunch of debug logging that was slowing down the LUA token.Newline


Added the WEEKNUM token, along with DAYNUM, weeknum, and daynum.

Whack-a-mole with PayPal's random changes.


Warn when PayPal seems to have given a bogus code in the web-confirmation page.


Some error messages were presented incorrectly.


Added {ExportedByteSize} and {ExportedFileSize} to the plugin-specific list of tokens.

Fixed that the Province template token did not respect the plugin-specific geo-privacy settings.

Fixed an issue with the {Newline} token, and added {Comma}, {Hyphen}, and {Space} for good measure.

Fixed a problem with filters on the {Keyword} token.


Reworked the Keywords token to better accept filters.

Added 'separated by' to the People token.


Added the ImageViewDirection and ImageViewBearing tokens.

Working around 'constant table overflow' error.


Added the PF filter to turn typographic fractions into plain-ASCII fractions.


Updates for Lr10

Added the SpeedKnots token.


Worked around an "unknown key captureTime" error.

Added the {PlusCode} and {GeoHash} tokens.


Added keyboard shortcut hooks for the Plugin Extras menu, on Windows.


Work around a Windows bug related to canceling out of the registration dialog.

Some of the filename-related tokens could be incorrect in rare situations.

Added some extra debug logging to note whether the plugin is enabled.


Updates for Lr9 (Lightroom Classic CC Version 9).


Added the LensInfo template token.

Updated the Exposure token to allow customization.

More token work: added {Urls}, and updated {ISO} and {Copyright} to allow customization.

Added the {RelativeFolder} token.


Fixed the SST1 and SST2 tokens.


Updated the PublishCollectionName token (and CollectionNames and CollectionFullNames) to remove the MIRROR: prefix from the name that mirrored collections within my Collection Publisher plugin automatically get.


Fixed a problem related to template tokens and photos without capture times.

Added functions uc(), ucFirst(), lc(), and lcFirst() to the LUA token.


Added the PEOPLE variable to the LUA token.

Fixed a problem with the SpeedKPH token.

Added TempC and TempF to the template tokens that my plugins understand.

Added the TempC and TempF tokens.

Updated the keyword-related tokens to accept standard filters.

Work around a bug that sometimes causes plugins to be disabled when starting Lightroom via clicking on a catalog file.

Fix an "Unknown key: captureTime" crash.

Added the GPSCoords token.


Updates for Lr8 (Lightroom Classic CC Version 8).

Added hierarchical options to the Keywords token.

Added the special PP() function to the {LUA} token.

Try to work around a Lightroom bug related to photo timezones and how Lightroom handles accessing plugin data.


Added the 'nicknames' modifier to the {People} token.

Added the SST1, SST2, and SS3 tokens to the template tokens that the plugin understands.


Try to avoid having unexpectedly-long error messages create too-big a dialog.


Allowed the custom commands (in File > Plugin Extras) to be configured to be invoked on all selected photos as a group, or individually one by one.

Fixed a bug when 'Token Examples' invoked in certain situations.

Clicking on the version number in the Plugin Manager now copies version info to the clipboard

Updated the PublishCollectionName token to allow numeric arguments along the lines of the CollectionName token.

Added the folowing template tokens: {home}, {desktop}, {temp}, {pictures}, {documents}

, {IptcDateTaken}

Added a bunch of token filters: F2D F2S F2X B2D B2S B2X S2X A2D A2S A2X

Added the 'PCH' variable to the {LUA} tag.


Updates to the data templates that my plugins understand: updated the Keywords token, added CollectionNames and CollectionFullNames tokens, and added a bunch of stuff (KWf, CN, CFN, CNf, CFNf) to the {LUA} token.


Fixed some stuff with the custom-command feature.


Oops, more Lr7 stuff.


Updates for Lightroom 7


Better handle some character-encoding issues related to template tokens.

Allow the "If Exists" feature of Templat Tokens to work with the PluginProperty token.

Update registration support to handle a stupid bug at PayPal that PayPal refuses to fix )-:


Fixed broken error reporting with the upon-completion command preparation execution.


Fixed a bug introduced in previous update.


Added support for generic template tokens in the after-export command, with per-photo tokens referring to the first photo successfully exported.


Fixed a bug introuded the other day in template tokens, related to Windows filenames.


Added the Newline template token.

Enhanced the FolderName token

Added the "only if it has a value" feature to template tokens.


An error message confusingly had the name of another plugin in it.


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: 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 67; see all), most recent last...

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 (10 years, 6 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 (9 years, 6 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 (8 years, 6 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 (8 years, 6 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 (8 years, 3 months 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 (8 years, 1 month 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 (8 years 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 (8 years ago) comment permalink

Can I use this plugin to add a logo to a jpg picture and then save or overwrite the existing picture? If possible, How do I do it?


This plugin can execute an external command, so you’d need an external command that does your logo thing (or perhaps a Photoshop “Droplet”, I think it’s called). As for overlaying a logo, you might consider the Lr/Mogrify plugin —Jeffrey

— comment by Manny on May 5th, 2017 at 5:11am JST (7 years, 2 months ago) comment permalink


This plugin seems to be exactly what I need, but before I get lost trying to figure out HOW to do this, I’m wondering if you could tell me whether or not it’s even possible.

I publish photos to my WordPress website using WP/LR sync. This allows for the standard Lightroom publish settings such as image size and quality, but what I am really missing is some way to compress them appropriately for web, using a service such as jpegmini or some other… to be determined.

Will this plugin allow me to click publish on the WP/LR sync plugin, have this plugin intercept the created jpg, compress it, then continue the upload to my site?

Hopefully I haven’t misunderstood what your plugin is capable of…. thanks in advance!


Yes, but if you have jpegmini, you can just use their Lightroom plugin directly. In any case, you can use this plugin to do whatever you want to the image file…. so long as the file ends up in the same place when you’re done, you can do whatever you like to it. —Jeffrey

— comment by Joe on July 2nd, 2017 at 7:57pm JST (7 years ago) comment permalink

Hello Jeffrey!

It seems there’s no notification via Run Any Command when a file is ‘deleted’ from a publish collection, which causes the file to be deleted from the publish destination. There’s not even a notification at the end of the publish operation. My usage (in conjunction with your Folder Publisher) is to trigger a program to update a web gallery database (Piwigo) with newly published images. That’s working fine, but it would be nice to also remove photos from the gallery using the same mechanism. Did I miss something? Or perhaps this is not supported by LR?! It’s not something that I plan on doing often. But it leaves an unsatisfying gap in my otherwise elegant gallery syncing process.

Thanks for the great plugins! 🙂
Ferg — from Bellevue, WA

That one bit that lacks elegance can be really painful, like a little pebble in your shoe. Sadly, Lightroom doesn’t provide for any way to call a plugin like this during deletion. I might be able to build something into Folder Publisher… let me add that to the todo list… —Jeffrey

— comment by Scott Ferguson on August 30th, 2017 at 2:41pm JST (6 years, 11 months ago) comment permalink

Hi again Jeffrey!

After aborting a publish operation I continue getting invocations from Run Any Command for files not actually published. In this case, three files are marked to be published: DSC05015.JPG, MAH02617.MP4 and DSC02612. I aborted the Publish operation immediately after starting it. NO files were actually ever copied to the final destination. My program received invocations for the two JPGs, but not for the MP4.

Sometime earlier, I had aborted a Publish with a large number of files yet unpublished. I can’t say how many of those received invocations, but it was also a large number.

It seems that this is not the desired behavior. Maybe a problem/limitation with LR? Also likely I can work around it easily enough. Haven’t tried yet.

Logs have been sent for Run Any Command and Folder Publisher as well.

Unfortunately, I don’t think there’s anything I can do here. Lightroom invokes the plugin when it’s got the rendered copy ready for export, so the plugin is just responding to that. You’d imagine that Lightroom would be checking whether the export is canceled at regular milestones, such as just before invoking a plugin, but from what you report it sounds as if they don’t. )-: I’m not sure what to do other than report it to Adobe. —Jeffrey

— comment by Scott Ferguson on September 4th, 2017 at 2:35pm JST (6 years, 10 months ago) comment permalink


I am wondering if you can help with if a concept is achievable using Run Any Command. I use a number of publish services (e.g. Envira, jfFacebook, jfFlickr, 500px, LR/Instagram) and I would like to be able to place a backup of the file(s) I am exporting into a local folder which is backed up to Google Sync and Backup.

At the moment I use the Run Any Command on a per image basis to create dropshadows for the images before they go through LR/Morgify 2, is there a way I can install another version of the plugin, or run a command so that at the very end, after dropshadow is created, the image is morgify’d and just before it is uploaded it is copied to the backup folder?

Using windows specifically, the reason I ask is that some plugins don’t specify the folder to store the image, others only specify a temp folder so I thought run any command might be a good way to do this?

Many thanks!

It’s built into Lightroom publishing services that you can put the exported copy wherever you like, and have it left there after the publish service is otherwise done with it. Publish services will default this to a temp folder that’s cleaned up when done, but they should let you set it as you like. (They can remove your ability to set it as you like, but they have to explicitly go to the trouble to do it; if one of your publish-service plugins is doing that, contact the author to ask whether they might not let you make your own decision.) —Jeffrey

— comment by Travis H on September 9th, 2017 at 2:16pm JST (6 years, 10 months ago) comment permalink

I just installed this to try to make animated GIFs as suggested above. When I ran Custom Command 1, I got this error:

Assert Failed run-any-command#93 U[1506302414]+5226.7:[x6080005612c8] @InitPlugin line 1044:
Assertion failed(!):
[x6080005612c8] @InitPlugin line 1044
[x6080005612c8] @CustomCommand line 146
[x6080005612c8] @Trap line 222

Followed by another dialog with “Assert @Debug:880”.

The command I was trying was:
convert -loop 0 -delay 50 {FILES} -set filename:f “output_%t” “{desktop}/animated/%[filename:f].gif”

But it seems to happen even with simpler commands.

From Berkeley, CA.

It’s hard to guess without the plugin log… please make sure you’re using the most recent version of the plugin, then if you encounter the error again, please send a log. Thanks. —Jeffrey

— comment by David Glasser on September 25th, 2017 at 10:21am JST (6 years, 10 months ago) comment permalink

How can I batch rename all assets in LR based on a certain string scheme AND most importantly the UUID of each LR asset?

Lightroom doesn’t allow for a plugin to rename items, so any solution will involve something outside of Lightroom. You can make a list of file/UUID pairs via my Data Explorer plugin. When you enable the “collect per-image data for spreadsheet export” and then export that data, Lightroom’s UUID of the photo is included in the spreadsheet. —Jeffrey

— comment by Matt on October 1st, 2017 at 2:28am JST (6 years, 10 months ago) comment permalink

Thank you, Jeffrey. I was not aware of this restriction. Alternatively, is there a way to put the UUID in one of the iptc or exif meta fields? how long would that take for a library of about 600,000 pictures? Would the LR assets/pictures need to be ‘online’ (all external drives attached) for this to work? Also – on export – would it be possible to rename the files to something like FirstName_LastName_UUID?

You can fill in a standard field with the UUID via my bag-o-goodies plugin. No idea how long it might take for 600,000 photos, but I imagine a while. It’s a database-only operation, so image files don’t need to be online. As for naming files on export, it’s trivial if you’ve stuffed the data info fields available to Lightroom filename templates. You might stuff “FirstName_LastName_UUID” into, for example, the Caption field, and use a filename template that refers to the caption. Also, some of my plugins (such as Collection Publisher) have enhanced-renaming support. —Jeffrey

— comment by Matt on October 2nd, 2017 at 4:19am JST (6 years, 10 months ago) comment permalink

One last thing: Is there anything we can do about syncing LR with a PHP web gallery? Similar to LR’s flickr plugin. (Syncing image edits, meta data edits and order of images in the online gallery)?

This kind of thing can certainly be built, either with a normal plugin or with a Web-Module plugin, and I know such things have been done for various web-gallery platforms, but I don’t know anything specific about “PHP web gallery”. —Jeffrey

— comment by Matt on October 2nd, 2017 at 4:21am JST (6 years, 10 months ago) comment permalink

howdy. After years of getting “the droplet couldn’t communicate with photoshop” found your plugin.
I have got it to work running with each image, but it produces an error: ‘the command attempted by the “run any command” filter failed’. Then lists the command path and file path (correctly). (But the next bit – path sent to OS has a 1 appended and another path at the end that I dont understand).

This is my command per image:
“C:\Users\me\AppData\Roaming\Adobe\Lightroom\Export Actions\3-2013 REAL STYLE other agents with blur group.exe” “{FILE}”

Its working – the image is exported and the action applied. I just get the error at the end.
also how would I get the droplet to run on all the images after export? Do I use {manifest} or {FILES}??

About the error you’re seeing, please send a log the next time you encounter it. As for how to run just once after the export, on all the exported files, that depends on how your target command works. If your exe command can be given a bunch of files on the command line and then do the right thing, you’d want {FILES}. —Jeffrey

— comment by Gethin Coles on December 11th, 2017 at 8:07pm JST (6 years, 7 months ago) comment permalink

Can I use this plugin to add a attribute/rating/colour to the files as they are exported or after export?
Regards Ian

This plugin allows you to set those things during export (set them for the Lightroom photo, not the exported copy). —Jeffrey

— comment by Ian Stuart on April 30th, 2018 at 11:42am JST (6 years, 3 months ago) comment permalink

Hello! I was referred to the “Run Any Command” plugin as a way to get around the Lightroom to Photoshop Droplet error of “droplet couldn’t communicate with Photoshop”. I can run a droplet with a handful of images, when I export a larger batch (20+ it begins to error out)… I’m told it’s something to do with the limit of characters being passed (too many) with it being a limitation of Windows. I am wanting to export via a droplet (in PS run some plugins & save) and after it saves, I need it to stack with the original image in Lightroom. What do I need to change so that I stop getting this error? Thanks for your time! ~Cathy

I’m afraid that I can’t offer any help… I don’t really know anything about “droplets” nor how they communicate with Photoshop. Just guessing from what you’ve described, though, I wonder whether it’s not a problem of asynchronicity, that is, running more than one at a time. Perhaps they have to be synchronous, but aren’t? —Jeffrey

— comment by Cathy on June 3rd, 2018 at 5:20am JST (6 years, 2 months ago) comment permalink

Hi Jeffrey,

is this plugin somehow usable for initiating a second export?

The use-case is that I need to deliver two different resolutions of the same photo, and I am executing two different exports with two different presets which is very cumbersome.

Thanks B

Yes, it’s cumbersome, and if there were an easy way around it, believe me, I’d have implemented it. I export two versions of every photo I put on my blog, and indeed have to launch two exports from two different presets. It’s a pain. )-: —Jeffrey

— comment by Bence on October 4th, 2018 at 5:50am JST (5 years, 10 months ago) comment permalink

Hi Jeffrey,

I’m trying to export images to a folder named after the `Title` metadata tag. I used mkdir ‘{Title}’ but I get a `permission denied` error. I’ve tried the same command in terminal and it worked fine in the same folder as the export.

Exemple of what I’m trying to achieve:

Images 1 to image 10 have title tag: 101-345
Images 11 to image 15 have title tag: 101-346
Images 16 to image 29 have title tag: 101-350

Result would be:

Folder name: 101-345
Content: images 1-10

Folder name: 101-346
Content: images 11-15

Folder name: 101-350
Content: images 16-29


The command is not run from within the folder of the export… it’s run, I suppose, from your home directory (but even that you shouldn’t count on). You probably want to use a fully-qualified path, such as with {folder}. —Jeffrey

— comment by Fabrice on October 29th, 2018 at 11:05am JST (5 years, 9 months ago) comment permalink

{GPSCoordinates} outputs a string containing single and doublequotes which are super hard to escape
8°50’57.76″ S 115°9’42.509″ E
It was impossible to pass these values to exiftool directly, had to clean them up and reformat in a separate batch.
It would be super awesome if the plugin would split up this value beforehand and substitute ° and ‘ by space and delete ”
{GPSLatitude} = 8 50 57.76 S
{GPSLongitude} = 115 9 42.509 E

in this format it can be passed to exiftool directly -exif:gpslatitude=”42 30 0.00 S”

The tokens {Latitude} and {Longitude} give simple floating-point values, which ExifTool accepts. —Jeffrey

— comment by Ostap on March 13th, 2019 at 10:40pm JST (5 years, 4 months ago) comment permalink

Is there any way to set up a command for exporting in a master folder (e.g. /myphoto) and move the exported photo in a sub-folder named after the catalog name (eg: /myphoto/my_catalog_name/ ) ?
I use several LR catalogues and i don’t feel like changing the destination folder any time i switch to a different catalogue. Many thanks in advance and congratulations for excellent work

You can’t move the photo because Lightroom will think the plugin somehow broke the export, but you can have this plugin copy to where you want, e.g. on MacOS, with a command like:

mkdir "/myphoto/{CatalogName}";  cp "{FILE}"  "/myphoto/{CatalogName}/"


— comment by Andrea on July 21st, 2019 at 2:41am JST (5 years ago) comment permalink

Hi Jeffrey
Suddenly my export preset that runs a droplet is returning “droplet couldn’t communicate with photoshop”. The path is long: :\VIDEO \STOCK\Urunga\hungry head from august 2019 onwards\hungry head long lens stills\RAW\Processed
Last night windows 10 updated to 1903. I’m running the latest PR version of LR.
The path to the plugin is also quite long.
Have you had any other reports of 1903 breaking things?

I’ve not heard anything about Windows updates breaking droplets, but then I wouldn’t normally hear about such things. Can you run the droplet directly, outside Lightroom? —Jeffrey

— comment by Gethin Coles on August 2nd, 2019 at 7:56pm JST (5 years ago) comment permalink


Is it possible to automatically export photos – simply put I want a smart collection to automatically or every “x” minutes export a jpeg to a specific folder -?

If not, I am attempting through “Run Any Command” so that upon publishing of a “Pixieset” set/collection another Pixieset smart set/collection publishes. The pulldown “Publish this Collection” under “Command to execute upon Completion” only shows you collections from other Publish Services. I created a duplicate publish service of my Pixieset and they appear on the dropdown now, but when I set it up and Publish, it simply Publishes the 1st set, no the automatic.

The scenario is this: I send all photos to clients through pixieset – I create a set/collection in LR then export. While editing I want to mark photos with a Color Label and have a Smart Collection created. When I export my clients set/collection, I want the color marked Smart Collection to publish automatically?


I just added the “Publish Continuously” feature to my Bag-o-Goodies plugin, so if you get your photos into a Publish Service (e.g. with my Collection Publisher plugin or my Folder Publisher plugin, it should do what you want. —Jeffrey

— comment by Matthew Davis on February 1st, 2020 at 7:32am JST (4 years, 6 months ago) comment permalink


I am now using the Plugin Extras custom commands to do scripted manipulations on selected images in my LR catalog. Everything works great, this is just a request for a couple of minor enhancements:

Allow to give a name to each custom command. If I’ve been away from the commands for a while, I forget which command executes which script. I then have to go into Configure and check the script name just to be sure. It would be great to be able to assign a friendly command name in the menu.
Similarly, the Run-Any-Command extras are at the bottom of my very long extras menu. Is there any way to assign a hot key so that I can easily invoke the command of choice without error? If not, then if I can customize the command name, I can type the first letter of the command to move the menu selection to it. Right now I have a lot of Extras menu items that begin with ‘C’.


— comment by David Zeleznik on April 18th, 2020 at 1:20am JST (4 years, 3 months ago) comment permalink

When ever I run this plugin using “Export Batch” I get the following error.
LrCollection:addToCollection: must be called from within a withWriteAccessDo block
In this case I have each export add the images to a collection, and I find when I run them as a batch I get this error and then some of the image are not added to one or more collections.

This is likely a bug on my part… could you send a plugin log next time you encounter it? Thanks. —Jeffrey

— comment by Richard Bowden on November 15th, 2020 at 9:09pm JST (3 years, 8 months ago) comment permalink


I’m trying to use ‘run-any-command’ to fetch my raw files from a version control system when I need to edit them. I can’t keep all the raw files on my working system due to space requirements, but they are added to a version control system on import. Normally I’ll do any editing and exporting immediately after import, then remove the local copy. But sometimes I need to return to a file later for more work, so I have to fetch it from the version control system. I’ve tried using the following command:

p4 sync {FILE}
p4 sync {FolderPath}

but I get the following error:
“Aborting custom command # 1: the master image file ^[^1^] is not present. C:\path\to\file.cr2”
Since the goal is to retrieve a not-present file, is there any way to solve this?

I’m running plugin version 20210721.117 in LR 4.4


The Run-any-Command plugin is invoked after an export has completed, so it doesn’t seem to be the appropriate tool for what you need. Perhaps John Beardsworth’s “Open Directly” plugin would be better? (I do see that I screwed up the presentation of the error message; FWIW, I’ve pushed out a new version of the plugin that fixes that.) —Jeffrey

— comment by Bob Craig on October 28th, 2021 at 4:13pm JST (2 years, 9 months ago) comment permalink

Hi Jeffrey,

just switched from Lightroom 6 to Lightroom Classic and performed a plugin update to current version of run-any-command for Lightroom Classic. Sadly, I cannot add the plugin via plugin manager as Lightroom reports an error while loading the newly added plugin.

Any hint?
I don’t want to miss this great plugin.

Best regards

It’s difficult to guess what the problem might be (“an error” doesn’t tell much), but perhaps it was a problem with the self upgrade attempt. Perhaps delete the copies you might have on your system, and download a fresh copy for a manual install? —Jeffrey

— comment by Markus on December 31st, 2021 at 7:50pm JST (2 years, 7 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.

IMPORTANT:I'm mostly retired, so I don't check comments often anymore, sorry.

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

Subscribe without commenting