[aur-dev] [PATCH] Fix: FS#13189, infinite variable replacement cycle
Hi, Bug report FS#13189 brought to light a situation when certain lines in the PKGBUILD would cause the pkgbuild.php end up in an infinite cycle. Example is a line such as: foo=$foo or as in the bug report: CXXFLAGS=$CXXFLAGS' -fpic' In the first case, e.g. $foo would be recognized as a call for replacement for "foo", and then replaced with "$foo", then checked again for values to replace.... you can guess how well it goes... This patch removes this situation by setting the variable value to empty (to ""), if it recognizes that there would be such a cycle. This behaviour is not exactly what bash would do, since e.g. if there are two lines in the PKGBUILD such as: foo=something foo=$foo then in bash in the end foo would have a proper value ("something"), while in our case it would be empty. In my opinion this is not a problem, since generally these kind of PKGBUILDs could be considered malformed..... The eval type parameter substitution is not changed at the moment, since even if does not give the same value as bash, it does not cause such cycle as the normal substitution. Cheers, Greg
Yeah, except I missed attaching the patch, bummer... 2009/2/14 Gergely Imreh <imrehg@gmail.com>:
Hi,
Bug report FS#13189 brought to light a situation when certain lines in the PKGBUILD would cause the pkgbuild.php end up in an infinite cycle. Example is a line such as: foo=$foo or as in the bug report: CXXFLAGS=$CXXFLAGS' -fpic'
In the first case, e.g. $foo would be recognized as a call for replacement for "foo", and then replaced with "$foo", then checked again for values to replace.... you can guess how well it goes...
This patch removes this situation by setting the variable value to empty (to ""), if it recognizes that there would be such a cycle. This behaviour is not exactly what bash would do, since e.g. if there are two lines in the PKGBUILD such as: foo=something foo=$foo then in bash in the end foo would have a proper value ("something"), while in our case it would be empty. In my opinion this is not a problem, since generally these kind of PKGBUILDs could be considered malformed.....
The eval type parameter substitution is not changed at the moment, since even if does not give the same value as bash, it does not cause such cycle as the normal substitution.
Cheers, Greg
-- (\__/) (='.'=)This is Bunny. Copy and paste bunny into your (")_(")signature to help him gain world domination
On Sat, Feb 14, 2009 at 01:05:24AM +0800, Gergely Imreh wrote:
Yeah, except I missed attaching the patch, bummer...
Hmm looks like it was missed again...
On Fri, Feb 13, 2009 at 1:17 PM, Loui Chang <louipc.ist@gmail.com> wrote:
On Sat, Feb 14, 2009 at 01:05:24AM +0800, Gergely Imreh wrote:
Yeah, except I missed attaching the patch, bummer...
Hmm looks like it was missed again...
Might be getting stripped by the new mailman settings I added to strip html mails - mind forwarding the original mail to me personally so I can check it?
On Fri, Feb 13, 2009 at 01:24:38PM -0600, Aaron Griffin wrote:
On Fri, Feb 13, 2009 at 1:17 PM, Loui Chang <louipc.ist@gmail.com> wrote:
On Sat, Feb 14, 2009 at 01:05:24AM +0800, Gergely Imreh wrote:
Yeah, except I missed attaching the patch, bummer...
Hmm looks like it was missed again...
Might be getting stripped by the new mailman settings I added to strip html mails - mind forwarding the original mail to me personally so I can check it?
Crazy gmail. Thanks for fixing that.
2009/2/14 Loui Chang <louipc.ist@gmail.com>:
On Fri, Feb 13, 2009 at 01:24:38PM -0600, Aaron Griffin wrote:
On Fri, Feb 13, 2009 at 1:17 PM, Loui Chang <louipc.ist@gmail.com> wrote:
On Sat, Feb 14, 2009 at 01:05:24AM +0800, Gergely Imreh wrote:
Yeah, except I missed attaching the patch, bummer...
Hmm looks like it was missed again...
Might be getting stripped by the new mailman settings I added to strip html mails - mind forwarding the original mail to me personally so I can check it?
Crazy gmail. Thanks for fixing that.
It was because gmail attached things as "application/octet-stream", and encodes it as bas64... No html mails from me. ;)
Now, hopefully for the last time, after some mailman changes, here we go again. 2009/2/14 Gergely Imreh <imrehg@gmail.com>:
Yeah, except I missed attaching the patch, bummer...
2009/2/14 Gergely Imreh <imrehg@gmail.com>:
Hi,
Bug report FS#13189 brought to light a situation when certain lines in the PKGBUILD would cause the pkgbuild.php end up in an infinite cycle. Example is a line such as: foo=$foo or as in the bug report: CXXFLAGS=$CXXFLAGS' -fpic'
In the first case, e.g. $foo would be recognized as a call for replacement for "foo", and then replaced with "$foo", then checked again for values to replace.... you can guess how well it goes...
This patch removes this situation by setting the variable value to empty (to ""), if it recognizes that there would be such a cycle. This behaviour is not exactly what bash would do, since e.g. if there are two lines in the PKGBUILD such as: foo=something foo=$foo then in bash in the end foo would have a proper value ("something"), while in our case it would be empty. In my opinion this is not a problem, since generally these kind of PKGBUILDs could be considered malformed.....
The eval type parameter substitution is not changed at the moment, since even if does not give the same value as bash, it does not cause such cycle as the normal substitution.
Cheers, Greg
2009/2/14 Gergely Imreh <imrehg@gmail.com>:
Bug report FS#13189 brought to light a situation when certain lines in the PKGBUILD would cause the pkgbuild.php end up in an infinite cycle. Example is a line such as: foo=$foo or as in the bug report: CXXFLAGS=$CXXFLAGS' -fpic'
In the first case, e.g. $foo would be recognized as a call for replacement for "foo", and then replaced with "$foo", then checked again for values to replace.... you can guess how well it goes...
This patch removes this situation by setting the variable value to empty (to ""), if it recognizes that there would be such a cycle. This behaviour is not exactly what bash would do, since e.g. if there are two lines in the PKGBUILD such as: foo=something foo=$foo then in bash in the end foo would have a proper value ("something"), while in our case it would be empty. In my opinion this is not a problem, since generally these kind of PKGBUILDs could be considered malformed.....
The eval type parameter substitution is not changed at the moment, since even if does not give the same value as bash, it does not cause such cycle as the normal substitution.
Many thanks for the fix. This is pushed.
participants (3)
-
Aaron Griffin
-
Gergely Imreh
-
Loui Chang