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

[Wayne_Johnson]

---------------------- Forwarded by Wayne Johnson/MINN/Candle on 01/25/2001
04:16 PM ---------------------------


William Schoen <wjs@US.IBM.COM> on 01/25/2001 04:11:18 PM

Please respond to MVS OpenEdition <MVS-OE@VM.MARIST.EDU>

To:   MVS-OE@VM.MARIST.EDU
cc:    (bcc: Wayne Johnson/MINN/Candle)
Subject:  Re: [To CVS-Dev] CVS Directory Order and sanity.sh



Correct.  readdir does not give any guarantee of order and different file
system types will return names in different order.

Bill Schoen


Wayne Johnson <Wayne_Johnson@CANDLE.COM>@VM.MARIST.EDU> on 01/25/2001
04:46:24 PM

Please respond to MVS OpenEdition <MVS-OE@VM.MARIST.EDU>

Sent by:  MVS OpenEdition <MVS-OE@VM.MARIST.EDU>


To:   MVS-OE@VM.MARIST.EDU
cc:
Subject:  Re: [To CVS-Dev] CVS Directory Order and sanity.sh



>From the research and responses I've gotten so far, it sounds like
opendir/readdir does not honor LC_ALL (or it's cousin LC_COLLATE).  In
fact,
there appears to be no guarantee as to what order things get returned, at
least
the man pages are strangely quite in this matter.

Anyone find otherwise?

I have been coding alternate responses for the various locations where the
files
come in a different order, but when we get into remote CVS services, it'll
be
interesting to see if we get the MVS order or the UNIX order.

Thanks.





"Derek R. Price" <derek.price@openavenue.com> on 01/25/2001 03:34:25 PM

To:   Wayne Johnson/MINN/Candle@Candle
cc:   MVS-OE@VM.MARIST.EDU, bug-cvs@gnu.org, info-cvs@gnu.org
Subject:  Re: [To CVS-Dev] CVS Directory Order and sanity.sh



I cc'd bug-cvs@gnu.org since more of the technical development discussions
seem
to
go on there.  Replies can probably safely remove info-cvs@gnu.org from the
cc
list.

Wayne_Johnson@candle.com 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:dprice@openavenue.com     OpenAvenue ( http://OpenAvenue.com )
--
Information is the currency of democracy.

                        - Thomas Jefferson