1New features with AN-2020-10-09:
2
3This is the first localization step for the schily source consolidation. Many
4programs now (hopefully) call gettext() for all strings that need localization.
5
6-	The next step will include dgettext() calls for the libraries and the
7	missing programs
8
9-	The following step will include the extracted strings
10
11-	The last step will include German translations and install support
12	for the resulting binary message object files.
13
14----------> Please test and report compilation problems! <---------
15
16***** NOTE: As mentioned since 2004, frontends to the tools should *****
17*****		call all programs in the "C" locale		   *****
18*****		by e.g. calling: LC_ALL=C cdrecord ....		   *****
19*****		unless these frontends support localized strings   *****
20*****		used by the cdrtools with NLS support.		   *****
21
22		*** WARNING        ***
23		*** Need new smake ***
24
25	*** Due to the fact that schily-tools 2014-04-03 introduced to use new macro
26	*** expansions and a related bug fix in smake, you need a newer smake
27	*** to compile this source. If your smake is too old and aborts, ensure to
28	*** use the recent smake by calling:
29
30	cd ./psmake
31	./MAKE-all
32	cd ..
33	psmake/smake
34	psmake/smake install
35
36	The new smake version mentioned above is smake-1.2.4
37	The recent smake version is smake-1.3
38
39	*** Due to the fact that schily-tools 2018-01-26 introduced
40	*** optimizations for the Schily version of SunPro Make, you
41	*** need at least the dmake version from 2018/01/11 with support
42	*** for the "export" directive to compile with this makefile system.
43
44
45	WARNING: the new version of the isoinfo program makes use of the
46		*at() series of functions that have been introduced by Sun
47		in August 2001 and added to POSIX.1-2008. For older platforms,
48		libschily now includes emulations for these functions but
49		these emulations have not yet been tested thoroughly.
50		Please report problems!
51
52	BUG WARNING: Please never report bugs only to Linux distributions as
53		they usually do not forward these bug reports upstream and as
54		the Linux distributions typically do not let skilled people
55		check the bugs. We did not hear about a FIFO problem in star
56		for a long time. Then a problem on Linux occurred once
57		every 6000-10000 tries but it did not happen on Solaris after
58		even 10 million tries, so it was not known besides Linux.
59
60	BUG WARNING: *** GNU make *** starts too early with parallel
61		execution (when reading Makefiles and evaluating rules for
62		"include" statements already). Since GNU make does not
63		support a concept for a correct ordering of such actions,
64		you need to be prepared to see gmake fail in parallel
65		mode. If you are interested in reliable parallel execution,
66		it is recommended to use the included "dmake" program with
67		a command line like:
68
69			dmake -j10 -f SMakefile
70
71		from the top level directory. Note that if you are on Linux,
72		you need a halfway recent kernel or the compile time will not
73		go down because of the low POSIX semaphore performance in
74		older Linux kernels.
75
76		The "dmake" program included in the schilytools tarball is the
77		current version of the "new" SunOS make program that has been
78		introduced in January 1986 by Sun Microsystems. It also
79		introduced new features like the "include" directive that
80		3 years later have been copied by gmake in a partially buggy
81		way. As gmake does not fix showstopper bugs, it cannot be
82		supported. Current showstoppers are: 1) gmake executes
83		"include" related rules in the inverse order, causing rules
84		to fail if they depend on files created by an "earlier" action
85		2) gmake caches an outdated state of the directory and aborts
86		with a wrong complain about allegedly missing files that in
87		fact exist already.
88
89-	autoconf: Added support for newer HP-UX versions on Itanium.
90
91	Thanks to Rudi Blom for reporting and making a change proposal.
92
93-	libschily: getdelim() now always allocates a new line buffer if
94	line_size is 0 at entry of getdelim().
95
96-	udiff: replaced a call to mmap() by an assignment to "" in case that
97	the the file size is 0. This avoids the need to call seek()/getdelim()
98	for zero sized files, which is documented to fai.
99
100-	udiff: reset a common line buffer to NULL if it's size is listed as 0
101	before fcalling getdelim().
102
103	On FreeBSD 12 and 13, udiff dumped core when calling "udiff file empty"
104	and getdelim() from the new FreeBSD libc triggers the core dump, because
105	a previous getgelim() emulation in udiff.c from a mmap()d file did set
106	the line buffer to a value != NULL without allocating space and without
107	setting the size because that was set to a pointer from the mmap()d
108	area.
109
110	Thanks to Nico Sonack for reporting
111
112-	udiff: no longer calls mmap() if the file is not a regular file
113	because in that case, statbuf.st_size may not be correct if the object
114	is not a plain file. Named pipes e.g. list statbuf.st_size as 0 but
115	read() returns data.
116
117-	SCCS: libcomobj: sethome.c: If sethome was called from the project home
118	directory and not from a subdirectory inside the project home directory,
119	sethome() did try to access buf[strlen(buf)]. This did not yet cause
120	any problems on Solaris or Linux and this still did not cause problems
121	on FreeBSD older than FreeBSD-13. On FreeBSD-13, the buffer (which is
122	on the stack) seems to have non-nul content past the end of the string
123	and thus bulkprepare() fails. We now introduced a special condition that
124	handles this case and that sets cwdprefixlen to 0 and cwdprefix to ""
125	in such a case.
126
127	Thanks to Nico Sonack for reporting
128
129-	SCCS: a new version date has been created.
130
131-	Bourne Shell: The "wait" builtin is now POSIX compliant and returns 127
132	in $? in case that a process id to be waited for does not exist.
133
134-	Bourne Shell: The exit code retrieved by $/ no longer is masked by 0xFF
135	when this code originates from a wait(1) call.
136
137	Thanks to Koichi Nakashima for reporting
138
139-	Bourne Shell: The man page has been enhanced for a better description
140	of the exit code constraitns.
141
142	Thanks to Koichi Nakashima for reporting
143
144-	Bourne Shell: The exit code from background jobs is now kept until
145	the builtin wait(1) is called.
146
147	Note that this introduces the need to call "wait" from time to time
148	in order to free shell job management resources.
149
150	Thanks to Koichi Nakashima for reporting
151
152-	Bourne Shell: The changes to keep exit codes for background jobs
153	caused problems that triggered a SIGSEGV in the shell with jobs like:
154
155		(sleep 10; exit 17)&
156
157	This needed a restructuring in the job management implementation.
158
159-	Bourne Shell: Since the next POSIX standard will make it optional
160	whether sig2str() and str2sig() deal with entries for "EXIT" / 0,
161	we enhanced the trap2str() and str2trap() interfaces to handle
162	"EXIT" / 0 and now call these functions before sig2str() and
163	str2sig().
164
165-	Bourne Shell: trap2str() is only needed with DO_POSIX_TRAP, so
166	make it #ifdefd to avoid a warning when compiling obosh.
167
168-	Bourne Shell: a new version date has been created.
169
170-	SunPro Make: The man pages now include a "SOURCE DOWNLOAD"
171	section.
172
173
174
175-	SCCS: The current idea for converting a historic SCCS project into
176	a project oriented SCCS history bundle is the following:
177
178	-	Create a user map file for "sccslog" by calling:
179
180		mkdir $HOME/.sccs
181		$EDITOR $HOME/.sccs/usermap
182
183		Enter the UNIX login names followed by a TAB, followed
184		by an E-mail notation. Use one line per user, e.g.
185
186			joerg	J. Schilling <joerg@mail.com>
187
188	-	Create a copy of the whole project to work on for this test.
189		Do not do this conversion on the original project until
190		sccs-6.0 is ready.
191
192	-	chdir to the project home directory of the just created copy.
193
194	-	Call "sccs init -i ." to make the project using an in-tree
195		project oriented repository.
196
197	-	Call:
198
199		find * -path '*SCCS/s.*' | /opt/schily/ccs/bin/sccscvt -NSCCS/s. -k -ooo -V6 -
200
201		for the CSRG BSD project use:
202
203		find * -path '*SCCS/s.*' | TZ=US/Pacific /opt/schily/ccs/bin/sccscvt -NSCCS/s. -k -ooo -V6 -
204
205		to convert all history files into SCCSv6 history files. The
206		TZ=US/Pacific is important for the UCB conversion since SCCSv6
207		uses timezones but SCCSv4 does not and we need to have the
208		correct timezone entries in the SCCSv6 history files.
209
210		For the complete "schilytools" project with 4200 SCCS history
211		files in 55 Mbytes, this takes 12 seconds for the SCCS history
212		from 1984 .. 2020, but note that most of the edits from the
213		1980s are lost, so there are few entries from the time
214		before 1989.
215
216		An alternate example: the SCCS history from the BSD-4.4 project
217		from December 1979 up to June 1995 is in 12600 SCCS history
218		files that take up 125 MB.
219		The conversion time to the SCCSv6 history file format is
220		18 seconds.
221
222	-	Call:
223
224		find * -path '*SCCS/s.*' | /opt/schily/ccs/bin/sccslog -changeset -
225
226		to populate the changeset file from the existing deltas.
227
228		For the complete "schilytools" project with 19600 commits,
229		this takes 8 minutes. The resulting file .sccs/SCCS/s.changeset
230		has a size of approx. 7 MBytes.
231
232		An alternate example: the SCCS history from the BSD-4.4 project
233		from December 1979 up to June 1995 has approx. 47000 commits.
234		The conversion time is approx. 40 minutes.
235		The size of the resulting changeset file is approx. 14 MBytes.
236
237	-	convert the in-tree repository into an off-tree repository.
238		This final step is not yet needed and there is currently no
239		code to do that automatically.
240
241	-	If you like to check the resulting changeset file, there is
242		currently only one way to look at it, by calling:
243
244		sccs -O get -p -A -m .sccs/SCCS/s.changeset | more
245
246		This prints an annotated version of the changeset file.
247		The next task is to develop an enhancement to "sccs log"
248		that prints the changeset in a way similar to what "hg log -v"
249		prints.
250
251	-	NOTE: Normal filesystems on Linux are slow, it is advised to
252		make the conversions on tmpfs for performance reasons in case
253		you are using Linux.
254
255	Please however keep in mind that this is still experimental and there is
256	absolutely no grant that a changelog created with current experimental
257	software will work correctly with the final SCCS version. The procedure
258	is just an example to check how it may look like.
259
260	The final conversion method will be more automated... most likely
261	by a command similar to "sccs import ..."
262
263	IMPORTANT: This is not yet the time to finally convert a project into
264	the project mode, because the project would be stuck in the current
265	state. What we need to continue work in that repository state in the
266	project mode is at least a working "sccs commit". Be prepared to remove
267	the changeset history file once "sccs commit" works and to re-create
268	the changeset file for that time.
269
270
271
272-	SCCS TODO:
273
274	-	Activate "fsdiff" as a "bdiff" replacement in delta(1)
275		to speed up delta(1) and to reduce the size of the SCCS
276		history files.
277
278	-	Implement something that outputs similar information from
279		the changeset file as printed with "hg log -v".
280
281		This would be the next key feature.
282
283	-	verify whether sccs.c uses -NSCCS in the back end programs
284		correctly, instead of converting g-file names from the command
285		line into s.file names in the frontend in order to forward
286		s.file names to the backend programs. This is needed for an
287		off-tree repository.
288
289		The related unit tests are already passed.
290
291	-	Add code to to sccs(1) to send a list of files to admin(1) and
292		delta(1) with new or modified files in order to have all
293		important code for a "sccs commit" in a single program that
294		does not need to deal with ARG_MAX limitations.
295
296	-	Add code to admin(1), delta(1), sccs-log(1) and get(1) to
297		maintain/understand the changeset file.
298
299		This is mainly writing out the sccschangeset(4) entries to an
300		intermediate store if a single file has been treated
301		successfully. For sccs-log(1), see below.
302
303	-	Finish the work to allow normal line based diffs in SCCS even
304		for binary files. This are files that include nul bytes and
305		this needs to completely avoid fputs() and this needs an
306		initialized member p_line_length in struct packet even for
307		all content that does not result from a previous getline() call.
308
309	-	sccs -R tell (and probably other subcommands?) does not yet
310		work in NewMode
311
312	-	Add code to libcomobj to understand the changeset file.
313		This is needed in order to e.g. know the file names and file
314		specific SIDs/state that corresponds to a project global SID.
315
316	-	Find/verify a complete transactional model that allows to repair
317		complex changes to the set of files for a project that have
318		been aborted in the middle. The current idea is to create the
319		file $PROJECTHOME/.sccs/changeset with the deltas to the
320		changeset during a complex update operation.
321
322	-	Find a decision on how to deal with the admin flags that are
323		currently implemented as global flags and thus do not depend on
324		the SID (version) if the history file.
325
326	-	Aborting a transaction via ^C currently requires a manual
327		removal of the global lock file. Find a way to avoid this in
328		case that a commit has been aborted while being prompted for
329		a commit message (which is before any real action happened).
330
331	-	Implement a fully automated method to convert a SCCSv4 based
332		history with unrelated history files into a new SCCSv6 based
333		project mode history with a populated changeset history file.
334
335		This will most likely be done as a variant of the to be defined
336		new command "sccs sccsimport" that imports a whole existing old
337		SCCS project.
338
339	-	Implement this "sccs sccsimport" based conversion in a way where
340		sccs(1) holds the global changeset lock for the whole time
341		of the conversion.
342
343
344
345
346-	Bourne Shell Missing features for POSIX compliance:
347
348	- Support for $'...' quoting (this is not needed for the current
349					version of POSIX but for the next POSIX
350					version that will be named SUSv8).
351					The development of SUSv8 will start in
352					late 2016.
353
354	We are now expecting the Bourne Shell to be fully POSIX compliant.
355
356-	Bourne Shell further TODO list:
357
358	-	Finish loadable builtin support.
359
360	-	POSIX does not allow us to implement ". -h", so we will
361		add a "source" builtin to be able to implement "source -h"
362
363-	The following builtins (that are available in bsh) are still missing in
364	the Bourne Shell:
365
366	err			echo with output going to stderr
367	glob			echo with '\0' instead of ' ' between args
368	env			a builtin version of /usr/bin/env
369
370	The following bsh intrinsics are still missing in the Bourne Shell:
371
372	-			the restricted bsh has restriction features that
373				are missing in the Bourne shell.
374
375	-	source -h	read file into history but do not execute
376
377	and probably more features not yet identified to be bsh unique.
378
379
380
381Author:
382
383Joerg Schilling
384D-13353 Berlin
385Germany
386
387Email: 	joerg@schily.net, joerg.schilling@fokus.fraunhofer.de
388
389Please mail bugs and suggestions to me.
390