[aur-dev] [PATCH] Fix: FS#13189, infinite variable replacement cycle

Gergely Imreh

13 Feb 2009 13 Feb '09

4:44 p.m.

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

Show replies by date

Gergely Imreh

13 Feb 13 Feb

5:05 p.m.

New subject: [aur-dev] [PATCH] Fix: FS#13189, infinite variable replacement cycle

Yeah, except I missed attaching the patch, bummer... 2009/2/14 Gergely Imreh :

...

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

Loui Chang

7:17 p.m.

New subject: [aur-dev] [PATCH] Fix: FS#13189, infinite variable replacement cycle

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...

Aaron Griffin

7:24 p.m.

New subject: [aur-dev] [PATCH] Fix: FS#13189, infinite variable replacement cycle

On Fri, Feb 13, 2009 at 1:17 PM, Loui Chang 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?

Loui Chang

14 Feb 14 Feb

12:16 a.m.

New subject: [aur-dev] [PATCH] Fix: FS#13189, infinite variable replacement cycle

On Fri, Feb 13, 2009 at 01:24:38PM -0600, Aaron Griffin wrote:

...

On Fri, Feb 13, 2009 at 1:17 PM, Loui Chang 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.

Gergely Imreh

12:21 a.m.

New subject: [aur-dev] [PATCH] Fix: FS#13189, infinite variable replacement cycle

2009/2/14 Loui Chang :

...

On Fri, Feb 13, 2009 at 01:24:38PM -0600, Aaron Griffin wrote:

...
On Fri, Feb 13, 2009 at 1:17 PM, Loui Chang 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. ;)

Gergely Imreh

13 Feb 13 Feb

11:59 p.m.

New subject: [aur-dev] [PATCH] Fix: FS#13189, infinite variable replacement cycle

Now, hopefully for the last time, after some mailman changes, here we go again. 2009/2/14 Gergely Imreh :

...

Yeah, except I missed attaching the patch, bummer...

2009/2/14 Gergely Imreh :

...
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

Loui Chang

15 Feb 15 Feb

8:37 p.m.

New subject: [aur-dev] [PATCH] Fix: FS#13189, infinite variable replacement cycle

...

...
2009/2/14 Gergely Imreh :

...
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.

5550

Age (days ago)

5552

Last active (days ago)

List overview

Download

7 comments

3 participants

participants (3)

Aaron Griffin
Gergely Imreh
Loui Chang