On 27/10/19 10:26 pm, la.l...@free.fr wrote:
> Uses stat -c '%i %s' and sort -u to count hardlink one time.
> Gives same result than cat | wc -c without harlinks and good result with
> hardlinks.
> Doesn't use filenames
>
>
>>From cf4ef0333ccc6f080882ee9f3c27049be41bce67 Mon Sep 17 00:00:00 2001
Uses stat -c '%i %s' and sort -u to count hardlink one time.
Gives same result than cat | wc -c without harlinks and good result with
hardlinks.
Doesn't use filenames
>From cf4ef0333ccc6f080882ee9f3c27049be41bce67 Mon Sep 17 00:00:00 2001
From: nenesse
Date: Sun, 27 Oct 2019 12:08:36 +0100
Subj
Uses stat -c '%i %s' and sort -u to count hardlink one time.
Gives same result than cat | wc -c without harlinks and good result with
hardlinks.
Doesn't use filenames
Exclude files with hardlinks when cat'ing all the files, and do a second
run to look at each file with hardlinks, keep track of the ones we've
already operated on, and only cat each inode once. Then use "wc -c" to get
the size of all (deduplicated) files the same way we were already doing.
Origina
From: Ronan Pigott
V3 addresses eschwartz comment that leading trailing whitespace are not
handled correctly. With these changes it is no longer necessary to
modify INODECMD and other files that use it, so those changes have been
removed and another patch can address them if necessary. Filenames
From: Ronan Pigott
Signed-off-by: Ronan Pigott
---
scripts/Makefile.am | 1 +
scripts/libmakepkg/util/dirsize.sh.in | 45 +++
scripts/libmakepkg/util/meson.build | 1 +
scripts/makepkg.sh.in | 2 +-
4 files changed, 48 insertions(+)
zipman:
read -r protects against those evil manpages whose filenames contain
backslash escapes, (muahahaha?)
IFS= read protects against filenames with:
- leading whitespace (but no one is actually stupid enough to configure
their MAN_DIRS=() in makepkg.conf with such silly directories, *right*
On Sun Oct 27, 2019 at 2:42 AM Eli Schwartz wrote:
> You mention:
>
> > To make supporting whitespace in filenames easier, I changed INODECMD
> > to output only the inode and instead rely on find's -print0 to
> > reliably
> > parse complete filenames. This fixes some errors for files that begin
>
