bug#13344: 24.3.50; Gnus error c:/dev/fd/0

bug#13344: 24.3.50; Gnus error c:/dev/fd/0

[nyc4bos]

Hi,

There appears to be an error opening up the .authinfo.gpg file.

I get the error in the *Messages* buffer:

Unable to open server nnimap+aol due to: Opening input file: Opening process input file, no such file or directory, c:/dev/fd/0
Opening nnimap server on aol...failed:

Using the exact same setup but running the emacs version:

In GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601)
 of 2012-12-27 on MS-W7-DANI
Bzr revision: 111346 rgm@gnu.org-20121227111738-6kwixgc9fa2pxvbp

works correctly. 

Additionly, with this version of Gnu Emacs (Bzr 111393), I don't get
prompted for my GPG password, unlike Gnu Emacs Bzr 111345 where I
do get prompted and it works correctly.

Thanks.



In GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601)
 of 2013-01-01 on MS-W8-DANI
Bzr revision: 111393 rgm@gnu.org-20130101111746-zy3elvsny49dik4y
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-dev_1.4.3-1_win32/include
 -Ic:/emacs/libs/zlib-dev_1.2.5-2_win32/include
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.1.5-w32/include
 -Ic:/emacs/libs/libiconv-1.14-2-mingw32-dev/include'

Important settings:
  value of $LANG: en_US
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <send-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win
w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32notify w32
multi-tty emacs)

bug#13344: 24.3.50; Gnus error c:/dev/fd/0

[Lars Magne Ingebrigtsen]

nyc4bos@aol.com writes:

> There appears to be an error opening up the .authinfo.gpg file.
>
> I get the error in the *Messages* buffer:
>
> Unable to open server nnimap+aol due to: Opening input file: Opening process input file, no such file or directory, c:/dev/fd/0
> Opening nnimap server on aol...failed:

My guess is that it's a problem with your gpg setup.  What happens when
you try to open that file manually?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#13344: 24.3.50; Gnus error c:/dev/fd/0

[nyc4bos]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> nyc4bos@aol.com writes:
>
>> There appears to be an error opening up the .authinfo.gpg file.
>>
>> I get the error in the *Messages* buffer:
>>
>> Unable to open server nnimap+aol due to: Opening input file: Opening process input file, no such file or directory, c:/dev/fd/0
>> Opening nnimap server on aol...failed:
>
> My guess is that it's a problem with your gpg setup.  What happens when
> you try to open that file manually?

Looks like there was a change in epg.el:epg--start that is causing
this problem (so it's not a Gnus problem -- it's caused by a change in
epg.el).

(See Eli's comment to this bug report for details)

Thanks.

bug#13344: 24.3.50; Gnus error c:/dev/fd/0

[Eli Zaretskii]

> From: nyc4bos@aol.com
> Date: Thu, 03 Jan 2013 00:14:43 +0000
> 
> There appears to be an error opening up the .authinfo.gpg file.
> 
> I get the error in the *Messages* buffer:
> 
> Unable to open server nnimap+aol due to: Opening input file: Opening process input file, no such file or directory, c:/dev/fd/0
> Opening nnimap server on aol...failed:

Looks like this comes from this snippet in epg.el:epg--start:

    ;; Set GPG_TTY and TERM for pinentry-curses.  Note that we can't
    ;; use `terminal-name' here to get the real pty name for the child
    ;; process, though /dev/fd/0" is not portable.
    (with-temp-buffer
      (when (= (call-process "tty" "/dev/fd/0" t) 0)
	(delete-backward-char 1)
	(setq terminal-name (buffer-string))))

Obviously, this will never work on Windows.

I know nothing about this stuff, so I have no idea why you get there
now, but didn't get there before.  Maybe this will give you a hint to
start digging.

bug#13344: 24.3.50; Gnus error c:/dev/fd/0

[nyc4bos]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: nyc4bos@aol.com
>> Date: Thu, 03 Jan 2013 00:14:43 +0000
>> 
>> There appears to be an error opening up the .authinfo.gpg file.
>> 
>> I get the error in the *Messages* buffer:
>> 
>> Unable to open server nnimap+aol due to: Opening input file: Opening process input file, no such file or directory, c:/dev/fd/0
>> Opening nnimap server on aol...failed:
>
> Looks like this comes from this snippet in epg.el:epg--start:
>
>     ;; Set GPG_TTY and TERM for pinentry-curses.  Note that we can't
>     ;; use `terminal-name' here to get the real pty name for the child
>     ;; process, though /dev/fd/0" is not portable.
>     (with-temp-buffer
>       (when (= (call-process "tty" "/dev/fd/0" t) 0)
> 	(delete-backward-char 1)
> 	(setq terminal-name (buffer-string))))
>
> Obviously, this will never work on Windows.
>
> I know nothing about this stuff, so I have no idea why you get there
> now, but didn't get there before.  Maybe this will give you a hint to
> start digging.

Thanks Eli.

Here is the bare-bones way to duplicate this bug.

From runemacs.exe -Q, evaluated in *scratch* the following:

(require 'epa-file)
(epa-file-enable)
(setq epa-file-cache-passphrase-for-symmetric-encryption t)


The output I get after "(epa-file-enable)" is:
"`epa-file' already enabled"

Now, setting `toggle-debug-on-error' and just using ^X^F `(find-file)'
on the .authinfo.gpg file, I get the following backtrace:

Debugger entered--Lisp error: (file-error "Opening input file" "Opening process input file" "no such file or directory" "c:/dev/fd/0").
  signal(file-error ("Opening input file" "Opening process input file" "no such file or directory" "c:/dev/fd/0")).
  epa-file--find-file-not-found-function().
  run-hook-with-args-until-success(epa-file--find-file-not-found-function).
  byte-code("\303\b!\203.\0\304\b!\204.\0\305	!\210\306\307\310\bD\"\210\311\312!\204\x1f.\313.\303\207" [filename buf error file-exists-p file-readable-p kill-buffer signal file-error "File is not readable" run-hook-with-args-until-success find-file-not-found-functions t] 4).
  find-file-noselect-1(#<killed buffer> "~/.authinfo.gpg" nil nil "~/.authinfo.gpg" (0 146575129)).
  find-file-noselect("c:/home/.authinfo.gpg" nil nil t).
  find-file("c:/home/.authinfo.gpg" t).
  call-interactively(find-file nil nil).


Maybe if "/dev/fd/0" (or its equivalent) doesn't exists, this part of
epg.el:epg--start should be skipped as the comment acknowledges that
"/dev/fd/0" is not portable?

Thanks.

bug#13344: 24.3.50; Gnus error c:/dev/fd/0

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Looks like this comes from this snippet in epg.el:epg--start:
>
>     ;; Set GPG_TTY and TERM for pinentry-curses.  Note that we can't
>     ;; use `terminal-name' here to get the real pty name for the child
>     ;; process, though /dev/fd/0" is not portable.
>     (with-temp-buffer
>       (when (= (call-process "tty" "/dev/fd/0" t) 0)
> 	(delete-backward-char 1)
> 	(setq terminal-name (buffer-string))))
>
> Obviously, this will never work on Windows.

Looks like this code was introduced by this patch:

2012-12-28  Daiki Ueno  <ueno@gnu.org>

	* epg.el: Support pinentry-curses.

So perhaps that code should just be disabled for Windows?        

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#13344: 24.3.50; Gnus error c:/dev/fd/0

[Daiki Ueno]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> Looks like this comes from this snippet in epg.el:epg--start:
>>
>>     ;; Set GPG_TTY and TERM for pinentry-curses.  Note that we can't
>>     ;; use `terminal-name' here to get the real pty name for the child
>>     ;; process, though /dev/fd/0" is not portable.
>>     (with-temp-buffer
>>       (when (= (call-process "tty" "/dev/fd/0" t) 0)
>> 	(delete-backward-char 1)
>> 	(setq terminal-name (buffer-string))))
>>
>> Obviously, this will never work on Windows.
>
> So perhaps that code should just be disabled for Windows?        

Oops.  Though I tend to revert the previous patch, I've just added error
check around call-process for now.  Sorry for the inconvenience.

Regards,
-- 
Daiki Ueno

bug#13344: 24.3.50; Gnus error c:/dev/fd/0

[Eli Zaretskii]

> From: Daiki Ueno <ueno@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  nyc4bos@aol.com, 13344-done@debbugs.gnu.org
> Date: Fri, 04 Jan 2013 09:03:13 +0900
> 
> >>     ;; Set GPG_TTY and TERM for pinentry-curses.  Note that we can't
> >>     ;; use `terminal-name' here to get the real pty name for the child
> >>     ;; process, though /dev/fd/0" is not portable.
> >>     (with-temp-buffer
> >>       (when (= (call-process "tty" "/dev/fd/0" t) 0)
> >> 	(delete-backward-char 1)
> >> 	(setq terminal-name (buffer-string))))
> >>
> >> Obviously, this will never work on Windows.
> >
> > So perhaps that code should just be disabled for Windows?        
> 
> Oops.  Though I tend to revert the previous patch, I've just added error
> check around call-process for now.  Sorry for the inconvenience.

I don't think ignoring errors is TRT here.  You are invoking a command
that doesn't exist on Windows out of the box; however, if some user,
for some reason, does have that command somewhere on PATH, it _will_
be invoked, but the results could be unpredictable, because the
command by that name on MS-Windows can be unrelated to its Posix
namesake.

So it is best to avoid that call on Windows entirely.

bug#13344: 24.3.50; Gnus error c:/dev/fd/0

[Daiki Ueno]

Eli Zaretskii <eliz@gnu.org> writes:

>> >>       (when (= (call-process "tty" "/dev/fd/0" t) 0)
>
> I don't think ignoring errors is TRT here.  You are invoking a command
> that doesn't exist on Windows out of the box; however, if some user,
> for some reason, does have that command somewhere on PATH, it _will_
> be invoked, but the results could be unpredictable, because the
> command by that name on MS-Windows can be unrelated to its Posix
> namesake.
>
> So it is best to avoid that call on Windows entirely.

Okay, changed the code so that it won't be called on Windows.
Thanks for the explanation.

Regards,
-- 
Daiki Ueno