[PATCH] am: invoke perl's strftime in C locale

Subsystems: the rest

STALE3715d

6 messages, 3 authors, 2016-06-15 · open the first message on its own page

[PATCH] am: invoke perl's strftime in C locale

From: Dmitry V. Levin <hidden>
Date: 2016-06-15 22:55:45

This fixes "hg" patch format support for locales other than C and en_*,
see https://bugzilla.altlinux.org/show_bug.cgi?id=28248

Signed-off-by: Dmitry V. Levin <redacted>
---
 git-am.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-am.sh b/git-am.sh
index c682d34..64b88e4 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -334,7 +334,7 @@ split_patches () {
 			# Since we cannot guarantee that the commit message is in
 			# git-friendly format, we put no Subject: line and just consume
 			# all of the message as the body
-			perl -M'POSIX qw(strftime)' -ne 'BEGIN { $subject = 0 }
+			LC_ALL=C perl -M'POSIX qw(strftime)' -ne 'BEGIN { $subject = 0 }
 				if ($subject) { print ; }
 				elsif (/^\# User /) { s/\# User/From:/ ; print ; }
 				elsif (/^\# Date /) {
-- 
ldv

Re: [PATCH] am: invoke perl's strftime in C locale

From: Jeff King <hidden>
Date: 2016-06-15 22:55:46

On Tue, Jan 15, 2013 at 12:59:33AM +0400, Dmitry V. Levin wrote:
quoted hunk
diff --git a/git-am.sh b/git-am.sh
index c682d34..64b88e4 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -334,7 +334,7 @@ split_patches () {
 			# Since we cannot guarantee that the commit message is in
 			# git-friendly format, we put no Subject: line and just consume
 			# all of the message as the body
-			perl -M'POSIX qw(strftime)' -ne 'BEGIN { $subject = 0 }
+			LC_ALL=C perl -M'POSIX qw(strftime)' -ne 'BEGIN { $subject = 0 }
 				if ($subject) { print ; }
 				elsif (/^\# User /) { s/\# User/From:/ ; print ; }
 				elsif (/^\# Date /) {
This puts all of perl into the C locale, which would mean error messages
from perl would be in English rather than the user's language. It
probably isn't a big deal, because that snippet of perl is short and not
likely to produce problems, but I wonder how hard it would be to set the
locale just for the strftime call.

-Peff

Re: [PATCH] am: invoke perl's strftime in C locale

From: Antoine Pelisse <hidden>
Date: 2016-06-15 22:55:46

This puts all of perl into the C locale, which would mean error messages
from perl would be in English rather than the user's language. It
probably isn't a big deal, because that snippet of perl is short and not
likely to produce problems, but I wonder how hard it would be to set the
locale just for the strftime call.
Maybe just setting LC_TIME to C would do ...
From locale(7) man page:
       LC_TIME
              changes  the behavior of the strftime(3) function to
display the current time in a locally acceptable form; for
              example, most of Europe uses a 24-hour clock versus the
12-hour clock used in the United States.

Re: [PATCH] am: invoke perl's strftime in C locale

From: Jeff King <hidden>
Date: 2016-06-15 22:55:46

On Tue, Jan 15, 2013 at 05:42:12PM +0100, Antoine Pelisse wrote:
quoted
This puts all of perl into the C locale, which would mean error messages
from perl would be in English rather than the user's language. It
probably isn't a big deal, because that snippet of perl is short and not
likely to produce problems, but I wonder how hard it would be to set the
locale just for the strftime call.
Maybe just setting LC_TIME to C would do ...
Yeah, that is a nice simple solution. Dmitry, does just setting LC_TIME
fix the problem for you?

-Peff

Re: [PATCH] am: invoke perl's strftime in C locale

From: Dmitry V. Levin <hidden>
Date: 2016-06-15 22:55:46

On Tue, Jan 15, 2013 at 08:50:59AM -0800, Jeff King wrote:
On Tue, Jan 15, 2013 at 05:42:12PM +0100, Antoine Pelisse wrote:
quoted
quoted
This puts all of perl into the C locale, which would mean error messages
from perl would be in English rather than the user's language. It
probably isn't a big deal, because that snippet of perl is short and not
likely to produce problems, but I wonder how hard it would be to set the
locale just for the strftime call.
Maybe just setting LC_TIME to C would do ...
Yeah, that is a nice simple solution. Dmitry, does just setting LC_TIME
fix the problem for you?
Just setting LC_TIME environment variable instead of LC_ALL would end up
with unreliable solution because LC_ALL has the highest priority.

If keeping error messages from perl has the utmost importance, it could be
achieved by
-			perl -M'POSIX qw(strftime)' -ne 'BEGIN { $subject = 0 }
+			perl -M'POSIX qw(strftime :locale_h)' -ne '
+				BEGIN { setlocale(LC_TIME, "C"); $subject = 0 }
but the little perl helper script we are talking about hardly worths so
much efforts.


-- 
ldv

[PATCH v3] am: invoke perl's strftime in C locale

From: Dmitry V. Levin <hidden>
Date: 2016-06-15 22:55:46

This fixes "hg" patch format support for locales other than C and en_*.
Before the change, git-am was making "Date:" line from hg changeset
metadata according to the current locale, and this line was rejected
later with "invalid date format" diagnostics because localized date
strings are not supported.

Reported-by: Gleb Fotengauer-Malinovskiy <redacted>
Signed-off-by: Dmitry V. Levin <redacted>
---

 v3: alternative implementation using setlocale(LC_TIME, "C")

 git-am.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/git-am.sh b/git-am.sh
index c682d34..8677d8c 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -334,7 +334,8 @@ split_patches () {
 			# Since we cannot guarantee that the commit message is in
 			# git-friendly format, we put no Subject: line and just consume
 			# all of the message as the body
-			perl -M'POSIX qw(strftime)' -ne 'BEGIN { $subject = 0 }
+			perl -M'POSIX qw(strftime :locale_h)' -ne '
+				BEGIN { setlocale(LC_TIME, "C"); $subject = 0 }
 				if ($subject) { print ; }
 				elsif (/^\# User /) { s/\# User/From:/ ; print ; }
 				elsif (/^\# Date /) {
-- 
ldv
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help