Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jobEnvironment dropping content after = in value #33

Open
cancan101 opened this issue Jul 22, 2015 · 6 comments
Open

jobEnvironment dropping content after = in value #33

cancan101 opened this issue Jul 22, 2015 · 6 comments

Comments

@cancan101
Copy link

I am running this script:

   with drmaa.Session() as s:
       jt = s.createJobTemplate()
       jt.remoteCommand = "python"
       jt.args = ['env.py']
       jt.jobEnvironment = {'ALEX':'alex=2'}
       jt.joinFiles=True
       jobid = s.runJob(jt)
       s.deleteJobTemplate(jt)

with this script env.py:

import os
print os.environ

When I look at my environment, I see:

'ALEX': 'alex', 
@cancan101
Copy link
Author

For reference, this works fine: $ qsub -v ALEX=alex=2 -b y -j y python env.py.

@dan-blanchard
Copy link
Contributor

That's very strange. From looking at where we handle setting DictAttribute values, I don't see anything that jumps out as wrong.

Could you try changing {'ALEX': 'alex=2'} to {'ALEX': '"alex=2"'} (with extra inner double-quotes around the value)? I'm wondering if the DRMAA C implementation you're using is doing something stupid on its end.

@cancan101
Copy link
Author

I believe I was able to get this bug reproduced using your travis setup:
c8a9c5e
results: https://travis-ci.org/cancan101/drmaa-python/jobs/72308774

@cancan101
Copy link
Author

Wrapping with " still leads to the same truncation after the =: '"alex

@nicoulaj
Copy link

FYI, this bug is in the C implementation of DRMAA, see http://gridengine.org/pipermail/users/2016-April/009042.html

@jakirkham
Copy link
Contributor

It's worth noting that users may be able to hack around this by using nativeSpecification. In any event, this is an issue with the particular DRMAA implementation itself and not drmaa-python. As such, this probably should be closed. Possibly could add a note in the docs about this issue and the (proposed) workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants