David Kastrup <d...@gnu.org> writes:

> Junio C Hamano <gits...@pobox.com> writes:
>> Jonathan Nieder <jrnie...@gmail.com> writes:
>>> Junio C Hamano wrote:
>>>>> Uwe Storbeck wrote:
>>>>>> +        printf '%s\n' "$@" | sed -e 's/^/#      /'
>>>> This is wrong, isn't it?  Why do we want one line per item here?
>>> Yes, Hannes caught the same, too.  Sorry for the sloppiness.
>>> We currently use "echo" all over the place (e.g., 'echo "$path"' in
>>> git-sh-setup), and every time we fix it there is a chance of making
>>> mistakes.  I wonder if it would make sense to add a helper to make the
>>> echo calls easier to replace:
>> I agree that we would benefit from having a helper to print a single
>> line, which we very often do, without having to worry about the
>> boilerplate '%s\n' of printf or the portability gotcha of echo.
>> I am a bit reluctant to name the helper "sane_echo" to declare "echo
>> that interprets backslashes in the string is insane", though.
> raw_echo

Yeah, but the thing is, this is not even "raw" if you view it from
the direction of knowing what "echo" does.  That is why I repeated
"helper to print a single line", which is a viewpoint from the user
side.  "We do not care how it is implemented, we just want a single
line printed" is what we want to express, which "say" is perfectly
in line with.  "We use a subset semantics of 'echo' to implement it"
is of secondary concern.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to