Each -printf invocation created a memstream, then freed the underlying
buffer without closing the stream, resulting in a segfault on exit
when libc tried to flush all the streams. Drop the memstream, which
isn't really needed.
Furthermore:
* Change escape() to return char * instead of const char *
* Simplify the implementation of %h
* Fix %M, which printed an extra space
* Implement %l correctly
* Implement %Y and %y
* Add tests for everything except %S
Fixes: 7b9c912c41
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D51776
In fd186cd16e I read the condition backwards. We want to stat all the
time until we can implement something to do it more inteligently as
Jiles suggested in the review.
Fixes: fd186cd16e
Noticed by: des
Sponsored by: Netflix
Implement -fprint fn which will print the matching files to fn, each
followed by a newline ('\n'). And -fprint0 (same, except followed by a
NUL). Both of these are always true. The file is created if it does not
exist, or truncated if it does. This is done first thing
unconditionally, so if there's no output, the file will have zero
length.
Note: GNU Find appears to collect the output for -fprint* to the same
file such that they don't interfere. That detail is unimplemented at
present.
Sponsored by: Netflix
Discussed with: jilles
Reviewed by: pauamma@gundo.com (man)
Differential Revision: https://reviews.freebsd.org/D42667
Implements most of gnu find's -printf predicate. However, the '#', '-',
'.' and size format modifiers are unimplemented, as are %P, %H, %F, %y,
and %Y formats. Follows what I think it should do based on the info
page, I've not looked at the gnu find code.
Sponsored by: Netflix
Discussed with: des, jilles
Reviewed by: pauamma@gundo.com (man)
Differential Revision: https://reviews.freebsd.org/D38138
This was made conditional to support cross-builds, but the relevant
header wasn't included so it was never enabled for native builds.
PR: 278124
Fixes: c3a6ea5ba6 Allow compiling usr.bin/find on Linux and Mac
After commit 3bfbb521fe, -g stopped being a no-op. The -g hasn't
been required for equivalent output since 4.4BSD.
PR: 282901
Fixes: 3bfbb521 ls: Improve POSIX compatibility for -g and -n.
In 2005, Gnu find deprecated '+' as the leading character for the -perm
argument, instead preferring '/' with the same meaning. Implement that
behavior here, and document it in the man page.
Reviewed by: imp, emaste
Pull Request: https://github.com/freebsd/freebsd-src/pull/1060
Print number of files processed and path currently being processed on
SIGINFO.
Reviewed by: des, asomers
Sponsored by: Axcient
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D43380
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
We've ifdef'd out the copyright strings for some time now. Go ahead and
remove the ifdefs. Plus whatever other detritis was left over from other
recent removals. These copyright strings are present in the comments and
are largely from CSRG's attempt at adding their copyright to every
binary file (which modern interpretations of the license doesn't
require).
Sponsored by: Netflix
For the uncommon items: Go through the tree and remove sccs tags that
didn't fit any nice pattern. If in the neighborhood, other SCM tags were
removed when they were detritis of long-ago CVS somehow in the early
mists of the project. Some adjacent copyrights stringswere removed (they
duplicated the copyright notices in the file). This also removed
non-standard formations of omission of SCCS tags (usually by adding an
extra #if 0 somewhere.
After this commit, a number of strings tagged with the 'what' @(#)
prefix remain, but they are primarily copyright notices.
Sponsored by: Netflix
Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.
Sponsored by: Netflix
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
Arguments follow primaries, not the other way around.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D38173
The ls(1) (with -l option) and find(1) (with -ls option) utilties
segment fault when operating on files with very large modification
times. A recent disk corruption set a spurious bit in the mtime
field of one of my files to 0x8000000630b0167 (576460753965089127)
which is in year 18,266,940,962. I discovered the problem when
running fsck_ffs(8) which uses ctime(3) to convert it to a readable
format. Ctime cannot fit the year into its four character field, so
returns ??? ??? ?? ??:??:?? ???? (typically Thu Nov 24 18:22:48 2021).
With the filesystem mounted, I used `ls -l' to see how it would
report the modification time and it segment faulted. The find(1)
program also segment faulted (see script below). Both these utilities
call the localtime(3) function to decode the modification time.
Localtime(3) returns a pointer to a struct tm (which breaks things
out into its component pieces: year, month, day, hour, minute,
second). The ls(1) and find(1) utilities then print out the date
based on the appropriate fields in the returned tm structure.
Although not documented in the localtime(3) manual page, localtime(3)
returns a NULL pointer if the passed in time translates to a year
that will not fit in an "int" (which if "int" is 32-bits cannot
hold the year 18,266,940,962). Since ls(1) and find(1) do not check
for a NULL struct tm * return from localtime(3), they segment fault
when they try to dereference it.
When localtime(3) returns NULL, the attached patches produce a date
string of "bad date val". This string is chosen because it has the
same number of characters (12) and white spaces (2) as the usual
date string, for example "Sep 3 22:06" or "May 15 2017".
The most recent ANSI standard for localtime(3) does say that localtime(3)
can return NULL (see https://pubs.opengroup.org/onlinepubs/9699919799/
and enter localtime in the search box). Our localtime(3) man page should
be updated to indicate that NULL is a possible return. More importantly,
there are over 100 uses of localtime(3) in the FreeBSD source tree (see
Differential Revision D36474 for the list). Most do not check for a NULL
return from localtime(3).
Reported by: Peter Holm
Reviewed by: kib, Chuck Silvers, Warner Losh
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36474
- new sentence, new line
- unknown AT&T UNIX version: At v7
- no blank before trailing delimiter
- reference the ASCII(8) manual page
MFC after: 5 days
Move some needed binaries/libs from FreeBSD-utilities to FreeBSD_runtime.
This is everything needed to boot to multiuser with FreeBSD-rc installed.
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33435
cvs(1) is not installed by default. Change the date format reference to
note that find(1) understands ISO8601 and RFC822 date formats. Also
remove references to cvs(1).
PR: 254894
MFC after: 3 days
Reported by: danielsh@apache.org
A simple find command appeared in Version 1 AT&T UNIX and was removed in
Version 3 AT&T UNIX. It was rewritten for Version 5 AT&T UNIX and later
be enhanced for the Programmer's Workbench (PWB). These changes were
later incorporated in AT&T UNIX v7.
Reviewed by: imp
MFC after: 1 week
find(1) ignores -type w passed to it. With this patch find(1) properly
identifies and prints whiteouts.
PR: 126384, 156703
Submitted by: oleg@mamontov.net
MFC after: 1 week
This code isn't designed to be particularly portable outside of FreeBSD.
To be more specific it doesn't make much sense to support compiling
find(1) on VMS.
When building FreeBSD the makefiles invoke find with various flags such as
`-s` that aren't supported in the native /usr/bin/find. To fix this I
build the FreeBSD version of find and use that when crossbuilding.
Inserting lots if #ifdefs in the code is rather ugly but I don't see a
better solution.
Reviewed By: brooks (mentor)
Approved By: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D13306
By default, or with the -P flag, find(1) should evaluate paths "physically."
For symlinks, this means using the link itself instead of the target.
Historically (since the import of BSD 4.4-lite from CSRG), find(1) has
failed to refer to the link itself, at least for -newer and -samefile.
[0]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html
PR: 222698
Reported by: Harald Schmalzbauer <bugzilla.freebsd AT omnilan.de>
Sponsored by: Dell EMC Isilon
