# libpcre version requirements - Thread: https://externals.io/message/87706 - Original archive: https://news-web.php.net/php.internals/87706 - Started by Christoph Becker on 2015-08-11T16:46:23+00:00 - Messages: 19 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #87706 — Christoph Becker — 2015-08-11T16:46:23+00:00 URL: https://externals.io/message/87706#87706 Hi all! What is the minimum libpcre version that is supported as external libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6 (2006-02-06), but is this still valid and do we really have to support such old versions? I'm asking because of bug #70232 which can easily be fixed, but that requires PCRE 8.00 (2009-10-19). If we have to support older PCRE versions, we'd probably need a fallback to the current behavior (which would obviously keep the bug). -- Christoph M. Becker --- ## #87707 — Adam Harvey — 2015-08-11T17:01:06+00:00 URL: https://externals.io/message/87706#87707 · In reply to: #87706 > What is the minimum libpcre version that is supported as external > libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6 > (2006-02-06), but is this still valid and do we really have to support > such old versions? CentOS/RHEL 5 provides libpcre 6.6, which is probably where that specific minimum version comes from. Someone out there is probably still building packages that rely on this. > I'm asking because of bug #70232 which can easily be fixed, but that > requires PCRE 8.00 (2009-10-19). If we have to support older PCRE > versions, we'd probably need a fallback to the current behavior (which > would obviously keep the bug). I guess the question's really whether we should still support an _external_ libpcre that old, since we bundle much newer versions. I think the argument against changing it has always been that it works and we didn't need anything newer, but if we have a reason now then that doesn't really hold. One problem is that I don't think we can really change the minimum requirement on a stable branch, so for 5.5 and 5.6 we're going to have to implement something that works with older versions regardless, but I'd be for bumping the minimum version requirement for 7.0 if it makes the code cleaner (on that branch, at least) moving forward. Adam --- ## #87710 — Christoph Becker — 2015-08-11T17:55:55+00:00 URL: https://externals.io/message/87706#87710 · In reply to: #87707 > > > […] > > CentOS/RHEL 5 provides libpcre 6.6, which is probably where that > specific minimum version comes from. Someone out there is probably > still building packages that rely on this. FWIW, this PCRE 6.6 requirement has been introduced with commit 1ad21d9b in May 2006, thus before CentOS/RHEL 5.0 had been released. It seems to me that nobody simply touched this requirement since then. Actually some features already require more recent libpcre, for instance, the \K modifier requires PCRE 7.2. > > […] > > I guess the question's really whether we should still support an > _external_ libpcre that old, since we bundle much newer versions. I > think the argument against changing it has always been that it works > and we didn't need anything newer, but if we have a reason now then > that doesn't really hold. > > One problem is that I don't think we can really change the minimum > requirement on a stable branch, so for 5.5 and 5.6 we're going to have > to implement something that works with older versions regardless, but > I'd be for bumping the minimum version requirement for 7.0 if it makes > the code cleaner (on that branch, at least) moving forward. I don't know if we can implement a fully working fallback for PCRE < 8 in a viable way. Actually, PCRE_NOTEMPTY_ATSTART had been added to libpcre to solve the issue with \K for /g[1]. Note the wording of the commit message: | Added PCRE_NOTEMPTY_ATSTART in order to be able to correctly | implement the /g option in pcretest when the pattern contains \K, | [...] My best idea so far is to use PCRE_NOTEMPTY_ATSTART and to fallback to PCRE_NOTEMPTY, if the former is not available. Of course the bug would persist for old libpcre, but \K will not be effective for PCRE 6.6 anyway. [1] -- Christoph M. Becker --- ## #87715 — Yasuo Ohgaki — 2015-08-11T19:59:45+00:00 URL: https://externals.io/message/87706#87715 · In reply to: #87710 Hi all, > > […] > > I don't know if we can implement a fully working fallback for PCRE < 8 > in a viable way. Actually, PCRE_NOTEMPTY_ATSTART had been added to > libpcre to solve the issue with \K for /g[1]. Note the wording of the > commit message: > > | Added PCRE_NOTEMPTY_ATSTART in order to be able to correctly > | implement the /g option in pcretest when the pattern contains \K, > | [...] > > My best idea so far is to use PCRE_NOTEMPTY_ATSTART and to fallback to > PCRE_NOTEMPTY, if the former is not available. Of course the bug would > persist for old libpcre, but \K will not be effective for PCRE 6.6 anyway. Isn't it normal that PHP would not support features that underlying libs do not support? We have number of such functions. Isn't it the reason why `phpinfo()` shows underlying library versions? Distributions prefer to use system's libraries. I suppose question is if PHP supports older systems such as RHEL/CentOS 5 or not. They are used widely. I prefer to support them if it is possible/feasible. Features that are not supported by libs could be documentation issues. IMO. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #87716 — Yasuo Ohgaki — 2015-08-11T20:08:03+00:00 URL: https://externals.io/message/87706#87716 · In reply to: #87715 > Distributions prefer to use system's libraries. I suppose question is if > PHP > supports older systems such as RHEL/CentOS 5 or not. They are used widely. > I prefer to support them if it is possible/feasible. Features that are not > supported > by libs could be documentation issues. IMO. > BTW, I don't think we should support very old libraries for new major release. -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #87721 — Anatol Belski — 2015-08-11T20:46:17+00:00 URL: https://externals.io/message/87706#87721 · In reply to: #87706 Hi Christoph, > -----Original Message----- > From: Christoph Becker [mailto:cmbecker69@gmx.de] > Sent: Tuesday, August 11, 2015 6:46 PM > To: PHP internals > Subject: [PHP-DEV] libpcre version requirements > > Hi all! > > What is the minimum libpcre version that is supported as external libpcre for > ext/pcre? According to config0.m4 it is PCRE 6.6 (2006-02-06), but is this still > valid and do we really have to support such old versions? > > I'm asking because of bug #70232 which can easily be fixed, but that requires > PCRE 8.00 (2009-10-19). If we have to support older PCRE versions, we'd > probably need a fallback to the current behavior (which would obviously keep > the bug). > IMHO the dependent version shouldn't be raised. But not sure what is meant by "implementing for lower versions". Probably if it's missing in PCRE, so is it. We should avoid reimplementing it, but just doing what is done in the other exts, fe curl. Users can choose to upgrade the dependency or to miss the feature. So a compile time PCRE version check were enough. Regards Anatol --- ## #87722 — Christoph Becker — 2015-08-11T20:51:04+00:00 URL: https://externals.io/message/87706#87722 · In reply to: #87716 > > > > […] Well, of course we can document all these details, but see, for instance, – hard to document, hard to remember, and hard to implement for apps which are supposed to run in different environments. At least we should try to reduce the divergence as much as possible (i.e. without introducing BC breaks in revisions). > BTW, I don't think we should support very old libraries for new major > release. ACK. IMHO requiring PCRE >= 8.0 would be fine for PHP 7. -- Christoph M. Becker --- ## #87723 — Christoph Becker — 2015-08-11T21:09:03+00:00 URL: https://externals.io/message/87706#87723 · In reply to: #87721 > > […] > > IMHO the dependent version shouldn't be raised. But not sure what is meant by "implementing for lower versions". Probably if it's missing in PCRE, so is it. We should avoid reimplementing it, but just doing what is done in the other exts, fe curl. Users can choose to upgrade the dependency or to miss the feature. So a compile time PCRE version check were enough. The difference to cURL, AIUI, is that this is not about an option that can be supplied by the user (and checked for existance in user-land code, by e.g. defined(CURLOPT_*)), but rather something that is for internal use only, and therefore much less obvious for user-land developers. IOW: fixing bug #70232 is trivial, but the bug would still persist for libpcre 7.2 - 7.9. If that's not regarded as a general issue, I'm fine with it. Still, I would suggest to raise the libpcre requirements to PCRE >= 8.0 for PHP 7.0 or at least for PHP 7.1. -- Christoph M. Becker --- ## #87727 — Anatol Belski — 2015-08-12T06:44:50+00:00 URL: https://externals.io/message/87706#87727 · In reply to: #87723 > -----Original Message----- > From: Christoph Becker [mailto:cmbecker69@gmx.de] > Sent: Tuesday, August 11, 2015 11:09 PM > To: Anatol Belski ; 'PHP internals' > > Subject: Re: [PHP-DEV] libpcre version requirements > > > > > […] > versions? > > […] > by "implementing for lower versions". Probably if it's missing in PCRE, so is it. > We should avoid reimplementing it, but just doing what is done in the other exts, > fe curl. Users can choose to upgrade the dependency or to miss the feature. So > a compile time PCRE version check were enough. > > The difference to cURL, AIUI, is that this is not about an option that can be > supplied by the user (and checked for existance in user-land code, by e.g. > defined(CURLOPT_*)), but rather something that is for internal use only, and > therefore much less obvious for user-land developers. > > IOW: fixing bug #70232 is trivial, but the bug would still persist for libpcre 7.2 - > 7.9. If that's not regarded as a general issue, I'm fine with it. > > Still, I would suggest to raise the libpcre requirements to PCRE >= 8.0 for PHP 7.0 > or at least for PHP 7.1. > Yeah, it's different from curl in some ways. However look - http://w3techs.com/technologies/details/os-linux/all/all . From those, CentOS 5/6 releases are not even a year old and contain 6.6, 7.x but take 20% of all the Linux market share. Note that according to that Linux takes only 35.9% of it. Now, say disregarding CentOS 5 and other rare/too old platforms, the other 65% of the usages are not taken into account. So how much loss on PHP7 adoption would happen, is a question. Maybe there are other stats, just operating on what is available. On the other hand - as with the bug #70232, is it really worth disabling the whole PCRE just to be sure one bug is fixed? I would see it as not being such. It is clear, that no distro will suddenly be upgrading from say PHP 5.3 to PHP7 in an older branch, but keeping as much compat as possible will allow third party repositories to still provide PHP7 there. This is at least my reason to say the version shouldn't be raised - as it shouldn't go beyond 7.x at least because of CentOS 6, and then it is probably useless to do it ATM. As long as it doesn't block the work towards future, at least. Regards Anatol --- ## #87740 — Christoph Becker — 2015-08-13T11:35:24+00:00 URL: https://externals.io/message/87706#87740 · In reply to: #87727 > > […] > > [...] However look - http://w3techs.com/technologies/details/os-linux/all/all . From those, CentOS 5/6 releases are not even a year old and contain 6.6, 7.x but take 20% of all the Linux market share. Note that according to that Linux takes only 35.9% of it. Now, say disregarding CentOS 5 and other rare/too old platforms, the other 65% of the usages are not taken into account. So how much loss on PHP7 adoption would happen, is a question. Maybe there are other stats, just operating on what is available. > > On the other hand - as with the bug #70232, is it really worth disabling the whole PCRE just to be sure one bug is fixed? I would see it as not being such. It is clear, that no distro will suddenly be upgrading from say PHP 5.3 to PHP7 in an older branch, but keeping as much compat as possible will allow third party repositories to still provide PHP7 there. This is at least my reason to say the version shouldn't be raised - as it shouldn't go beyond 7.x at least because of CentOS 6, and then it is probably useless to do it ATM. As long as it doesn't block the work towards future, at least. Well, then it might be best to leave the requirements as they are for now. :) -- Christoph M. Becker --- ## #87747 — Adam Harvey — 2015-08-13T18:44:16+00:00 URL: https://externals.io/message/87706#87747 · In reply to: #87740 > > > […] > > Well, then it might be best to leave the requirements as they are for > now. :) I'm still OK requiring 8.00 in PHP 7.0, personally — even that is almost six years old, and users on older distros and OSes can use the bundled libpcre. It's not like this is going to break the common case where the user doesn't set any specific PCRE flags in configure, and I don't think it's unreasonable to expect third party packagers to use a bundled library if they're building on that old a system. They're effectively shouldering the burden of providing security updates for PHP regardless of what the distro does. Adam --- ## #87749 — Anatol Belski — 2015-08-13T23:25:00+00:00 URL: https://externals.io/message/87706#87749 · In reply to: #87747 > -----Original Message----- > From: adam@adamharvey.name [mailto:adam@adamharvey.name] On Behalf > Of Adam Harvey > Sent: Thursday, August 13, 2015 8:44 PM > To: Christoph Becker > Cc: Anatol Belski ; PHP internals > > Subject: Re: [PHP-DEV] libpcre version requirements > > > > […] > . From those, CentOS 5/6 releases are not even a year old and contain 6.6, 7.x > but take 20% of all the Linux market share. Note that according to that Linux > takes only 35.9% of it. Now, say disregarding CentOS 5 and other rare/too old > platforms, the other 65% of the usages are not taken into account. So how > much loss on PHP7 adoption would happen, is a question. Maybe there are other > stats, just operating on what is available. > > […] > whole PCRE just to be sure one bug is fixed? I would see it as not being such. It > is clear, that no distro will suddenly be upgrading from say PHP 5.3 to PHP7 in an > older branch, but keeping as much compat as possible will allow third party > repositories to still provide PHP7 there. This is at least my reason to say the > version shouldn't be raised - as it shouldn't go beyond 7.x at least because of > CentOS 6, and then it is probably useless to do it ATM. As long as it doesn't block > the work towards future, at least. > > […] > > I'm still OK requiring 8.00 in PHP 7.0, personally — even that is almost six years > old, and users on older distros and OSes can use the bundled libpcre. It's not like > this is going to break the common case where the user doesn't set any specific > PCRE flags in configure, and I don't think it's unreasonable to expect third party > packagers to use a bundled library if they're building on that old a system. > They're effectively shouldering the burden of providing security updates for PHP > regardless of what the distro does. What about the other 65% of the market share where we have no idea what happens? Well, some of them are Windows where bundled PCRE is used, but the rest is like UNIXes, maybe they're 50/50 or alike. Besides that - an average user won't even have gcc installed to use the bundled PCRE or not, and what packagers would do - yep, that's a question. However distributions usually enforce shared libs usage for the exact reason to centralize delivery of the (security) updates. I would suggest to make this move (raising the PCRE version to 7 or 8) in master after 7.0 is branched. Then there were enough time to see how 7.0 is being handled, to get feedback on that change and to react accordingly, if needed. Regards Anatol --- ## #87837 — Nikita Popov — 2015-08-21T13:14:16+00:00 URL: https://externals.io/message/87706#87837 · In reply to: #87749 On Fri, Aug 14, 2015 at 1:25 AM, Anatol Belski wrote: > > > > […] > http://w3techs.com/technologies/details/os-linux/all/all > > […] > 6.6, 7.x > > […] > Linux > > […] > rare/too old > > […] > other > > […] > disabling the > > […] > such. It > > […] > PHP7 in an > > […] > party > > […] > say the > > […] > because of > > […] > doesn't block > > […] > six years > > […] > It's not like > > […] > specific > > […] > third party > > […] > system. > > […] > for PHP > > […] > > What about the other 65% of the market share where we have no idea what > happens? Well, some of them are Windows where bundled PCRE is used, but the > rest is like UNIXes, maybe they're 50/50 or alike. > > Besides that - an average user won't even have gcc installed to use the > bundled PCRE or not, and what packagers would do - yep, that's a question. > However distributions usually enforce shared libs usage for the exact > reason to centralize delivery of the (security) updates. > > I would suggest to make this move (raising the PCRE version to 7 or 8) in > master after 7.0 is branched. Then there were enough time to see how 7.0 is > being handled, to get feedback on that change and to react accordingly, if > needed. > > Regards > > Anatol > There already was some discussion about bumping the libpcre version for 5.6. I'll quote what I said back then: > [...] I think the low version requirement is bad for other reasons: There's a big gulf in terms of both features and bug fixes between PCRE 6.6 and what PHP currently bundles. It's a bit ridiculous that you can end up using a PHP version from 2014 together with a decade old PCRE version. and > It would still be nice to increase the minimum version number [...], because allowing prehistoric PCRE versions in a new release makes zero sense. I recommend at least 8.10 because it both supports marks and - more relevantly to most users - supports UCP mode, which PHP uses by default (if available). UCP mode can significantly change the behavior of PCRE with the /u modifier, as such guaranteeing a minimum version of 8.10 will also guarantee a somewhat consistent /u behavior. Basically, if we allow a too broad range of PCRE versions, we also allow a broad range of behavior people have to deal with. If people use the /u modifier, they will get significantly (and at the same time subtly) different behavior if PHP was linked against libpcre newer or older than 8.10. Distros that will ship with PHP 7 will also ship with new PCRE versions. External package repositories with PHP 7 will also have newer PCRE versions. People compiling themselves use the bundled version. Let's bump this. If you install PHP 7 in 2016 you should *not* have to deal with a PCRE version released in 2006. Nikita --- ## #87844 — Anatol Belski — 2015-08-21T20:37:00+00:00 URL: https://externals.io/message/87706#87844 · In reply to: #87837 > -----Original Message----- > From: Nikita Popov [mailto:nikita.ppv@gmail.com] > Sent: Friday, August 21, 2015 3:14 PM > To: Anatol Belski > Cc: Adam Harvey ; Christoph Becker > ; PHP internals > Subject: Re: [PHP-DEV] libpcre version requirements > > On Fri, Aug 14, 2015 at 1:25 AM, Anatol Belski > wrote: > > > […] > Behalf > > […] > wrote: > > […] > question. > > […] > > There already was some discussion about bumping the libpcre version for 5.6. I'll > quote what I said back then: > > > […] > There's a big gulf in terms of both features and bug fixes between PCRE 6.6 and > what PHP currently bundles. It's a bit ridiculous that you can end up using a PHP > version from 2014 together with a decade old PCRE version. > > and > > > […] > because allowing prehistoric PCRE versions in a new release makes zero sense. I > recommend at least 8.10 because it both supports marks and - more relevantly > to most users - supports UCP mode, which PHP uses by default (if available). UCP > mode can significantly change the behavior of PCRE with the /u modifier, as > such guaranteeing a minimum version of 8.10 will also guarantee a somewhat > consistent /u behavior. > > Basically, if we allow a too broad range of PCRE versions, we also allow a broad > range of behavior people have to deal with. If people use the /u modifier, they > will get significantly (and at the same time subtly) different behavior if PHP was > linked against libpcre newer or older than 8.10. > > Distros that will ship with PHP 7 will also ship with new PCRE versions. > External package repositories with PHP 7 will also have newer PCRE versions. > People compiling themselves use the bundled version. > > Let's bump this. If you install PHP 7 in 2016 you should *not* have to deal with a > PCRE version released in 2006. > Yeah, I read this discussion here http://grokbase.com/t/php/php-internals/142wrqvs7p/add-support-for-pcre-marks . Seems it was not finished for some reasons. I was mentioning "if it doesn't block the future development" exactly for the reason to hear if there's something. Now turns out there are at least two issues (count yours and Christoph's one) requiring a newer PCRE. Nevertheless - I'd prefer to keep the current situation for 7.0 and do it directly in master after 7.0 was branched which is merely a month away. Primarily to keep 7.0 compatible in as much areas as possible. Also worried a bit about that other 60% from the stats which are not Linux, Linuxes look actually good having >8.10 even for old stable. But that also means - keeping or not an option to use a lower version doesn't really hurt (at least for the popular distros like Debian, Ubuntu, Fedora). Also about the future work - IMHO it would make sense to start a port for PCRE2 at some point in autumn (and I'm intended to if no one started earlier) to target 7.1 or later. Regarding PCRE - it most likely won't get any new features but bug fixes only, PCRE2 is what were future oriented. 7.0 won't arrive in the distros earlier than in a yeah, or alike. And by that time that can be completely another priority. So concluding - preferably were to keep the PCRE version for 7.0 and raise in master, unless you see some hard issue or want to make use of "new" features in PCRE 8.x that can't wait anymore, then please do now. Regards Anatol --- ## #87846 — Christoph Becker — 2015-08-21T21:30:00+00:00 URL: https://externals.io/message/87706#87846 · In reply to: #87844 > > […] > > Yeah, I read this discussion here http://grokbase.com/t/php/php-internals/142wrqvs7p/add-support-for-pcre-marks . Seems it was not finished for some reasons. > > I was mentioning "if it doesn't block the future development" exactly for the reason to hear if there's something. Now turns out there are at least two issues (count yours and Christoph's one) requiring a newer PCRE. Nevertheless - I'd prefer to keep the current situation for 7.0 and do it directly in master after 7.0 was branched which is merely a month away. Primarily to keep 7.0 compatible in as much areas as possible. Also worried a bit about that other 60% from the stats which are not Linux, Linuxes look actually good having >8.10 even for old stable. But that also means - keeping or not an option to use a lower version doesn't really hurt (at least for the popular distros like Debian, Ubuntu, Fedora). > > Also about the future work - IMHO it would make sense to start a port for PCRE2 at some point in autumn (and I'm intended to if no one started earlier) to target 7.1 or later. Regarding PCRE - it most likely won't get any new features but bug fixes only, PCRE2 is what were future oriented. 7.0 won't arrive in the distros earlier than in a yeah, or alike. And by that time that can be completely another priority. > > So concluding - preferably were to keep the PCRE version for 7.0 and raise in master, unless you see some hard issue or want to make use of "new" features in PCRE 8.x that can't wait anymore, then please do now. Would it be an acceptable compromise for everybody to stick with the current *requirements* for now, but to document[1] that PCRE >= 8.10 is *recommended* for PHP 5.6 and 7.0? [1] -- Christoph M. Becker --- ## #87864 — Anatol Belski — 2015-08-22T14:52:48+00:00 URL: https://externals.io/message/87706#87864 · In reply to: #87846 Hi Christoph, > -----Original Message----- > From: Christoph Becker [mailto:cmbecker69@gmx.de] > Sent: Friday, August 21, 2015 11:30 PM > To: Anatol Belski ; 'Nikita Popov' > > Cc: 'Adam Harvey' ; 'Christoph Becker' > ; 'PHP internals' > Subject: Re: [PHP-DEV] libpcre version requirements > > > > > […] > PCRE version. > > […] > older than 8.10. > > […] > internals/142wrqvs7p/add-support-for-pcre-marks . Seems it was not finished > for some reasons. > > […] > reason to hear if there's something. Now turns out there are at least two issues > (count yours and Christoph's one) requiring a newer PCRE. Nevertheless - I'd > prefer to keep the current situation for 7.0 and do it directly in master after 7.0 > was branched which is merely a month away. Primarily to keep 7.0 compatible in > as much areas as possible. Also worried a bit about that other 60% from the > stats which are not Linux, Linuxes look actually good having >8.10 even for old > stable. But that also means - keeping or not an option to use a lower version > doesn't really hurt (at least for the popular distros like Debian, Ubuntu, Fedora). > > […] > PCRE2 at some point in autumn (and I'm intended to if no one started earlier) to > target 7.1 or later. Regarding PCRE - it most likely won't get any new features > but bug fixes only, PCRE2 is what were future oriented. 7.0 won't arrive in the > distros earlier than in a yeah, or alike. And by that time that can be completely > another priority. > > […] > master, unless you see some hard issue or want to make use of "new" features > in PCRE 8.x that can't wait anymore, then please do now. > > Would it be an acceptable compromise for everybody to stick with the current > *requirements* for now, but to document[1] that PCRE >= 8.10 is > *recommended* for PHP 5.6 and 7.0? > A documentation can never hurt. For the case the requirement wouldn't be changed, it's of course even better to have a doc line, IMHO. Regards Anatol --- ## #87867 — Christoph Becker — 2015-08-22T16:54:47+00:00 URL: https://externals.io/message/87706#87867 · In reply to: #87864 Hi Anatol, > > […] > A documentation can never hurt. For the case the requirement wouldn't be changed, it's of course even better to have a doc line, IMHO. I've added the recommendation: . What do you mean by "doc line"? A note in UPGRADING? -- Christoph M. Becker --- ## #87869 — Anatol Belski — 2015-08-22T19:21:46+00:00 URL: https://externals.io/message/87706#87869 · In reply to: #87867 Hi Christoph, > -----Original Message----- > From: Christoph Becker [mailto:cmbecker69@gmx.de] > Sent: Saturday, August 22, 2015 6:55 PM > To: Anatol Belski ; 'Nikita Popov' > > Cc: 'Adam Harvey' ; 'PHP internals' > Subject: Re: [PHP-DEV] libpcre version requirements > > Hi Anatol, > > > > > […] > changed, it's of course even better to have a doc line, IMHO. > > I've added the recommendation: > . > > What do you mean by "doc line"? A note in UPGRADING? > Nope, I meant exactly what you did :) Thanks Anatol --- ## #87878 — Christoph Becker — 2015-08-23T14:57:04+00:00 URL: https://externals.io/message/87706#87878 · In reply to: #87869 Hi Anatol, > Hi Christoph, > > > […] > > Nope, I meant exactly what you did :) Fine. Thanks. -- Christoph M. Becker