Re: [Bug-cssc] Test delta/errorcase.sh -> E30 .. E32

[Joerg Schilling]

James Youngman <address@hidden> wrote:

> > It tests whether it is possible to create an encoded SCCS history file by
> > calling:
> >
> >        admin -b -n s.foo
> >
> > As this does not match the documented behavior for SCCS, it is not expected 
> > to
> > succeed.
>
> That is common behaviour.   But it's not documented behaviour.  At
> least, it's not documented in a place where many users will see it.
> Pulling a fragment from a SUNOS 5.10 manpage from the web:
> """
> -b
>
> Forces encoding of binary data. Files that contain ASCII NUL or other
> control characters, or that do not end with a NEWLINE, are recognized
> as binary data files. The contents of such files are stored in the
> history file in encoded form. See uuencode(1C) for details about the
> encoding. This option is normally used in conjunction with -i to force
> admin to encode initial versions not recognized as containing binary
> data.
> """
>
> Note "is normally used" not "can only be used".

OK, this might permit -n -b

> >        docommand E28 "${admin} -b -n -i/dev/null $s" 0 IGNORE IGNORE
> >
> > Will match the SCCS documentation....
> >
> >
> > The background for my mail is that there are more than 1100 tests in your 
> > suite
> > and only three of them fail with SCCS:
> >
> >        delta/errorcase.sh E28 (se above)
> >                                                This test as implemented by 
> > you
> >                                                does not match the documented
> >                                                behavior and I believe that 
> > the
> >                                                man page is correct here and
> >                                                you should chnage your test.
>
> I've never seen documentation stating that "-b -n" is not allowed but
> "-b -n -i/dev/null" is allowed.   I agree it is the historic
> behaviour, but frankly I've always considered that to be an oversight
> in the Sun implementation.

Sun added a lot of nice minor enhancements that have never been documented 
(probably because this was a feature intended for NSE and because NSE has been 
withdrain around 1990).

I am currently under way of adding the missing documentation and I am under way 
of adding missing minor features that make sense in the area of these features.

        admin "-fi%W% %E% %Q%"

e.g. will cause admin -i or later delta's to abort with an error in case that 
the 
ID string "%W% %E% %Q%" was found on no line.

Yesterday, I added the inverse feature:

        admin -fy 

will switch off the warning "No id keywords (cm7)" in case that there was no
keyword expanded. Sun's SCCS did already supress this warning when in NSE mode.

I also added a new -o (original date) option to "admin" and "delta" as the 
related feature exists since 1987 as default in NSE mode (using -q). For 
orthogonality I yesterday added -o to "get" too.

> I don't really see a case here for disallowing -b without -i, when the
> user's intent is clear and for decades the SCCS documentation didn't
> point out that -b is not allowed without -i.

Well, the related code is only in the -i code path. The behavior thus seems to 
be indented this way by Sun.

==>     I however could be convinced to permit admin -b -n


> >        admin/r-option.sh.
> >        docommand t5 "${admin} -n -r2 $s" 1 "" IGNORE
> >                                                Here you are aligned with the
> >                                                documentation, but I am
> >                                                interested to change the
> >                                                documentation as SCCS started
> >                                                to asume -n in case -i was
> >                                                specified and SCCS now 
> > permits
> >                                                -r with both -n and -i (which
> >                                                looks useful).
>
> The only use I can think of offhand is the initialisation of multiple
> SCCS files with empty bodies at a revision greater than 1.   I concede
> that there may be a use case for it.    I'm a little concerned that
> this could result in people writing shell scripts which don't work on
> older versions of SCCS but that's always a risk with any functional
> change.

SVr4 permits -r only with -i, so this is a Solaris change. I have no idea when 
it has been introduced. As mentioned, I believe it is useful.

==>     I just like to inform you that there should be no test that expects to 
        see "admin -r2 -n s.foo" to fail.

Regarding portability of scripts, we could make the documentation in a way that 
permits admin -r -n to fail, e.g. by the hint: "max not work with onther SCCS 
versions".

I am sure that you know that the existence of --something in many GNU tools did 
already result in many non-portable scripts and there is no man page that warns 
of using --something.



> >        binary/auto.sh
> >        test_ascii fa11 "x\000y\n"              Is expected to succeed and 
> > not
> >                                                to fail as you asume, as it
> >                                                matches the way Sun 
> > implemented
> >                                                it.
>
> I hope my previous email on this subject helped clear up this
> misunderstanding.  The CSSC regression test suite does not *expect*
> this test to fail for SCCS.   In fact this test is *not carried out at
> all* on SCCS.   If this test is run, somehow on an implementation of
> SCCS, it may fail, or it may not fail, depending on the SCCS
> implementation.

Well, I tried to inform you that you may enable _many_ other tests for a recent 
SCCS. There currently are just three tests that fail in case you enable all of 
these tests.

If you don't include code in CSSC that automatically switches to binary 
(encoded) mode, why did you write this test?


> > Given the fact that the current SCCS implementation can be identified by 
> > calling
> >
> >        sccs -V
> >
> >        Output is:
> >                sccs schily-SCCS version 1.00.05 2011/04/20 
> > (i386-pc-solaris2.11)
> >        or similar
> >
> > it would be nice if all tests could be called and passed by both, the 
> > current
> > CSSC and the current SCCS.
>
> I also think that would be a good idea.

Thank you

> > Conclusion:
> >
> >        E28     should be changed to match the documented behavior.
> I disagree, because this behaviour is not documented, and the user's
> intent is clear.

Let me quote the POSIX standard:

-i[name]
    Specify the name of a file from which the text for a new SCCS file shall be 
    taken. The text constitutes the first delta of the file (see the -r option 
    for the delta numbering scheme). If the -i option is used, but the name 
    option-argument is omitted, the text shall be obtained by reading the 
    standard input. If this option is omitted, the SCCS file shall be created
    with control information but without any file data. The -i option implies
    the -n option.

The last sentence is in conflict with historic SCCS behavior, but Sun chnaged 
their copy to match POSIX. POSIX does not mention that -n if exquivalent, but 
if we agree that the last sentence from POSIX -i should be interpreted to:
"The options -n -and -i are equivalent except for the parameter to -i", then
I would need to permit "admin -b -r s.foo" with SCCS.

You however would then also need to permit "admin -r2 -n s.foo" with CSSC for 
orthogonality.

>
> >        fa11    should be changed to match observed behavior from SCCS since
> >                1987
> This test shouldn't be run on SCCS, so I think this is moot.

If you just see it as a test to verify that nobody changes CSSC to 
automatically switsch to binary mode, you may be right.


> >        t5      We need to discuss whether it is better to match observed
> >                behavior from SCCS from Solaris (SVR4 behaves as documented)
> >                or whether it seems to be better to follow the documented
> >                behavior.
>
> Let's try to be unambiguous here.   The SunOS 5.10 manpage says of
> "-r", " -r may be used only in conjunction with -i".   However, the
> POSIX 2008 standard does not require this.   Hence I suppose a strict
> reading of the text of the POSIX standard would imply that  "admin -n
> -r2 s.foo" should succeed, as you suggest.

See above....

> It seems to me that we may be able to get this fixed as a bug in the
> commercial Unix vendors' SCCS implementations, too.    We can deal
> with that in a separate thread.

Do you have contact to the related people?

Jörg

-- 
 EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden                (uni)  
       address@hidden (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily