Re: [PATCHv2 1/3] git-sh-setup: introduce say() for quiet options

[Junio C Hamano <gitster@pobox.com>]

Thomas Adam <thomas.adam22@gmail.com> writes:

> 2009/6/15 Stephen Boyd <bebarino@gmail.com>:
>> 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 <bebarino@gmail.com>
>> ---
>>  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.