2

I have a simple Python GUI that gathers a list of image file locations, which is passes to subproccess.run, which targets the gimp-console exe in order to modify them. While working with a large number of files with reasonably long directories I found that Subprocess was no longer executing.

Reducing the number of files and changing the directory to the root drive were both individually-valid solutions, which indicates to me that the issue is with the length of the string being passed to Subprocess is the issue. After further testing using subprocess.list2cmdline I found that this number is somewhere between 1124 and 1159 characters (seemed like a small enough range that I didn't try to get a finer result).

While I can, obviously, program around this limitation, what is bothering me is that this number is very dissimilar to the limitations I've found in this post and another post here. As noted in the answer to the second post, shell is off by default for subprocess.run, which should give it a maximum of 32,768 (so close to 30 times what I'm getting), and just to make sure I wasn't going insane, I explicitly set shell to False (predictably, to no effect).

I did some searching around concerning GIMP specifically, but could not locate any relevant information.

So, per the title of the question: Why is the maximum commandline length I'm passing to subprocess so different from what I (presumably) should be expecting?

Since os may have something to do with it, I'm on Windows 10 64-bit. Also, while the code shouldn't be a problem since- as stated- it does run successfully with shorter calls, I'm including it for completeness sake:

##  multifiles is a comma-separated string of filelocations, which is parsed by the 
##  python-fu script
sub=subprocess.run(
            ['##System Path##\\gimp-console-2.8.exe',
             '-i', '-b',
             '(python-fu-al-multifile 1 "{multifiles}")'.format(multifiles=multifiles),
             '-b', '(gimp-quit 1)'],
            stderr=subprocess.PIPE,check=True,shell=False)

Edit: Not a duplicate of Python Script, args not transferred to Script, as the problem on that post was that args were being lost: compare- subprocess not executing to begin with due to length of args (i.e.- args are accepted and executed correctly provided the total length of the run command is under a certain threshold). The solution for that question was to change the python file extensions or append the run command: compare- this post runs a non-python executable.

Reid Ballard
  • 1,480
  • 14
  • 19
  • 1
    You can sidestep the issue by creating a temp file with the list of files to process and have your Gimp script read that file. Also, there is nothing that your GUI python does that couldn't be done in the Gimp python script, so if you get the files from some selection parameter (everything under some directory, for instance), then your Gimp script could receive the selection parameter and do the file search by itself. – xenoid Jul 14 '16 at 23:05
  • Possible duplicate of [Python Script, args not transferred to Script](https://stackoverflow.com/questions/7530303/python-script-args-not-transferred-to-script) – Paul Sweatte Aug 24 '17 at 02:03
  • If this still happens with GIMP 2.10, it might be a good idea to file this at https://gitlab.gnome.org/GNOME/gimp/issues if you want the GIMP developers to examine the issue. – Michael Schumacher Sep 24 '18 at 15:19

0 Answers0