This expression was wrong, but it was causing a false positive
in some compilers that couldn't see that error() cannot return.
The actual problem of the line is that it was too complex and it is better
to split it in simplex expressions.
Copy was using directly the line numbers and incrementing them
without calling nextln(). It also didn't worry about how
line numbers are modified when we insert new lines.
Current handling of strings is a bit messy. This type is copied
from the sed implementation. Addchar_ is added to be able to live
with String and old style chars based in 3 different variables.
's/[[x=]//' was parsed as 's/[[=x]//' which (correctly)
raises an error because the "second delimiter is missing", here =].
The two got mixed up because the parser didn't return to
the "inside bracket"-state after encountering an opening bracket
while inside the bracket expression.
When `makeset` got a string containing square brackets
followed by at least one extra character, e.g. "[abc]d",
it entered an infinite loop because it was assumed
`j` could not exceed `len` without having been equal to `len`.
It can, however, when `m == len` and subsequently `j = m + 1`.
Previously, running `chmod 777` on a directory that had no read or
execute access (e.g. 111 or 000) would cause chmod to throw its
toys since it was trying to opendir before having added read permission
to the directory.
Previous behaviour was to call opendir regardless of if we are actually going
to be recursing into the directory. Additionally, some utilities that use
DIRFIRST benefit from running the function pointed to by fn before the call
to opendir. One such example is `chmod [-R] 777 dir` on a directory with mode
000, where it will be expected for chmod to first give itself rwx before
optionally listing the directory to traverse it.
Printing `undefined` to stdout means that the variable is valid but not
set. Instead, report an error in this case.
linux 4.13 appends the result of `getconf LFS_CFLAGS` to HOSTCFLAGS,
even if it prints `undefined`. This is arguably a bug in the Makefile,
but even so, getconf shouldn't report that unsupported variables are
valid.
We should not try and perform operations on an invalid DIR* stream.
Instead, we shall let the error message be printed, and the return
code set (existing behaviour) and abort afterwards.
POSIX says that -c specifies a number of bytes, not characters. This
flag is commonly used by scripts that operate on binary files to things
like extract a header. Treating the offsets as character offsets will
break things in mysterious ways.
Instead, add a -m option (chosen to match `wc -m`, which also operates
on characters) to handle character offsets.
Previously, when the destination file was created with fopen, we needed
to use fchmod to set its permissions.
Now that we pass in the mode to creat, we already get the desired
behavior of creating the file with the same mode as the source file
modified by the user's file creation mask.
This fixes the issue where a directory or special file created with
mkdir/mknod does not end up with the appropriate mode with -p or -a
(since it may have been narrowed by the umask).
This also allows us to clear the SUID and SGID bits from the mode if the
chown fails, as specified by POSIX.
If we are just copying data from one file to another, we don't need to
fill a complete buffer, just read a chunk at a time, and write it to the
output.
fread reads the entire requested size (BUFSIZ), which causes tools to
block if only small amounts of data are available at a time. At best,
this causes unnecessary copies and inefficiency, at worst, tools like
tee and cat are almost unusable in some cases since they only display
large chunks of data at a time.
writeall makes successive write calls to write an entire buffer to the
output file descriptor. It returns the number of bytes written, or -1 on
the first error.
Previously, with -p, the specified directory and all of its parents
would be 0777&~filemask (regardless of the -m flag). POSIX says parent
directories must created as (0300|~filemask)&0777, and of course if -m
is set, the specified directory should be created with those
permissions.
Additionally, POSIX says that for symbolic_mode strings, + and - should
be interpretted relative to a default mode of 0777 (not 0).
Without -p, previously the directory would be created first with
0777&~filemask (before a chmod), but POSIX says that the directory shall
at no point in time have permissions less restrictive than the -m mode
argument.
Rather than dealing with mkdir removing the filemask bits by calling
chmod afterward, just clear the umask and remove the bits manually.
