X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Thu, 26 Jul 2012 10:17:22 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Maxima can't write to /dev/stdout Message-ID: <20120726081722.GA5132@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Jul 26 07:04, Achim Gratz wrote: > The following maxima session encounters an EACCESS error that I can't > make sense of: > > (%i1) m: genmatrix (lambda([i,j], i+j-1), 3, 3)$ > (%i2) write_data(m, "/dev/stdout")$ > Maxima encountered a Lisp error: > > > UNIX error 13 (EACCES): Permission denied > > Automatically continuing. > To enable the Lisp debugger set *debugger-hook* to nil. > (%i3) > > The strace corresponding to opening /dev/stdout looks normal to me up until the > write fails: > [...] > 133 28731254 [main] lisp 196 symlink_info::check: 15 = > symlink.check(C:\Programs\Cygwin\dev\stdout, 0xDC16B0) (0x3000B) > 28 28731282 [main] lisp 196 path_conv::check: this->path(/proc/self/fd/1), > has_acls(1) /dev/stdout is a symlink to /proc/self/fd/. > 25 28731595 [main] lisp 196 build_fh_pc: fh 0x612883D0, dev 0xFF > 22 28731617 [main] lisp 196 fhandler_proc::exists: exists (/proc/self) > 21 28731638 [main] lisp 196 getpid: 196 = getpid() /proc/self is a symlink to /proc/196. > 25 28731663 [main] lisp 196 normalize_posix_path: src /proc/196/fd > 21 28731684 [main] lisp 196 normalize_posix_path: /proc/196/fd = > normalize_posix_path (/proc/196/fd) And here something goes wrong. If I call `echo foo > /dev/stdout' in bash, the above normalize_posix_path calls already handle the path /proc/196/fd/1, not just /proc/196/fd as lisp does. > 22 28731706 [main] lisp 196 mount_info::conv_to_win32_path: > conv_to_win32_path (/proc/196/fd) > 21 28731727 [main] lisp 196 fhandler_proc::get_proc_fhandler: > get_proc_fhandler(/proc/196/fd) > 22 28731749 [main] lisp 196 set_flags: flags: binary (0x2) > 24 28731773 [main] lisp 196 mount_info::conv_to_win32_path: src_path > /proc/196/fd, dst /proc/196/fd, flags 0x2, rc 0 > 25 28731798 [main] lisp 196 build_fh_pc: fh 0x612883D0, dev 0xFE > 22 28731820 [main] lisp 196 fhandler_process::exists: exists (/proc/196/fd) > 31 28731851 [main] lisp 196 lstat64: entering Here it calls lstat(/proc/196/fd/1), which works, but doesn't resolve the symlink. > [...] > 23 28732180 [main] lisp 196 stat_worker: 0 = (/proc/196/fd/1,0xDC3B30) > 23 28732203 [main] lisp 196 normalize_posix_path: src /proc/196/fd/1 > 23 28732226 [main] lisp 196 normalize_posix_path: /proc/196/fd/1 = > normalize_posix_path (/proc/196/fd/1) > 21 28732247 [main] lisp 196 mount_info::conv_to_win32_path: > conv_to_win32_path (/proc/196/fd/1) > 22 28732269 [main] lisp 196 fhandler_proc::get_proc_fhandler: > get_proc_fhandler(/proc/196/fd/1) > 21 28732290 [main] lisp 196 set_flags: flags: binary (0x2) > 21 28732311 [main] lisp 196 mount_info::conv_to_win32_path: src_path > /proc/196/fd/1, dst /proc/196/fd/1, flags 0x2, rc 0 > 26 28732337 [main] lisp 196 build_fh_pc: fh 0x612883D0, dev 0xFE > 22 28732359 [main] lisp 196 fhandler_process::exists: exists (/proc/196/fd/1) In fact, it never tried to resolve the symlink up to here. > 29 28732388 [main] lisp 196 normalize_posix_path: src /proc/196/fd/. > 22 28732410 [main] lisp 196 normalize_posix_path: /proc/196/fd/ = > normalize_posix_path (/proc/196/fd/.) ...so what is it doing with /proc/196/fd/. now? > [...] > 98 28757380 [main] lisp 196 stat64: entering > [...] > 26 28757895 [main] lisp 196 stat_worker: 0 = (/proc/196/fd,0xDC39E0) Calling stat on it, but what for? > 28 28757923 [main] lisp 196 stat64: entering > [...] > 72 28758456 [main] lisp 196 stat_worker: 0 = (/proc/196/fd,0xDC3A50) ...and again... > 26 28758482 [main] lisp 196 open: open(/proc/196/fd/, 0x10601) And now it opend the directory /proc/196/fd ... > 88 28759279 [main] lisp 196 open: 4 = open(/proc/196/fd/, 0x18601) gets the descriptor 4 ... > 550 28759904 [main] lisp 196 write: write(4, 0xDC2480, 1) > 38 28759942 [main] lisp 196 __set_errno: virtual ssize_t > fhandler_virtual::write(const void*, size_t):211 setting errno 13 > 29 28759971 [main] lisp 196 write: -1 = write(4, 0xDC2480, 1), errno 13 ... tries to write to it and *of course* gets an EACCES. I don't know what lisp is trying to do here, but it doesn't look like Cygwin's fault. After all, echo foo > /dev/stdout works fine. Also, if descriptor 1 is closed, the error message looks different: $ echo foo 1>&- >/dev/stdout bash: /dev/stdout: No such file or directory Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple