bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Wayne_Johnson
Subject: Re: [To CVS-Dev] CVS Directory Order and sanity.sh
Date: Thu, 25 Jan 2001 15:46:24 -0600


>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" <address@hidden> on 01/25/2001 03:34:25 PM

To:   Wayne Johnson/MINN/address@hidden
cc:   address@hidden, address@hidden, address@hidden
Subject:  Re: [To CVS-Dev] CVS Directory Order and sanity.sh



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










reply via email to

[Prev in Thread] Current Thread [Next in Thread]