Author: Morel Bérenger <firstname.lastname@example.org>
Date: Wed, 26 Feb 2020 00:28:22 +0100
rewrote README file
|M||README|| | ||64||++++++++++++++++++++++++++++++++--------------------------------|
|M||merge.cpp|| | ||4||++++|
2 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/README b/README
@@ -1,39 +1,39 @@
This tool merges sequential entries if they have some fields with same values.
-It's only mandatory argument for now is the FIELDS environment variable, which
-is used to know which fields are to be exact in order to be merged.
-*All* fields must match, otherwise entries will not be merged.
-Entries needs to be sorted on those fields in order to be merges.
-FIELD_SEP is an environment variable that allows one to define the list of
-characters that will be considered as fields delimiters. Each character will be
-a field delimiter (UTF-8 not supported for now). By default, field separators
-are space (" ", 0x20) and horizontal tabulation ("\t", 0x09).
-Entries are defined in the environment variable ENTRY_SEP, and is the line feed
-character ("\n", 0x0A) by default. This is not tested though, so it is probably
-safer to stay with the default, which is anyway used by most if not all other
-This is a work in progress tool, but it works for me.
-Example of usage:
-FIELD_SEP=": \t" FIELDS="1,3" ./merge <<EOF
+* a C++ compiler (clang and g++ have been tested);
+* pandoc to build man-page;
-This is a single file project, at least for now, so to use it, well, just use
-your favorite C++ compiler and run the resulting binary with some path
-information, for example:
-clang++ merge.cpp -o merge && FIELDS="1" ./merge < foo.data
+This is a work in progress tool, but it works for me.
-A Makefile should be writen, someday. Same for a real man-page.
+It is possible to build a statically linked binary, but the invocation will be
+different depending on your OS and requires alternate tools. To be honest, it is
+quite hackish, which is why it's not (yet?) a Makefile build option.
+Even on Debian, the invocation may differ a lot between major versions, for
+example it's more hackish un current stable (Buster) than it was in old-stable
+(Stretch), especially with the include paths.
+On Debian buster, I do this for example (beware, every single change can break
+clang++ -o merge \
+ merge.cpp /usr/lib/x86_64-linux-musl/crt1.o \
+ -Os -nostdlib -static -fno-exceptions -stdlib=libc++ -nobuiltininc -nostdinc++ \
+ -L /usr/lib/x86_64-linux-musl \
+ -lpthread -lc \
+ -I /usr/lib/llvm-7/include/c++/v1/ \
+ -I /usr/include/x86_64-linux-musl/ \
+ -D LIBCPP_MUSL_STATIC
+The resulting binary is bigger than the output of `make` (on this system,
+stripped dynamic linking gives a 19Kio binary, stripped static gives a 38Kio one)
+but does not imply to install the dynamic libraries, which are, here, around
+2Mio for libstdc++ and 850Kio for libc++.
+Some would also argue about security, since statically linked executables do not
+load code from files than can be hijacked, for example with `$LD_LIBRARY_PATH`.
diff --git a/merge.cpp b/merge.cpp
@@ -1,3 +1,7 @@
+#define __GLIBC_PREREQ(x,y) 0