src-test2/usr.bin/locate/code, branch release/2.2.5_cvs

This commit was manufactured by cvs2svn to create tag

1997-10-21T01:56:05Z

'RELENG_2_2_5_RELEASE'. This commit was manufactured to restore the state of the 2.2.5-RELEASE image. Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs.

MFC: getopt returns -1 not EOF

1997-08-29T05:30:15Z

Do not store character 30. I made a test at my CS department

1996-10-27T19:04:27Z

and at least one user use this char in a file name. Older locate implementions core'd.

8-Bit character support.

1996-10-13T01:44:43Z

Old locate(1) programs still works with the new database format, print some garbage for 8 bit characters, but don't core (maybe except char 30). 7-Bit Puritan should not notice any difference. Same speed, Same database size if the database contain only ASCII characters. Reviewed by: ache

NULL -> '\0'

1996-08-31T14:51:18Z

Submitted by: Bruce, see also c-faq 5.6 and 5.9

code cleanup

1996-08-22T18:46:13Z

bigram

1996-08-14T00:22:31Z

Bigram does not remove newline at end of filename. This break particulary the bigram algorithm and /var/db/locate.database grow up 15 %. Bigram does not check for characters outside 32-127. The bigram output is silly and need ~1/2 CPU time of database rebuilding. old: locate.bigram < $filelist | sort | uniq -c | sort -nr ^^^^^^^^^^^^^^ this can easy made bigram new: bigram < $filelist | sort -nr code Code does not check for char 31. Use a lookup array instead a function. 3 x faster. updatedb rewritten sync with bigram changes read config file /etc/locate.rc if exists submitted by: guido@gvr.win.tue.nl (Guido van Rooij) concatdb - concatenate locate databases mklocatedb - build locate database

Better protection against too long pathes and 8bit controls in file

1995-01-21T05:50:50Z

names, locate dumps core instead

BSD 4.4 Lite Usr.bin Sources

1994-05-27T12:33:43Z