From: Junio C Hamano Date: Mon, 15 Jun 2009 04:23:08 GMT Subject: Re: [PATCHv2 1/3] git-sh-setup: introduce say() for quiet options Message-ID: <7vab4ap1lf.fsf@alter.siamese.dyndns.org> In-Reply-To: <18071eea0906141621t676a965aqc3056b481b8e8796@mail.gmail.com> Thomas Adam writes: > 2009/6/15 Stephen Boyd : >> Scripts should use say() when they want to echo to stdout. Setting >> GIT_QUIET will mute say(), allowing scripts to easily implement a quiet >> option. >> >> Signed-off-by: Stephen Boyd >> --- >>  git-sh-setup.sh |    7 +++++++ >>  1 files changed, 7 insertions(+), 0 deletions(-) >> >> diff --git a/git-sh-setup.sh b/git-sh-setup.sh >> index 80acb7d..f88184e 100755 >> --- a/git-sh-setup.sh >> +++ b/git-sh-setup.sh >> @@ -44,6 +44,13 @@ die() { >>        exit 1 >>  } >> >> +say () { >> +       if test -z "$GIT_QUIET" >> +       then >> +               echo "$@" > > Except that where you've then replaced various calls with say() they > were originally using printf. The only difference I found in these three patch series is this hunk on git-am.sh in [PATCHv2 3/3]: @@ -498,7 +505,7 @@ do stop_here $this fi - printf 'Applying: %s\n' "$FIRSTLINE" + say "Applying: $FIRSTLINE" case "$resolved" in '') This was made from echo to printf with 4b7cc26 (git-am: use printf instead of echo on user-supplied strings, 2007-05-25), with reason: Under some implementations of echo (such as that provided by dash), backslash escapes are recognized without any other options. This means that echo-ing user-supplied strings may cause any backslash sequences in them to be converted. Using printf resolves the ambiguity. This bug can be seen when using git-am to apply a patch whose subject contains the character sequence "\n"; the characters are converted to a literal newline. Noticed by Szekeres Istvan. To make the conversion of the above hunk correct, say() must use printf "%s" "$*" Needless to say, all the conversions from "echo" to "say" in the patch series need to be verified.