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
