Re: [To CVS-Dev] CVS Directory Order and sanity.sh

[Derek R. Price]

I cc'd address@hidden since more of the technical development discussions seem 
to
go on there.  Replies can probably safely remove address@hidden from the cc 
list.

address@hidden wrote:

> I've almost got the CVS for MVS (AKA OS/390) port working, including binary 
> and
> compression.  At this point I'm trying to get through sanity.sh but am having 
> a
> few problems.
>
> 1) Some of IBM's system messages like "update: cannot open CVS/Entries for
> reading: No such file or directory" actually come out as "update: cannot open
> CVS/Entries for reading:  EDC5129I No such file or directory.".  This is 
> pretty
> easily avoided by changing the regexp to "update: cannot open CVS/Entries for
> reading: .*".  Is this acceptable?

I'd prefer, "update: cannot open CVS/Entries for reading: .*No such file or
directory\.?".  The more data you can include and still match both cases, the
better.

(Is '?' valid?  I forget.  You might have to use \.* on the end there)


> 2) It seems that quite often the order that files are processed is different 
> on
> MVS.  For example, in basicb-7, the output that is expected is:
>  'T Emptydir/sfile1
> T sdir2/sfile2'
>
> but on MVS it's:
> 'T sdir2/sfile2
> T Emptydir/sfile1'
>
> I am assuming that the change is due to a different collating sequence between
> ASCII and EBCDIC.  My question is, shouldn't LC_COLLATE=C fix this?  I looked 
> in
> the opendir/readdir function descriptions on several different UNIX (UNII?) 
> and
> LINUX docs and none mention the order that these files/directories should be
> listed, nor use of LC_COLLATE.
>
> Is this a hole in the tests?  If the order of files returned by 
> opendir/readdir
> if undefined, should they be written a bit more specific, such that the
> individual directories/files to be used in the test be explicitly listed in 
> the
> command?  Or should I just put a MVS specific bypass in the tests to expect 
> the
> alternate order?

I believe sanity.sh relies on setting LC_ALL=C to preserve sorting order and 
other
tidbits.  Not sure what that does to C code.

I would say that my preferred solutions, in order of preference, are:

1)  Get the C code to return file lists in the correct order somehow, 
especially if
this is as simple as setting an environment variable, which it might well be.
2)  Use dotest_sort instead of dotest to compare the result.
3)  Use the ability of dotest to pass multiple patterns to add a pattern for 
MVS.

I'd try and put some extra effort into #1 simply because each test using
dotest_sort means more possibly undesirable changes to the code which can get 
past
the test suite.

Maybe a variation on dotest_sort that is smart enough to extract a file list and
only sort those lines?  This would preserve most of the important information,
I think.  'dotest_sort_files'?

Second opinions?

P.S. the man page on my system with a list of the localization settings is
locale(7).  It seems to imply that LC_ALL=C (which sanity.sh sets and exports)
should do the trick if anything should, which is corroborated by what I've read 
on
writing portable shell code, but maybe there's something different on VMS?

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden     OpenAvenue ( http://OpenAvenue.com )
--
Information is the currency of democracy.

                        - Thomas Jefferson