• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

LrTasks.execute return code 65280?

New Here ,
Nov 19, 2018 Nov 19, 2018

Copy link to clipboard

Copied

Hi,

I have an issue with a Lightroom plugin that uses a command line tool to communicate with another application, on MacOS. The Lua code in the plugin calls on to the command line tool with a call to LrTasks.execute. This works perfectly fine with all tests, and has been working nicely for quite some time now, with various users not reporting any issues. Except for one user now, where the command line can't be launched.

If I launch the command line tool manually, everything works nicely. But when launched from the plugin, after enabling some logging in the plugin, I can see that I get a return code of '65280', and not much more. The system console log doesn't say much either, and nothing notable was appearing during the tests with this user.

This user is on MacOS 10.13.6, and has another computer where everything works fine. We tried disabling his antivirus, just in case, but that didn't do much. Apart from that, I couldn't see what would explain the difference between his two computers.

Are there any Lightroom logs somewhere that would give more info on what's happening behind the scenes?

Or would anyone know a bit more about what is causing this return code?

TOPICS
SDK

Views

1.2K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

LEGEND , Nov 19, 2018 Nov 19, 2018

Are you executing ssh / sftp or something that involves Perl?  Google shows a fair number of people asking about the error code being returned by Perl, on Unix-like systems and Windows.  And this article suggests that ssh / sftp on Mac can return that code: 520927 .

As for generic debugging tools for LrTasks.execute(), I've probably spent more time over the years debugging invocations of external programs and shell scripts than any other single aspect of the SDK.  The SDK environment is fragile,

...

Votes

Translate

Translate
LEGEND ,
Nov 19, 2018 Nov 19, 2018

Copy link to clipboard

Copied

Are you executing ssh / sftp or something that involves Perl?  Google shows a fair number of people asking about the error code being returned by Perl, on Unix-like systems and Windows.  And this article suggests that ssh / sftp on Mac can return that code: 520927 .

As for generic debugging tools for LrTasks.execute(), I've probably spent more time over the years debugging invocations of external programs and shell scripts than any other single aspect of the SDK.  The SDK environment is fragile, and of course, so many aspects of external programs are fragile (complicated syntax rules, buggy, undocumented, unpredictable, etc.), including the Mac and Windows shells used by execute() to execute the command lines.

Some issues to be aware of:

- The current directory execute() uses on Mac is "/", so be sure to test your command lines executing from there.

- Be sure to capture both standard output and standard error by using shell redirection.  There may be clues there.  I've included my Util.safeExecute() function below that does that.

- Beware of paths containing spaces, especially user names with spaces (yes, that can happen rarely on Mac).  Quote command line arguments early and often to try to stay out of quoting hell.

- Once or twice, I've encountered issues on Mac with paths containing multibyte UTF-8 characters (it's more of a nightmare on Windows). I can't remember the details offhand. So see if any of the paths involved contain multibyte UTF-8 characters on one machine but not the other.

- You can get stack traces from LR of every call to error(), which infrequently can be useful to gather clues: Lightroom -traceback debugging tip

--[[----------------------------------------------------------------------------

public int exitCode, string output, string errOutput

safeExecute (string commandLine [, boolean getOutput])

Executes the command line "commandLine" in the platform shell via

LrTasks.execute, working around a bug in execute() on Windows where quoted

program names aren't accepted.

If "getOutput" is true, "output" will contain standard out and standard

error and "errOutput" will be "".  If "getOutput" is "separate", then

"output" will contain standard out and "errOutput" will contain standard

error.  If "getOutput" is false, then both "output" and "errOutput" will be

"".

Returns in "exitCode" the exit code of the command line. If any errors

occur in safeExecute itself, "exitCode" will be -1, and "output" and

"errOutput" will be:

getOuptut == "separate": "", <error message>

otherwise:               <error message>, ""

------------------------------------------------------------------------------]]

function Util.safeExecute (commandLine, getOutput)

return Debug.callWithContext ("", function (context)

    local outFile, errFile

    context:addCleanupHandler (function ()

        if outFile then LrFileUtils.delete (outFile) end

        if errFile then LrFileUtils.delete (errFile) end

        end)

       

    if getOutput then

        local uuid = LrUUID.generateUUID ()

        outFile = child (getStandardFilePath ("temp"), uuid .. ".out")

        commandLine = commandLine .. ' > "' .. outFile .. '"'

        if getOutput == "separate" then

            errFile = child (getStandardFilePath ("temp"), uuid .. ".err")

            commandLine = commandLine .. ' 2>"' .. errFile .. '"'

        else

            commandLine = commandLine .. ' 2>&1'

            end

        end

    if WIN_ENV then commandLine = '"' .. commandLine .. '"' end

    local exitStatus = LrTasks.execute (commandLine)

    local output, errOutput, success = "", ""

    local function outputErr (file, output)

        local err = string.format ("Couldn't read output:\n%s\n%s",

            file, output)

        if getOutput == "separate" then

            return -1, "", err

        else

            return -1, err, ""

            end

        end

    if outFile then

        success, output = pcall (LrFileUtils.readFile, outFile)

        if not success then return outputErr (outFile, output) end

        end

    if errFile then

        success, errOutput = pcall (LrFileUtils.readFile, errFile)

        if not success then return outputErr (errFile, errOutput) end

        end

    return exitStatus, output, errOutput

    end) end

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Nov 20, 2018 Nov 20, 2018

Copy link to clipboard

Copied

Nope, the command line tool is not using Perl at all, nor is it using ssh/sftp. It's just a simple tool that uses XPC to communicate with another application. I had done the same search and came up with the exact same results around Perl, which led me to believe that maybe there was some Perl inside the SDK somehow, which seemed weird, since the plugins themselves are in Lua...

Anyhow, thanks a lot for all the tips and pointers for debugging this. I'll try and build a more verbose version of the plugin for the customer, so we can check if we can grab more info on that. I had noticed that he had a weird path to his user home, so there may be something there.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Nov 20, 2018 Nov 20, 2018

Copy link to clipboard

Copied

It's just a simple tool that uses XPC to communicate with another application.

That ssh article hints that perhaps there's a shared library that's missing on one of the computers.  On Mac, you can list the shared libraries to be loaded by an executable using "otool -L".

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Nov 29, 2018 Nov 29, 2018

Copy link to clipboard

Copied

Well, I finally pinpointed the issue, and it was a weird character indeed! Your code to get the stdout/stderr definitely helped, since the tool was properly started, but just returned its usage (I still don't know where the code 65280 from though..).

Turned out that a path to an image had a "$user" in it, which was not escaped and thus resolved to nothing, which in turn made the path wrong.

Thanks a lot for the tips!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Nov 29, 2018 Nov 29, 2018

Copy link to clipboard

Copied

LATEST

Glad you got it resolved.  Quoting hell indeed.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines