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