X-Spam-Check-By: sourceware.org MIME-Version: 1.0 From: "Andy AT Jet-Net" To: =?iso-8859-1?q?Ren=E9_Berber?= Cc: cygwin AT cygwin DOT com Date: Mon, 08 May 2006 10:22:06 +0100 Subject: Re: C exe redirection blank file Message-ID: <4e23bac6d1Andy@jet-net.co.uk> In-Reply-To: References: <4e225417b8AndyBurgess AT argonet DOT co DOT uk> <4e2269bfcfAndy AT jet-net DOT co DOT uk> <4e22e3825fAndy AT jet-net DOT co DOT uk> User-Agent: Pluto/3.03h (RISC-OS/4.02) POPstar/2.06-ds.3 Content-Type: text/plain; charset=iso-8859-1 X-orpheus-MailScanner: Found to be clean X-orpheus-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.284, required 5, autolearn=disabled, AWL 0.28) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id k489YHQM020483 Thanks again for your reply, René > cygcheck Did that. Gives me the same DLLs as the working one. > > Incidentally I'm run a one minute cron job (for the working process) - > > would that affect anything? > Could be, if the process runs more than once concurrently and tries to > access the same file. It certainly will try to access the same port. Nope it shouldn't access any of the same files, apart from - as you say - the port. > [snip] > >>> Is there a limit to the number of files on XP > I don't know what functionality you are looking for, do you expect a > limit on the number of files on a directory? Windows does have a limit > on the size of a path, and there is a limit on the number of files but > it is pretty big (I don't remember it at the moment.) I'm not looking for any functionality here, just wondering if it could be affecting anything. I have had issues on other systems with numbers of files - but not on PCs. > > none of problem_program's output! > This is only on one machine, right? just as if you are closing stdout. Yep - only on one machine. Incidentally I did have trouble with the serial port baud rate, and increased programmatically for this program up to 38400 (from 9600). Would this have any bearing? It's the same on both PCs (and same hardware attached to each on the same port number). However, just recompiled another program that uses the same serial-port handler and string-handler (include files), copied over to 'live' and it can redirect OK. Limits it down to main() or the one remaining include file (big one) of this program! I may experiment with it while I eagerly await your reply. > There are many possibilities but none will stand if the program works > one way on > a computer and another way on a different computer. So the most > probable cause > is some difference between computers. Right, been looking into that. I have the following set up PROBLEM PC: I'm using .bash_profile to set things, rather than a user profile (not created). I'm using the variable $CC to hold the working directory (would this conflict with a c compiler variable?). On this PC I set up the variable in the following way (at the end of .bash_profile): CC=c:/dir export $CC cd $CC in ENV: HOMEPATH=\Documents and Settings\Andy PROCESSOR_IDENTIFIER=x86 Family 15 Model 1 Stepping 2, GenuineIntel OLDPWD=/home/Andy !C:=C:\cygwin\bin HOME=/home/Andy HOMEDRIVE=C: CC=c:/dir WORKING PC: I use my username's .profile. I set up the variable $CDIR to hold the working directory. On this PC I set up the variable in the following way: created Windows "Environment Variable" %cdir% as "e:/c/workshop/dir" in my user ".profile" I do cd $CDIR in ENV: HOMEPATH=\ PROCESSOR_IDENTIFIER=x86 Family 15 Model 3 Stepping 4, GenuineIntel OLDPWD=/cygdrive/b (connecting to remote drive on Bad PC) !C:=C:\ HOME=//computer/data HOMEDRIVE=T: (a share I mapped previously in Windows). CC=/usr/bin/gcc.exe (although I don't use $CC otherwise) The USER and MAKEMODE details are the same. I have other C compilers installed on the Good PC. The problem PC also has TEXDOCVIEW entries? Would any of this affect my processing? Would any other env entries help with clarification? > > * Is the chkdsk error significant...... > I don't see how it could be a factor, but I may be missing something. > Better try to see what's the cause (a damaged sector that cannot be > remapped?). I'll probably have to backup my hard disc first, and then run a Seagate diagnostic tool, but I'm loathed to do so. I've read on the internet that this message could be a red herring. I have a hardware-expert friend, I'll contact him too. > > * Have you ever heard of anything similar on Linux/Unix? > Anything is possible. For instance, an uninitialized pointer could cause > writing in the file descriptor table same effect as closing/changing > those file descriptors, An uninitialised pointer, you say? I'm only using character pointers. I suppose an "uninitialised" one would just be used (in say strcpy) rather than having been set beforehand. How can you detect it in GDB? > if the program is not too complex I would use gdb to see the execution at > least once, if it is complex then better isolate the problem first. Ok, it's not *too* complicated. How would you advise using GDB to test this issue? I've only just learnt that tool. What should I be checking for - adding a watch on "stdout" or something? > > * Does windows have a lock on a file or something? > Yes. You probably have seen it, when Windows doesn't allow you to delete > a file because it is "in use" Oh yes, I've seen it - especially on Windows 3.1! Bearing in mind I've rebooted a few time, I don't think that'd happen again - would it? > (try deleting all the .tmp files in your temp directory). I've done that. No joy. > > * I'm sure I haven't, but if something in the program redirected 'stdout', > > would this have any affect like I'm experiencing - i.e. overriding the > > command line's redirection? > As I said, anything is possible. The important clue is that it runs always > on one computer, it never runs on another (I should really say "seems to"). I also run in on the development machine in a different folder structure - e:\C\workshop\dir. Cygwin is installed on the E drive on the development machine, and on C on the 'live' machine. This reminds me of configuring serial printers.... settings had to match on both the terminal and the printer! Cheers Andy -- _____ ______ _____________________________________________ //_ / /| /_ / / __//__ / / |/__ / /...Your friendly computer professionals ____________________/ andy AT jet-net DOT co DOT uk -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/