[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[To CVS-Dev] CVS Directory Order and sanity.sh
From: |
Wayne_Johnson |
Subject: |
[To CVS-Dev] CVS Directory Order and sanity.sh |
Date: |
Thu, 25 Jan 2001 11:15:01 -0600 |
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?
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?
Thanks for your input.
- [To CVS-Dev] CVS Directory Order and sanity.sh,
Wayne_Johnson <=