[Fuego] [PATCH] pam: add test case for pam.

[Tim.Bird at sony.com]

> -----Original Message-----
> From: Zheng, Ruoqin 
> 
> Hi Tim:
> 
> Last time you said:
> 
> > We do this often enough, that we should make a special case in the parser
> for
> > this exact sequence (maybe paramterized with a regular expression).
> >
> > Something like:
> > #!/usr/bin/python
> > sys.path.insert(0, os.environ['FUEGO_CORE'] + '/engine/scripts/parser')
> import
> > sys import common as plib regex_string = '^ -> (.*): TEST-(.*)$'
> > sys.exit(plib.collect_PASS_FAIL_testcases(regex_string))
> >
> > And, getting off on a tangent here, we should have the Fuego core add
> > $FUEGO_CORE/engine/scripts/parser to the python path, before calling
> the
> > parser module, and common.py should be renamed plib.py, so this could
> be
> > further reduced to:
> >
> > #!/usr/bin/python
> > import sys, plib
> > sys.exit(plib.collect_PASS_FAIL_testcases(regex_string))
> >
> > I don't suppose you would be willing to work on these changes to the
> parsing
> > core, would you?  That would be really helpful, and would make future
> parsers
> > much shorter.
> 
> My question is that if I rename common.py to plib.py,  it will affect other
> testcases or modules who have imported common.

Yes.  However, I was hoping that we could keep backwards compatibility
by having a symlink common.py to plib.py.  I haven't tested it, but I'm hoping 
it would work.

> 
> If so, should I modify all the testcases or modules?
That would be great, but if the symlink works, it wouldn't be a strong requirement.
I would like to change the import line for all parser modules that reference common.py

OK - I just looked, and there is already a python module called plib.  
See https://pypi.org/project/plib/

If we proceed with this change ,then it would be better to called the module something besides plib.
However, that ends up changing a lot more code, since all references to plib in the code, and not just
the import line, would have to change.  I think that is too big of a change, and I'd like to take the time to
figure out a good name that has no conflicts with other systems.

So, for now, just do the other parts I described.  But please do change other test's parser modules
to use the changes, where applicable. 

Thanks very much for working on this.
 -- Tim