[PATCH] sys$command
Sven Strickroth
perl of msysgit seems to be build with "msys" as achitecture. This
causes that git-svn (better Term\ReadLine.pm) creates empty
"sys$command" files in some circumstances.
The following patch fixes this issue:
From bb2620155bb0351a385c87b6b38edbb0b03cf7e9 Mon Sep 17 00:00:00 2001
From: Sven Strickroth <em...@cs-ware.de>
Date: Fri, 30 Dec 2011 04:57:47 +0100
Subject: [PATCH] correctly detect console
Signed-off-by: Sven Strickroth <em...@cs-ware.de>
---
lib/perl5/5.8.8/Term/ReadLine.pm | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/perl5/5.8.8/Term/ReadLine.pm b/lib/perl5/5.8.8/Term/ReadLine.pm
index 48eb991..6965aec 100644
--- a/lib/perl5/5.8.8/Term/ReadLine.pm
+++ b/lib/perl5/5.8.8/Term/ReadLine.pm
@@ -214,7 +214,7 @@ sub findConsole {
$console = "Dev:Console";
} elsif (-e "/dev/tty") {
$console = "/dev/tty";
- } elsif (-e "con" or $^O eq 'MSWin32') {
+ } elsif (-e "con" or $^O eq 'MSWin32' or $^O eq 'msys') {
$console = "con";
} else {
$console = "sys\$command";
--
1.7.8.msysgit.0
--
Best regards,
Sven Strickroth
ClamAV, a GPL anti-virus toolkit http://www.clamav.net
PGP key id F5A9D4C4 @ any key-server
Sebastian Schuberth
> perl of msysgit seems to be build with "msys" as achitecture. This
Yes, it is.
> causes that git-svn (better Term\ReadLine.pm) creates empty
> "sys$command" files in some circumstances.
What are these circumstances? Please provide a use-case in the commit
message.
> diff --git a/lib/perl5/5.8.8/Term/ReadLine.pm b/lib/perl5/5.8.8/Term/ReadLine.pm
> index 48eb991..6965aec 100644
> --- a/lib/perl5/5.8.8/Term/ReadLine.pm
> +++ b/lib/perl5/5.8.8/Term/ReadLine.pm
> @@ -214,7 +214,7 @@ sub findConsole {
> $console = "Dev:Console";
> } elsif (-e "/dev/tty") {
> $console = "/dev/tty";
> - } elsif (-e "con" or $^O eq 'MSWin32') {
> + } elsif (-e "con" or $^O eq 'MSWin32' or $^O eq 'msys') {
> $console = "con";
> } else {
> $console = "sys\$command";
You're patching a file that we are taking as-is from upstream MSYS. As a
consequence, the patch should preferably go to the MinGW/MSYS guys.
Moreover, I'm wondering if this patch really is the correct thing to do,
because if it was, I would assume it would have been fixed already by
the MinGW/MSYS people in the same run as adding the MSWin32 check.
--
Sebastian Schuberth
Sven Strickroth
>> causes that git-svn (better Term\ReadLine.pm) creates empty
>> "sys$command" files in some circumstances.
>
> What are these circumstances? Please provide a use-case in the commit
> message.
http://code.google.com/p/tortoisegit/issues/detail?id=1011
I haven't tracked it down, but I suppoe this happens if no STDIN is
connected.
> You're patching a file that we are taking as-is from upstream MSYS. As a
> consequence, the patch should preferably go to the MinGW/MSYS guys.
I could not find that file in the msys repository, so I reported it
here, in hope the msysgit developers have better contacts to the
msys-team and can report it upstream.
> Moreover, I'm wondering if this patch really is the correct thing to do,
> because if it was, I would assume it would have been fixed already by
> the MinGW/MSYS people in the same run as adding the MSWin32 check.
Any any case: it's not fixed in msysgit repository.
Sebastian Schuberth
<sven.st...@tu-clausthal.de> wrote:
>> What are these circumstances? Please provide a use-case in the commit
>> message.
>
> http://code.google.com/p/tortoisegit/issues/detail?id=1011
So that link should go to the commit message.
> I haven't tracked it down, but I suppoe this happens if no STDIN is
> connected.
So you're just guessing that your patch will fix the issue?
> I could not find that file in the msys repository, so I reported it
> here, in hope the msysgit developers have better contacts to the
> msys-team and can report it upstream.
That file is not part of the msys repository, it's part of the package
files [1]. So you'd need to patch the script that builds the package
files. However, the package build system is currently being migrated
to the new mgwport system. I guess I'd just file a patch at [2].
>> Moreover, I'm wondering if this patch really is the correct thing to do,
>> because if it was, I would assume it would have been fixed already by
>> the MinGW/MSYS people in the same run as adding the MSWin32 check.
>
> Any any case: it's not fixed in msysgit repository.
We're trying to not apply any patches that are not contributed back
upstream to avoid diverging code bases. We already have plenty of
custom msys patches applied which has caused some resentments in the
past between the msysGit and msys communities.
I'm currently working on a Git for Windows installer [3] that will use
vanilla msys packages using the new mingw-get system. For this to
work, all our custom msys patches need to go upstream first.
[1] http://sourceforge.net/projects/mingw/files/MSYS/Extension/perl/perl-5.8.8-1/
[2] http://sourceforge.net/tracker/?limit=25&func=&group_id=2435&atid=302435&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter
[3] https://github.com/sschuberth/mingwGitDevEnv
--
Sebastian Schuberth
Sven Strickroth
> So you're just guessing that your patch will fix the issue?
As mentioned in the link, the issue was fixed by the patch. I just could
not track down if and only if the bug occours in the case that no STDIN
is connected.
> That file is not part of the msys repository, it's part of the package
> files [1]. So you'd need to patch the script that builds the package
> files. However, the package build system is currently being migrated
> to the new mgwport system. I guess I'd just file a patch at [2].
>
>>> Moreover, I'm wondering if this patch really is the correct thing to do,
>>> because if it was, I would assume it would have been fixed already by
>>> the MinGW/MSYS people in the same run as adding the MSWin32 check.
> We're trying to not apply any patches that are not contributed back
> upstream to avoid diverging code bases. We already have plenty of
> custom msys patches applied which has caused some resentments in the
> past between the msysGit and msys communities.
Reported upstream:
<https://sourceforge.net/tracker/?func=detail&aid=3468255&group_id=2435&atid=302435>
Sven Strickroth
> Reported upstream:
> <https://sourceforge.net/tracker/?func=detail&aid=3468255&group_id=2435&atid=302435>
Maybe s.o. from the msysgit team or you, Sebastian, can add some more
information about used msys and/or perl versions of msysgit to make it
easier to the msys maintainers to find and reproduce the problem.
msysgit 1.7.4, 1.7.6 and 1.7.7 work, but starting from 1.7.7.1
"sys$command" files are created.
Sebastian Schuberth
<sven.st...@tu-clausthal.de> wrote:
>> Reported upstream:
>> <https://sourceforge.net/tracker/?func=detail&aid=3468255&group_id=2435&atid=302435>
Thanks.
> msysgit 1.7.4, 1.7.6 and 1.7.7 work, but starting from 1.7.7.1
> "sys$command" files are created.
This is good to know as there are only a few changes between msysGit
1.7.7 and 1.7.7.1 which all seem unrelated:
$ git log --oneline Git-1.7.7-preview20111012^..Git-1.7.7.1-preview20111027
350141a Updated to Git v1.7.7.1
ade986f rebasing-merge: Added --cherry and --dry-run options
c15af73 apply-from-gmane: also handle thread.gmane.org URLs
143c72f Mark shell scripts executable
4b1ea39 Installer: Make SetEnvStrings update the environment of the current proc
2ee4773 Installer: Add a fallback for built-in environment variables
028a638 Installer: Add a missing default wizard image
81143a8 Patched Git v1.7.7
1e534f0 etc/profile: set MAGIC only if the magic file exists
e04fe54 copy-files: include the mergetools subdirectory under git-core
d6b6865 Fix fetching the temporary folder to use the correct enumeration value.
4400e9f fixup broken commit
96e245c Updated to Git v1.7.7
As the shipped MSYS Perl did not change either it has to be an
upstream Git change which causes this, I guess.
--
Sebastian Schuberth