David Kastrup <dak@xxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Jonathan Nieder <jrnieder@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html