1b6cee71dSXin LI 2b6cee71dSXin LI#------------------------------------------------------------------------------ 3*43a5ec4eSXin LI# $File: sccs,v 1.8 2020/06/20 21:32:52 christos Exp $ 4b6cee71dSXin LI# sccs: file(1) magic for SCCS archives 5b6cee71dSXin LI# 6*43a5ec4eSXin LI# SCCS v4 archive structure: 7b6cee71dSXin LI# \001h01207 8b6cee71dSXin LI# \001s 00276/00000/00000 9b6cee71dSXin LI# \001d D 1.1 87/09/23 08:09:20 ian 1 0 10b6cee71dSXin LI# \001c date and time created 87/09/23 08:09:20 by ian 11b6cee71dSXin LI# \001e 12b6cee71dSXin LI# \001u 13b6cee71dSXin LI# \001U 14b6cee71dSXin LI# ... etc. 15b6cee71dSXin LI# Now '\001h' happens to be the same as the 3B20's a.out magic number (0550). 16b6cee71dSXin LI# *Sigh*. And these both came from various parts of the USG. 17b6cee71dSXin LI# Maybe we should just switch everybody from SCCS to RCS! 18b6cee71dSXin LI# Further, you can't just say '\001h0', because the five-digit number 19b6cee71dSXin LI# is a checksum that could (presumably) have any leading digit, 20*43a5ec4eSXin LI# Fortunately we have regular expression matching: 21*43a5ec4eSXin LI0 string \001h 22*43a5ec4eSXin LI>2 regex [0-9][0-9][0-9][0-9][0-9]$ 23*43a5ec4eSXin LI>>8 string \001s\040 SCCS v4 archive data 24*43a5ec4eSXin LI>2 string V6,sum= SCCS v6 archive data 25