Exported upstart configuration silently fails with quoted variables

[migurski]

At or near d8be8f4a8 (version 0.5.0), quoted variables in exported upstart scripts became invalid and fail silently. Previously, quoted .env variables with spaces generated upstart configurations with correctly-nested double and single quotes. This is an example generated by 84a1f7d (also version 0.5.0):

VAR="foo bar"

start on starting things-stuff
stop on stopping things-stuff
respawn

exec su - migurski -s /bin/sh -c 'cd /home/migurski/things; export PORT=5000; export VAR="foo bar"; python stuff.py >> /var/log/things/stuff-1.log 2>&1'

Starting at d8be8f4a8 and still in 0.6.6, the exported configuration from the configuration above began producing this invalid and failing upstart configuration, due to the single quotes:

start on starting things-stuff
stop on stopping things-stuff
respawn

exec su - migurski -s /bin/sh -c 'cd /home/migurski/things;export VAR='foo bar';export PORT=5000;python stuff.py >> /var/log/things/stuff-1.log 2>&1'

Here are my Procfile and python script for testing:

stuff: python stuff.py

from sys import stderr
from os import environ
from time import sleep

while True:
    print >> stderr, repr(environ['VAR'])
    sleep(5)

[migurski]

I’m tracking the issue down to process.conf where shellquote is used. By default it uses single quotes. Overall it seems necessary to wrap the entirety of the argument to exec in quotes as well using Jinja block assignments, which are new in version 2.8.

[slafs]

Hey! Thanks for the report. Yeah... this seems like an edge case and a regression from v0.5.0. Could you contribute a test case for this issue? We should probably replicate quote function to use " in this case. Or maybe @msabramo has a better idea?

[migurski]

I will contribute a test!

[migurski]

:point_up: poke