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.
Previously:
$ du doesntexist
du: lstat doesntexist: No such file or directory
0 doesntexist
Now:
$ du doesntexist
du: lstat doesntexist: No such file or directory
Also, just call nblks one time.
In the description of 3111908b03, it says
that the functions must be able to handle st being NULL, but recurse
always passes a valid pointer. The only function that was ever passed
NULL was rm(), but this was changed to go through recurse in
2f4ab52739, so now the checks are
pointless.
In commit 30fd43d7f3, unescape was
simplified significantly, but the new version failed to NULL terminate
the resulting string.
This causes bad behavior in various utilities, for example tr:
Broken:
$ echo b2 | tr '\142' '\143'
c3
Fixed:
$ echo b2 | tr '\142' '\143'
c2
This bug breaks libtool's usage of tr, causing gcc to fail to build with
sbase.
Function declarators with empty parentheses is an obsolescent feature in
C99, and it is not clear to me that the standard allows assigning
assigning a function pointer declared in this way to a function declared
in prototype-format.
In any case, using a union for the functions is just as simple and
enforces that we pass the correct types to the functions.
From 6665eaa1d2c25a95b44a4f4fb3d24a3bd5c1180f Mon Sep 17 00:00:00 2001
From: Thomas Mannay <audiobarrier@openmailbox.org>
Date: Thu, 3 Nov 2016 15:16:32 +0000
Subject: [PATCH] Treat addresses of 0 as 1 for insert
_Bug_
Got the following error after cloning and running make:
paste.c: In function ‘parallel’:
paste.c:70:4: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
else
^~~~
paste.c:72:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘else’
last++;
^~~~
This patch preserves the same functionality and just adjusts indentation to squelch the warning.
_Test plan_
Used the following 'script' to convince myself output looked correct for inputs
where the latter arguments to paste had fewer lines.
make && printf "1\n2\n" > two.txt && printf "" > zero.txt && ./paste -d, two.txt zero.txt
Previously, if a file failed to read in a checksum list, it would be
reported as not matched rather than a read failure.
Also, if reading from stdin failed, previously a bogus checksum would be
printed anyway.
The -s flag previously called strip(1) on the installed file.
This patch changes install(1)'s behaviour to ignore -s.
Many makefiles use the -s flag, so it has to be recognised for
compatibility, however it does not have to do anything because
symbols do not negatively affect the functionallity of binaries.
Ignoring -s have the added benefit that the user do not need
to edit makefiles if they want the symbols that are useful for
debugging. If the user wants to strip away symbols, it can be
done manually or automatically by the package manager.
Laslo: Update the man-date and remove -s from usage()
Signed-off-by: Mattias Andrée <maandree@kth.se>
