[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in gencmdlist.sh (or is it?)
From: |
Duboucher Thomas |
Subject: |
Re: Bug in gencmdlist.sh (or is it?) |
Date: |
Thu, 02 Jul 2009 07:42:39 +0200 |
User-agent: |
Thunderbird 2.0.0.22 (Windows/20090605) |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pavel Roskin a écrit :
> On Thu, 2009-07-02 at 00:34 +0200, Duboucher Thomas wrote:
>
>> I was working on some Grub2 module a few days ago and I spent a lot of
>> time on this. Basically, I was unable to correctly generate the file
>> command.lst; my new commands simply didn't appeared in it.
>> I finally found that gencmdlist.sh is only processing line per line
>> using sed, so that if one is writing with a different indentation, the
>> script silently fail. For instance,
>>> grub_extcmd
>>> (
>>> "foo",
>> does not produce any output.
>
> I confirm that it's indeed a limitation of gencmdlist.sh. It may be
> possible to handle it by using C preprocessor before sed, but I don't
> think it's an urgent issue. It's shouldn't be a problem for properly
> indented source.
No, it is not really urgent. As I said, I have already found a
workaround. But based on Grub2 being a module-based project, I don't
think an indentation-dependant parser is a good idea, nor is it robust.
>
>> I am working now with a small script
>> written in Lua, but it is neither efficient, nor a good idea to add Lua
>> as a dependency.
>
> I don't understand how this is related.
>
I have replaced gencmdlist.sh by a script in Lua that does the same, and
can handle any kind of indentation - or at least the resulting file is
identical even if I mess the indentation; but based on how and when I
have writen it, well, I'm not very confident ;) -.
>> Perhaps a sed guru can have a look at this?
>
> I actually don't feel good about using anything other that a C compiler
> or preprocessor to parse C sources.
>
> It's working for now, but if we want to make it more reliable, I'd
> rather not ask a "sed guru".
>
There are tools to parse source code, but that is not my domain. That's
the reason I was reporting this. :)
Regards,
Thomas.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpMSM8ACgkQBV7eXqefhqgzGwCcD5cXmwsCREdwNUBjgvACc9xK
xxoAoLIBToOcZ5oig5T/ihd9av/wioed
=6XCt
-----END PGP SIGNATURE-----