db21@ihlpl.ATT.COM (Dave Beyerl) (06/22/88)
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
dick@slvblc.UUCP (Dick Flanagan) (06/25/88)
In article <5439@ihlpl.ATT.COM> db21@ihlpl.ATT.COM (Dave Beyerl) writes: > I have experienced the following problems when trying to > recompile head and tail from the source that was posted a few > weeks back. > > [comments on problems found porting to Microsoft environment] The contributor of head, tail, and split used a non- Microsoft assembler and compiler. Porting this code to other development environments is obviously left as an exercise for the downloader. 8-) > 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? I daresay that any source is better than no source, but the best source of all is that from which the application was actually built. And that is what the contributor provided, even it it wasn't in a turn-key, Microsoft-oriented package. > 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. Perhaps by the quality of the contributions you make to comp.binaries.ibm.pc, we can all learn from your example. (1/2 :-) Seriously, I would like to thank the contributor of head, tail, and split, for placing their sources in the Public Domain and I would like to encourage others to share their programs with us as well. And if the tools they use aren't industrial-strength, if their documentation isn't all that complete, and even if they've never even heard of a make file, I would still encourage them to contribute. This is a newsgroup (and a network) for helping, for sharing, for learning. Let's *all* use it in that context . . . please. Dick -- Dick Flanagan, vacation moderator of comp.binaries.ibm.pc {backbones}!ucbvax!ucscc!slvblc!dick or slvblc!dick@ucscc.ucsc.edu
graham@sce.UUCP (Doug Graham) (06/27/88)
In article <11314@agate.BERKELEY.EDU>, vojta@maalox.berkeley.edu (paul vojta) writes: > Personally, I find most makefiles useless, especially for short programs like > these. I'm curious. How do develop your programs? ie. What actions must you perform in the course of compiling and linking a program. Even for a program consisting of only a single source file, isn't it a pain to have to keep doing cc file.c link file.obj or whatever your equivalent is? Wouldn't just typing "make" be much easier on both the fingers, and the brain? A big advantage of make is that running it is all very mechanical. You don't have to remember filenames, or which compiler/assembler/linker to use or which compiler/assembler/linker options to use. And the people to whom you distribute your source then don't have to figure out the same things. Try it, you'll like it. Doug.