Subject: Re: C exe redirection blank file
From: "Andy@Jet-Net" <[email-masked]>
To: René Berber <[email-masked]>
Cc: [email-masked]
Date: Mon, 08 May 2006 10:22:06 +0100

Thanks again for your reply, René

> cygcheck <program>
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
____________________/ [email-masked]

--
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/