{"thread":{"id":"47073","subject":"[PATCH 0/3] mingw: introduce a way to avoid std handle inheritance","startedAt":"2017-10-30T17:10:32Z","lastAt":"2017-11-03T11:51:51Z","messageCount":22,"participants":["Johannes Schindelin","Eric Sunshine","Jonathan Nieder","Junio C Hamano","Stefan Beller"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"331368","messageId":"cover.1509382976.git.johannes.schindelin@gmx.de","threadId":"47073","inReplyTo":null,"subject":"[PATCH 0/3] mingw: introduce a way to avoid std handle inheritance","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-10-30T17:10:19Z","receivedAt":"2017-10-30T17:10:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Particularly when calling Git from applications, such as Visual Studio,\nit is important that stdin/stdout/stderr are closed properly. However,\nwhen spawning processes on Windows, those handles must be marked as\ninheritable if we want to use them, but that flag is a global flag and\nmay very well be used by other spawned processes which then do not know\nto close those handles.\n\nAs a workaround, introduce handling for the environment variables\nGIT_REDIRECT_STD* to read/write from/to named pipes instead\n(conceptually similar to Unix sockets, for you Linux folks). These do\nnot need to be marked as inheritable, as the process can simply open the\nnamed pipe. No global flags. No problems.\n\nThis feature was introduced as an experimental feature into Git for\nWindows v2.11.0(2) and has been tested ever since. I feel it is\nwell-tested enough that it can be integrated into core Git.\n\nOnce it has been reviewed enough, I will gladly remove the\n\"experimental\" adjectives and warnings.\n\n\nJohannes Schindelin (3):\n  mingw: add experimental feature to redirect standard handles\n  mingw: special-case GIT_REDIRECT_STDERR=2>&1\n  mingw: document the experimental standard handle redirection\n\n Documentation/git.txt | 17 +++++++++++++++\n compat/mingw.c        | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++\n t/t0001-init.sh       | 12 +++++++++++\n 3 files changed, 87 insertions(+)\n\n\nbase-commit: cb5918aa0d50f50e83787f65c2ddc3dcb10159fe\nPublished-As: https://github.com/dscho/git/releases/tag/redirect-std-handles-v1\nFetch-It-Via: git fetch https://github.com/dscho/git redirect-std-handles-v1\n-- \n2.15.0.windows.1\n\n"},{"id":"331369","messageId":"804f26293de8f7cf805711313e376a513011a048.1509382976.git.johannes.schindelin@gmx.de","threadId":"47073","inReplyTo":"cover.1509382976.git.johannes.schindelin@gmx.de","subject":"[PATCH 1/3] mingw: add experimental feature to redirect standard handles","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-10-30T17:10:23Z","receivedAt":"2017-10-30T17:10:34Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"On Windows, file handles need to be marked inheritable when they need to\nbe used as standard input/output/error handles for a newly spawned\nprocess. The problem with that, of course, is that the \"inheritable\" flag\nis global and therefore can wreak havoc with highly multi-threaded\napplications: other spawned processes will *also* inherit those file\nhandles, despite having *other* input/output/error handles, and never\nclose the former handles because they do not know about them.\n\nLet's introduce a set of environment variables (GIT_REDIRECT_STDIN and\nfriends) that point to files, or even better, named pipes and that are\nused by the spawned Git process. This helps work around above-mentioned\nissue: those named pipes will be opened in a non-inheritable way upon\nstartup, and no handles are passed around.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n compat/mingw.c  | 43 +++++++++++++++++++++++++++++++++++++++++++\n t/t0001-init.sh |  6 ++++++\n 2 files changed, 49 insertions(+)\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex 8b6fa0db446..6c6c7795a70 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -2139,6 +2139,47 @@ static char *wcstoutfdup_startup(char *buffer, const wchar_t *wcs, size_t len)\n \treturn memcpy(malloc_startup(len), buffer, len);\n }\n \n+static void maybe_redirect_std_handle(const wchar_t *key, DWORD std_id, int fd,\n+\t\t\t\t      DWORD desired_access, DWORD flags)\n+{\n+\tDWORD create_flag = fd ? OPEN_ALWAYS : OPEN_EXISTING;\n+\twchar_t buf[MAX_PATH];\n+\tDWORD max = ARRAY_SIZE(buf);\n+\tHANDLE handle;\n+\tDWORD ret = GetEnvironmentVariableW(key, buf, max);\n+\n+\tif (!ret || ret >= max)\n+\t\treturn;\n+\n+\t/* make sure this does not leak into child processes */\n+\tSetEnvironmentVariableW(key, NULL);\n+\tif (!wcscmp(buf, L\"off\")) {\n+\t\tclose(fd);\n+\t\thandle = GetStdHandle(std_id);\n+\t\tif (handle != INVALID_HANDLE_VALUE)\n+\t\t\tCloseHandle(handle);\n+\t\treturn;\n+\t}\n+\thandle = CreateFileW(buf, desired_access, 0, NULL, create_flag,\n+\t\t\t     flags, NULL);\n+\tif (handle != INVALID_HANDLE_VALUE) {\n+\t\tint new_fd = _open_osfhandle((intptr_t)handle, O_BINARY);\n+\t\tSetStdHandle(std_id, handle);\n+\t\tdup2(new_fd, fd);\n+\t\tclose(new_fd);\n+\t}\n+}\n+\n+static void maybe_redirect_std_handles(void)\n+{\n+\tmaybe_redirect_std_handle(L\"GIT_REDIRECT_STDIN\", STD_INPUT_HANDLE, 0,\n+\t\t\t\t  GENERIC_READ, FILE_ATTRIBUTE_NORMAL);\n+\tmaybe_redirect_std_handle(L\"GIT_REDIRECT_STDOUT\", STD_OUTPUT_HANDLE, 1,\n+\t\t\t\t  GENERIC_WRITE, FILE_ATTRIBUTE_NORMAL);\n+\tmaybe_redirect_std_handle(L\"GIT_REDIRECT_STDERR\", STD_ERROR_HANDLE, 2,\n+\t\t\t\t  GENERIC_WRITE, FILE_FLAG_NO_BUFFERING);\n+}\n+\n void mingw_startup(void)\n {\n \tint i, maxlen, argc;\n@@ -2146,6 +2187,8 @@ void mingw_startup(void)\n \twchar_t **wenv, **wargv;\n \t_startupinfo si;\n \n+\tmaybe_redirect_std_handles();\n+\n \t/* get wide char arguments and environment */\n \tsi.newmode = 0;\n \tif (__wgetmainargs(&argc, &wargv, &wenv, _CRT_glob, &si) < 0)\ndiff --git a/t/t0001-init.sh b/t/t0001-init.sh\nindex 86c1a51654f..0fd2fc45385 100755\n--- a/t/t0001-init.sh\n+++ b/t/t0001-init.sh\n@@ -453,4 +453,10 @@ test_expect_success 're-init from a linked worktree' '\n \t)\n '\n \n+test_expect_success MINGW 'redirect std handles' '\n+\tGIT_REDIRECT_STDOUT=output.txt git rev-parse --git-dir &&\n+\ttest .git = \"$(cat output.txt)\" &&\n+\ttest -z \"$(GIT_REDIRECT_STDOUT=off git rev-parse --git-dir)\"\n+'\n+\n test_done\n-- \n2.15.0.windows.1\n\n\n"},{"id":"331370","messageId":"bb3cec73c50a36af31b029ab37949decdfe45857.1509382976.git.johannes.schindelin@gmx.de","threadId":"47073","inReplyTo":"cover.1509382976.git.johannes.schindelin@gmx.de","subject":"[PATCH 2/3] mingw: special-case GIT_REDIRECT_STDERR=2>&1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-10-30T17:10:27Z","receivedAt":"2017-10-30T17:10:37Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"The \"2>&1\" notation in POSIX shells implies that stderr is redirected to\nstdout. Let's special-case this value for the environment variable\nGIT_REDIRECT_STDERR to allow writing to the same destination as stdout.\n\nThe functionality was suggested by Jeff Hostetler.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n compat/mingw.c  | 15 +++++++++++++++\n t/t0001-init.sh |  8 +++++++-\n 2 files changed, 22 insertions(+), 1 deletion(-)\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex 6c6c7795a70..2d44d21aca8 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -2160,6 +2160,21 @@ static void maybe_redirect_std_handle(const wchar_t *key, DWORD std_id, int fd,\n \t\t\tCloseHandle(handle);\n \t\treturn;\n \t}\n+\tif (std_id == STD_ERROR_HANDLE && !wcscmp(buf, L\"2>&1\")) {\n+\t\thandle = GetStdHandle(STD_OUTPUT_HANDLE);\n+\t\tif (handle == INVALID_HANDLE_VALUE) {\n+\t\t\tclose(fd);\n+\t\t\thandle = GetStdHandle(std_id);\n+\t\t\tif (handle != INVALID_HANDLE_VALUE)\n+\t\t\t\tCloseHandle(handle);\n+\t\t} else {\n+\t\t\tint new_fd = _open_osfhandle((intptr_t)handle, O_BINARY);\n+\t\t\tSetStdHandle(std_id, handle);\n+\t\t\tdup2(new_fd, fd);\n+\t\t\t/* do *not* close the new_fd: that would close stdout */\n+\t\t}\n+\t\treturn;\n+\t}\n \thandle = CreateFileW(buf, desired_access, 0, NULL, create_flag,\n \t\t\t     flags, NULL);\n \tif (handle != INVALID_HANDLE_VALUE) {\ndiff --git a/t/t0001-init.sh b/t/t0001-init.sh\nindex 0fd2fc45385..c413bff9cf1 100755\n--- a/t/t0001-init.sh\n+++ b/t/t0001-init.sh\n@@ -456,7 +456,13 @@ test_expect_success 're-init from a linked worktree' '\n test_expect_success MINGW 'redirect std handles' '\n \tGIT_REDIRECT_STDOUT=output.txt git rev-parse --git-dir &&\n \ttest .git = \"$(cat output.txt)\" &&\n-\ttest -z \"$(GIT_REDIRECT_STDOUT=off git rev-parse --git-dir)\"\n+\ttest -z \"$(GIT_REDIRECT_STDOUT=off git rev-parse --git-dir)\" &&\n+\ttest_must_fail env \\\n+\t\tGIT_REDIRECT_STDOUT=output.txt \\\n+\t\tGIT_REDIRECT_STDERR=\"2>&1\" \\\n+\t\tgit rev-parse --git-dir --verify refs/invalid &&\n+\tprintf \".git\\nfatal: Needed a single revision\\n\" >expect &&\n+\ttest_cmp expect output.txt\n '\n \n test_done\n-- \n2.15.0.windows.1\n\n\n"},{"id":"331371","messageId":"436f0fb010709fe0d90460dc7bc1b3482237b192.1509382976.git.johannes.schindelin@gmx.de","threadId":"47073","inReplyTo":"cover.1509382976.git.johannes.schindelin@gmx.de","subject":"[PATCH 3/3] mingw: document the experimental standard handle redirection","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-10-30T17:10:30Z","receivedAt":"2017-10-30T17:10:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"This feature is still highly experimental and has not even been\ncontributed to the Git mailing list yet: the feature still needs to be\nbattle-tested more.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n Documentation/git.txt | 17 +++++++++++++++++\n 1 file changed, 17 insertions(+)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 7a1d629ca06..10a98603b39 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -709,6 +709,23 @@ of clones and fetches.\n \tthe background which do not want to cause lock contention with\n \tother operations on the repository.  Defaults to `1`.\n \n+`GIT_REDIRECT_STDIN`::\n+`GIT_REDIRECT_STDOUT`::\n+`GIT_REDIRECT_STDERR`::\n+\t(EXPERIMENTAL) Windows-only: allow redirecting the standard\n+\tinput/output/error handles. This is particularly useful in\n+\tmulti-threaded applications where the canonical way to pass\n+\tstandard handles via `CreateProcess()` is not an option because\n+\tit would require the handles to be marked inheritable (and\n+\tconsequently *every* spawned process would inherit them, possibly\n+\tblocking regular Git operations). The primary intended use case\n+\tis to use named pipes for communication.\n++\n+Two special values are supported: `off` will simply close the\n+corresponding standard handle, and if `GIT_REDIRECT_STDERR` is\n+`2>&1`, standard error will be redirected to the same handle as\n+standard output.\n+\n Discussion[[Discussion]]\n ------------------------\n \n-- \n2.15.0.windows.1\n"},{"id":"331403","messageId":"CAPig+cQs+6xCn=OR_Mw8vbEwEJ0c=sqnaEChOxuVw=kV4PQwsw@mail.gmail.com","threadId":"47073","inReplyTo":"436f0fb010709fe0d90460dc7bc1b3482237b192.1509382976.git.johannes.schindelin@gmx.de","subject":"Re: [PATCH 3/3] mingw: document the experimental standard handle redirection","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2017-10-30T18:58:14Z","receivedAt":"2017-10-30T18:58:20Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Oct 30, 2017 at 1:10 PM, Johannes Schindelin\n<johannes.schindelin@gmx.de> wrote:\n> This feature is still highly experimental and has not even been\n> contributed to the Git mailing list yet: the feature still needs to be\n> battle-tested more.\n>\n> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> ---\n> +`GIT_REDIRECT_STDIN`::\n> +`GIT_REDIRECT_STDOUT`::\n> +`GIT_REDIRECT_STDERR`::\n> +       (EXPERIMENTAL) Windows-only: allow redirecting the standard\n> +       input/output/error handles. This is particularly useful in\n> +       multi-threaded applications where the canonical way to pass\n> +       standard handles via `CreateProcess()` is not an option because\n> +       it would require the handles to be marked inheritable (and\n> +       consequently *every* spawned process would inherit them, possibly\n> +       blocking regular Git operations). The primary intended use case\n> +       is to use named pipes for communication.\n> ++\n> +Two special values are supported: `off` will simply close the\n> +corresponding standard handle, and if `GIT_REDIRECT_STDERR` is\n> +`2>&1`, standard error will be redirected to the same handle as\n> +standard output.\n\nConsistent with the Unixy special-case for '2>&1', I wonder if the\n'off' case would be more intuitively stated as '>/dev/null' or just\n'/dev/null'...\n"},{"id":"331415","messageId":"20171030205522.hur26cumwusk7wwa@aiede.mtv.corp.google.com","threadId":"47073","inReplyTo":"cover.1509382976.git.johannes.schindelin@gmx.de","subject":"Re: [PATCH 0/3] mingw: introduce a way to avoid std handle inheritance","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-10-30T20:55:22Z","receivedAt":"2017-10-30T20:56:06Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJohannes Schindelin wrote:\n\n> Particularly when calling Git from applications, such as Visual Studio,\n> it is important that stdin/stdout/stderr are closed properly. However,\n> when spawning processes on Windows, those handles must be marked as\n> inheritable if we want to use them, but that flag is a global flag and\n> may very well be used by other spawned processes which then do not know\n> to close those handles.\n>\n> As a workaround, introduce handling for the environment variables\n> GIT_REDIRECT_STD* to read/write from/to named pipes instead\n> (conceptually similar to Unix sockets, for you Linux folks). These do\n> not need to be marked as inheritable, as the process can simply open the\n> named pipe. No global flags. No problems.\n>\n> This feature was introduced as an experimental feature into Git for\n> Windows v2.11.0(2) and has been tested ever since. I feel it is\n> well-tested enough that it can be integrated into core Git.\n\nCan this rationale go in the commit messages?\n\nActually I wouldn't mind if this were all a single patch, with such a\nrationale in the commit message.\n\nThe patches' concept seems sane.  I haven't looked closely at the\nimplementation.\n\nThanks,\nJonathan\n"},{"id":"331456","messageId":"xmqqy3nrzx4d.fsf@gitster.mtv.corp.google.com","threadId":"47073","inReplyTo":"20171030205522.hur26cumwusk7wwa@aiede.mtv.corp.google.com","subject":"Re: [PATCH 0/3] mingw: introduce a way to avoid std handle inheritance","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-10-31T05:48:02Z","receivedAt":"2017-10-31T05:48:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n>> This feature was introduced as an experimental feature into Git for\n>> Windows v2.11.0(2) and has been tested ever since. I feel it is\n>> well-tested enough that it can be integrated into core Git.\n>\n> Can this rationale go in the commit messages?\n>\n> Actually I wouldn't mind if this were all a single patch, with such a\n> rationale in the commit message.\n>\n> The patches' concept seems sane.  I haven't looked closely at the\n> implementation.\n\n+1.\n"},{"id":"331481","messageId":"alpine.DEB.2.21.1.1710311807420.6482@virtualbox","threadId":"47073","inReplyTo":"CAPig+cQs+6xCn=OR_Mw8vbEwEJ0c=sqnaEChOxuVw=kV4PQwsw@mail.gmail.com","subject":"Re: [PATCH 3/3] mingw: document the experimental standard handle redirection","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-10-31T17:08:57Z","receivedAt":"2017-10-31T17:09:15Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Eric,\n\nOn Mon, 30 Oct 2017, Eric Sunshine wrote:\n\n> On Mon, Oct 30, 2017 at 1:10 PM, Johannes Schindelin\n> <johannes.schindelin@gmx.de> wrote:\n> > This feature is still highly experimental and has not even been\n> > contributed to the Git mailing list yet: the feature still needs to be\n> > battle-tested more.\n> >\n> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > ---\n> > +`GIT_REDIRECT_STDIN`::\n> > +`GIT_REDIRECT_STDOUT`::\n> > +`GIT_REDIRECT_STDERR`::\n> > +       (EXPERIMENTAL) Windows-only: allow redirecting the standard\n> > +       input/output/error handles. This is particularly useful in\n> > +       multi-threaded applications where the canonical way to pass\n> > +       standard handles via `CreateProcess()` is not an option because\n> > +       it would require the handles to be marked inheritable (and\n> > +       consequently *every* spawned process would inherit them, possibly\n> > +       blocking regular Git operations). The primary intended use case\n> > +       is to use named pipes for communication.\n> > ++\n> > +Two special values are supported: `off` will simply close the\n> > +corresponding standard handle, and if `GIT_REDIRECT_STDERR` is\n> > +`2>&1`, standard error will be redirected to the same handle as\n> > +standard output.\n> \n> Consistent with the Unixy special-case for '2>&1', I wonder if the\n> 'off' case would be more intuitively stated as '>/dev/null' or just\n> '/dev/null'...\n\nI feel this is the wrong way round. `>/dev/null` may sound very intuitive\nto you, but this feature is Windows only. Guess three times how intuitive\nit sounds to Windows developers to write `>/dev/null` if you want to\nsuppress output...\n\n:0)\n\nCiao,\nDscho\n"},{"id":"331484","messageId":"alpine.DEB.2.21.1.1710311809570.6482@virtualbox","threadId":"47073","inReplyTo":"20171030205522.hur26cumwusk7wwa@aiede.mtv.corp.google.com","subject":"Re: [PATCH 0/3] mingw: introduce a way to avoid std handle inheritance","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-10-31T17:12:46Z","receivedAt":"2017-10-31T17:12:56Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Jonathan,\n\nOn Mon, 30 Oct 2017, Jonathan Nieder wrote:\n\n> Johannes Schindelin wrote:\n> \n> > Particularly when calling Git from applications, such as Visual Studio,\n> > it is important that stdin/stdout/stderr are closed properly. However,\n> > when spawning processes on Windows, those handles must be marked as\n> > inheritable if we want to use them, but that flag is a global flag and\n> > may very well be used by other spawned processes which then do not know\n> > to close those handles.\n> >\n> > As a workaround, introduce handling for the environment variables\n> > GIT_REDIRECT_STD* to read/write from/to named pipes instead\n> > (conceptually similar to Unix sockets, for you Linux folks). These do\n> > not need to be marked as inheritable, as the process can simply open the\n> > named pipe. No global flags. No problems.\n> >\n> > This feature was introduced as an experimental feature into Git for\n> > Windows v2.11.0(2) and has been tested ever since. I feel it is\n> > well-tested enough that it can be integrated into core Git.\n> \n> Can this rationale go in the commit messages?\n\nI thought I had done exactly that in 1/3...\n\n> Actually I wouldn't mind if this were all a single patch, with such a\n> rationale in the commit message.\n\nQuite honestly, I'd rather not. There is a logical structure to the three\npatches (and I left a Duck in 3/3, to see who bothers to actually read\nwhat I wrote).\n\nThe redirection, for example, is a very special thing that I would like to\nkeep in a separate commit, for clarity.\n\n> The patches' concept seems sane.  I haven't looked closely at the\n> implementation.\n\nThanks,\nDscho\n"},{"id":"331495","messageId":"20171031180933.styinoik4npmd53b@aiede.mtv.corp.google.com","threadId":"47073","inReplyTo":"alpine.DEB.2.21.1.1710311809570.6482@virtualbox","subject":"Re: [PATCH 0/3] mingw: introduce a way to avoid std handle inheritance","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-10-31T18:09:33Z","receivedAt":"2017-10-31T18:09:44Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJohannes Schindelin wrote:\n> On Mon, 30 Oct 2017, Jonathan Nieder wrote:\n\n>> Can this rationale go in the commit messages?\n>\n> I thought I had done exactly that in 1/3...\n\nOkay, I'll be more specific.  This cover letter includes some\ninformation about the rationale and motivation for the series.  That's\ngreat: it makes reading the patches easier.  But TBH I'd rather that\nit hadn't included that information at all, since if it said \"see\npatch 1/3 for rationale\" then I could save the trouble of reading the\nsame information twice.\n\nAnd unfortunately much of the relevant information is not repeated\nthere.  The cover letter mentions:\n\n- that Visual Studio is a motivating example\n- that this is conceptually similar to Unix sockets\n- that those do not need to be marked as inheritable, as the process\n  can simply open the named pipe. No global flags. No problems.\n- that this has already seem some testing in Git for Windows (i.e.\n  analagous information to what a Tested-by footer would say)\n\nIt is also just more readable than patch 1/3's commit message.  That's\nto be expected, since it was written later.  My second draft of\nsomething is often clearer than the first draft.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"331541","messageId":"xmqq4lqevbmk.fsf@gitster.mtv.corp.google.com","threadId":"47073","inReplyTo":"alpine.DEB.2.21.1.1710311807420.6482@virtualbox","subject":"Re: [PATCH 3/3] mingw: document the experimental standard handle redirection","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-01T04:58:11Z","receivedAt":"2017-11-01T05:03:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> > +Two special values are supported: `off` will simply close the\n>> > +corresponding standard handle, and if `GIT_REDIRECT_STDERR` is\n>> > +`2>&1`, standard error will be redirected to the same handle as\n>> > +standard output.\n>> \n>> Consistent with the Unixy special-case for '2>&1', I wonder if the\n>> 'off' case would be more intuitively stated as '>/dev/null' or just\n>> '/dev/null'...\n>\n> I feel this is the wrong way round. `>/dev/null` may sound very intuitive\n> to you, but this feature is Windows only. Guess three times how intuitive\n> it sounds to Windows developers to write `>/dev/null` if you want to\n> suppress output...\n\nIt would be just as intuitive to write '2>&1' for dup-redirection,\nso I tend to agree with both of you in that perhaps '2>&1' may have\nto become less Unix-y (or more Windows-y) to make these special\ncases more consistent.  Perhaps \"dup-to-stdout\" or even just \"stdout\".\n\n\tSide note: if we really wanted to go in the other direction\n\tEric suggests, \"off\" probably should be spelled as \">&-\" ;-)\n\nBy the way, the description talks about \"special values\", but it\nleaves it completely unclear what their normal values mean.  Are\nthey filenames, or integers that denote file descriptors, or\nsomething else?  To those who read, wrote, or reviewed the code in\nthese patches, the answer is obvious (and I do *not* want you to\ngive your answer to *me* in your response for that reason).  But\nwe'd want to give the answer to future readers by clarifying this\ndocumentation.\n"},{"id":"331573","messageId":"alpine.DEB.2.21.1.1711011726030.6482@virtualbox","threadId":"47073","inReplyTo":"xmqq4lqevbmk.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 3/3] mingw: document the experimental standard handle redirection","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-11-01T16:37:05Z","receivedAt":"2017-11-01T16:37:29Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 1 Nov 2017, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> >> > +Two special values are supported: `off` will simply close the\n> >> > +corresponding standard handle, and if `GIT_REDIRECT_STDERR` is\n> >> > +`2>&1`, standard error will be redirected to the same handle as\n> >> > +standard output.\n> >> \n> >> Consistent with the Unixy special-case for '2>&1', I wonder if the\n> >> 'off' case would be more intuitively stated as '>/dev/null' or just\n> >> '/dev/null'...\n> >\n> > I feel this is the wrong way round. `>/dev/null` may sound very intuitive\n> > to you, but this feature is Windows only. Guess three times how intuitive\n> > it sounds to Windows developers to write `>/dev/null` if you want to\n> > suppress output...\n> \n> It would be just as intuitive to write '2>&1' for dup-redirection,\n\nNo. You misunderstand. I was mainly concerned with the `/dev/null`. Every\nWindows developer knows what `>file.txt` means, and many know what\n`2>error.txt` means. But `/dev/null` is not Windows, period. It is so not\nWindows that Git itself translates it to `NUL` (which you Linux die-hards\nwon't have a clue about, I would wager a bet).\n\n> Perhaps \"dup-to-stdout\" or even just \"stdout\".\n\nNo. The value is a path. I can special-case values that are not even valid\nWindows file names (such as `2>&1`). I cannot special-case values that are\nperfectly valid paths.\n\n> By the way, the description talks about \"special values\", but it\n> leaves it completely unclear what their normal values mean.\n\nTrue. Fixed. I also threw in an example for a pipe.\n\nCiao,\nDscho\n"},{"id":"331577","messageId":"alpine.DEB.2.21.1.1711011737460.6482@virtualbox","threadId":"47073","inReplyTo":"20171031180933.styinoik4npmd53b@aiede.mtv.corp.google.com","subject":"Re: [PATCH 0/3] mingw: introduce a way to avoid std handle inheritance","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-11-01T17:07:25Z","receivedAt":"2017-11-01T17:07:38Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Jonahtan,\n\nOn Tue, 31 Oct 2017, Jonathan Nieder wrote:\n\n> Johannes Schindelin wrote:\n> > On Mon, 30 Oct 2017, Jonathan Nieder wrote:\n> \n> >> Can this rationale go in the commit messages?\n> >\n> > I thought I had done exactly that in 1/3...\n> \n> Okay, I'll be more specific.  This cover letter includes some\n> information about the rationale and motivation for the series.  That's\n> great: it makes reading the patches easier.  But TBH I'd rather that\n> it hadn't included that information at all, since if it said \"see\n> patch 1/3 for rationale\" then I could save the trouble of reading the\n> same information twice.\n\nAlas, I am the exact opposite. You see, I am seriously short on time, and\nif the cover letter of a patch series leaves everything about the changes\nunclear, I throw my laptop out the window (actually, I suppress the urge\nand just delete the mail thread in my mail reader) and move to the next\nmail.\n\nIt sounds a bit stupid to cater to myself in patches *I* submit, but I\nrefuse to believe that there are many people with more time on their hands\nthan myself (last time I tried to research this, it looked as everybody\nhas the same 86,400 seconds per day available, give or take the occasional\nleap second).\n\n> And unfortunately much of the relevant information is not repeated\n> there.  The cover letter mentions:\n> \n> - that Visual Studio is a motivating example\n\nThat was actually on purpose. Personally, I want to read the motivation in\nthe cover letter, and not get distracted by it when reading the commit\nlogs.\n\nTo make you happy, I added this, though.\n\n> - that this is conceptually similar to Unix sockets\n\nTo make you happy, I added this, too.\n\n> - that those do not need to be marked as inheritable, as the process\n>   can simply open the named pipe. No global flags. No problems.\n\nI just added \"(and therefore no inherited handles need to be closed)\" to\nthe last sentence of 1/3's commit message that already mentioned this.\n\n> - that this has already seem some testing in Git for Windows (i.e.\n>   analagous information to what a Tested-by footer would say)\n\nI mentioned this twice, in 1/3's and in 3/3's commit message.\n\n> It is also just more readable than patch 1/3's commit message.  That's\n> to be expected, since it was written later.  My second draft of\n> something is often clearer than the first draft.\n\nI took your cue and simply replaced the first paragraph of 1/3's commit\nmessage by the first paragraph of the cover letter.\n\nCiao,\nDscho\n"},{"id":"331579","messageId":"21f71a95fbb1626ad5b98065571175c06e858f92.1509556153.git.johannes.schindelin@gmx.de","threadId":"47073","inReplyTo":"cover.1509556153.git.johannes.schindelin@gmx.de","subject":"[PATCH v2 1/3] mingw: add experimental feature to redirect standard handles","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-11-01T17:10:25Z","receivedAt":"2017-11-01T17:10:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Particularly when calling Git from applications, such as Visual Studio's\nTeam Explorer, it is important that stdin/stdout/stderr are closed\nproperly. However, when spawning processes on Windows, those handles\nmust be marked as inheritable if we want to use them, but that flag is a\nglobal flag and may very well be used by other spawned processes which\nthen do not know to close those handles.\n\nLet's introduce a set of environment variables (GIT_REDIRECT_STDIN and\nfriends) that specify paths to files, or even better, named pipes (which\nare similar to Unix sockets) and that are used by the spawned Git\nprocess.  This helps work around above-mentioned issue: those named\npipes will be opened in a non-inheritable way upon startup, and no\nhandles are passed around (and therefore no inherited handles need to be\nclosed by any spawned child).\n\nThis feature shipped with Git for Windows (marked as experimental) since\nv2.11.0(2), so it has seen some serious testing in the meantime.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n compat/mingw.c  | 43 +++++++++++++++++++++++++++++++++++++++++++\n t/t0001-init.sh |  6 ++++++\n 2 files changed, 49 insertions(+)\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex 8b6fa0db446..6c6c7795a70 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -2139,6 +2139,47 @@ static char *wcstoutfdup_startup(char *buffer, const wchar_t *wcs, size_t len)\n \treturn memcpy(malloc_startup(len), buffer, len);\n }\n \n+static void maybe_redirect_std_handle(const wchar_t *key, DWORD std_id, int fd,\n+\t\t\t\t      DWORD desired_access, DWORD flags)\n+{\n+\tDWORD create_flag = fd ? OPEN_ALWAYS : OPEN_EXISTING;\n+\twchar_t buf[MAX_PATH];\n+\tDWORD max = ARRAY_SIZE(buf);\n+\tHANDLE handle;\n+\tDWORD ret = GetEnvironmentVariableW(key, buf, max);\n+\n+\tif (!ret || ret >= max)\n+\t\treturn;\n+\n+\t/* make sure this does not leak into child processes */\n+\tSetEnvironmentVariableW(key, NULL);\n+\tif (!wcscmp(buf, L\"off\")) {\n+\t\tclose(fd);\n+\t\thandle = GetStdHandle(std_id);\n+\t\tif (handle != INVALID_HANDLE_VALUE)\n+\t\t\tCloseHandle(handle);\n+\t\treturn;\n+\t}\n+\thandle = CreateFileW(buf, desired_access, 0, NULL, create_flag,\n+\t\t\t     flags, NULL);\n+\tif (handle != INVALID_HANDLE_VALUE) {\n+\t\tint new_fd = _open_osfhandle((intptr_t)handle, O_BINARY);\n+\t\tSetStdHandle(std_id, handle);\n+\t\tdup2(new_fd, fd);\n+\t\tclose(new_fd);\n+\t}\n+}\n+\n+static void maybe_redirect_std_handles(void)\n+{\n+\tmaybe_redirect_std_handle(L\"GIT_REDIRECT_STDIN\", STD_INPUT_HANDLE, 0,\n+\t\t\t\t  GENERIC_READ, FILE_ATTRIBUTE_NORMAL);\n+\tmaybe_redirect_std_handle(L\"GIT_REDIRECT_STDOUT\", STD_OUTPUT_HANDLE, 1,\n+\t\t\t\t  GENERIC_WRITE, FILE_ATTRIBUTE_NORMAL);\n+\tmaybe_redirect_std_handle(L\"GIT_REDIRECT_STDERR\", STD_ERROR_HANDLE, 2,\n+\t\t\t\t  GENERIC_WRITE, FILE_FLAG_NO_BUFFERING);\n+}\n+\n void mingw_startup(void)\n {\n \tint i, maxlen, argc;\n@@ -2146,6 +2187,8 @@ void mingw_startup(void)\n \twchar_t **wenv, **wargv;\n \t_startupinfo si;\n \n+\tmaybe_redirect_std_handles();\n+\n \t/* get wide char arguments and environment */\n \tsi.newmode = 0;\n \tif (__wgetmainargs(&argc, &wargv, &wenv, _CRT_glob, &si) < 0)\ndiff --git a/t/t0001-init.sh b/t/t0001-init.sh\nindex 86c1a51654f..0fd2fc45385 100755\n--- a/t/t0001-init.sh\n+++ b/t/t0001-init.sh\n@@ -453,4 +453,10 @@ test_expect_success 're-init from a linked worktree' '\n \t)\n '\n \n+test_expect_success MINGW 'redirect std handles' '\n+\tGIT_REDIRECT_STDOUT=output.txt git rev-parse --git-dir &&\n+\ttest .git = \"$(cat output.txt)\" &&\n+\ttest -z \"$(GIT_REDIRECT_STDOUT=off git rev-parse --git-dir)\"\n+'\n+\n test_done\n-- \n2.15.0.windows.1\n\n\n"},{"id":"331580","messageId":"cover.1509556153.git.johannes.schindelin@gmx.de","threadId":"47073","inReplyTo":"cover.1509382976.git.johannes.schindelin@gmx.de","subject":"[PATCH v2 0/3] mingw: introduce a way to avoid std handle inheritance","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-11-01T17:10:21Z","receivedAt":"2017-11-01T17:10:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Particularly when calling Git from applications, such as Visual Studio,\nit is important that stdin/stdout/stderr are closed properly. However,\nwhen spawning processes on Windows, those handles must be marked as\ninheritable if we want to use them, but that flag is a global flag and\nmay very well be used by other spawned processes which then do not know\nto close those handles.\n\nAs a workaround, introduce handling for the environment variables\nGIT_REDIRECT_STD* to read/write from/to named pipes instead\n(conceptually similar to Unix sockets, for you Linux folks). These do\nnot need to be marked as inheritable, as the process can simply open the\nnamed pipe. No global flags. No problems.\n\nThis feature was introduced as an experimental feature into Git for\nWindows v2.11.0(2) and has been tested ever since. I feel it is\nwell-tested enough that it can be integrated into core Git.\n\nChanges since v1:\n\n- clarified what the values of the environment variables mean.\n\n- the feature is no longer marked experimental (I actually expected *some*\n  remark about this, but it seems nobody looked at that patch all that closely\n  *frown*)\n\n- edited all commit messages heavily (primarily prodded by Jonathan's feedback).\n\n\nJohannes Schindelin (3):\n  mingw: add experimental feature to redirect standard handles\n  mingw: optionally redirect stderr/stdout via the same handle\n  mingw: document the standard handle redirection\n\n Documentation/git.txt | 18 ++++++++++++++++\n compat/mingw.c        | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++\n t/t0001-init.sh       | 12 +++++++++++\n 3 files changed, 88 insertions(+)\n\n\nbase-commit: cb5918aa0d50f50e83787f65c2ddc3dcb10159fe\nPublished-As: https://github.com/dscho/git/releases/tag/redirect-std-handles-v2\nFetch-It-Via: git fetch https://github.com/dscho/git redirect-std-handles-v2\n\nInterdiff vs v1:\n diff --git a/Documentation/git.txt b/Documentation/git.txt\n index 10a98603b39..463b0eb0f5c 100644\n --- a/Documentation/git.txt\n +++ b/Documentation/git.txt\n @@ -712,14 +712,15 @@ of clones and fetches.\n  `GIT_REDIRECT_STDIN`::\n  `GIT_REDIRECT_STDOUT`::\n  `GIT_REDIRECT_STDERR`::\n -\t(EXPERIMENTAL) Windows-only: allow redirecting the standard\n -\tinput/output/error handles. This is particularly useful in\n -\tmulti-threaded applications where the canonical way to pass\n -\tstandard handles via `CreateProcess()` is not an option because\n -\tit would require the handles to be marked inheritable (and\n -\tconsequently *every* spawned process would inherit them, possibly\n -\tblocking regular Git operations). The primary intended use case\n -\tis to use named pipes for communication.\n +\tWindows-only: allow redirecting the standard input/output/error\n +\thandles to paths specified by the environment variables. This is\n +\tparticularly useful in multi-threaded applications where the\n +\tcanonical way to pass standard handles via `CreateProcess()` is\n +\tnot an option because it would require the handles to be marked\n +\tinheritable (and consequently *every* spawned process would\n +\tinherit them, possibly blocking regular Git operations). The\n +\tprimary intended use case is to use named pipes for communication\n +\t(e.g. `\\\\.\\pipe\\my-git-stdin-123`).\n  +\n  Two special values are supported: `off` will simply close the\n  corresponding standard handle, and if `GIT_REDIRECT_STDERR` is\n-- \n2.15.0.windows.1\n\n"},{"id":"331581","messageId":"d98f6a9a6eeb01f68f4bc853952ca675e97940bd.1509556153.git.johannes.schindelin@gmx.de","threadId":"47073","inReplyTo":"cover.1509556153.git.johannes.schindelin@gmx.de","subject":"[PATCH v2 2/3] mingw: optionally redirect stderr/stdout via the same handle","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-11-01T17:10:30Z","receivedAt":"2017-11-01T17:10:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"The \"2>&1\" notation in Powershell and in Unix shells implies that stderr\nis redirected to the same handle into which stdout is already written.\n\nLet's use this special value to allow the same trick with\nGIT_REDIRECT_STDERR and GIT_REDIRECT_STDOUT: if the former's value is\n`2>&1`, then stderr will simply be written to the same handle as stdout.\n\nThe functionality was suggested by Jeff Hostetler.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n compat/mingw.c  | 15 +++++++++++++++\n t/t0001-init.sh |  8 +++++++-\n 2 files changed, 22 insertions(+), 1 deletion(-)\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex 6c6c7795a70..2d44d21aca8 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -2160,6 +2160,21 @@ static void maybe_redirect_std_handle(const wchar_t *key, DWORD std_id, int fd,\n \t\t\tCloseHandle(handle);\n \t\treturn;\n \t}\n+\tif (std_id == STD_ERROR_HANDLE && !wcscmp(buf, L\"2>&1\")) {\n+\t\thandle = GetStdHandle(STD_OUTPUT_HANDLE);\n+\t\tif (handle == INVALID_HANDLE_VALUE) {\n+\t\t\tclose(fd);\n+\t\t\thandle = GetStdHandle(std_id);\n+\t\t\tif (handle != INVALID_HANDLE_VALUE)\n+\t\t\t\tCloseHandle(handle);\n+\t\t} else {\n+\t\t\tint new_fd = _open_osfhandle((intptr_t)handle, O_BINARY);\n+\t\t\tSetStdHandle(std_id, handle);\n+\t\t\tdup2(new_fd, fd);\n+\t\t\t/* do *not* close the new_fd: that would close stdout */\n+\t\t}\n+\t\treturn;\n+\t}\n \thandle = CreateFileW(buf, desired_access, 0, NULL, create_flag,\n \t\t\t     flags, NULL);\n \tif (handle != INVALID_HANDLE_VALUE) {\ndiff --git a/t/t0001-init.sh b/t/t0001-init.sh\nindex 0fd2fc45385..c413bff9cf1 100755\n--- a/t/t0001-init.sh\n+++ b/t/t0001-init.sh\n@@ -456,7 +456,13 @@ test_expect_success 're-init from a linked worktree' '\n test_expect_success MINGW 'redirect std handles' '\n \tGIT_REDIRECT_STDOUT=output.txt git rev-parse --git-dir &&\n \ttest .git = \"$(cat output.txt)\" &&\n-\ttest -z \"$(GIT_REDIRECT_STDOUT=off git rev-parse --git-dir)\"\n+\ttest -z \"$(GIT_REDIRECT_STDOUT=off git rev-parse --git-dir)\" &&\n+\ttest_must_fail env \\\n+\t\tGIT_REDIRECT_STDOUT=output.txt \\\n+\t\tGIT_REDIRECT_STDERR=\"2>&1\" \\\n+\t\tgit rev-parse --git-dir --verify refs/invalid &&\n+\tprintf \".git\\nfatal: Needed a single revision\\n\" >expect &&\n+\ttest_cmp expect output.txt\n '\n \n test_done\n-- \n2.15.0.windows.1\n\n\n"},{"id":"331582","messageId":"80b58f364375a72d7efd547a90f284accfeab877.1509556153.git.johannes.schindelin@gmx.de","threadId":"47073","inReplyTo":"cover.1509556153.git.johannes.schindelin@gmx.de","subject":"[PATCH v2 3/3] mingw: document the standard handle redirection","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-11-01T17:10:33Z","receivedAt":"2017-11-01T17:10:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"This feature has been in Git for Windows since v2.11.0(2), as an\nexperimental option. Now it is considered mature, and it is high time to\ndocument it properly.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n Documentation/git.txt | 18 ++++++++++++++++++\n 1 file changed, 18 insertions(+)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 7a1d629ca06..463b0eb0f5c 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -709,6 +709,24 @@ of clones and fetches.\n \tthe background which do not want to cause lock contention with\n \tother operations on the repository.  Defaults to `1`.\n \n+`GIT_REDIRECT_STDIN`::\n+`GIT_REDIRECT_STDOUT`::\n+`GIT_REDIRECT_STDERR`::\n+\tWindows-only: allow redirecting the standard input/output/error\n+\thandles to paths specified by the environment variables. This is\n+\tparticularly useful in multi-threaded applications where the\n+\tcanonical way to pass standard handles via `CreateProcess()` is\n+\tnot an option because it would require the handles to be marked\n+\tinheritable (and consequently *every* spawned process would\n+\tinherit them, possibly blocking regular Git operations). The\n+\tprimary intended use case is to use named pipes for communication\n+\t(e.g. `\\\\.\\pipe\\my-git-stdin-123`).\n++\n+Two special values are supported: `off` will simply close the\n+corresponding standard handle, and if `GIT_REDIRECT_STDERR` is\n+`2>&1`, standard error will be redirected to the same handle as\n+standard output.\n+\n Discussion[[Discussion]]\n ------------------------\n \n-- \n2.15.0.windows.1\n"},{"id":"331584","messageId":"CAGZ79kbQW_EdYrvst+vRPY_uqdFuqesKzpgTwx=yr8dCx=8yCQ@mail.gmail.com","threadId":"47073","inReplyTo":"alpine.DEB.2.21.1.1711011737460.6482@virtualbox","subject":"Re: [PATCH 0/3] mingw: introduce a way to avoid std handle inheritance","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-11-01T17:17:57Z","receivedAt":"2017-11-01T17:18:03Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"> It sounds a bit stupid to cater to myself in patches *I* submit, but I\n> refuse to believe that there are many people with more time on their hands\n> than myself (last time I tried to research this, it looked as everybody\n> has the same 86,400 seconds per day available, give or take the occasional\n> leap second).\n\nTry traveling west bound every day.\nThis one weird trick with time zones will amaze you!\n"},{"id":"331636","messageId":"xmqqr2thsby4.fsf@gitster.mtv.corp.google.com","threadId":"47073","inReplyTo":"alpine.DEB.2.21.1.1711011726030.6482@virtualbox","subject":"Re: [PATCH 3/3] mingw: document the experimental standard handle redirection","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-02T01:31:47Z","receivedAt":"2017-11-02T01:31:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> > I feel this is the wrong way round. `>/dev/null` may sound very intuitive\n>> > to you, but this feature is Windows only. Guess three times how intuitive\n>> > it sounds to Windows developers to write `>/dev/null` if you want to\n>> > suppress output...\n>> \n>> It would be just as intuitive to write '2>&1' for dup-redirection,\n>\n> No. You misunderstand. I was mainly concerned with the `/dev/null`. Every\n> Windows developer knows what `>file.txt` means, and many know what\n> `2>error.txt` means. But `/dev/null` is not Windows, period.\n\nActually I did know that much.  \n\nIf I was correct in assuming that \"2>&1\" is just as foreign as\n\">/dev/null\", then we should be shunning \"2>&1\" just like we shun\n\">/dev/null\".  That was all I meant to say.\n\nAre you saying \"2>&1\" is just as likely to be known as \">file.txt\"\nand my assumption of foreignness of \"2>&1\" was incorrect?\n\n\tSide note: would \">NUL\" look more familiar, I wonder, and\n\tcan stand for \">/dev/null\" for the target audience?\n\n> ... It is so not\n> Windows that Git itself translates it to `NUL` (which you Linux die-hards\n> won't have a clue about, I would wager a bet).\n\nAh, you lost your bet.  When can I collect ;-)?\n"},{"id":"331670","messageId":"alpine.DEB.2.21.1.1711021819430.6482@virtualbox","threadId":"47073","inReplyTo":"xmqqr2thsby4.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 3/3] mingw: document the experimental standard handle redirection","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-11-02T17:20:25Z","receivedAt":"2017-11-02T17:21:12Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 2 Nov 2017, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> >> > I feel this is the wrong way round. `>/dev/null` may sound very intuitive\n> >> > to you, but this feature is Windows only. Guess three times how intuitive\n> >> > it sounds to Windows developers to write `>/dev/null` if you want to\n> >> > suppress output...\n> >> \n> >> It would be just as intuitive to write '2>&1' for dup-redirection,\n> >\n> > No. You misunderstand. I was mainly concerned with the `/dev/null`. Every\n> > Windows developer knows what `>file.txt` means, and many know what\n> > `2>error.txt` means. But `/dev/null` is not Windows, period.\n> \n> Actually I did know that much.  \n> \n> If I was correct in assuming that \"2>&1\" is just as foreign as\n> \">/dev/null\", then we should be shunning \"2>&1\" just like we shun\n> \">/dev/null\".  That was all I meant to say.\n\nDid you know that `2>&1` works in Powershell?\n\n> Are you saying \"2>&1\" is just as likely to be known as \">file.txt\"\n> and my assumption of foreignness of \"2>&1\" was incorrect?\n> \n> \tSide note: would \">NUL\" look more familiar, I wonder, and\n> \tcan stand for \">/dev/null\" for the target audience?\n> \n> > ... It is so not\n> > Windows that Git itself translates it to `NUL` (which you Linux die-hards\n> > won't have a clue about, I would wager a bet).\n> \n> Ah, you lost your bet.  When can I collect ;-)?\n\nAs soon as we meet in person again.\n\nCiao,\nDscho\n"},{"id":"331757","messageId":"xmqqzi84p1ue.fsf@gitster.mtv.corp.google.com","threadId":"47073","inReplyTo":"alpine.DEB.2.21.1.1711021819430.6482@virtualbox","subject":"Re: [PATCH 3/3] mingw: document the experimental standard handle redirection","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-03T01:50:33Z","receivedAt":"2017-11-03T01:50:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> If I was correct in assuming that \"2>&1\" is just as foreign as\n>> \">/dev/null\", then we should be shunning \"2>&1\" just like we shun\n>> \">/dev/null\".  That was all I meant to say.\n>\n> Did you know that `2>&1` works in Powershell?\n\nNo.  And that makes me curious if \">&-\" is also there to replace\n\"off\" ;-)\n\n"},{"id":"331770","messageId":"alpine.DEB.2.21.1.1711031251060.6482@virtualbox","threadId":"47073","inReplyTo":"xmqqzi84p1ue.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 3/3] mingw: document the experimental standard handle redirection","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-11-03T11:51:11Z","receivedAt":"2017-11-03T11:51:51Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Fri, 3 Nov 2017, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> >> If I was correct in assuming that \"2>&1\" is just as foreign as\n> >> \">/dev/null\", then we should be shunning \"2>&1\" just like we shun\n> >> \">/dev/null\".  That was all I meant to say.\n> >\n> > Did you know that `2>&1` works in Powershell?\n> \n> No.  And that makes me curious if \">&-\" is also there to replace\n> \"off\" ;-)\n\nNo, it does not:\n\n-- snip --\nPS C:\\Users\\me> echo 123 >&-\nAt line:1 char:11\n+ echo 123 >&-\n+           ~\nMissing file specification after redirection operator.\nAt line:1 char:11\n+ echo 123 >&-\n+           ~\nThe ampersand (&) character is not allowed. The & operator is reserved for future use; wrap an ampersand in double\nquotation marks (\"&\") to pass it as part of a string.\n    + CategoryInfo          : ParserError: (:) [],\nParentContainsErrorRecordException\n    + FullyQualifiedErrorId : MissingFileSpecification\n-- snap --\n\nBesides, we're really getting off-track here. I do not *like* `2>&1` as\nquite cryptic placeholder for `redirect stderr into the same handle as\nstdout was already redirected`. It is Perl-level obscurity.\n\nAdding even more of those \"let's string together non-alphanumerical\ncharacters together and declare that they have some special meaning that\nnobody would guess so they have to ask us and thereby make us feel smarter\nthan we are\" is definitely not anything I want.\n\nIn my opinion, `off` is kind of a compromise that is both easy to\nunderstand and hard to confuse.\n\nIf there was a short, succinct and easy-to-understand textual\nrepresentation of `same as stdout` that would not be easily confused for a\nreal file path, I would rather use that instead.\n\nPlease note, though, that I am again very reluctant to change things for\nless than really compelling reasons at this stage. I have just burned two\ndays as a consequence of Peff's decision to take my --no-lock-index work\nand turn it into something different enough that I had to put in more work\nto adjust it, only to introduce a bug in something that worked without any\nproblem for over one entire year.\n\nIt is quite a bit ridiculous just how much bug hunting time I have to\nspend lately on stuff that used to work and that got broken on transit\ninto git.git. It adds a whole new stress level to my work.\n\nCiao,\nDscho\n"}]}