home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / unix / 425 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  1.9 KB
  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: brnstnd@KRAMDEN.ACF.NYU.EDU (D. J. Bernstein)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: Report on POSIX.2: Shell and Utilities
  5. Date: 14 Sep 1992 22:30:49 -0700
  6. Organization: IR
  7. Lines: 29
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <193se9INN4h7@ftp.UU.NET>
  11. References: <18lqglINN992@ftp.UU.NET> <18u2i5INNo7e@ftp.UU.NET> <190k6vINN5g9@ftp.UU.NET> <192n6aINNlt2@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (D. J. Bernstein)
  16.  
  17. Scott E. Preece writes:
  18. > So you have to write a
  19. > standard that specifies things nobody specified before and you have to
  20. > try to merge different versions of the same functionality.
  21.  
  22. Ah, but you never _have_ to write a standard.
  23.  
  24. You see that systems vary widely in, e.g., the output format of ``who'',
  25. and even the type of information stored in /etc/utmp (or whatever file
  26. ``who'' reads). Does this mean you have to apply your imagination,
  27. specify what the market hasn't specified, merge what the market hasn't
  28. merged? No. It's a very strong signal that standardization is premature.
  29. You shouldn't standardize ``who'' at all. Wait for market convergence.
  30.  
  31. You see that the market has come to agree on what you are sure is bad
  32. practice. Does this mean you have to resist documenting that practice in
  33. a standard? No. It means that your conceptions of what's good and bad
  34. are out of sync with the market. Your responsibility as standards-writer
  35. is to document what's being done, not to dream up new solutions. ``Only
  36. those who code have the right to dream.'' If you can identify a
  37. technical flaw in the bad practice, go ahead and document that! If
  38. you're sure that you can make a better solution, try it on the market!
  39.  
  40. ---Dan, still wondering why POSIX [:digit:] is better than Perl \d
  41.  
  42.  
  43. Volume-Number: Volume 29, Number 37
  44.