I am in the process of testing an upgrade from a Zope 2.8.4 system to a Zope 2.9.1 system. The process I used: 1) Install 2.9.1 on a Win2003 system (it happens to be the same one that the 2.8.4 system is running but I changed the config so the ports don't conflict). The installation is successful 2) Copy the Product directory from my functioning 2.8.4 system instance to the 2.9.1 instance 3) copy the ZODB from the functioning 2.8.4 system to the 2.9.1 system All appears to go well -- the 2.9.1 system appears to be running everything from the 2.8.4 system correctly. A deeper check though shows that a few Python scripts in the ZODB (this in a system that has 20 or 30 scripts) fail. Examining the scripts indicates an error at line 3 -- but no such error can be found, however saving the script with no changes eliminates the error and also causes the script to now function. After finding and correcting these scripts everything seems to be working well. Any idea what happened during the upgrade to cause this strange behaviour and how can I avoid it? I will have to go through a similar upgrade at a customer's site and would like to avoid hand checking every script if I can avoid it.
Hi, On 3/8/06, Brian Sullivan <briansullivan@gmail.com> wrote:
I am in the process of testing an upgrade from a Zope 2.8.4 system to a Zope 2.9.1 system.
The process I used:
1) Install 2.9.1 on a Win2003 system (it happens to be the same one that the 2.8.4 system is running but I changed the config so the ports don't conflict). The installation is successful
2) Copy the Product directory from my functioning 2.8.4 system instance to the 2.9.1 instance
3) copy the ZODB from the functioning 2.8.4 system to the 2.9.1 system
All appears to go well -- the 2.9.1 system appears to be running everything from the 2.8.4 system correctly. A deeper check though shows that a few Python scripts in the ZODB (this in a system that has 20 or 30 scripts) fail. Examining the scripts indicates an error at line 3 -- but no such error can be found, however saving the script with no changes eliminates the error and also causes the script to now function.
After finding and correcting these scripts everything seems to be working well.
Any idea what happened during the upgrade to cause this strange behaviour and how can I avoid it?
I will have to go through a similar upgrade at a customer's site and would like to avoid hand checking every script if I can avoid it.
I had the same problem : Windows CR/LF line endings are not supported anymore for PythonScripts. According to Dieter Maurer, it has to do with Python 2.4 rather than Zope 2.9. Regards, Patrick.
On 3/8/06, Patrick Decat <pdecat@gmail.com> wrote:
Hi,
On 3/8/06, Brian Sullivan <briansullivan@gmail.com> wrote:
I am in the process of testing an upgrade from a Zope 2.8.4 system to a Zope 2.9.1 system.
The process I used:
1) Install 2.9.1 on a Win2003 system (it happens to be the same one that the 2.8.4 system is running but I changed the config so the ports don't conflict). The installation is successful
2) Copy the Product directory from my functioning 2.8.4 system instance to the 2.9.1 instance
3) copy the ZODB from the functioning 2.8.4 system to the 2.9.1 system
All appears to go well -- the 2.9.1 system appears to be running everything from the 2.8.4 system correctly. A deeper check though shows that a few Python scripts in the ZODB (this in a system that has 20 or 30 scripts) fail. Examining the scripts indicates an error at line 3 -- but no such error can be found, however saving the script with no changes eliminates the error and also causes the script to now function.
After finding and correcting these scripts everything seems to be working well.
Any idea what happened during the upgrade to cause this strange behaviour and how can I avoid it?
I will have to go through a similar upgrade at a customer's site and would like to avoid hand checking every script if I can avoid it.
I had the same problem : Windows CR/LF line endings are not supported anymore for PythonScripts. According to Dieter Maurer, it has to do with Python 2.4 rather than Zope 2.9.
OK -- sounds like a plausible explanation. Any idea how to predict when this is going to be a problem?
Patrick Decat wrote:
I had the same problem : Windows CR/LF line endings are not supported anymore for PythonScripts. According to Dieter Maurer, it has to do with Python 2.4 rather than Zope 2.9.
Really? I find that pretty suprising. Python has never cared about line endings before and I'd be pretty mortified if it started now :-( Dieter? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2006-3-9 08:10 +0000:
... Really? I find that pretty suprising. Python has never cared about line endings before and I'd be pretty mortified if it started now :-(
Dieter?
It does now -- at least for "FSPythonScripts" when you are on a *nix platform and your files contain DOS lineends. You then will get (starting with Python 2.4) SyntaxErrors at line ends. Of course, things are different when you are on a Windows platform and your files contain DOS lineends... -- Dieter
On 3/9/06, Dieter Maurer <dieter@handshake.de> wrote:
Chris Withers wrote at 2006-3-9 08:10 +0000:
... Really? I find that pretty suprising. Python has never cared about line endings before and I'd be pretty mortified if it started now :-(
Dieter?
It does now -- at least for "FSPythonScripts" when you are on a *nix platform and your files contain DOS lineends.
You then will get (starting with Python 2.4) SyntaxErrors at line ends.
Of course, things are different when you are on a Windows platform and your files contain DOS lineends...
Different in what way? I was experiencing difficulty on a Windows platform. The scripts in question have never seen anything other than Windows. Are you indicating that the line end issue is not what I was experiencing?
Brian Sullivan wrote at 2006-3-9 14:23 -0500:
On 3/9/06, Dieter Maurer <dieter@handshake.de> wrote: ...
It does now -- at least for "FSPythonScripts" when you are on a *nix platform and your files contain DOS lineends.
You then will get (starting with Python 2.4) SyntaxErrors at line ends.
Of course, things are different when you are on a Windows platform and your files contain DOS lineends...
Different in what way?
On Windows, FSPythonScripts may use DOS lineends.
I was experiencing difficulty on a Windows platform. The scripts in question have never seen anything other than Windows.
Are you indicating that the line end issue is not what I was experiencing?
Indeed, it looks this way. However, there is another caveat: Sometimes files with DOS lineends end up in CVS (maybe SVN) (in your own that of the developpers). When they are extracted from Windows, then the DOS lineend "\r\n" can become "\r\r\n" and that Python does not like even under Windows. You can easily find out whether you have a lineend problem by examining your files with a binary viewer (do not know what such a binary viewer is under Windows -- under *nix, "od" is one). -- Dieter
Dieter Maurer wrote:
It does now -- at least for "FSPythonScripts" when you are on a *nix platform and your files contain DOS lineends.
Does this only affect (FS)PythonScripts or all disk based python code? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Dieter Maurer wrote:
It does now -- at least for "FSPythonScripts" when you are on a *nix platform and your files contain DOS lineends.
Does this only affect (FS)PythonScripts or all disk based python code?
There has been a bug in Zope since ages, where multiline python in tal fails if it has Window line endings. Eg. this will fail with windows line endings: <div tal:content="content python:' '.join(['oh', 'bugger'])"> This does not have multiline Python in the tal expression and will not fail: <div tal:attributes="title string:a title; id python: '42';"> I have no idea if it is a manifestation of the same problem. Since no one with the knowledge of the ZPT is willing to fix it, I did it for myself by setting up my svn rules to linux line endings ... But it is clearly an annoying bug. Imagine if plain Python worked that way :-( -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science Phone: +45 66 11 84 94 Mobile: +45 29 93 42 96
On 3/10/06, Max M <maxm@mxm.dk> wrote:
There has been a bug in Zope since ages, where multiline python in tal fails if it has Window line endings.
Eg. this will fail with windows line endings:
<div tal:content="content python:' '.join(['oh', 'bugger'])">
Hmm; I'll investigate if I can reproduce this and see if the same fix (universal line endings) will solve this too. I strongly suspect the fix will be just as easy (line 81 of FSPageTemplate.py, add a 'U' to the file opening flags). The harder bit is the tests.. -- Martijn Pieters
On 3/10/06, Martijn Pieters <mj@zopatista.com> wrote:
Hmm; I'll investigate if I can reproduce this and see if the same fix (universal line endings) will solve this too. I strongly suspect the fix will be just as easy (line 81 of FSPageTemplate.py, add a 'U' to the file opening flags). The harder bit is the tests..
I checked in a testcase and a fix on the CMF Trunk, and will merge it to the 1.5 and 1.6 branches after lunch. Indeed, universal line endings solve the problem here too. -- Martijn Pieters
Chris Withers wrote at 2006-3-10 08:17 +0000:
Dieter Maurer wrote:
It does now -- at least for "FSPythonScripts" when you are on a *nix platform and your files contain DOS lineends.
Does this only affect (FS)PythonScripts or all disk based python code?
I do not know. Try it out... -- Dieter
participants (6)
-
Brian Sullivan -
Chris Withers -
Dieter Maurer -
Martijn Pieters -
Max M -
Patrick Decat