1*36c0c0feStedu# $OpenBSD: sccs,v 1.3 2004/06/03 03:14:20 tedu Exp $ 2df930be7Sderaadt 3df930be7Sderaadt#------------------------------------------------------------------------------ 4df930be7Sderaadt# sccs: file(1) magic for SCCS archives 5df930be7Sderaadt# 6df930be7Sderaadt# SCCS archive structure: 7df930be7Sderaadt# \001h01207 8df930be7Sderaadt# \001s 00276/00000/00000 9df930be7Sderaadt# \001d D 1.1 87/09/23 08:09:20 ian 1 0 10df930be7Sderaadt# \001c date and time created 87/09/23 08:09:20 by ian 11df930be7Sderaadt# \001e 12df930be7Sderaadt# \001u 13df930be7Sderaadt# \001U 14df930be7Sderaadt# ... etc. 15df930be7Sderaadt# Now '\001h' happens to be the same as the 3B20's a.out magic number (0550). 16df930be7Sderaadt# *Sigh*. And these both came from various parts of the USG. 17df930be7Sderaadt# Maybe we should just switch everybody from SCCS to RCS! 18df930be7Sderaadt# Further, you can't just say '\001h0', because the five-digit number 19df930be7Sderaadt# is a checksum that could (presumably) have any leading digit, 20df930be7Sderaadt# and we don't have regular expression matching yet. 21df930be7Sderaadt# Hence the following official kludge: 22e2a32a0eSderaadt8 string \001s\ SCCS archive data 23