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.
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