_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>
memmove moves a number of bytes, not pointers, so if you passed a number
of arguments that is larger than the pointer byte size, you could
end up crashing or skipping the install of a file and installing another
twice.
Also, argv was never decreased to match the moved arguments, so the -t
parameter was added in the NULL argv slot.
Also, since parsemode exits on failure, don't bother checking return
value in xinstall (this would never trigger anyway because mode_t can be
unsigned).
The %b case was using fputs after unescape to print the argument, which
meant that it could not handle nul bytes. Instead, store the length
returned from unescape and use fwrite to properly handle them.
Laslo: Fix some things pointed out by mandoc -Tlint:
1) replace empty lines with .Pp, we want to start a new
paragraph
2) Add a comma before the second item in SEE ALSO
3) Place SEE ALSO before STANDARDS, as is the convention
4) Update the man-date
By stripping backslashes this code caused a number of bugs.
'\<digit>' expressions caused literal <digit>s to be subbed-in,
'\&' was treated identically to '&', and other escaped characters
added garbage to the string.
regexec(3) happily matches /^$/ against the text of line
zero (the null string), causing an error.
Also update email address for Wolfgang Corcoran-Mathe
See his description below. Thanks Michael!
---
A bug was introduced in bc4c293fe5 causing the
range length for the next set to be used instead of the first one. This causes
issues when choosing the replacement rune when the ranges are of different
lengths.
Current behavior:
$ echo 1234 | tr 'a-f1-4' '1-6a-d'
56ab
Correct behavior:
$ echo 1234 | tr 'a-f1-4' '1-6a-d'
abcd
This also fixes range expressions in the form [a-z], which get encoded as four
ranges '[', 'a'..'z', ']', causing all a-z characters to get mapped to ']'. This
form is occasionally used in shell scripts, including the syscalltbl.sh script
used to build linux.
---
Previously, this would not work properly and not be let through the
sanity check.
This is a dirty hack until the next iteration where I'll clean up the
data structures and make this saner.
If you look at GNU coreutils, they do not support the mappings
$ echo "1234abc" | tr "[:alnum:]" "[:upper:]"
$ echo "ABCabc" | tr -c "[:upper:]" "[l*]"
to only give a few examples. This commit broadens the scope of tr(1)
as far as humanly possible to map between classes and non-classes,
making tr a usable tool and actually fulfilling user expectations.
Posix really is of no help here as it still kind of assumes the
fixed ASCII table instead of complex Unicode code points or even
Grapheme clusters.
Okay, it took me a while and another look at the Posix spec to see that
I have been dealing with squeezing in a way too complicated way.
What just needed to be done is before doing the final write to deploy
the squeeze-check. We actually do not need this atomically complicated
squeeze check in every single edge-case. Now it should work properly.
Given:
static int marks['z' - 'a'];
marks[c];
In this case c is the character read and index is out of bounds. We
need marks[c - 'a']
While playing around with optimization settings gcc caught caught this.
Also fix one check for c, change from isalpha to islower.
-emg
From 2cc36818283e9068576c1042690c016a81b709a3 Mon Sep 17 00:00:00 2001
From: Evan Gates <evan.gates@gmail.com>
Date: Fri, 15 Jul 2016 09:52:39 -0700
Subject: [PATCH] fix marks indexing
This allows users to touch files they have write access to, but aren't the
owner.
Also, remove utime.h include (not necessary since
4132561c17), and make sure to check the return
value of localtime (potentially preventing a NULL pointer derefence).
Currently, if the caller has a umask of 002 or 000, the file gets created as 644
anyway.
Also, add O_WRONLY to the open call, since POSIX says that "Applications shall
specify exactly one of the first five values (file access modes) below in the
value of oflag".
This is required in order for autoconf's AC_PROG_INSTALL to use the sbase
install. Otherwise it will fall back to the slow and sucky install-sh script
from automake.
Currently, if you specify -t x, then s is advanced once in the switch statement
to determine the length, and then once again in the for loop, resulting in a
read past the end of the argument.
Also, use sizeof(int) when no length is specified, as specified by POSIX.
