On Tue, Mar 5, 2013 at 4:02 PM, Lukas Fleischer <[email protected]> wrote: > On Tue, Mar 05, 2013 at 03:46:55PM +0100, Alexander Griesbaum wrote: >> >> On Mar 5, 2013, at 1:37 PM, Lukas Fleischer wrote: >> >> > + foreach (explode("\n", $srcinfo_raw) as $line) { >> > + if ($line[0] = '#') { >> > + continue; >> > + } >> > + list($key, $value) = explode(' = ', $line, 2); >> >> Hey, it's me again. >> >> I think it wouldn't be bad to process the file in the same way as the >> PKGBUILD is processed[1]: >> >> <snip> >> foreach (explode("\n", $pkgbuild_raw) as $line) { >> $line = trim($line); >> # Remove comments >> $line = preg_replace('/\s*#.*/', '', $line); >> <snip> >> >> I didn't look deep into the whole code and maybe you've got good reasons to >> change that procedure so please ignore my mail if you like. Though it may be >> unnecessairy to change the whole procedure, I really recommend to add the >> trim() line for more comfort. > > The difference between PKGBUILD and .SRCINFO parsing is that we want > .SRCINFO metadata to be as simple to parse as possible and therefore > don't support quoting etc. > > This implies that there will only be full-line comments since otherwise, > there would be no way to add a package description that contains a pound > sign ("#"). > > The trim() line is something I am not sure about. libalpm doesn't seem > to do this when parsing .PKGINFO files but I also can't imagine any use > case where leading/trailing space would come in handy...
Hey. Thanks a lot for your explanation. trim(): It isn't really handy, right. But I still think it should be handled the same way as the PKGBUILD is. To have the trim() there would be more.. let's say... tolerant? Alex
