Pointers are only visible when run as superuser. Also in most cases
you want to know which process is the session leader and which process
groups belong together. So it is better to print the session id.
OK deraadt@ (long time ago)
line, it should abort ("syntax error: NUL byte unexpected"). There
appears to be one piece of software which is misinterpreting guidance
of this, and trying to depend upon embedded NUL. During research,
every shell we tested has one or more cases where a NUL byte in the
input or inside variable contents will create divergent behaviour from
other shells. (ie. gets converted to a space, is silently skipped, or
aborts script parsing or later execution). All the shells are written
in C, and majority of them use C strings for everything, which means
they cannot embed a NUL, so this is not surprising. It is quite
unbelievable there are people trying to rewrite history on a lark, and
expecting the world to follow alone.
If there is ONE THING the Unix world needs, it is for bash/ksh/sh to
stop diverging further by permitting STUPID INPUT that cannot
plausibly work in all other shells. We are in a post-Postel world.
It remains possible to put arbitrary bytes *AFTER* the parts of the
shell script that get parsed & executed (like some Solaris patch files
do). But you can't put arbirary bytes in the middle, ahead of shell
script parsed lines, because shells can't jump to arbitrary offsets
inside the input file, they go THROUGH all the 'valid shell script
text lines' to get there.
This was in snapshots for more than 2 months, and only spotted one
other program depending on the behaviour (and that test program did
not observe that it was therefore depending in incorrect behaviour!!)
ok ingo. Softer ok's from various others.
no change noted from 2008 spec, but i've added -h to the list
of extensions. that was an omission from our 2008 notes,
rather than a change in the spec.
the hup flag before and after that call, when the buffer structures are stable
for write_file() to work. Remove the hup handling from the SPL0() macro,
because this is run in at least one place during structure instability.
The SIGINT handler, which uses siglongjmp(), is also trusting the SPL1/SPL0
dance more than it should.
ok millert
This makes signal handler safe on OpenBSD.
To avoid overflows the accuracy is scaled. Above 10 minutes run time
we only care about second accuracy. Between 1 seconds and 10 minutes
we use millisecond accuracy.
Below one second we use nanoseconds, but those numbers are probably
meaningless.
Signal handler problem pointed out by deraadt
OK deraadt, millert, tb
the signal handler was calling a big function which is shared between
multiple contexts -- that hides the rule that this big function has
signal safe requirements (which it fails). now, the signal handler
contains all the code, and everyone else calls the signal handler function
as a regular function, from their (normal) contexts.
the signal handler context is the most strict, so this pattern is better.
ok florian
It's hopeless because POSIX requires both since Issue 6 (2001).
Both always worked on OpenBSD, no matter which base system shell was used.
According to research done by jsg@, it seems likely that actually,
"test -L" has precedence over "test -h" by about one year:
v8 (Feb 1985) had -L, SunOS 3.0 (Feb 1986) had -h; but SVR4 (1989)
already had both, so we are talking about 35 years of petrification.
More details: https://marc.info/?l=openbsd-bugs&m=171867441927989
Resolving a question raised by Tim dot theCHASEs dot com on bugs@.
OK deraadt@ millert@ jsg@ jmc@ and also works for Tim Chase.
'too old', use pathconfat(_PC_TIMESTAMP_RESOLUTION, AT_SYMLINK_NOFOLLOW)
to get the timestamp resolution to which the _source_ timestamp
should be truncated for a stable comparison.
Problem reported by Walter Alejandro Iglesias (wai(at)roquesor.com)
ok millert@
This fixes a problem where the file list output was fully-buffered
when used as part of a pipeline. With this change, files are listed
as they are extracted in verbose mode. OK deraadt@ guenther@
The existing tar_opt() implements support for -o write_opt=nodir for the
old tar and ustar formats. We don't really want to support it for the
pax format, and we want to be able to implement pax format specific
options (even if there are none right now). ok millert@
Lets us store longer file names, link names, finer grained timestamps,
larger archive member files, etc; at the expense of larger uncompressed
archives and less widespread support across the ecosystem. If you're
unhappy with the new defaults, you can use -F ustar. Or you can help
fix bugs / find a better middle ground.
Prodding from various including job@ and deraadt@
ok sthen@ caspar@ millert@
512 bytes isn't enough if you want to store rather large but still
useful long file names or symbolic links destinations. The best way to
size the buffer to read those records is based upon the largest paths
pax(1) can handle, and that is PAXPATHLEN.
Reported by caspar@, input and ok millert@
We want to move towards 'pax' as the default format for writing, this
option lets users downgrade to -F ustar where the 'pax' format isn't
convenient/usable (same as -x <format> in pax(1)).
-F <format> is more generic than -o/-O. -H (GNU tar) was already used
and we don't want long options so --format (NetBSD/FreeBSD) is excluded
too.
ok sthen@ caspar@ millert@
We expect that existing pax archives start with a global or extended
header. If they don't, append operations will be done using ustar
format.
Fixes append mode on pax archives where pax(1) would bail out when
appending to pax archives, falsely detecting a mismatch. Reading was
unaffected. Reported by caspar@, ok caspar@ millert@
Softdep has been a no-op for some time now, this removes it to get
it out of the way.
Flensing mostly done in Talinn, with some help from krw@
ok deraadt@
