home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / shell / 3741 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  2.9 KB
  1. Xref: sparky comp.unix.shell:3741 comp.unix.questions:10617
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!jvnc.net!yale.edu!think.com!barmar
  3. From: barmar@think.com (Barry Margolin)
  4. Newsgroups: comp.unix.shell,comp.unix.questions
  5. Subject: Re: Some Unix qs
  6. Date: 1 Sep 1992 20:06:31 GMT
  7. Organization: Thinking Machines Corporation, Cambridge MA, USA
  8. Lines: 60
  9. Message-ID: <180ig7INNifo@early-bird.think.com>
  10. References: <1992Sep1.145646.1663@cc.gatech.edu>
  11. NNTP-Posting-Host: telecaster.think.com
  12.  
  13. Please use more descriptive Subject lines.  Nearly everything in
  14. comp.unix.questions is "Some Unix qs", so using that as your subject is not
  15. very useful.  See my revised Subject line for an example.
  16.  
  17. In article <1992Sep1.145646.1663@cc.gatech.edu> sougata@cc.gatech.edu (Sougata Mukherjea) writes:
  18. >    I have a file say X which contains some records. These records are 
  19. >fixed-format, single line ( each record ends with a NEWLINE character) and the
  20. >record length extends upto 1600 characters.
  21. ...
  22. >    The problem I run into while applying the same technique to this
  23. >file X is, that  when I apply the "comm" command to the sorted data files X1 and
  24. >X2, each record breaks up (WHY ??) into multiple records (each of length 256
  25. >characters).
  26.  
  27. Many Unix programs have arbitrary limits like this.  The particular
  28. behavior of breaking long lines into multiple lines often comes from the
  29. following programming practice:
  30.  
  31. #define BUFSIZ 256
  32.  
  33. char line[BUFSIZ];
  34.  
  35. ...
  36.  
  37. while (1) {
  38.     result = fgets(line, BUFSIZ, stdin);
  39.     if (result == 0) break;
  40.     ...
  41. }
  42.  
  43. fgets() will read up to BUFSIZ-1 characters, a newline, or EOF, whichever
  44. comes first.  In the case of a line longer than BUFSIZ-1, the next
  45. iteration will begin with the file pointer in the middle of the line.
  46.  
  47. Be thankful that it simply treats the long line as multiple lines.  Less
  48. careful programs use gets() instead of fgets(), and it doesn't take a
  49. buffer size parameter.  In that case, it will read beyond the end of the
  50. line[] array and overwrite lots of other variables.
  51.  
  52. >My question is how do I perform the above operations [ (i), (ii) & (iii) ]
  53. >without breaking a record into pieces. The output SHOULD preserve the 
  54. >existing record format ( which "comm" does for small record lengths) and
  55. >SHOULD NOT introduce extraneous characters in the output files. 
  56.  
  57. If you must use the standard utilities, you're stuck with their arbitrary
  58. limitations.  
  59.  
  60. Often GNU versions of Unix utilities don't have these limits.  In
  61. particular, they often use the GNU readline() subroutine to read input
  62. instead of fgets().  Readline() allocates the input buffer itself, and
  63. automatically expands it as necessary.  And if the GNU version still
  64. doesn't quite meet your needs you have source so you can fix it if
  65. necessary.
  66.  
  67. The GNU version of comm(1) is in the textutils package.
  68. -- 
  69. Barry Margolin
  70. System Manager, Thinking Machines Corp.
  71.  
  72. barmar@think.com          {uunet,harvard}!think!barmar
  73.