conf/121452: /etc/rc.d/ppp not working as expected

[Maksim Yevmenkin]

On Fri, Mar 7, 2008 at 10:09 AM, Brooks Davis <brooks at freebsd.org> wrote:
> On Fri, Mar 07, 2008 at 09:34:06AM -0800, Maksim Yevmenkin wrote:
>  > On Fri, Mar 7, 2008 at 7:49 AM, Brooks Davis <brooks at freebsd.org> wrote:
>  > > The following patch should allow profile name to contain ".-/+" characters
>  > >  as we do with interfaces.  It also documents the previous undocumnted
>  > >  per-profile overrides of _mode and _nat which were the cause of the problem.
>  > >  If someone who uses ppp could test this, I'd be happy to commit it.
>  >
>  > i'm not so sure about this one. if i have "t-dsl" as a profile name, i
>  > will not be able to specify any overrides for this profile, because
>  > shell won't let me have "ppp_t-dsl_mode" and/or "ppp_t-dsl_nat"
>  > variable. so, the translation here is not really needed, imo, and,
>  > perhaps, could even be considered harmful. perhaps we should do one of
>  > the following
>
>  The point of the patch is to change all ".-/+" characters to _ which
>  means the variable will be ppp_t_dsl_(mode|nat) so you can use the
>  profile overrides.  It's an exact copy of the code we use for interface
>  variables.

i get that. what i was trying to say is that overrides for the "t-dsl"
profile (with hyphen) are now, obviously, "ppp_t_dsl_mode" and/or
"ppp_t_dsl_nat".  to me, it is somewhat confusing. another (pretty
weak :) argument is that all ".-/+" characters are mapped onto single
"_"  character. this could potentially create a collision in variable
names. i realize that you have done exactly the same thing as in
get_if_var() in network.subr. are there any examples of network
interface variable names that are not "shell clean"?

>  > 1) demand that ppp profile names should be "shell clean" and document it
>  >
>  > or
>  >
>  > 2)  if a ppp profile name is not "shell clean" simply do not evaluate
>  > profile overrides and use defaults
>
>  I'm opposed to 2.  I'd be OK with 1, but think folding common
>  punctuation into _ may be a better option given that we're already doing
>  it elsewhere.

i'm still not sure :) however, please do not take it as an objection
:) since we already have similar code (and no one, including me,
complained :), it probably makes more sense to do the same here.

thanks,
max