threads / patch / 1726

patchMake sure the diff machinery outputs "\ No newline ..." in english

Subject: [PATCH] Make sure the diff machinery outputs "\ No newline ..." in english

## tl;dr

5 messages between Sep 4, 2005 and Sep 6, 2005. Diffs are folded; open one to read it.

replies: 4people: 4as markdown or json

Fredrik Kuivinen· Sep 4, 2005, 18:17 UTC · lore

In non-english locales diff(1) do sometimes output "\ No newline at end of file" in some other language. Set LC_ALL to C before execing diff to avoid this behaviour.

Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>

---

 diff.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

eb6261334d65c3134d9dd822fd64e33ed8ad2dfc

Show changes to diff.c +1 −0

diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -207,6 +207,7 @@ static void builtin_diff(const char *nam
 		}
 	}
 	fflush(NULL);
+	putenv("LC_ALL=C");
 	execlp("/bin/sh","sh", "-c", cmd, NULL);
 }

Junio C Hamano· Sep 4, 2005, 18:48 UTC · re: Fredrik Kuivinen · lore

Re: [PATCH] Make sure the diff machinery outputs "\ No newline ..." in english

Fredrik Kuivinen <freku045@student.liu.se> writes:

Show 5 quoted lines

> In non-english locales diff(1) do sometimes output "\ No newline at end of
> file" in some other language. Set LC_ALL to C before execing diff to avoid
> this behaviour.
>
> Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>

I was thinking about this when I was examining your other patch.

What else, other than the incomplete line marker (and timestamp output it uses by default, which we disable by passing explicit -L flags), are affected by locale in diff output?

Especially, if the diff output is more readable for human consumers (i.e. reviewers) without making it harder to use to machine consumers (i.e. patch or git-apply) when generated under a locale that is 'native' to the data, this patch robs from users the possibility of doing so.

IOW, in a Swedes-only project that tracks a document in Swedish, it _might_ be friendlier and more useful to the users if allowed generating diffs under sv_SE locale, as long as such a diff does not make the processing by patch and git-apply more difficult (which your other patch already solved for git-apply).

Fredrik Kuivinen· Sep 5, 2005, 06:01 UTC · re: Junio C Hamano · lore

Re: [PATCH] Make sure the diff machinery outputs "\ No newline ..." in english

On Sun, Sep 04, 2005 at 11:48:08AM -0700, Junio C Hamano wrote:

Show 13 quoted lines

> Fredrik Kuivinen <freku045@student.liu.se> writes:
> 
> > In non-english locales diff(1) do sometimes output "\ No newline at end of
> > file" in some other language. Set LC_ALL to C before execing diff to avoid
> > this behaviour.
> >
> > Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
> 
> I was thinking about this when I was examining your other patch.
> 
> What else, other than the incomplete line marker (and timestamp
> output it uses by default, which we disable by passing explicit
> -L flags), are affected by locale in diff output?

After a quick look through the diff source I didn't find anything else. It's quite possible that I haved missed something though. Most of the translated messages are related to error reporting, which I guess might be nice to have in the user specified language.

Show 11 quoted lines

> Especially, if the diff output is more readable for human
> consumers (i.e. reviewers) without making it harder to use to
> machine consumers (i.e. patch or git-apply) when generated under
> a locale that is 'native' to the data, this patch robs from
> users the possibility of doing so.
> 
> IOW, in a Swedes-only project that tracks a document in Swedish,
> it _might_ be friendlier and more useful to the users if allowed
> generating diffs under sv_SE locale, as long as such a diff does
> not make the processing by patch and git-apply more difficult
> (which your other patch already solved for git-apply).

I agree that it's kind of evil to remove the option of generating the output in some other language.

Another possibility is to set LC_MESSAGES to C instead. If we go this way the user can override it by setting LC_ALL. The difference is that in most configurations the user has to make an active choice to get the 'native' language output and english will be the default.

- Fredrik

Linus Torvalds· Sep 5, 2005, 15:52 UTC · re: Fredrik Kuivinen · lore

Re: [PATCH] Make sure the diff machinery outputs "\ No newline ..." in english

On Mon, 5 Sep 2005, Fredrik Kuivinen wrote:

Show 5 quoted lines

> 
> After a quick look through the diff source I didn't find anything
> else. It's quite possible that I haved missed something though. Most
> of the translated messages are related to error reporting, which I
> guess might be nice to have in the user specified language.

Is it possible that we could integrate the "diff" algorithm into git, and get rid of the dependency on an external GNU diff? It would also make the portability problems go away (ie old diff's being broken).

It would also potentially speed up the normal built-in diff a lot, since we wouldn't have to execute a whole other program to generate a diff, just call a helper function the way we do for xdiff..

Unreasonable?

		Linus

Daniel Barkalow· Sep 6, 2005, 20:05 UTC · re: Linus Torvalds · lore

Re: [PATCH] Make sure the diff machinery outputs "\ No newline ..." in english

On Mon, 5 Sep 2005, Linus Torvalds wrote:

Show 16 quoted lines

> On Mon, 5 Sep 2005, Fredrik Kuivinen wrote:
> > 
> > After a quick look through the diff source I didn't find anything
> > else. It's quite possible that I haved missed something though. Most
> > of the translated messages are related to error reporting, which I
> > guess might be nice to have in the user specified language.
> 
> Is it possible that we could integrate the "diff" algorithm into git, and 
> get rid of the dependency on an external GNU diff? It would also make the 
> portability problems go away (ie old diff's being broken).
> 
> It would also potentially speed up the normal built-in diff a lot, since
> we wouldn't have to execute a whole other program to generate a diff, just
> call a helper function the way we do for xdiff..
> 
> Unreasonable?

The algorithm actually used by GNU diff is pretty complicated, and I don't really understand the actual implementation, which evidentally has a few important refinements over the original paper.

I've written my own diff, mainly to try a different algorithm, and it seems to work, but the code isn't yet appropriate to submit. This algorithm also has the advantage that it can identify moved sections and is less interested in interleaving a removed function with a new function to provide the shortest possible diff. I expect that I could get it to work if I put in a day on it; it's mostly writing a hashtable implementation for non-NULL-terminated string-keyed hash tables.

	-Daniel
*This .sig left intentionally blank*