asterisk users - Aug 2007 - Hierarchical Config file (re)writing (bug 8684)

Anyone remember the problem with writing out config files that had
#include directives in them? You'd get a single, flat config file when
you saved it back out. I have heard a few howls of complaint! (see bug
8684)

Well, I just checked in a fix for this into trunk. My simple tests say
it's working, but the "real thing" may say otherwise. It will
re-write
the config file in question, and also re-write all the files included by
it. All will have the little header inserted at the top, revealing that
the file is generated. I only see a few places in the code where the
text_file_save function is called: in the manager (AMI) code, and the
voicemail app(-- if you are in realtime, I think.)

What might be different:

1. If you included the same file twice (or more), you will see that,
after it is rewritten to disk, now two different files are included (one
a copy of the first), and if changes are made to one, and not the other,
then they may not be the same anymore.

2. Blank lines between entries will get dropped. Sorry. If you really
like
blank lines, then include a comment of a blank line.

3. Comments preceded by a large amount of whitespace will probably have
most of the preceding space dropped. sorry. Start your or comment at the
beginning of a line, or immediately after statements, and you'll keep
the spaces that way.

4. Trailing comments will get dropped. Put your comments in front of a
variable definition, or in front of a category definition. Comments with
no variable decls or category decls (you know, the [general] type
stuff...) will not be attached to anything, and will be lost.

5. Right now, #exec lines will be written out, if they are included, but
their output will not be included in the saved set. (Well, you could
look in /var/tmp, but they aren't ref'd by anything.). But, I think you
just want #exec's to get repeated as you placed them. Their output is a
dynamic thing anyway...!


So, I ask those who were interested in seeing this kind of
functionality, to test it out in trunk and report the bugs via the bug
tracker. I know there are some who would like this in 1.4, and after we
toughen up the code in trunk, maybe we could call it a bugfix and get it
in 1.4, if that is the right thing to do.

murf

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url :
http://lists.digium.com/pipermail/asterisk-users/attachments/20070830/d36ce28c/attachment.bin

On Thu, 2007-08-30 at 14:13 -0600, Steve Murphy wrote:
> 2. Blank lines between entries will get dropped. Sorry. If you really
> like
> blank lines, then include a comment of a blank line.
Ouch... this makes it quite cumbersome.  In fact, that's the number one
complaint I get from students in the bootcamp classes is that the
Asterisk GUI eats their blank lines.
> 4. Trailing comments will get dropped. Put your comments in front of a
> variable definition, or in front of a category definition. Comments with
> no variable decls or category decls (you know, the [general] type
> stuff...) will not be attached to anything, and will be lost.
Ouch... this one hurts too... most everyone I know uses trailing
comments.  Is there a technical reason why this has to be?

Don't get me wrong, I'm happy to see the changes you've done. 
I'd just
like to make this as user-friendly as possible.  One of the overriding
goals of the Asterisk GUI is to leave the config files hand-editable,
and removing comments and blank lines makes that harder.


-- 
Jared Smith
Community Relations Manager
Digium, Inc.