Sublime Forum

subprocess.Popen in plugin not working as expected in linux

#1

Hi ST experts,
I am working on a plugin for version control and everything works as expected in windows. Its a different story on linux (ubuntu 14.04), I see that if start sublime from terminal, my plugin works as expected, however when I launch Sublime from desktop shortcut, popen command does not return the expected command. What am I missing? What is difference b/w launching sublime from terminal vs launching from shortcut?

p = subprocess.Popen(command, stdout=subprocess.PIPE, stderr=subprocess.PIPE, cwd=global_folder, shell=True)
    result, err = p.communicate()

I have tried command = ["p4", "info"] and command = "p4 info", both don’t work when sublime has been launched from desktop shortcut. Both these work when I have started sublime from a terminal window.

Thanks for your time and I hope someone has seen this before and/or point me in the right direction.

0 Likes

#2

Sublime Text doesn’t inherit any shell variables on POSIX systems if you don’t start it from the terminal, I am guessing the p4 application is not in your /usr/bin or /usr/local/bin paths, try to start ST from the command line, if you have the path to p4 in your $PATH it will work.

Edit: you can also use the full route to the app as first element of the command list

0 Likes

#3

If you open Default/exec.py with the PackageResourceViewer plugin, you can see that sublime handles this as follows:

# <snip> ...
        elif shell_cmd and sys.platform == "linux":
            # Explicitly use /bin/bash on Linux, to keep Linux and OSX as
            # similar as possible. A login shell is explicitly not used for
            # linux, as it's not required
            self.proc = subprocess.Popen(
                ["/bin/bash", "-c", shell_cmd],
                stdout=subprocess.PIPE,
                stderr=subprocess.PIPE,
                stdin=subprocess.PIPE,
                startupinfo=startupinfo,
                env=proc_env,
                shell=False)
# <snip> ...

As you can see it wraps the call in a bash shell. Maybe you could try that?

2 Likes