sccs-devel Mailing List for SCCS

Hello Justin.
Justin Goldberg wrote in
 <CAA...@ma...>:
 |The crash is referenced here:
 |https://sccs.sourceforge.net/sccs_vs_rcs.html
 |
 |Kirk McKusick was at UCB in 1984:
 |https://archive.is/fVnCS
 |
 |This post describes it as well, it is quoted below:
 |https://news.ycombinator.com/item?id=35891400
 |
 |"e40 39 days ago | parent | context | favorite | on: 50 years in
 |filesystems: 1984 BSD FFS
 |
 |I was at UCB during this time. Very exciting! Here's a story people may not
 |know:
 |The dump program, once the FFS was deployed, had not been modified to
 |backup the last fragment of a file (because it was smaller, possibly than
 |4k). There was a disk crash on the VAX with the BSD source code and the
 |disk company (Ampex, I think) came out and meticulously scrapped the bits
 |off the disk, so CSRG could recovered the source code. There was no
 |complete backup of it anywhere else.
 |
 |That was a fun, early lesson in "test your backups".
Interesting story, the response was very funny, too.
Jörg Schilling unfortunately died on 2021年10月10日, on a Sunday noon,
and one day before the first cold wave of the year arrived.
(At least here, i am about 443,59 kilometres away says Google.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

The crash is referenced here:
https://sccs.sourceforge.net/sccs_vs_rcs.html
Kirk McKusick was at UCB in 1984:
https://archive.is/fVnCS
This post describes it as well, it is quoted below:
https://news.ycombinator.com/item?id=35891400
"e40 39 days ago | parent | context | favorite | on: 50 years in
filesystems: 1984 BSD FFS
I was at UCB during this time. Very exciting! Here's a story people may not
know:
The dump program, once the FFS was deployed, had not been modified to
backup the last fragment of a file (because it was smaller, possibly than
4k). There was a disk crash on the VAX with the BSD source code and the
disk company (Ampex, I think) came out and meticulously scrapped the bits
off the disk, so CSRG could recovered the source code. There was no
complete backup of it anywhere else.
That was a fun, early lesson in "test your backups".
Sincerely,
Justin

Nothings wrong with communicating here...

Hi,
Is there an irc room or discord channel where to talk?

Hi,
since you mention SCCS-5.09, it may be that you use the separate distribution 
that is outdated (2 years old).
The most recent version is always inside the schilytools package.
It e.g. uses a different diff program (the fastest known) and this results in 
30% better performance. Other new features in the version from schilytools:
-	Smaller diffs for longer files, since bdiff is no longer used and
	the diff thus is no longer segmented.
-	SCCSv6 history files now fully support libe based diffs for binary
	files.
-	If SCCSv6 history files are selected, no UU-encode is used anymore
	for binary data.
-	Better support for the new mode that is neded for the upcomming
	v6 in project mode.
Christopher Chen <chr...@ca...> wrote:
> This is just a FYI, not a complaint. I'm glad someone is keeping it together.
> 
> I used gmake, and did a 'INS_BASE=/usr/local/'. As a result, I got:
> 
> > > which sccs
> > /usr/local/bin/sccs
Please note the text from README.compile:
 Note that INS_BASE=/usr/local needs to be specified for every operation 
 that compiles or links programs, as the path may be stored inside the 
 binaries. 
Unlike some programs like the Sun/Oracle compiler collection, that dynamically 
determine their installation directory, sccs has the strings compiled in.
As a result, you need to specify a non-standard installation directory (hello 
anno 1980 for /usr/local) while compiling the code and not only while 
installing. 
Jörg
-- 
EMail:jo...@sc... Jörg Schilling D-13353 Berlin
					Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

This is just a FYI, not a complaint. I'm glad someone is keeping it together.
I used gmake, and did a 'INS_BASE=/usr/local/'. As a result, I got:
> > which sccs
> /usr/local/bin/sccs
> > sccs get parse_tmax_sf.py 
>
> sccs SYSERR: cannot execute /opt/schily/ccs/bin/get
> No such file or directory
So, I created a symlink, as a workaround, which worked fine.
> # ls -l /opt/schily/ccs
> lrwxrwxrwx. 1 root root 14 May 23 01:51 /opt/schily/ccs -> /usr/local/ccs
Hope this helped. Thx!
Chris C.

I'm not sure whether this is a bug or not but
sccs create foo
doesn't just create SCCS/s.foo but also an empty file named ,foo (in the current directory). I was unable to find anyhing about this in the POSIX specification. Any ideas?
Cheers,Bogdan

Good evening,
is there any support for Windows 10 planned? Can I help to port SCCS? It looks like a tool that solves very specific problems for me. :-)
SK 

Jonathan Leffler wrote:
> The classic technique... was to use extra quotes to 
> break up the strings that could be identified as SCCS keywords. For 
> example, something along the lines of:
> 
> DATE=$(date +'%Y''%m%d-%H''%M''%S')
> Eventually I found an alternative, but roughly 
> equivalent, technique:
> 
> RCS/build.ids.sh <http://build.ids.sh>,v:tag=`date +JL-"%Y"%m"%d"."%H"%M"%S"` # SCCS!
> 
> This uses pairs of double quotes around `%X` units within the format 
> string (and the earliest version dates back to 2004).
> 
Thanks for the quick answer.
I've tested both your suggestions and they work with Schily SCCS.
scot

The classic technique, which I used extensively before I (reluctantly)
switched to RCS before the Y2K 'crisis', was to use extra quotes to break
up the strings that could be identified as SCCS keywords. For example,
something along the lines of:
DATE=$(date +'%Y''%m%d-%H''%M''%S')
That replacement uses $(...) in preference to `...`; it also uses single quotes
around the whole format string, and then within the string, uses adjacent
single quotes (not double quotes) to separate %M, %H or %Y from the
following %, etc. This requires no changes to SCCS; it merely requires
care when writing the script.
Because my current code is mainly stored in RCS, I no longer have to worry
as much about that (there are other problems instead), but I found a pair
of scripts in my bin directory:
isodate:fmt_c="%Y%m%d.%H%M%S" # Compact -- Beware SCCS
prodverstamp:else PRODVRSN="${BASEVRSN}.`date +%Y%m%d`" # Beware SCCS!
These are not protected from SCCS, but I have still noted that SCCS could
screw them up. The earliest version of both those files is after 2000. I
didn't find a pre-Y2K script that used any variation on the technique
because I didn't use the date formatting options in date all that often
back then. Eventually I found an alternative, but roughly equivalent,
technique:
RCS/build.ids.sh,v:tag=`date +JL-"%Y"%m"%d"."%H"%M"%S"` # SCCS!
This uses pairs of double quotes around `%X` units within the format string
(and the earliest version dates back to 2004).
All the examples are from my private set of scripts. They have more or
less inscrutable purposes.
On Wed, Aug 1, 2018 at 4:43 PM thinkunix <thi...@zo...> wrote:
> Hi,
>
> I have been using Schily SCCS for a while and it has worked
> great. Recently I ran into an issue with ID keyword expansion.
>
> I have a shell script which is setting a variable using the
> date(1) format controls, like so:
>
> ....................cut here....................
> :
> # datestring.sh
> #ident %W% %E% %U% %Q%
> #
>
> DATE=`date +%Y%m%d-%H%M%S`
> echo "DATE = [$DATE]"
> ....................cut here....................
>
> I check it into SCCS then check out a read-only copy which
> will have the ID keywords expanded using the following sequence:
>
> $ admin -idatestring.sh -y'initial version' s.datestring.sh
> $ rm datestring.sh
> $ get s.datestring.sh
> 1.1
> 7 lines
>
>
> The problem is the multiple '%' chars in the date(1) command
> are being expanded as though they were SCCS ID keywords.
> Obviously, this breaks the shell script.
>
> $ cat datestring.sh
>
> ....................cut here....................
> :
> # datestring.sh
> #ident @(#)datestring.sh 1.1 18/08/01 19:13:22
> #
>
> DATE=`date +m%d-08/01/18M%S`
> echo "DATE = [$DATE]"
> $ sh ./datestring.sh
> DATE = [m01-08/01/18M35]
> ....................cut here....................
>
>
> Historically date(1) lacked format strings, e.g. "+%Y%m%d",
> so this was never an issue.
>
> I tried "get -k" but that prevents expanding _ALL_ SCCS ID keywords,
> and I do want them for revision identification.
>
> I am running Slackware 14.2 on x86 with SCCS version:
> admin schily-SCCS version 5.05 2011年10月01日 (i686-pc-linux-gnu)
>
> I also tried:
> admin schily-SCCS version 5.08 2015年09月05日 (i686-pc-linux-gnu)
>
> with the same results.
>
> Any suggestions on how to work around this?
>
> I could call date(1) multiple times and build up the date string
> but that seems wasteful. Something like this:
>
> YEAR=`date +%Y`
> MONTH=`date +%m`
> DAY=`date +%d`
> ...
>
> TODAY="$YEAR$MONTH$DAY..."
>
> thanks,
> scot
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Sccs-devel mailing list
> Scc...@li...
> https://lists.sourceforge.net/lists/listinfo/sccs-devel
>
-- 
Jonathan Leffler <jon...@gm...> #include <disclaimer.h>
Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

Hi,
I have been using Schily SCCS for a while and it has worked
great. Recently I ran into an issue with ID keyword expansion.
I have a shell script which is setting a variable using the
date(1) format controls, like so:
....................cut here....................
:
# datestring.sh
#ident %W% %E% %U% %Q%
#
DATE=`date +%Y%m%d-%H%M%S`
echo "DATE = [$DATE]"
....................cut here....................
I check it into SCCS then check out a read-only copy which
will have the ID keywords expanded using the following sequence:
$ admin -idatestring.sh -y'initial version' s.datestring.sh
$ rm datestring.sh
$ get s.datestring.sh
1.1
7 lines
The problem is the multiple '%' chars in the date(1) command
are being expanded as though they were SCCS ID keywords.
Obviously, this breaks the shell script.
$ cat datestring.sh
....................cut here....................
:
# datestring.sh
#ident @(#)datestring.sh 1.1 18/08/01 19:13:22
#
DATE=`date +m%d-08/01/18M%S`
echo "DATE = [$DATE]"
$ sh ./datestring.sh
DATE = [m01-08/01/18M35]
....................cut here....................
Historically date(1) lacked format strings, e.g. "+%Y%m%d",
so this was never an issue.
I tried "get -k" but that prevents expanding _ALL_ SCCS ID keywords,
and I do want them for revision identification.
I am running Slackware 14.2 on x86 with SCCS version:
admin schily-SCCS version 5.05 2011年10月01日 (i686-pc-linux-gnu)
I also tried:
admin schily-SCCS version 5.08 2015年09月05日 (i686-pc-linux-gnu)
with the same results.
Any suggestions on how to work around this?
I could call date(1) multiple times and build up the date string
but that seems wasteful. Something like this:
YEAR=`date +%Y`
MONTH=`date +%m`
DAY=`date +%d`
...
TODAY="$YEAR$MONTH$DAY..."
thanks,
scot

>ca. line 131, the pattern '*s.*' matches e.g. filename text "mess.c",
>but shouldn't (that filename
>is not an SCCS file). The pattern should be '^s.*|*/s.*'. That would
>still incorrectly match a
>path containing a directory or subdirectory beginning with "s.", but
>presumably SCCS
>users wouldn't create such a directory... No change to the
>documentation is necessary.
Hi,
^ does not work as a wildchart in the shell language, but 
	s.*|*/s.*
would work.
Since this needs to match the whole string, it works as you intend.
Thank you for the hint.
Jörg
-- 
 EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
 joe...@fo... (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

ca. line 131, the pattern '*s.*' matches e.g. filename text "mess.c",
but shouldn't (that filename
is not an SCCS file). The pattern should be '^s.*|*/s.*'. That would
still incorrectly match a
path containing a directory or subdirectory beginning with "s.", but
presumably SCCS
users wouldn't create such a directory... No change to the
documentation is necessary.

Bruce Lilly <bru...@gm...> wrote:
> On Tue, Oct 13, 2015 at 12:23 PM, Joerg Schilling
> <Joe...@fo...> wrote:
> > Bruce Lilly <bru...@gm...> wrote:
> [...]
> > OK, I'll have to look at this....
> >
> > The fact that you do just the opposite of what is already on the sources makes
> > me suspect a problem in your solution.
>
> By all means check it; at the moment, the zone offset here is -14400 seconds,
> so to get UTC from local time, the zone offset must be subtracted (note the
> local times from script vs. the UTC time from date and in the files from my test
> case report).
Avoiding a warning is not a proof for correct implementation.
Last evening, I verified that your solution for dodelt.c is indeed incorrect.
I still need to find a solution that is not in conflict with the GMT hack in 
get(1) and delta(1) that was introduce for performance reasons on SunOS-4.x and 
Linux as these systems do not have a timezone offset cache like Solaris.
> > There are so many standards for time stamps, why do you believe that the ony
> > you selected is superior to others?
>
> It is compliant with a published de jure international standard (ISO 8601) and
> with standards derived from that, including the three freely available ones
> mentioned in my initial bug report message, and with those based on it
> and/or the latter three (e.g. W3C, XML, and RFC 5424). ISO 8601 is also
> the basis for many national standards, such as DIN ISO 8601, BS EN 28601,
> and ANSI INCITS 30-1997 (R2008). Others referencing ISO 8601 include
> DoD 5015.2 STD (http://www.dtic.mil/whs/directives/corres/pdf/501502std.pdf).
OK, I checked that DIN ISO 8601 was marked to replace DIN 1355, so it seems to 
be the major time format standard nowerdays.
> As far as I know, none of the ones presently used in SCCS are compliant with
> any de jure international standard.
Well, SCCS started in 1972 in the USA and it seems that it initially used the 
strange US date conventions.
All time stamp notations used by SCCS except for those in the s-files are part 
of the POSIX standard and as a result part of an international standard.
> The ones in SCCS are particularly bad: if a gotten file says 10/11/12
> for the date, the meaning depends on whether it came from %E% or %G%,
> and there's no clue in the file itself!
This is a result of the fact that US people introduced a date notation that is 
in conflict with any notation in the rest of the world. It seems that the UNIX 
people have been aware about this problem early and introduced alternate date 
formats.
It may be a useful enhancement to let SCCS optionally create DIN ISO 8601 time 
stamps at places that are not important for internal file formats. This seems 
to be expanded get(1) keywords for now. Do you know about other places that may 
be of interest?
It may also be useful to permit SCCS to be able to read cutoff time stamps in 
that format.
Given that I already mentioned that extended (what was not present in February 
1977 with SCCSv4) keyword definitions should be disabled by default to avoid 
unpredictable problems, I recommend the following new keyletters:
	%t%	Current time in RFC 3339 format: yyy-mm-ddThh:mm:ss[.frac][+|-}hh:mm]
	%u%	Newest applied delta time in RFC 3339 format: yyy-mm-ddThh:mm:ss[.frac][+|-}hh:mm]
Lower case keywords are disabled by default and need to be swiched on via 
admin(1) to be usable.
> >> But the p-file isn't, and the existing format suffer from all of the
> >> problems that you noted (and more):
> >
> > This is not a problem, as p-files are temporary files and as the timestamps in
> > these files are not used for storing anything in the history file.
>
> If a goal is for a distributed version control system, the p-files may
> be visible
> and the ambiguities (timestamp issues being only part of the problem) are
> relevant. This is even the case for a single multiuser system (note that
> different users, possibly connecting remotely via ssh or similar, might
> have different environment TZ settings).
It is a pity that POSIX did not think about this possibility but we have to 
live with it. Because these time stamps are only used for informational 
purposes: "user xxx did edit this file at yyy", I do not see a real problem 
resulting from this local time format.
It may be that the reason why POSIX did define any semi permanent and permanent
file content but the s-file format is a result of the fact that AT&T offers 
"sablime" which is a hacked SCCS with binary history files.
In case of a SCCS configuration that disables concurrent edits, you may use 
filesystem timestamps from p-files.
In the other case, you will still know which edit started earlier, as the new 
content is appended to the existing p-file. I see no reason, why this 
informational time stamp needs to be more accurate than a day.
Jörg
-- 
 EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
 joe...@fo... (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

On Tue, Oct 13, 2015 at 12:23 PM, Joerg Schilling
<Joe...@fo...> wrote:
> Bruce Lilly <bru...@gm...> wrote:
[...]
> OK, I'll have to look at this....
>
> The fact that you do just the opposite of what is already on the sources makes
> me suspect a problem in your solution.
By all means check it; at the moment, the zone offset here is -14400 seconds,
so to get UTC from local time, the zone offset must be subtracted (note the
local times from script vs. the UTC time from date and in the files from my test
case report).
[...]
>> The purpose is to provide expansion of date-time in standard format.
>
> There are so many standards for time stamps, why do you believe that the ony
> you selected is superior to others?
It is compliant with a published de jure international standard (ISO 8601) and
with standards derived from that, including the three freely available ones
mentioned in my initial bug report message, and with those based on it
and/or the latter three (e.g. W3C, XML, and RFC 5424). ISO 8601 is also
the basis for many national standards, such as DIN ISO 8601, BS EN 28601,
and ANSI INCITS 30-1997 (R2008). Others referencing ISO 8601 include
DoD 5015.2 STD (http://www.dtic.mil/whs/directives/corres/pdf/501502std.pdf).
In addition the format is used nearly ubiquitously in computing:
https://technet.microsoft.com/en-us/library/ms190977%28v=sql.90%29.aspx
http://www.w3.org/QA/Tips/iso-date
http://www.w3.org/TR/NOTE-datetime
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#isoformats
http://microformats.org/wiki/iso-8601
http://www.uic.edu/depts/accc/software/isodates/index.html
http://support.sas.com/documentation/cdl/en/leforinforref/64790/HTML/default/viewer.htm#p1a0qt18rxydrkn1b0rtdfh2t8zs.htm
http://php.net/manual/en/function.date.php
https://www.gnu.org/software/emacs/manual/html_node/calc/ISO-8601.html
http://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-DATETIME-DATE-TABLE
http://filmstandards.org/fiaf/wiki/doku.php?do=export_raw&id=date_types
http://code.logos.com/blog/2009/04/datetime_and_iso8601.html
Need more examples?:
https://duckduckgo.com/?q=ISO+8601&ia=about
As far as I know, none of the ones presently used in SCCS are compliant with
any de jure international standard.
The ones in SCCS are particularly bad: if a gotten file says 10/11/12
for the date, the meaning depends on whether it came from %E% or %G%,
and there's no clue in the file itself!
ISO 8601 and its derivatives always present components from most to
least significant: years, months, days, hours, minutes, seconds; the
text version can therefore be easily sorted chronologically.
See http://www.iso.org/iso/home/standards/iso8601.htm and
https://en.wikipedia.org/wiki/ISO_8601
The major disadvantage of ISO 8601 per se (aside from the price) is the
many cases of exceptions allowed "by mutual agreement" which isn't
possible for published documents. The three freely available standards
which I mentioned do not suffer from that defect.
>> > The format of the s.files is bejond POSIX.
>>
>> But the p-file isn't, and the existing format suffer from all of the
>> problems that you noted (and more):
>
> This is not a problem, as p-files are temporary files and as the timestamps in
> these files are not used for storing anything in the history file.
If a goal is for a distributed version control system, the p-files may
be visible
and the ambiguities (timestamp issues being only part of the problem) are
relevant. This is even the case for a single multiuser system (note that
different users, possibly connecting remotely via ssh or similar, might
have different environment TZ settings).

Bruce Lilly <bru...@gm...> wrote:
> > Could you please give a test case for the problem you have in mind?
>
> With prs.c patched but w/o the patch to dodelt.c:
>
> Script started on Tue Oct 13 11:48:58 2015
> # date -u +%%Z%%%Y-%m-%dT%H:%M:%SZ > test.txt
> # /opt/schily/ccs/bin/admin -itest.txt s.test.txt
> # rm test.txt
> # /opt/schily/ccs/bin/get s.test.txt
> Time stamp later than current clock time (co10)
> 1.1
> 1 lines
> # head -99 test.txt s.test.txt
> ==> test.txt <==
> @(#)2015年10月13日T15:49:03Z
>
> ==> s.test.txt <==
> h09367
> s 00001/00000/00000
> d D 1.1 15/10/13 15:49:09 root 1 0
> c date and time created 15/10/13 15:49:09 by root
> e
> u
> U
> f e 0
> G r
> t
> T
> I 1
> %Z%2015年10月13日T15:49:03Z
> E 1
> #
>
> Script done on Tue Oct 13 11:49:55 2015
>
> Note the erroneous co10 error message.
OK, I'll have to look at this....
The fact that you do just the opposite of what is already on the sources makes 
me suspect a problem in your solution.
> >> Related features added:
> >>
> >> * %N% and %O% keywords added and documented.
> >>
> >> These are for current date-time and last applied delta date-time,
> >> respectively. Format is standard date-time format as documented in:
> >
> > What is the main purpose for this modification?
>
> The purpose is to provide expansion of date-time in standard format.
There are so many standards for time stamps, why do you believe that the ony 
you selected is superior to others?
> > The format of the s.files is bejond POSIX.
>
> But the p-file isn't, and the existing format suffer from all of the
> problems that you noted (and more):
This is not a problem, as p-files are temporary files and as the timestamps in 
these files are not used for storing anything in the history file.
Jörg
-- 
 EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
 joe...@fo... (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

Partial response:
On Tue, Oct 13, 2015 at 8:44 AM, Joerg Schilling
<Joe...@fo...> wrote:
> Bruce Lilly <bru...@gm...> wrote:
>
>> This started as a bug-fix for prs.c, which wouldn't compile with
>> -DGMT_TIME. During testing, I found several related bugs, and added some
>> related features which I've been using locally for some time. These may
>> help with v6.
>
> No, SCCSv6 does not need the workaround introduced by Sun between 1990 and 2006.
> This is because SCCS now supports much better and unique time stamp handling
> that includes GMT-offset.
>
>> Related bugs fixed:
>>
>> * Incorrect time (not corrected for zone offset) resulting in warnings
>> about retrieval time being older than delta time (noticeable West of the
>> Prime Meridian).
>
> Could you please give a test case for the problem you have in mind?
With prs.c patched but w/o the patch to dodelt.c:
Script started on Tue Oct 13 11:48:58 2015
# date -u +%%Z%%%Y-%m-%dT%H:%M:%SZ > test.txt
# /opt/schily/ccs/bin/admin -itest.txt s.test.txt
# rm test.txt
# /opt/schily/ccs/bin/get s.test.txt
Time stamp later than current clock time (co10)
1.1
1 lines
# head -99 test.txt s.test.txt
==> test.txt <==
@(#)2015年10月13日T15:49:03Z
==> s.test.txt <==
h09367
s 00001/00000/00000
d D 1.1 15/10/13 15:49:09 root 1 0
c date and time created 15/10/13 15:49:09 by root
e
u
U
f e 0
G r
t
T
I 1
%Z%2015年10月13日T15:49:03Z
E 1
#
Script done on Tue Oct 13 11:49:55 2015
Note the erroneous co10 error message.
>> Related features added:
>>
>> * %N% and %O% keywords added and documented.
>>
>> These are for current date-time and last applied delta date-time,
>> respectively. Format is standard date-time format as documented in:
>
> What is the main purpose for this modification?
The purpose is to provide expansion of date-time in standard format.
> Note that upper case keywords as extensions are not a good idea as they are
> always enabled by default and thus cause compatibility problems with older SCCS
> versions.
>
> ...
>> Examples:
>> %N% 2015年10月11日T17:55:49.104271752Z
>> %O% 2015年10月11日T11:45:16Z
>>
>> * Improved parsing of date and time.
>>
>> In case XPG decides to allow or require standard format date-time in the
>> s-file.
>
> The format of the s.files is bejond POSIX.
But the p-file isn't, and the existing format suffer from all of the
problems that you noted (and more):
[...]
> possible but still make the known problems disappear. The problems have been:
>
> - 2-digit years is a real problem, fixed by using 4+ digits in V6
>
> - local time without GMT-offset causes undeterminable time stamps.
> The problem is even present when always operating in the same timezone
> as there are DST switches that may the time to appear going backwards.
> Fixed by always adding a GMT offset.
>
> - coarse time resolution, fixed by optional second fraction up to
> nanosecond resolution.

Bruce Lilly <bru...@gm...> wrote:
> This started as a bug-fix for prs.c, which wouldn't compile with
> -DGMT_TIME. During testing, I found several related bugs, and added some
> related features which I've been using locally for some time. These may
> help with v6.
No, SCCSv6 does not need the workaround introduced by Sun between 1990 and 2006.
This is because SCCS now supports much better and unique time stamp handling 
that includes GMT-offset.
> Related bugs fixed:
>
> * Incorrect time (not corrected for zone offset) resulting in warnings
> about retrieval time being older than delta time (noticeable West of the
> Prime Meridian).
Could you please give a test case for the problem you have in mind?
> Related features added:
>
> * %N% and %O% keywords added and documented.
>
> These are for current date-time and last applied delta date-time,
> respectively. Format is standard date-time format as documented in:
What is the main purpose for this modification?
Note that upper case keywords as extensions are not a good idea as they are
always enabled by default and thus cause compatibility problems with older SCCS 
versions.
...
> Examples:
> %N% 2015年10月11日T17:55:49.104271752Z
> %O% 2015年10月11日T11:45:16Z
>
> * Improved parsing of date and time.
>
> In case XPG decides to allow or require standard format date-time in the
> s-file.
The format of the s.files is bejond POSIX.
This is why SCCSv6 will still be POSIX compliant as the s-file format changes 
are outside of the specification. 
The goal for the SCCSv4 vs. SCCSv6 format change was to chnage as few things as 
possible but still make the known problems disappear. The problems have been:
-	2-digit years is a real problem, fixed by using 4+ digits in V6
-	local time without GMT-offset causes undeterminable time stamps.
	The problem is even present when always operating in the same timezone
	as there are DST switches that may the time to appear going backwards.
	Fixed by always adding a GMT offset.
-	coarse time resolution, fixed by optional second fraction up to 
	nanosecond resolution.
> Incidentally, "GMT" is ambiguous and is considered archaic; better to use
> "UTC". Refer to:
As UNIX does not use leap seconds, I believe there is no difference on UNIX.
Jörg
-- 
 EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
 joe...@fo... (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

Bruce Lilly <bru...@gm...> wrote:
> Looking at The Open Group Base Specifications Issue 7 IEEE Std 1003.1,
> 2013 Edition, I see
> "The get utility shall conform to XBD Utility Syntax Guidelines .",
> so "-rsid" would not be permissible per Guideline 6 (sid, as a mandatory
> option argument must be separate from the -r flag), and the page for get there
> shows that. But that's another issue.
This is a missinterpretation of the standard.
The correct interpretation is that:
1) The man page must document the behavior. If both variants are OK, both need 
 to be mentioned.
2) A utility that supports the (to be avoided) optional option arguments must 
 support the single arg variant.
3) In other cases, the utility may support the single arg variant.
Note that SCCS was converted to use getopt() very late. This happened with the 
changes for SVr4.So e.g. SunOS-5.0 from around 1990 uses getopt() in SCCS while 
SunOS-4.1.X from 1992... still does not use getopt().
Given that it is not POSIX goal to break things, SCCS must support the single 
arg version, but this has to be documented.
The main effective difference between bin/get and xpg4/bin/get is that 
xpg4/bin/get creates an empty (so called g-) file in case you specify a 
non-existent SID, while bin/get aborts only with an error message but with no 
file created.
Note that the NSE enhancements from SCCS actively support optional option 
arguments. But even standard behavior (see admin command) uses POSIX documented 
optional option arguments.
> > Given that the man pages are originally taken from OpenSolaris, I would like to
> > keep the /usr/ccs and /usr/xpg4 paths intact. Yould you be OK with a NOTE that
> > explains that /usr/ has to be replaced by the "installation base" directory?
>
> I suppose so; better would be to make those the default installation
> locations (I
> suspect that there are very few people with anything under /opt/schily
> in $PATH)...
I guess that most people that compile/install will use /opt/schily while dostro 
creators usually chose a different installation base.
Jörg
-- 
 EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
 joe...@fo... (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

Comments in-line below.
On Tue, Oct 13, 2015 at 6:43 AM, Joerg Schilling
<Joe...@fo...> wrote:
> Bruce Lilly <bru...@gm...> wrote:
[...]
>> The man pages also have these locations baked in, for example:
>>
>> /usr/ccs/bin/get [-beFgkmnopst] [-l [p]] [-asequence]
>> /usr/xpg4/bin/get [-beFgkmnopst] [-l [p]] [-asequence]
>> /usr/ccs/bin/get
>> /usr/xpg4/bin/get
>> -rsid Same as for /usr/ccs/bin/get except that SID is mandatory.
>> -xsid-list Same as for /usr/ccs/bin/get except that sid-list is
>> /usr/ccs/bin/get
>> The output format for /usr/ccs/bin/get is as follows:
>> /usr/xpg4/bin/get
>> The output format for /usr/xpg4/bin/get is as follows:
>> /usr/ccs/bin/get
>> /usr/xpg4/bin/get
>>
>>
>> Obviously, neither the README.SCCS nor the generated man pages reflect the
>> actual install location, which is /opt/schily/....
>
> Most of the locations in the man files that mention a PATH use this to distinct
> bewteen different compile options (e.g. traditional UNIX vs. X-OPEN issue 4).
>
> Note that X-OPEN issue 4 is POSIX.1-1990 with a state from 1992. That standard
> rearranged the rules for Utility Syntax Guidelines and needs a slightly
> modified command line (option) parser.
Looking at The Open Group Base Specifications Issue 7 IEEE Std 1003.1,
2013 Edition, I see
"The get utility shall conform to XBD Utility Syntax Guidelines .",
so "-rsid" would not be permissible per Guideline 6 (sid, as a mandatory
option argument must be separate from the -r flag), and the page for get there
shows that. But that's another issue.
> Given that the man pages are originally taken from OpenSolaris, I would like to
> keep the /usr/ccs and /usr/xpg4 paths intact. Yould you be OK with a NOTE that
> explains that /usr/ has to be replaced by the "installation base" directory?
I suppose so; better would be to make those the default installation
locations (I
suspect that there are very few people with anything under /opt/schily
in $PATH)...

Bruce Lilly <bru...@gm...> wrote:
> The 5.08 distributed README.SCCS lists installation locations:
>
> $ egrep "usr/ccs|usr/xpg4" README.SCCS
>
> The binaries install to /usr/ccs/bin & /usr/xpg4/bin
> to a different dir than /usr/ccs, you need to edit all *.c files in the
> If you like to use sccs, you need to add /usr/ccs/bin to your PATH.
Thank you for the hint! This file is nownearly 9 years old and it was never 
really uptated to reflect the enhancements.
>
> The man pages also have these locations baked in, for example:
>
> /usr/ccs/bin/get [-beFgkmnopst] [-l [p]] [-asequence]
> /usr/xpg4/bin/get [-beFgkmnopst] [-l [p]] [-asequence]
> /usr/ccs/bin/get
> /usr/xpg4/bin/get
> -rsid Same as for /usr/ccs/bin/get except that SID is mandatory.
> -xsid-list Same as for /usr/ccs/bin/get except that sid-list is
> /usr/ccs/bin/get
> The output format for /usr/ccs/bin/get is as follows:
> /usr/xpg4/bin/get
> The output format for /usr/xpg4/bin/get is as follows:
> /usr/ccs/bin/get
> /usr/xpg4/bin/get
>
>
> Obviously, neither the README.SCCS nor the generated man pages reflect the
> actual install location, which is /opt/schily/....
Most of the locations in the man files that mention a PATH use this to distinct 
bewteen different compile options (e.g. traditional UNIX vs. X-OPEN issue 4).
Note that X-OPEN issue 4 is POSIX.1-1990 with a state from 1992. That standard 
rearranged the rules for Utility Syntax Guidelines and needs a slightly 
modified command line (option) parser.
Given that the man pages are originally taken from OpenSolaris, I would like to 
keep the /usr/ccs and /usr/xpg4 paths intact. Yould you be OK with a NOTE that 
explains that /usr/ has to be replaced by the "installation base" directory?
Jörg
-- 
 EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
 joe...@fo... (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

This started as a bug-fix for prs.c, which wouldn't compile with
-DGMT_TIME. During testing, I found several related bugs, and added some
related features which I've been using locally for some time. These may
help with v6.
Related bugs fixed:
 * Incorrect time (not corrected for zone offset) resulting in warnings
 about retrieval time being older than delta time (noticeable West of the
 Prime Meridian).
Related features added:
 * %N% and %O% keywords added and documented.
 These are for current date-time and last applied delta date-time,
 respectively. Format is standard date-time format as documented in:
 1. CCSDS 301.0-B-4 section 3.5 type A and B formats
 * http://public.ccsds.org/publications/archive/301x0b4e1.pdf
 2. EDSC EX000013.1
 * Http://www.exchangenetwork.net/standards/
 Rep_Date_Time_01_06_2006_Final.pdf
 3. RFC 3339
 * https://www.ietf.org/rfc/rfc3339.txt
 Note: all of the above are freely available at the URIs provided. They
 are all based on ISO 8601 (which is not freely available and is
 expensive).
 Examples:
 %N% 2015年10月11日T17:55:49.104271752Z
 %O% 2015年10月11日T11:45:16Z
 * Improved parsing of date and time.
 In case XPG decides to allow or require standard format date-time in the
 s-file.
Incidentally, "GMT" is ambiguous and is considered archaic; better to use
"UTC". Refer to:
 * http://www.ucolick.org/~sla/leapsecs/timescales.html
 and the references therein, especially:
 * http://articles.adsabs.harvard.edu/full/1978QJRAS..19..290S
Patch attached.

The 5.08 distributed README.SCCS lists installation locations:
 $ egrep "usr/ccs|usr/xpg4" README.SCCS
 The binaries install to /usr/ccs/bin & /usr/xpg4/bin
 to a different dir than /usr/ccs, you need to edit all *.c files in the
 If you like to use sccs, you need to add /usr/ccs/bin to your PATH.
The man pages also have these locations baked in, for example:
 /usr/ccs/bin/get [-beFgkmnopst] [-l [p]] [-asequence]
 /usr/xpg4/bin/get [-beFgkmnopst] [-l [p]] [-asequence]
 /usr/ccs/bin/get
 /usr/xpg4/bin/get
 -rsid Same as for /usr/ccs/bin/get except that SID is mandatory.
 -xsid-list Same as for /usr/ccs/bin/get except that sid-list is
 /usr/ccs/bin/get
 The output format for /usr/ccs/bin/get is as follows:
 /usr/xpg4/bin/get
 The output format for /usr/xpg4/bin/get is as follows:
 /usr/ccs/bin/get
 /usr/xpg4/bin/get
Obviously, neither the README.SCCS nor the generated man pages reflect the
actual install location, which is /opt/schily/....

Hi,
I just published a development snapshot at:
	http://sourceforge.net/projects/schilytools/files/
schily-2015年03月03日.tar.bz2
that is close to be able to support more than single files.
I am interested in thoughts ....
Jörg
-- 
 EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin
 joe...@fo... (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'