[augeas-devel] Weird print result with Perl bindings on amd64

[Daniel P. Berrange]

On Thu, Jan 15, 2009 at 09:19:50PM +0100, Jim Meyering wrote:
> David Lutterkort <lutter at redhat.com> wrote:
> > On Thu, 2009-01-15 at 16:46 +0100, Jim Meyering wrote:
> >> David Lutterkort <lutter at redhat.com> wrote:
> >> > On Wed, 2009-01-14 at 19:04 +0100, Dominique Dumont wrote:
> >> >> David Lutterkort <lutter at redhat.com> writes:
> >> >> >> Actually, after much tinkering with sshd lens, I have the gut feeling
> >> >> >> that the problem is in the key_re lens. Looks like the '-' operator
> >> >> >> between the 2 regex is not working properly.
> >> >> >
> >> >> > At first, that was my suspicion, too, but the regular expressions that
> >> >> > are used for matching are identical, and I can see in the debugger that
> >> >> > the regex matcher produces different results.
> >> >>
> >> >> I'm not sure that I follow you.
> >> >>
> >> >> IMHO, the suspect lens is
> >> >>
> >> >>    let key_re = /[A-Za-z0-9]+/
> >> >>          - /MACs|Match|AcceptEnv|Subsystem|(Allow|Deny)(Groups|Users)/
> >> >>
> >> >> The regex before and after the '-' are not identical ?? [ puzzled ]
> >> >>
> >> >> So, what do you mean by "the regular expressions that are used for
> >> >> matching are identical" ?
> >> >
> >> > Oh .. what I meant was: I checked with gdb what is happening behind the
> >> > scenes when the sshd lens is run on your example sshd_config, both
> >> > running it with augtool and with your Perl example.
> >> >
> >> > In both cases, the regexp that is fed to re_match[1] is exactly the
> >> > same, but the results of matching are different.
> >> >
> >> >> On my side, I've tinkered a lot the regex on the right side and never
> >> >> managed to have an effect. Even
> >> >>
> >> >>   let key_re = /[A-Za-z0-9]+/ - "Match"
> >> >>
> >> >> does not work. Hence the suspicion regarding the '-'
> >> >
> >> > It does not appear that the '-' is the problem. When you compute the
> >> > regexp for the above, you get
> >> >
> >> >         /Match[0-9A-Za-z][0-9A-Za-z]*|Matc([0-9A-Za-gi-z][0-9A-Za-z]*|())|Mat([0-9A-Zabd-z][0-9A-Za-z]*|())|Ma([0-9A-Za-su-z][0-9A-Za-z]*|())|(M[0-9A-Zb-z]|[0-9A-LN-Za-z][0-9A-Za-z])[0-9A-Za-z]*|M|[0-9A-LN-Za-z]/
> >> >
> >> > which is correct.
> >>
> >> Actually, that's the problem.
> >> Using such ranges is portable only in the C locale.
> >> Sometimes [A-Z] contains 51, sometimes a slightly different set of 51.
> >> Sometimes the expected 52.  That's why [[:upper:]] came about.
> >
> > The problem is that Augeas should always be operating in the C locale,
> 
> i.e., Augeas wishes it could assume it is operating in the C locale ;-)
> In other words, you'd like locale-agnostic/ignoring regexp code.
> 
> > no matter what the user has in their environment - the regexps are read
> > from files that should mean exactly the same in any locale.
> >
> > AFAICT, there's no clean way for libaugeas to switch to C locale upon
> > entry to one of its functions, and switch back to the user's locale on
> > return, since setlocale changes the locale for the entire process, not
> > just individual threads.

GLib >= 2.3 has  thread-local  locale support

  http://people.redhat.com/drepper/tllocale.ps.gz

But i guess you care about non-Linux cruft too ;-P

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|