Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#28 mksquashfs quiet/verbose output

Nick Cross

Currently mksquashfs is quite verbose in its output which isn't ideal for use in scripts. It would be really useful if the patch (or a variation on it) suggested here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443639 could be integrated. I have reproduced the webpage/patch below in case it ever disappears.

From: Justin Pryzby <jpryzby+d@quoininc.com>
To: submit@bugs.debian.org
Subject: squashfs-tools: please add -quiet mode
Date: Sun, 23 Sep 2007 00:08:36 -0400

[Message part 1 (text/plain, inline)]

Package: squashfs-tools
Version: 1:3.2r2-7
Severity: wishlist
Tags: upstream patch
X-Debbugs-Cc: plougher@users.sourceforge.net
Forwarded: plougher@users.sourceforge.net

For debian-live I wish to reduce the normal/expected output as much as
possible. At present output remaining after a grep |sed filter is
15+% from mksquashfs, and this is the only remaining output (after my
filter) which IMO should normally be suppressed.

(I also made the following filter for squash):
sed -re '/^Filesystem size/,/^Number of directories/d' \ -e '/^Number of [ug]ids/{:l; N; s/\n[[:space:]]//; t l; D}'

I note:
. "silent" already exists; it's initialized to TRUE = 1. Ulrich
Drepper would say that initialization of globals and other statics
should be to 0 whenever possible to minimize initialization
. I've not tried to use the existing variable but rather submit a
minimal patch. I think the ideally situation is "int verbose=0"
with -v verbose switch.
. -quiet support isn't complete. In particular read_fs outputs
things during append but doesn't already have access to "silent"
and I've not added "extern" entries to the header file or the other
C files. unsquashfs should probably also support -quiet.
. I don't think this should be added as a debian-specific patch
unless a compatible patch will be added upstream, otherwise debian
people will end up writing things using -quiet which fail on other
. valgrind shows some potentially-interesting output, although it's
my understanding that the zlib things are false positives and
deliberate behavior by zlib for performance.