Path: utzoo!utgpu!water!watmath!clyde!att!ihnp4!ihlpl!db21
From: db21@ihlpl.ATT.COM (Dave Beyerl)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: split, head and tail for MSDOS
Keywords: split, head, tail, problems
Message-ID: <5439@ihlpl.ATT.COM>
Date: 22 Jun 88 12:05:19 GMT
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 55

Re: split, head and tail for MSDOS, problems and *Flame*

	I have experienced the following problems when trying to 
recompile head and tail from the source that was posted a few
weeks back.

1)	The header for head.c had been copied from tail.c but
	was not modified to reflect the different program name
	and function.  In addition, the Usage description in the 
	header and usage procedures did not agree.

2)	Two assembly routines, strnchr and strrnchr, are provided 
	that will not assemble in their present form by masm (4.0
	or 5.0).  By adding two directives and modifying a couple
	of lines, I was able to get clean assemblies and .obj files.
	However, as noted later, I am having some other problems
	that may or may not be related to these changes.

3)	tail.c calls a function, fgetss, for which source code is
	not provided.  There are a couple of lines in the tail.c
	code that appear to work around this by using fgets but
	again it is not clear that the alternate code works. 

4)	Using the above modifications, I am able to get clean
	compiles of both head and tail.  head apparently works 
	as re-compiled, tail does not!  tail goes into an endless 
	loop displaying a portion of the input file repeatedly.  It 
	is not clear to me if the problems stem from the changes I 
	had to make or possibly from a more subtle problem addressed 
	by the note in the tail.c source that says "If you want to 
	recompile this, make sure your C library allows you to do 
	fseek() on stdin.", or yet some other problem(s).

	I would like to know if anyone else has noted similar
problems and what you did to resolve them.

			* Flame on *

	It is my opinion that this submission was incomplete and
lacking in quality, see items 1 & 3 above.  The dependency on 
assembly modules recommends that make files be supplied with the 
source and/or assembly instructions supplied.  The use of compiler 
specific functionality, ie. fseek on stdin, recommends that some 
information be provided on how this product was built.  For these 
programs, neither was provided.  Without this information, it is
practically impossible to do anything with these programs except
use the provided executables and then who needs the source?

	Given the problems I experienced with this posting and 
recent discussions on having a source group for DOS, I believe
we are apt to find many frustrated readers/users if the quality
of future postings matches this one.

						Dave Beyerl
						ihnp4!ihlpl!db21