''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't.

[omcujl92 at duck.com]

Thank you.

I don't follow all of that, such as deep diving into
gnupg/common/sysutils.c:translate_sys2libc_fd , but I do get the
answer is: Unsupported (at least at this time).

Could you make whatever notation at dev.gnupg.org is appropriate, please?
Summary: --passphrase-fd #, where # >= 3, fails under Windows / DOS
%COMSPEC% == unsupported (at this time).

So that, with that and this list, web searchers looking to figure out
why the described '--passphrase-fd #' isn't working for them, stop
chasing their tails?
[i.e. it's not user error, it's a Windows (DOS) issue not yet worked around].

-----

It is curious that fd 4 produced the different result of triggering a
graphical pinentry. I presume the file open failed and it fell back to
that mechanism.

And, interesting that under wsl:
'cat HelloWorld.txt | gpg.exe --pinentry-mode loopback --passphrase-fd
4 -c  4< HelloWorld.txt' returned the expected consistent result for
fd 3.
[with and without --pinentry-mode loopback]
> gpg: failed to translate osfhandle 0x00000004

Interesting in that:
(1) A call to an .exe file ran 'properly' (under wsl) at all. [Who
knew!] (Once I did, seemed worth a try, here.)
(2) The surrounding os file redirection services (between cmd.exe and
wsl.exe) are inconsistent - wsl.exe side behaviour better operating in
the traditional and expected manner, than cmd.exe.

>  lsb_release -a ; uname -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:    22.04
Codename:   jammy
Linux host 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5
21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux


On Mon, Mar 25, 2024 at 12:21 PM Werner Koch
<wk_at_gnupg.org_omcujl92 at duck.com> wrote:
>
> On Mon, 25 Mar 2024 08:33, Bee said:
>
> > C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 3 -c  3< HelloWorld.txt
> >> gpg: failed to translate osfhandle 0x00000003
>
> gpg takes system handles and not libc file descriptors.  File
> descriptors 0, 1, and 2 are handled by Windows in a different.  All
> other depend on which ABI you work.  cmd.exe seems to expect file
> descriptors which is good for scripting but gpg is rarely used in such a
> scripting environment but usuallay directly executed by CreateProcess
> and thus expects HANDLE values and not file descriptors.
>
> See gnupg/common/sysutils.c:translate_sys2libc_fd
>
> Actually it would be possible to provide an option to disable this
> translation and instead use libc file descriptors (with all the fun if
> different runtimes are used) but in more than 20 years we have not seen
> such a demand.
>
>
> Salam-Shalom,
>
>    Werner
>
> --
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein