| Issue Number | 4333 |
|---|---|
| Summary | Invoke python scripts by explicitly naming the interpreter (file associations) |
| Created | 2017-11-03 07:13:39 |
| Issue Type | Bug |
| Submitted By | Kline, Bob (NIH/NCI) [C] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2018-02-28 10:16:24 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/ocecdr/issue.216458 |
The Windows file type association for Python scripts is broken on some of the CDR server (certainly on DEV and PROD, probably on STAGE, but not on QA). We don't know how this happened, or how to correct it, or how to prevent it from happening. The result is that it no longer works to launch a process by telling Windows to run Python script by name. We must tell Windows to run the Python interpreter, passing the name of the Python script as the first non-option argument. This is how most of our software launches Python scripts, but there are a handful of cases in which we rely on the (now broken) Windows file association mechanism. For example, running the PubEmail.py script from tasks/publishing_task.py without directly running the Python interpreter broke scheduled publishing on the production server (and DEV) this week. We need to find and modify all such places. In the long run, we need to abandon use of ActiveState's Python distribution, as the standard python.org's distribution does not appear to share this problem.
https://github.com/NCIOCPL/cdr-scheduler/commit/525fd30e5d07c8068fa7adf34db473083ccfd7d6
(installed on PROD 2017-11-02)
I've updated the script
cdrpub.py
and created a new branch in the repo cdr-lib:
https://github.com/NCIOCPL/cdr-lib/commit/21d9f9b
I've updated the following script
uploade-zip-code-file.py
and created a new branch in the repo cdr-admin:
https://github.com/NCIOCPL/cdr-admin/commit/67afa8b2
(installed on PROD 2017-12-01)
I've updated the following script
ReverifyJob.py
and saved it to the branch hotfix-python in the repo
cdr-admin:
https://github.com/NCIOCPL/cdr-admin/commit/adb63411
(installed on PROD 2017-12-01)
~bkline, there were 3 scripts using subprocess that needed to be modified:
FIXED ./lib/Python/cdr.py
ALREADY MODIFIED ./tools/Build/install-docset.py
ALREADY MODIFIED ./tools/DevTools/Utilities/register-typelibs.py
The two scripts in the tools directory were already modified
in Fermi but not using the cdr.PYTHON variable. I left
those as is for now. The cdr.py has bee modified in
[hotfix-python 95cdb12]
https://github.com/NCIOCPL/cdr-lib/commit/95cdb12
Looks like changes to cdr.py on DEV may have introduced new problems. If you insert cdr.PYTHON at the front of every command that's got .py in it you'll end up with
python trying to run python.exe as if it's a script (for commands that already have the interpreter explicitly invoked); and
problems with commands like "run.cdr.pyrotechics.bat"
We may want to make sure ".py" is at the end of the command (or at least is followed by whitespace), and check to see if "python" appears in the command already. Or perhaps tackle the problem in the code that invokes cdr.runCommand.
I see. I thought I was doing just that. My changes worked for my tests but it's never that simple, especially at 6pm on Friday. :-(
I've made these changes on DEV but I'm requiring for the interpreter to be specified as python.exe and not just python. This would require at least one other program to be modified. If I remember correctly it's publishing-task.py.
I verified the correspondence mailers. I also ran a summary mailer for the Advisory Board and it appears to have completed successfully, but I don't remember how to view it. I will ask Bonnie to check it on her computer as well since she runs summary mailers regularly and this isn't something I do.
Bonnie tried running a summary mailer on DEV and was unable to view or print it. Here's what she said:'
"Well I’m not having any luck. I keep getting the message below in the command prompt window when I try to view or run it.
C:\windows\System32>runprintjob 16114
'runprintjob' is not recognized as an internal or external
command,
operable program or batch file."
I'm surprised about the job-id 16114 which is not a job that ran on DEV and I'm surprised about the "missing" program or batch file. I think I will have to visit Bonnie on Monday.
I checked with Bonnie regarding the problems printing. She opened a command prompt window pointing to her
C:\cdr\EBMS\bindirectory.
I created a shortcut for her that opens a command prompt in the correct directory and allows her to download and print the mailers. Everything worked as expected.
Can this ticket be closed? I'm a little puzzled by the status, which doesn't seem to have made it to the "In Progress" stage.
Never got a response to my last comment, so I'm closing this ticket.
The reason you didn't get a response is that I wasn't able to give you an answer right away and needed a little more time to look into the issue.
There were some programs we had modified and hot-fixed but not all of them. However, the problem got resolved at the system level. I still have a few local hotfix-python branches and I wasn't clear if we still wanted to go ahead and implement the changes regardless of the system-level fix.
If we're running into this Python file association problem again we'll just open a new ticket to fix it.
Elapsed: 0:00:00.001308