PR252358 reported a serious performance problem when
copying a large non-sparse file on a UFS file system.
This problem seems to have been caused by a large
number of SEEK_HOLE operations, with one done
for each copy_file_range(2) call.
This patch modifies cp(1) to use a large (SSIZE_MAX)
len argument, reducing the number of system calls
and resolving the performance issue.
While here, convert the type of the "rcount" from "int"
to "ssize_t" so that it is consistent with that returned
by both read(2) and copy_file_range(2).
PR: 252358
Reviewed by: asomers
Differential Revision: https://reviews.freebsd.org/D27937
Support for fractional seconds has become much more widespread since
this text was originally written.
Reported by: Mark Eichin
Reviewed by: gbe, jilles
Differential Revision: https://reviews.freebsd.org/D26208
This change has been motivated by a mail from bde sent in 2015 in
which he mentioned inappropriate use of sscanf() in 3 programs in
/bin.
This change removes the potential mismatch of the types of the return
values and the variable width specified in the scan pattern. While
there was no issue with the patterns and types used, the new code is
simpler and more efficient.
The previous version normalized the width list (replaced empty fields
with "0") just to be able to use sscanf() on the string.
It is much simpler to just parse the string as-is.
The clearing of f_notabs is preserved for the case that less than 9
width values have been defined, but I do not understand the rationale
for this particular condition. E.g., LS_COLWIDTHS="::::::::" will be
counted as 9 defined fields (may clear f_notabs) but is no different
fron LS_COLWIDTHS="" with regard to the field width (and that does not
clear f_notabs, since there are less than 9 fields).
This is addressing cases such as fts_read(3) encountering an [EIO]
from fchdir(2) when FTS_NOCHDIR is not set. That would otherwise be
seen as a successful traversal in some of these cases while silently
discarding expected work.
As noted in r264201, fts_read() does not set errno to 0 on a successful
EOF so it needs to be set before calling it. Otherwise we might see
a random error from one of the iterations.
gzip is ignoring most errors and could be improved separately.
Reviewed by: vangyzen
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D27184
The acl_from_stat function accepts a stat_t * argument, but only uses its
st_mode field. There is no reason to pass the whole struct, so make it accept
a mode_t and rename the function to acl_from_mode.
Linux has non-standard acl_from_mode function in its libacl, so naming the
function this way may help discovering it during porting efforts.
Reviewed by: tsoome, markj
Approved by: markj
Differential Revision: https://reviews.freebsd.org/D27292
This was marked deprecated in r329092, over two and a half years ago.
This functionality is also buggy per PR 237368.
PR: 237368
Reviewed by: brooks, cem, emaste, imp
Differential Revision: https://reviews.freebsd.org/D27197
Small EXAMPLES section.
Add reference to realpath(1) due to similarity.
Approved by: manpages (gbe@)
Differential Revision: https://reviews.freebsd.org/D26862
Add a dozen of examples to the EXAMPLES section for pgrep(1) and pkill(1).
Flags covered: -f, -F, -n, -j, -l, -S, -x
Approved by: mandoc (bcr@)
Differential Revision: pkill(1): Add EXAMPLES section to man page
* Add EXAMPLES section with four simple examples.
* Simplify -H flag description. This makes easy to see the difference between
this flag and -h
* While here, fix .Tn deprecated macro.
Approved by: manpages (bcr@)
Differential Revision: https://reviews.freebsd.org/D26662
* Add small EXAMPLES section to the man page showing the different
flags and exit codes.
* Complete description for -v flag.
Approved by: manpages (bcr@)
There are some tests available in the NetBSD test suite, but we don't
currently pass all of those; further investigation will go into that. For
now, just add a basic test as well as a test that copies from /dev/null to a
file.
The /dev/null test confirms that the file gets created if it's empty, then
that it truncates the file if it's non-empty. This matches some usage that
was previously employed in the build and was replaced in r366042 by a
simpler shell construct.
I will also plan on coming back to expand these in due time.
MFC after: 1 week
The current default is provided in various Makefile.inc in some top-level
directories and covers a good portion of the tree, but doesn't cover parts
of the build a little deeper (e.g. libcasper).
Provide a default in src.sys.mk and set WARNS to it in bsd.sys.mk if that
variable is defined. This lets us relatively cleanly provide a default WARNS
no matter where you're building in the src tree without breaking things
outside of the tree.
Crunchgen has been updated as a bootstrap tool to work on this change
because it needs r365605 at a minimum to succeed. The cleanup necessary to
successfully walk over this change on WITHOUT_CLEAN builds has been added.
There is a supplemental project to this to list all of the warnings that are
encountered when the environment has WARNS=6 NO_WERROR=yes:
https://warns.kevans.dev -- this project will hopefully eventually go away
in favor of CI doing a much better job than it.
Reviewed by: emaste, brooks, ngie (all earlier version)
Reviewed by: emaste, arichardson (depend-cleanup.sh change)
Differential Revision: https://reviews.freebsd.org/D26455
Even though copy_file_range has a file-system agnostic version, it still
fails on devfs (perhaps because the file descriptor is non-seekable?) In
that case, fallback to old-fashioned read/write. Fixes
"cp /dev/null /tmp/null"
PR: 249248
Reported by: Michael Butler
Reviewed by: mjg
MFC-With: 365549
Differential Revision: https://reviews.freebsd.org/D26395
This has three advantages over write(2)/read(2):
* Fewer context switches and data copies
* Mostly preserves a file's sparseness
* On some file systems (currently NFS 4.2) the file system will perform the
copy in an especially efficient way.
Reviewed by: rmacklem
MFC after: 2 weeks
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D26377
POSIX is pretty clear that command -v, command -V and type shall write
absolute pathnames. Therefore, we need to prepend the current directory's
name to relative pathnames.
This can happen either when PATH contains a relative pathname or when the
operand contains a slash but is not an absolute pathname.
If job control is not enabled, a background job (... &) ignores SIGINT and
SIGQUIT, but this can be reverted using the trap builtin in the same shell
environment.
Using the set builtin to change options would also revert SIGINT and SIGQUIT
to their previous dispositions.
This broke due to r317298. Calling setsignal() reverts the effect of
ignoresig().
Reported by: bdrewery
MFC after: 1 week
When -H is specified, for kernel threads the command is formatted as
"<proc name>/<td name>" and truncated to MAXCOMLEN. But each of the
proc name and td name may be up to MAXCOMLEN bytes in length.
Also handle the ki_moretdname field to ensure that the full thread name
gets printed. This is already handled correctly when formatting for
"-o tdname".
Reported by: freqlabs
Reviewed by: freqlabs
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25840
I've always found this a little bit confusing:
> sh
$ ^D> sh
$ ^D>
Reviewed by: 0mp, jilles
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25813
realtime priorities
The current `ps -axO rtprio' show threads running at interrupt
priority such as the [intr] thread as '1:48' and threads running
at kernel priority such as [pagedaemon] as normal:4294967260.
This change shows [intr] as intr:48 and [pagedaemon] as kernel:4.
Reviewed by: kib
MFC after: 1 week (together with -r362369)
Differential Revision: https://reviews.freebsd.org/D25660
INTOFF postpones SIGINT processing and INTON enables it again. This is
important so an interactive shell can return to the top level prompt when
Ctrl+C is pressed.
Given that INTON is automatically done when a builtin completes, the part
where onsig() ignores suppressint when in_dotrap is true is both unnecessary
and unsafe. If the trap is for some other signal than SIGINT, arbitrary code
could have been interrupted.
Historically, INTOFF remained in effect for longer.
Reviewed by: bdrewery
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25270
The manual page documents "\$" to expand to either "$" or "#" followed by
a single space. In reality, the single space character is not appended.
PR: 247791
Submitted by: kd-dev@pm.me
MFC after: 7 days
When job control is not enabled, the shell ignores SIGINT while waiting for
a foreground process unless that process exits on SIGINT. In this case, the
foreground process is sleep and it does not exit on SIGINT because the
signal is only sent to the shell. Depending on order of events, this could
cause the SIGINT to be unexpectedly ignored.
On lightly loaded bare metal, the chance of this happening tends to be less
than 0.01% but with higher loads and/or virtualization it becomes more
likely.
Starting the sleep in background and using the wait builtin ensures SIGINT
will not be ignored.
PR: 247559
Reported by: lwhsu
MFC after: 1 week
This flag will now show the processor number on which a process is running.
This change was inspired by PR129965. Initially I didn't think that the
patch attached to it was correct -- it sacrificed ki_estcpu use in "cpu"
for ki_lastcpu and I thought that the old functionality should be kept and
the new (cpu#) one added to it. But I've since discovered that ki_estcpu is
sched_4bsd-specific. What's worse, it represents the same thing as
ki_pctcpu, except ki_pctcpu is universal -- so "%cpu" has been using it
successfully. Therefore, I've decided to replace information based on
ki_estcpu with information based on ki_oncpu/ki_lastcpu.
Key parts of the code and manual changes were borrowed from top(1).
PR: 129965
Reported by: Nikola Knežević
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25377
Fix the rtprio option that for some reason was progessively becoming an
option showing the priority class of threads. In particular:
- use the constants defined in sys/sys/rtprio.h instead of those defined in
sys/sys/priority.h: this helps making clearer that the code actually is
about realtime priorities and not standard scheduler priorities;
- remove the PRI_ITHD case that has nothing to do with realtime priorities;
- convert the priority levels to realtime priority levels using the same
formulas used for pri_to_rtp function in sys/kern/kern_resource.c.
- remove outdated note "101 = not a realtime process" in the man page and
replace it with a more useful reference to man 1 rtprio.
Approved by: src (mckusick), manpages (bcr), gerald (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25266
If job control is not enabled, background commands shall ignore SIGINT and
SIGQUIT, and it shall be possible to override that ignore in the same shell.
MFC after: 1 week
Use %hs (locale-based encoding) instead of %s (UTF-8) format for
strings that are expected to be in current locale encoding (date/time,
process names/argument list).
PR: 241491
Reviewed by: phil
Differential Revision: https://reviews.freebsd.org/D22160
FreeBSD DD utility has not had support for the O_DIRECT flag, which
is useful to bypass local caching, e.g. for unconditionally issuing
NFS IO requests during testing.
Reviewed by: rgrimes (mentor)
Approved by: rgrimes (mentor, blanket)
MFC after: 3 weeks
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D25066
Historically, we've allowed read() of a directory and some filesystems will
accommodate (e.g. ufs/ffs, msdosfs). From the history department staffed by
Warner: <<EOF
pdp-7 unix seemed to allow reading directories, but they were weird, special
things there so I'm unsure (my pdp-7 assembler sucks).
1st Edition's sources are lost, mostly. The kernel allows it. The
reconstructed sources from 2nd or 3rd edition read it though.
V6 to V7 changed the filesystem format, and should have been a warning, but
reading directories weren't materially changed.
4.1b BSD introduced readdir because of UFS. UFS broke all directory reading
programs in 1983. ls, du, find, etc all had to be rewritten. readdir() and
friends were introduced here.
SysVr3 picked up readdir() in 1987 for the AT&T fork of Unix. SysVr4 updated
all the directory reading programs in 1988 because different filesystem
types were introduced.
In the 90s, these interfaces became completely ubiquitous as PDP-11s running
V7 faded from view and all the folks that initially started on V7 upgraded
to SysV. Linux never supported this (though I've not done the software
archeology to check) because it has always had a pathological diversity of
filesystems.
EOF
Disallowing read(2) on a directory has the side-effect of masking
application bugs from relying on other implementation's behavior
(e.g. Linux) of rejecting these with EISDIR across the board, but allowing
it has been a vector for at least one stack disclosure bug in the past[0].
By POSIX, this is implementation-defined whether read() handles directories
or not. Popular implementations have chosen to reject them, and this seems
sensible: the data you're reading from a directory is not structured in some
unified way across filesystem implementations like with readdir(2), so it is
impossible for applications to portably rely on this.
With this patch, we will reject most read(2) of a dirfd with EISDIR. Users
that know what they're doing can conscientiously set
bsd.security.allow_read_dir=1 to allow read(2) of directories, as it has
proven useful for debugging or recovery. A future commit will further limit
the sysctl to allow only the system root to read(2) directories, to make it
at least relatively safe to leave on for longer periods of time.
While we're adding logic pertaining to directory vnodes to vn_io_fault, an
additional assertion has also been added to ensure that we're not reaching
vn_io_fault with any write request on a directory vnode. Such request would
be a logical error in the kernel, and must be debugged rather than allowing
it to potentially silently error out.
Commented out shell aliases have been placed in root's chsrc/shrc to promote
awareness that grep may become noisy after this change, depending on your
usage.
A tentative MFC plan has been put together to try and make it as trivial as
possible to identify issues and collect reports; note that this will be
strongly re-evaluated. Tentatively, I will MFC this knob with the default as
it is in HEAD to improve our odds of actually getting reports. The future
priv(9) to further restrict the sysctl WILL NOT BE MERGED BACK, so the knob
will be a faithful reversion on stable/12. We will go into the merge
acknowledging that the sysctl default may be flipped back to restore
historical behavior at *any* point if it's warranted.
[0] https://www.freebsd.org/security/advisories/FreeBSD-SA-19:10.ufs.asc
PR: 246412
Reviewed by: mckusick, kib, emaste, jilles, cy, phk, imp (all previous)
Reviewed by: rgrimes (latest version)
MFC after: 1 month (note the MFC plan mentioned above)
Relnotes: absolutely, but will amend previous RELNOTES entry
Differential Revision: https://reviews.freebsd.org/D24596
Austin Group bugs #1226 and #1250 changed the requirements for shell scripts
without #! (POSIX does not specify #!; this is about the shell execution
when execve(2) returns an [ENOEXEC] error).
POSIX says we shall allow execution if the initial part intended to be
parsed by the shell consists of characters and does not contain the NUL
character. This allows concatenating a shell script (ending with exec or
exit) and a binary payload.
In order to reject common binary files such as PNG images, check that there
is a lowercase letter or expansion before the last newline before the NUL
character, in addition to the check for the newline character suggested by
POSIX.
Highlights:
- CLICOLOR in the environment should imply --color=auto to maintain
compatibility with historical behavior
- -G should set CLICOLOR and imply --color=auto
The manpage has been updated to draw the connection between -G and --color;
the former is in-fact a sort of compromise between --color=always and
--color=auto, where we'll output color regardless of the environment lacking
CLICOLOR/COLORTERM assuming stdout is a tty.
X-MFC-With: r361318
The regression is in-fact that I flipped the default from never to auto. The
incorrect impression was based on an alias that I failed to notice,
installed by the Linux distribution that I used for testing compatibility
here. Users that want the old default should be doing so with a shell alias
as is done elsewhere, rather than making this decision in ls(1).
Many thanks to rgrimes for pointing out the alias that I clearly overlooked
that resulted in this; if you despised colors in your terminal from this,
consider buying him a beer at the next venue that you see him at.
MFC after: 1 week
Relnotes: yes
The shell maintains a count of the number of times SIGINT processing has
been disabled via INTOFF, so SIGINT processing resumes when all disables
have enabled again (INTON).
If an error occurs in a vfork() child, the processing of the error enables
SIGINT processing again, and the INTON in vforkexecshell() causes the count
to become negative.
As a result, a later INTOFF may not actually disable SIGINT processing. This
might cause memory corruption if a SIGINT arrives at an inopportune time. As
of r360452, it causes the shell to abort when it would unsafely allocate or
free memory in certain ways.
Note that various places such as errors in non-special builtins
unconditionally reset the count to 0, so the problem might still not always
be visible.
PR: 246497
Reported by: jbeich
MFC after: 2 weeks
Initially it seemed that there were multiple possible ways to do it.
Processing option -p could conditionally add selected processes and
their descendants to the list for further work, but it is not guaranteed
to know whether the -d option has been used or not, and it also doesn't
have access to the process list just yet.
There is also descendant_sort() which has access to all possibly needed
information, but serves the purely post-processing purpose of sorting
output.
Then there is the loop that uses invocation information and full process
list to create a list of processes for final display. It seems the most
natural place to implement this, but indeterminate state of the process
list and volatility of the final list that is being created obstruct
adding an elegant search for all elements of process descendancy trees.
So I opted for adding another loop, just before the one I mentioned
above. For all selected processes it conditionally adds direct
descendants to the end of this list of selected processes.
Possible usage:
* ps -auxd -p $$
* ps -auxd -p 1
* while x=$(pgrep svnlite); do clear; ps auxd -p $x; sleep 2; done
* ps -auxd -p `pgrep make`
Reviewed by: kevans, kaktus (earlier version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D24380
As I noted in https://reviews.freebsd.org/D22756, INTOFF should be in effect
when calling ckmalloc/ckrealloc/ckfree to avoid memory leaks and double
frees. Therefore, change the functions to check if INTOFF is in effect
instead of applying it.
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D24599
r360139 made compiling with NO_HISTORY work. This #define does not remove
the fc and bind builtins completely but makes them always write an error
message.
However, there was also some code in builtins.def and mkbuiltins to remove
the fc builtin entirely (but not the bind builtin). The additional build
system complication to make this work seems not worth it, so remove that
code.
mips-gcc for mips32 was complaining that c was potentially used before
being set. Setting it to 0 before calling fdgetsc() looks like the right
thing to do in this instance; there's an explicit check for c == 0 later
on.
Tested: mips-gcc mips32 build, running /bin/sh on mips32
el is declared extern in myhistedit.h and defined in histedit.c. Remove the
duplicate definition in input.c to appease the -fno-common build.
-fno-common will become the default in GCC10/LLVM11.
MFC after: 3 days
Specifically, any system with a 32-bit size_t; -residue is calculated as a
32-bit *then* promoted to the 64-bit off_t and the result is ultimately
wrong. This resulted in what would appear to be truncated output, as only
the first line would be read.
Correct it by just making residue an off_t to begin with, since this is what
lseek will take anyways.
Reported by: antoine, dim
Triaged by: cem
Tested by: kevans
X-MFC-With: r358152
fd.
The read built-in command calls read(2) with a 1-byte buffer because
newline characters need to be detected even on a byte stream which
comes from a non-seekable file descriptor. Because of this, the
following script calls >6,000 read(2) to show a 6KiB file:
while read IN; do echo "$IN"; done < /COPYRIGHT
When the input byte stream is seekable, it is possible to read a data
block and then reposition the file pointer to where a newline
character found. This change adds a small buffer to do this and
reduces the number of read(2) calls.
Theoretically, multiple built-in commands reading the same seekable
byte stream in a single pipe chain can share the buffer. However,
this change just makes a single invocation of the read built-in
allocate a buffer and deallocate it every time for simplicity.
Although this causes read(2) to read the same regions multiple times,
the performance penalty should be small compared to the reduction of
read(2) calls.
Reviewed by: jilles
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D23747
`cat -l` is needed during the installworld phase and other system's cat
don't support that flag. To avoid portability issues when compiling on
Linux/macOS (such as the the direct access to &fp->_mbstate), we
disable the entire multibyte support when building as a boostrap tool.
Reviewed By: brooks, emaste
Differential Revision: https://reviews.freebsd.org/D13939
If getcwd() failed earlier on but later succeeded in the pwd builtin,
there was no INTOFF protection between calling savestr() and storing its
result.
It is quite rare for getcwd() to fail, and rarer for it to succeed later in
the same directory.
Found via code inspection for changing ckmalloc() and similar to assert
INTOFF protection instead of applying it directly (which protects against
corrupting malloc's internal state but allows memory leaks or double frees).
MFC after: 1 week
If executing a file fails with an [ENOEXEC] error, the shell executes the
file as a shell script, except that this execution may instead result in an
error message if the file is binary.
Per a recent Austin Group interpretation, we will need to change this to
allow a concatenation of a shell script and a binary payload. See
Austin Group bugs #1226 and #1250.
MFC after: 1 week
Update a bunch of Makefile.depend files as
a result of adding Makefile.depend.options files
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22494
Leaf directories that have dependencies impacted
by options need a Makefile.depend.options file
to avoid churn in Makefile.depend
DIRDEPS for cases such as OPENSSL, TCP_WRAPPERS etc
can be set in local.dirdeps-options.mk
which can add to those set in Makefile.depend.options
See share/mk/dirdeps-options.mk
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22469
Normally, count=n means read(2) will be called n times on the input to dd. If
the read() returns short, as may happen when reading from a pipe, fewer bytes
will be copied from the input. With conv=sync the buffer is padded with zeros
to fill the rest of the block.
iflag=fullblock causes dd to continue reading until the block is full, so that
count=n means n full blocks are copied. This flag is compatible with illumos
and GNU dd and is used in the ZFS test suite.
Submitted by: Ryan Moeller
Reviewed by: manpages, mmacy@
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D21441
Sets the O_FSYNC flag on the output file. oflag=fsync and oflag=sync are
synonyms just as O_FSYNC and O_SYNC are synonyms. This functionality is
intended to improve portability of dd commands in the ZFS test suite.
Submitted by: Ryan Moeller
Reviewed by: manpages, mmacy@
MFC after: 1 week
Sponsored by: iXsytems, Inc.
Differential Revision: https://reviews.freebsd.org/D21422
close(2) can return errors from previous operations which should not be ignored.
PR: 229616
Submitted by: Thomas Hurst
Reported by: Thomas Hurst
Reviewed by: mmacy@
Obtained from: Ryan Moeller
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21376
The fdatasync flag performs an fdatasync(2) on the output file before closing it.
This will be useful for the ZFS test suite.
Submitted by: Ryan Moeller
Reviewed by: manpages, mmacy@
MFC after: 1 week
Sponsored by: iXSystems, Inc.
Differential Revision: https://reviews.freebsd.org/D21373
The default package use to be FreeBSD-runtime but it should only contain
binaries and libs enough to boot to single user and repair the system, it
is also very handy to have a package that can be tranform to a small mfsroot.
So create a new package named FreeBSD-utilities and make it the default one.
Also move a few binaries and lib into this package when it make sense.
Reviewed by: bapt, gjb
Differential Revision: https://reviews.freebsd.org/D21506
The fsync flag performs an fsync(2) on the output file before closing it.
This will be useful for the ZFS test suite.
Submitted by: ryan@ixsystems.com
Reviewed by: jilles@, imp@
MFC after: 1 week
Sponsored by: iXsystems, Inc.
The RELEASE_CRUNCH check is redundant here. We don't need it for releases
anymore, and picobsd can control this more directly without making it a special
case.
asserted. Some development boards for example will reset on DTR,
and some radio interfaces will transmit on RTS.
This patch allows "stty -f /dev/ttyu9.init -rtsdtr" to prevent
RTS and DTR from being asserted on open(), allowing these devices
to be used without problems.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D20031
newvers.sh has supported a variable setting only mode, use that in
preference to grep to future proof this script from changes there.
Differential Revision: https://reviews.freebsd.org/D19849
Since D19668 was done, new users of the -n flag have surfaced. Parse
and ignore it on the command line until they can be updated.
Suggested by: rgrimes (in D19668).
These were used to set dst flag and minutes west of UTC
respectively. These are obsolete and have been removed form the
kernel. These existed primarily to faithfully emulate early
Unix ABIs that have been removed from FreeBSD.
Reviewed by: jbh@, brooks@
Differential Revision: https://reviews.freebsd.org/D19550
The pipefail option allows checking the exit status of all commands in a
pipeline more easily, at a limited cost of complexity in sh itself. It works
similarly to the option in bash, ksh93 and mksh.
Like ksh93 and unlike bash and mksh, the state of the option is saved when a
pipeline is started. Therefore, even in the case of commands like
A | B &
a later change of the option does not change the exit status, the same way
(A | B) &
works.
Since SIGPIPE is not handled specially, more work in the script is required
for a proper exit status for pipelines containing commands such as head that
may terminate successfully without reading all input. This can be something
like
(
cmd1
r=$?
if [ "$r" -gt 128 ] && [ "$(kill -l "$r")" = PIPE ]; then
exit 0
else
exit "$r"
fi
) | head
PR: 224270
Relnotes: yes
SVN r342880 was designed to fix $((-9223372036854775808)) and things like
$((0x8000000000000000)) but also broke error detection for values of
variables without dollar sign ($((x))).
For compatibility, overflow in plain literals continues to be ignored and
the value is clamped to the boundary (except 9223372036854775808 which is
changed to -9223372036854775808).
Reviewed by: se (although he would like error checking to be removed)
MFC after: 2 weeks
X-MFC-with: r342880
Differential Revision: https://reviews.freebsd.org/D18926
The rest of this stuff is still to be discussed, but I think at this
point we have the agreement that the aliases should go.
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
there's no need to even mention it in shell rc files. Not that it's wrong;
just pointless and somewhat misleading.
Reviewed by: jilles
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D18809
The libedit "fout" output must be sent to fd 2 since it contains prompts
that POSIX says must be sent to fd 2. However, the libedit "ferr" output
receives error messages such as from "bind" that make no sense to send to fd
1.
results between an expression that refers to a variable by name and the
same expression that includes the same variable by value.
Submitted by: se@
MFC after: 1 week
if -z option also used.
Recommend the use of zip(1) if compressed files of predictable size needed.
PR: docs/41089
Submitted by: Sevan Janiyan
Reported by: areilly@bigpond.net.au
While here, pet igor
Reviewed by: bcr
Differential Revision: https://reviews.freebsd.org/D18686
with macro based around memcmp(). The latter is expected to be some
8 times faster on a modern 64-bit architectures.
In practice, throughput of doing conv=sparse from /dev/zero to /dev/null
went up some 5-fold here from 1.9GB/sec to 9.7GB/sec with this change
(bs=128k).
MFC after: 2 weeks
If word in ${param?word} is missing, the shell shall write a default error
message. So expanding ${param?} when param is not set should write an error
message like
sh: param: parameter not set
This was broken by r316417.
PR: 233585
-P was introduced in 4.4BSD-Lite2 around 1994. It overwrote file contents
with a pass of 0xff, 0x00, then 0xff, in a low effort attempt to "really
delete" files.
It has no user-visible effect; at the end of the day, the file is unlinked via
the filesystem. Furthermore, the utility of overwriting files with patterned
data is extremely limited due to caveats at every layer of the stack[0] and
therefore mostly futile. At the least, three passes is likely wasteful on
modern hardware[1]. It could also be seen as a violation of the "Unix
Philosophy" to do one thing per tiny, composable program.
Since 1994, FreeBSD has left it alone; OpenBSD replaced it with a single
pass of arc4random(3) output in 2012[2]; and NetBSD implemented partial, but
explicitly incomplete support for U.S. DoD 5220.22-M, "National Industrial
Security Program Operating Manual" in 2004[3].
NetBSD's enhanced comment above rm_overwrite makes a strong case for removing
the flag entirely:
> This is an expensive way to keep people from recovering files from your
> non-snapshotted FFS filesystems using fsdb(8). Really. No more.
>
> It is impossible to actually conform to the exact procedure given in
> [NISPOM] if one is overwriting a file, not an entire disk, because the
> procedure requires examination and comparison of the disk's defect lists.
> Any program that claims to securely erase *files* while conforming to the
> standard, then, is not correct.
>
> Furthermore, the presence of track caches, disk and controller write
> caches, and so forth make it extremely difficult to ensure that data have
> actually been written to the disk, particularly when one tries to repeatedly
> overwrite the same sectors in quick succession. We call fsync(), but
> controllers with nonvolatile cache, as well as IDE disks that just plain lie
> about the stable storage of data, will defeat this.
>
> [NISPOM] requires physical media destruction, rather than any technique of
> the sort attempted here, for secret data.
As a first step towards evental removal, make it a placebo. It's not like
it was serving any security function. It is not defined in or mentioned by
POSIX.
If you are security conscious and need to erase your files, use a
woodchipper. At a minimum, the entire disk needs to be overwritten, not
just one file.
[0]: https://www.ru.nl/publish/pages/909282/draft-paper.pdf
[1]: https://commons.erau.edu/cgi/viewcontent.cgi?article=1131&context=jdfsl
[2]: https://github.com/openbsd/src/commit/7c5c57ba81b5fe8ff2d4899ff643af18c
[3]: https://github.com/NetBSD/src/commit/fdf0a7a25e59af958fca1e2159921562cd
Reviewed by: markj, Daniel O'Connor <darius AT dons.net.au> (previous version)
Differential Revision: https://reviews.freebsd.org/D17906
The difference between EXERROR and EXEXEC was that EXEXEC passed along
exitstatus and EXERROR set exitstatus to 2 in the handling code.
By changing the places that raised EXERROR to set exitstatus to 2, the
handling of EXERROR and EXEXEC becomes the same.
You should not be using DES. You should not have been using DES for the
past 30 years.
The ed DES-CBC scheme lacked several desirable properties of a sealed
document system, even ignoring DES itself. In particular, it did not
provide the "integrity" cryptographic property (detection of tampering), and
it treated ASCII passwords as 64-bit keys (instead of using a KDF like
scrypt or PBKDF2).
Some general approaches ed(1) users might consider to replace the removed
DES mode:
1. Full disk encryption with something like AES-XTS. This is easy to
conceptualize, design, and implement, and it provides confidentiality for
data at rest. Like CBC, it lacks tampering protection. Examples include
GELI, LUKS, FileVault2.
2. Encrypted overlay ("stackable") filesystems (EncFS, PEFS?, CryptoFS,
others).
3. Native encryption at the filesystem layer. Ext4/F2FS, ZFS, APFS, and
NTFS all have some flavor of this.
4. Storing your files unencrypted. It's not like DES was doing you much
good.
If you have DES-CBC scrambled files produced by ed(1) prior to this change,
you may decrypt them with:
openssl des-cbc -d -iv 0 -K <key in hex> -in <inputfile> -out <plaintext>
Reviewed by: allanjude, bapt, emaste
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D17829
- Use Xr to reference other manual pages.
- Reference execve(2) instead of exec(2) as exec(2) does not exist.
- Remove the deprecated "Tn" macro.
- Improve the formatting of the etime description.
Reviewed by: bcr
Approved by: krion (mentor, implicit), mat (mentor, implicit)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D17780
They only make sense in the context of directory ACLs, and attempting
to set them on regular files results in errors, causing a recursive
setfacl invocation to abort.
This is derived from patches by Shawn Webb <shawn.webb@hardenedbsd.org>
and Mitchell Horne <mhorne063@gmail.com>.
PR: 155163
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15061
Output padding is specified via outlen, which is set using the return value
of fprintf. Because it's printing that padding plus a trailing byte, it
grows by one each iteration rather than reflecting actual length.
Additionally, iec was sized improperly for scaling up similarly to si.
Fixing this revealed that the humanize_number(3) call to populate persec
was using the wrong width.
Submitted by: Thomas Hurst <tom@hur.st>
Reviewed by: imp
Approved by: re (kib)
Differential Revision: https://reviews.freebsd.org/D16960
Restore the original behavior of unlink(1), passing the provided filename
directly to unlink(2), handling the first argument being "--" correctly.
This fixes "unlink -foo", broken in r97533.
PR: 228448
Submitted by: Brennan Vincent <brennan@umanwizard.com> (original version)
Submitted by: Yuri Pankov
Reported by: Brennan Vincent <brennan@umanwizard.com>
Reviewed by: emaste, kevans, vangyzen, 0mp
Approved by: re (delphij)
Differential Revision: https://reviews.freebsd.org/D17132
The intention is to lower the value of the pointer, which according to ubsan
cannot be done by adding an unsigned quantity.
Reported by: kevans
Approved by: re (kib)
MFC after: 1 week
These aliases are supported and documented in the man page. For now, they
will not be mentioned in the error when an invalid argument is encountered,
instead keeping that list to the shorter 'preferred' names of each argument.
Reported by: rgrimes
--color may be set to one of: 'auto', 'always', and 'never'.
'auto' is the default behavior- output colors only if -G or COLORTERM are
set, and only if stdout is a tty.
'always' is a new behavior- output colors always. termcap(5) will be
consulted unless TERM is unset or not a recognized terminal, in which case
ls(1) will fall back to explicitly outputting ANSI escape sequences.
'never' to turn off any environment variable and -G usage.
Reviewed by: cem, 0mp (both modulo last-minute manpage changes
Differential Revision: https://reviews.freebsd.org/D16741
CLICOLOR will behavior as always- if present at all in the environment,
allow colors.
COLORTERM, recently enforced, will have to be both present and not empty.
Submitted by: imp
This fixes the build and I will redo these changes as part of a future review
that organizes them differently. The way I tried to do it here could be done
better. Sorry for the noise.
Approved by: will (mentor)
Differential Revision: https://reviews.freebsd.org/D16737
Notable changes from what landed in r337505:
- sigalarm handler isn't setup unless we're actually using it
- Humanized versions of the amount of data transferred in the progress
update
Submitted by: imp
Reviewed by: kevans
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D16642
This moves the symlink creation to after where the files are installed.
This also inverts the shell change so that it only happens if MK_TCSH is on.
Approved by: will (mentor)
Differential Revision: https://reviews.freebsd.org/D16725
This simplifies pkgbase by migrating these to CONFS so they are properly
tagged as config files.
Approved by: will (mentor)
Differential Revision: https://reviews.freebsd.org/D16708
COLORTERM is the de facto standard, while CLICOLOR is generally specific to
FreeBSD and ls(1).
PR: 230101
Submitted by: D Green <dfrg@xsmail.com> (with manpage additions by myself)
Reviewed by: cem ("LGTM" in PR; pre-manpage changes)
MFC after: 1 week
This reports the current status on a single line every second, mirroring
similar functionality in GNU dd, and carefully interacts with SIGINFO.
PR: 229615
Submitted by: Thomas Hurst <tom@hur.st> (modified for style(9) nits by me)
MFC after: 1 week
Using padvance() requires undoing its append of '/' and prevents adjusting
its '%' logic to allow most directories with '%' in PATH.
No functional change is intended.
These are not used to link the final tool anymore. At some point in the past
the suffix rules changed to not link these in. The original reason for this in
r19176 is unclear but seems to be related to mkdep. The .depend handling is
still broken here as it is for all build tool patterns like this.
Sponsored by: Dell EMC
POSIX requires accepting unquoted newlines in word in parameter expansions
like ${param+word}, ${param#word}, although the Bourne shell did not support
it, it is not commonly used and might make it harder to find a missing
closing brace.
It was also strange that something like
foo="${bar#
}"
was rejected.
Reported by: Martijn Dekker via Robert Elz
Add a -R option to setfacl to operate recursively on directories, along
with the accompanying flags -H, -L, and -P (whose behaviour mimics
chmod).
A patch was submitted with PR 155163, but this is a new implementation
based on comments raised in the Phabricator review for that patch
(review D9096).
PR: 155163
Submitted by: Mitchell Horne <mhorne063@gmail.com>
Reviewed by: jilles
MFC after: 2 weeks
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14934
Apply patch submitted with PR 217159 to make ps use unlimited
width when not associated with a terminal (i.e., none of stdout, stdin,
or stderr is a tty). Update comments and man page correspondingly.
This change was requested to work around lack of -ww in scripts from
third-party packages, including Hadoop, and adds a small measure of
Linux compatibility. Hopefully few if any non-interactive scripts
depend on the old default of 79.
PR: 217159
Submitted by: n.deepak at gmail.com
Reviewed by: vangyzen jhb
Differential Revision: https://reviews.freebsd.org/D14614
Revert r314685, and add a comment describing the original
behavior and the intent.
Reviewed by: dab@ vangyzen@ jhb@
Differential Revision: https://reviews.freebsd.org/D14530
to see how much space it on them.
Adjust MOUNT_CHAR_DEVS to allow the free space of already mounted
devices to be displayed and report an appropriate error if the
device isn't mounted.
Reviewed by: cem
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D8801
It won't work e.g. when crossbuilding from Ubuntu Linux as mktemp is in
/bin there.
Reviewed By: bdrewery
Approved By: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D13937
Use a setup_sig() helper and make it fail when either of sigaction fails.
While there, do not leak fds for "." + minor cleanup.
Obtained from: OpenBSD (through DragonFly git eca362d0f9bd086cc56d6b5bc4f03f09e040b9db)
- Simplify the description of -H to assume 1:1 threading.
- Drop 'process' from description of 'lwp' field and the corresponding
XO field name.
- Do add an expansion of LWP in the description of 'lwp' and 'nlwps'.
- Add 'tid' as an alias for the 'lwp' field.
Reviewed by: imp, kib (older version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14021
libxo imposes a large burden on system utilities. In the case of ls, that
burden is difficult to justify -- any language that can interact with json
output can use readdir(3) and stat(2).
Logically, this reverts r291607, r285857, r285803, r285734, r285425,
r284494, r284489, r284252, and r284198.
Kyua tests continue to pass (libxo integration was entirely untested).
Reported by: many
Reviewed by: imp
Discussed with: manu, bdrewery
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D13959
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
No functional change intended.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
The wrong index was being checked for == ' ' in the resulting stringified
mode from strmode(3) -- it should have been the 11th value, not the 10th.
MFC after: 3 days
PR: 76711
Submitted by: Vasil Dimov <vd@datamax.bg>
Previously it just didn't work at all - kvm_getprocs(3) doesn't update
the &nentries when it returns NULL. The end result was that ps(1) showed
garbage data instead of reporting kinfo_proc size mismatch.
Reviewed by: cem
Obtained from: CheriBSD
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D12414
If they are still needed, you can find them in the net/bsdrcmds port.
This was proposed June, 20th and approved by various committers [1].
They have been marked as deprecated on CURRENT in r320644 [2] on July, 4th.
Both stable/11 and release/11.1 contain the deprecation notice (thanks to
allanjude@).
Note that ruptime(1)/rwho(1)/rwhod(8) were initially thought to be part of
rcmds but this was a mistake and those are therefore NOT removed.
[1] https://lists.freebsd.org/pipermail/freebsd-arch/2017-June/018239.html
[2] https://svnweb.freebsd.org/base?view=revision&revision=320644
Reviewed by: bapt, brooks
Differential Revision: https://reviews.freebsd.org/D12573
from blank lines being numbered or unnumbered, depending on whether cat
was invoked with -ne or -be.
At present, when cat is invoked with -be, there is an aditional
difference that the '$' on blank lines is placed on the far left of the
output.
Discussed in bug 210607.
While here, revert the workaround from r304035 which skipped the unit test for
this issue previously.
PR: 210607
Submitted by: myself
Reviewed by: bdrewery
Obtained from: NetBSD
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D12432
Add basic command line parsing test coverage for these utilities. The tests
were automatically generated based on their man pages. These tests can be
expanded by hand for more thorough coverage. The aim is to generate very
basic amount of test coverage for all the utilities in the base system.
Submitted by: shivansh
Reviewed by: asomers, brooks
MFC after: 3 weeks
Sponsored by: Google, Inc (GSoC 2017)
Differential Revision: https://reviews.freebsd.org/D12036
we do for the usual nice values. It could be argued that they should
use another set of indicators, since the underlying mechanism is
different, but they match the description in the manual page, and so
I think it's ok to not overcomplicate things.
PR: 81757
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Though technically correct, GCC complains about usingi a "%zd" format
specifier for a long.
Reported by: cem
MFC after: 3 weeks
X-MFC-With: 322893
Sponsored by: Spectra Logic
dd(1) casts many of its numeric arguments from uintmax_t to intmax_t and
back again to detect whether or not the original arguments were negative.
This is not correct, and causes problems with boundary cases, for example
when count is SSIZE_MAX-1.
PR: 191263
Submitted by: will@worrbase.com
Reviewed by: pi, asomers
MFC after: 3 weeks
output to not include a trailing new line, which is a potential POLA violation
for existing consumers. Change pgrep to always emit a trailing new line on
completion of its output, regardless of the delimeter in use (which technically
is also a potential POLA violation for existing consumers that rely on the
pre-r322210 buggy behaviour, but a line has to be drawn somewhere).
PR: 221534
Submitted by: kdrakehp zoho com
Reported by: kdrakehp zoho com
MFC after: 1 week
X-MFC-with: r322210
Non-tests/... changes:
- Add HAS_TESTS= to Makefiles with libraries and programs to enable iteration
and propagate the appropriate environment down to *.test.mk.
tests/... changes:
- Add appropriate support Makefile.inc's to set HAS_TESTS in a minimal manner,
since tests/... is a special subdirectory tree compared to the others.
MFC after: 2 months
MFC with: r322511
Reviewed by: arch (silence), testing (silence)
Differential Revision: D12014
e.g. "pgrep -d, getty" outputs "1399,1386,1309,1308,1307,1306,1305,1302,"
Ensure the list is correctly delimited by suppressing the emission of the
delimiter after the final PID.
Reviewed by: imp, kib
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D8537
This will prevent false positives from occurring if the test is run on
ZFS since ZFS doesn't support fflags throbbing like UFS.
PR: 221189
MFC after: 4 days
MFC with: r321949
- :f_flag fails on ZFS because UF_IMMUTABLE isn't supported [1].
- :v_flag fails on ZFS because the mode for foo is [always] updated
unnecessarily.
get_filesystem(..) (supporting function that was added to the test script)
is based on equivalent logic in usr.bin/extattr/tests/extattr_test.sh .
MFC after: 1 week
PR: 221189 [1], 221188 [2]
directories to SUBDIR.${MK_TESTS} idiom
This is being done to pave the way for future work (and homogenity) in
^/projects/make-check-sandbox .
No functional change intended.
MFC after: 1 weeks
localtime(3) returns NULL when passed an invalid time_t but date(1)
previously did not handle it. Exit with an error in that case.
PR: 220828
Reported by: Vinícius Zavam
Reviewed by: cem, kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D11660
Apart from the fact that subtle syntactic changes make a poor compile-time
option, the NOHACK case has been obviously broken since it was added,
because it uses q uninitialized if (*p != '\0').
No functional change is intended.
After the addition of SUBDIR.yes, uniquifying/ordering the SUBDIRs doesn't
make a whole lot of sense, and it's in effect a half measure.
Ordering SUBDIR (after adding SUBDIR.yes to it) in bsd.subdir.mk is a
separate change that warrants more discussion/testing, because while
the SUBDIR_PARALLEL work largely fixed dependency ordering for SUBDIRs,
there might be downstream FreeBSD consumers that rely on the SUBDIR
ordering.
MFC after: 2 months
Reviewed by: bdrewery
Differential Revision: D11398
With this patch, ",n" is an abbreviation for "1,n", ";n" abbreviates
".;n". The "n," and "n;" variants mean "n,n" and "n;n", respectively.
Also, piping to a shell command does not count as a save, so don't reset
the modified flag.
Obtained from: OpenBSD (CVS Rev. 1.58, 1.59)
If CDPATH is used non-trivially or the operand is "-", cd writes the
directory actually switched to. (We currently do this only in interactive
shells, but POSIX requires this in non-interactive shells as well.)
As mentioned in Austin group bug #1045, cd shall not return an error while
leaving the current directory changed. Therefore, ignore any write error.
While here, also add a check to verify that the link target
is updated in the testcase
MFC after: 1 month
MFC with: r320172
PR: 219943
Differential Revision: D11167
Submitted by: shivansh
Sponsored by: Google (GSoC 2017)
When '-F' option is used, the target directory needs to be unlinked.
Currently, the modified target ("target/source") is being unlinked, and
since it doesn't yet exist, the original target isn't removed.
This is fixed by skipping the block where target is modified to
"target/source" when '-F' option is set.
Hence, a symbolic link (with the same name as of the original target) to
the source_file is produced.
Update the test for ln(1) to reflect fix for option '-F'
MFC after: 1 month
PR: 219943
Differential Revision: D11167
Submitted by: shivansh
Sponsored by: Google (GSoC 2017)
The testcase fails today, so mark it with atf_expect_fail: in
particular, the target (B) isn't being unlinked and the documentation
doesn't suggest special handling for directories. Thus, there's either
a doc or an implementation bug in ln(1) that needs to be resolved.
MFC after: 1 month
MFC with: r319714, r319854, r319855
PR: 219943
Reviewed by: ngie
Submitted by: shivansh
Differential Revision: D11159 (part of a larger diff)
Sponsored by: Google, Inc (GSoC 2017)
file(1) can be compiled out of the system via MK_FILE == no, and the
output isn't guaranteed to be stable. It's better to use stat(1)/readlink(1)
instead to query symlink/file paths.
MFC after: 1 month
MFC with: r319714, r319854
Reported by: ngie
Submitted by: shivansh
Differential Revision: D11159 (part of a larger diff)
Sponsored by: Google, Inc (GSoC 2017)
* Verify that when creating a hard link to a symbolic link, '-L' option
creates a hard link to the target of the symbolic link
* Verify that when creating a hard link to a symbolic link, '-P' option
creates a hard link to the symbolic link itself
* Verify that if the target file already exists, '-f' option unlinks it so
that link may occur
* Verify that if the target file or directory is a symbolic link, '-shf'
option prevents following the link
* Verify that if the target file or directory is a symbolic link, '-snf'
option prevents following the link
* Verify that '-s' option creates a symbolic link
* Verify that '-w' option produces a warning if the source of a symbolic
link does not currently exist
Submitted by: shivansh
Reviewed by: asomers, ngie
MFC after: 1 month
Sponsored by: Google, Inc (GSoC 2017)
Differential Revision: https://reviews.freebsd.org/D11084
Starting the fc -e editor can execute arbitrary script, and executing
arbitrary script with INTOFF in effect may cause unexpected results.
This change (together with other changes) serves mainly to allow asserting
that INTOFF is not in effect when starting the evaluation of a node.
Verify that echo(1) does not...
- ... print the trailing newline character with option '-n'.
- ... print the trailing newline character when '\c' is appended to
the end of the string.
Submitted by: shivansh
Reviewed by: asomers, ngie
MFC after: 1 month
Sponsored by: Google, Inc (GSoC 2017)
Differential Revision: D11036
Split the postive and negative parts into separate test cases. The positive
test case can only run on ZFS, because only ZFS supports files that large.
PR: 219757
Reported by: ngie
MFC after: 18 days
X-MFC-with: 319339
dd(1) tried to detect whether the seek offset would overflow, but it failed
to account for the case where the provided argument was negative and the
file was a regular file (negative seeks are allowed for character devices).
I fixed it, and added a regression test.
Reported by: Coverity
CID: 1368659
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Allocating and deallocating repeatedly the 1024-byte buffer for stdout from
builtins costs CPU time for little or no benefit.
A simple loop containing builtins that write to a file descriptor, such as
i=0; while [ "$i" -lt 1000000 ]; do printf .; i=$((i+1)); done >/dev/null
is over 10% faster in a simple benchmark on an amd64 virtual machine.
Similarly to how STPUTC was changed, change struct output to store the
pointer just past the end of the available space instead of the size of the
available space, so after writing a character it is only necessary to
increment a pointer and not to decrement a counter.
It does not make much sense to generate the '-' in a pattern bracket
expression using arithmetic expansion, but it does not make sense to forbid
it either.
Try to avoid reprocessing the string if it is unnecessary.
It does not make much sense to generate the '-' in a pattern bracket
expression using arithmetic expansion, but it does not make sense to forbid
it either.
This test already passes.
The special case of modifying an existing alias does not work correctly if
the alias is currently in use. Instead, handle this case by unaliasing the
old alias (if any) and then creating a new alias.
Quoting http://mdocml.bsd.lv/mdoc/details/width.html
Do not use macros in the argument specifying the width,
since that's not portable. While GNU troff can handle it,
mandoc cannot.
MFC after: 3 days
Sponsored by: Dell EMC
With the new expansion code (word splitting during instead of after other
expansion processing), tracing the result of command substitution is no
longer possible, so stop trying.
The parsed internal representation of words consists of a byte string with a
list of nodes (commands in command substitution). Each unescaped CTLBACKQ or
CTLBACKQ | CTLQUOTE byte corresponds to an entry in the list.
If param in ${param#%##%%word} is not set, the word is not expanded (in a
deviation of POSIX shared with other ash variants and ksh93). Erroneously,
the pointer in the list of commands (argbackq) was not advanced. This caused
the wrong command to be executed later if the outer word contained another
command substitution.
Example:
echo "${unsetvar#$(echo a)}$(echo b)"
wrote "a" but should write "b".
MFC after: 1 week
The exit status will be 124, as the timeout(1) utility uses.
Reviewed by: jilles
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D9697
A follow-up fix for r314685.
Because the -w flag is parsed after ps(1) infers termwidth from COLUMNS and
stdout, and UNLIMITED happens to be the zero value, the single -w flag in
combination with a non-terminal stdout or COLUMNS=0 could result in output
truncated at 131 characters. (Despite the output being unlimited without
-w.)
Obviously, adding more -w shouldn't truncate output lines.
The committed patch is from bdrewery@, and I've reviewed and tested it.
Submitted by: bdrewery@
Reported by: bdrewery@
Sponsored by: Dell EMC Isilon
Store the result in a proper long and then compare to the proper pid_t
for overflow, so that no MD assumptions are made.
Reviewed by: jilles
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D9887
Code like t=$(stat -f %m "$file") segfaulted if -T was active and a trap
was taken while the shell was waiting for the child process to finish.
What happened was that the dotrap() call in waitforjob() was hit. This
re-entered command execution (including expand.c) at a point not expected by
expbackq(), and global state (unallocated stack string and argbackq) was
corrupted.
To fix this, change expbackq() to prepare for command execution to be
re-entered.
Reported by: bdrewery
MFC after: 1 week
If stdout isn't a tty, use unlimited width output rather than truncating to
79 characters. This is helpful for shell scripts or e.g., 'ps | grep foo'.
This hardcoded width has some history: In The Beginning of History[0], the
width of ps was hardcoded as 80 bytes. In 1985, Bloom@ added detection
using TIOCGWINSZ on stdin.[1] In 1986, Kirk merged a change to check
stdout's window size instead. In 1990, the fallback checks to stderr and
stdin's TIOCGWINSZ were added by Marc@, with the commit message "new
version."[2]
OS X Darwin has a very similar modification to ps(1), which simply sets
UNLIMITED for all non-tty outputs.[3] I've chosen to respect COLUMNS
instead of behaving identically to Darwin here, but I don't feel strongly
about that. We could match OS X for parity if that is desired.
[0]: https://svnweb.freebsd.org/csrg/bin/ps/ps.c?annotate=1065
[1]: https://svnweb.freebsd.org/csrg/bin/ps/ps.c?r1=18105&r2=18106
[2]:
https://svnweb.freebsd.org/csrg/bin/ps/ps.c?r1=40675&r2=40674&pathrev=40675
[3]:
https://opensource.apple.com/source/adv_cmds/adv_cmds-168/ps/ps.c.auto.html
PR: 217159
Reported by: Deepak Nagaraj <n.deepak at gmail.com>
