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
Fix adding and removing files with git-style a/ b/ diffs: only skip
six letters if they actually match "--- a/" and "+++ b/" instead of
laxer checks.
Obtained from: OpenBSD (CVS 1.59)
The system call convention is different from i386 binaries running on
FreeBSD/amd64, but this is not noticeable by executables. On
FreeBSD/amd64, the vDSO already does padding of arguments and return
values to 64-bit values. On i386, it does not, meaning that system call
return values are simply stored in registers.
This change copies the existing amd64_cloudabi64.c to amd64_cloudabi32.c
and reimplements the functions for fetching system call arguments and
return values to use the same scheme as used by the vDSO that is used
when running cloudabi32 executables.
As arguments are automatically padded to 64-bit words by the vDSO in
userspace, we can copy the arguments directly into the array used by
truss(8) internally.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D13516
The number of lun exposed is now exposed via sysctl by the kernel.
Use that number in ctlstat instead of the hardcoded version
Add a backward compatibility in case the sysctl(2) request fails.
This also allows ctlstat -l 1118 to actually work when having more than
1024 luns.
Reviewed by: avg, manu (both before the backward compatibility addition)
Approved by: avg, manu (both before the backward compatibility addition)
MFC after: 2 weeks
Sponsored by: Gandi.net
Differential Revision: https://reviews.freebsd.org/D13446
fstat(2) is going to be a lot faster than reading all of the bytes in a
file, if we just need a character count for a regular file. This fast path
was accidentally broken in r326736.
PR: 224160
Reported by: bde
Sponsored by: Dell EMC Isilon
wc(1)'s slow path for counting words or multibyte characters requires
conversion of the 8-bit input stream to wide characters. However, a faster
path can be used for counting only lines ('-l' -- newlines have the same
representation in all supported encodings) or bytes ('-c').
The existing line count optimization was not used if the input was the
implicit stdin. Additionally, it wasn't used if only byte counting was
requested. This change expands the fast path to both of these scenarios.
Expanding the buffer size from 64 kB helps reduce the number of read(2)
calls needed, but exactly what impact that change has and what size to
expand the buffer to are still under discussion.
PR: 224160
Tested by: wosch (earlier version)
Sponsored by: Dell EMC Isilon
This option was used in the early days to allow performance measurements
extrapolating the use of SCTP checksum offloading. Since this feature
is now available, get rid of this option.
This also un-breaks the LINT kernel. Thanks to markj@ for making me
aware of the problem.
Our dc(1) has never correctly calculated remainders with fractional inputs.
Both bmod and bdivmod seem to have copy/pasted code from bdiv, which results
in the remainder having the wrong output scale.
PR: 162495
Reported by: anonymous
Reviewed by: pfg
Differential Revision: https://reviews.freebsd.org/D13390
I did a complete buildworld and test... with the program disconnected
from the tree. Revert the change for now.
(this keeps the change to .arclint which is still correct)
Wearing: my pointhat
Inputting fractional non-decimal numbers has never worked correctly in our
OpenBSD-derived dc(1). It truncates the input to a number of decimal places
equal to the number of hexadecimal (or whatever base) places given on the
input. That's unacceptable, because many numbers require more precision to
represent in base 10 than in their original bases.
Fix this bug by using as many decimal places as needed to represent the
input, up to the maximum of the global scale factor.
This has one mildly surprising side effect: the scale of a number entered in
non-decimal mode will no longer necessarily equal the number of hexadecimal
(or whatever base) places given on the input. I think that's an acceptable
behavior change, given that inputting fractional non-decimal numbers never
worked in the first place, and the man page doesn't specify whether trailing
zeros on the input should affect a number's scale.
PR: 206230
Reported by: nibbana@gmx.us
Reviewed by: pfg
Differential Revision: https://reviews.freebsd.org/D13336
sponge(1) is a utility that reads input until
complete, then opens the output file, then
writes to it. This makes it useful in pipelines
that read and write to the same file.
Reviewed by: wblock, jilles, imp, cem, danfe (all: various iterations)
Inspired by: https://joeyh.name/code/moreutils/
only.
In case we are trying to read a catpage, the manpage variable is not defined.
It results in the "cattool" having no arguments.
In case the catpage is compressed, the cattool used is "zcat" which dies if the
standard input is a terminal, meaning the function calling it is exiting as if
there were no ".so"
In case the catpage is uncompressed, the cattool used is "zcat -f" which waits
reading standard input, making the man(1) command hang.
PR: 223560
Reported by: wosch
MFC after: 3 days
The copyright notice was erroneously introduced as one from the NetBSD
foundation due to it being copied from a file in the NetBSD test suite, but
this file itself is not derived from or supplied with the NetBSD test suite.
MFC after: 3 days
Based on the patch by: Pawel Biernacki <pawel.biernacki@gmail.com>
Sponsored by: Mysterious Code Ltd. (Pawel),
The FreeBSD Foundation (me)
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D13228
