Summary:	ASTERISK-10233: Config parser eats comments for breakfast
Reporter:	Jared Smith (jsmith)	Labels:
Date Opened:	2007-09-04 14:04:56	Date Closed:	2007-09-05 09:34:07
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/ManagerInterface
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	The Asterisk config parser (used by AMI for GetConfig/UpdateConfig, etc.) eats comments on the end of lines, and makes it harder for people to follow the configuration files after they've been edited by Asterisk. I've talked with murf about this, and he asked me to open a bug so that he can track this and fix it.
Comments:	By: Brandon Kruse (bkruse) 2007-09-04 15:34:48 Does this mean that when I am using updateconfig and getconfig that I can possibly start sending comments also? Also, will it be a lot of overhead to receive/send those ;comments and blank lines? Please keep me updated to see if I need to change the API. Now we just have comment => whatever for context's in the dialplan, and they get parsed. However, I could make the GUI clean up the code, and make it MUCH more editable and readable. This could possibly lead to a perfect integration of creating things in the GUI, and the user being able to edit them, as where now it its kind of convoluted and obfuscated at points. I like it. -bk By: Steve Murphy (murf) 2007-09-05 09:22:51 Actually, the comments being lost/eaten here aren't at the end of the line, they are at the end of the file. The algorithm collects comments, and attaches them to the next following object, doing its best to keep any involved newlines. The comments at the end of a file, with no following "object", were lost. bkruse: The API doesn't allow (afaics) any way to attach/detach comments from an object. If you really want/need to, you might invent some really nifty, easy to follow, way to do this, both in the API and in the GUI. The two objects in a config file to which you can attach comments are the category decls (e.g. [general] ), and variable decls  (e.g.  host=20.30.40.200), and now, with the fix soon to be added, there will be 3 flavors of comment:   a. comments preceeding the object;   b. comments following the object, but on the same line.   c. comments following the object. (The reader will only attach the comments after the last object in a file) (but theoretically, any object can have trailing comments). If you attach trailing comments to an object, that is not the last object in the file, then, when you write out that config file, and read it back in, you will see that those comments have slid back to the following objects' preceeding comment set. The whole idea of attaching comments to objects was introduced by Mark in the original code; I just fleshed it out and expanded on the idea. If I tried to make comments a full-fledged object in its own right, then there'd be a ton of objects to ignore in places all over the code, a real mess. Tracking blank lines is a different issue, I'll attack that (as best I can) in 10642. Comments come in 3 types also:  a. preceeded by a ;, they go the end of the line  b. from  ;--  to  --;  (may be multiline comments)  c. ;! comments go to the end of a line, but are discarded by the reader.     (this way, we can insert generated headers that won't accumulate forever). I would probably hide type (c) from users, tho. Hope this helped! By: Steve Murphy (murf) 2007-09-05 09:34:06 This issue fixed via r81519.