Programming

The problem is particularly odd because the program compiles, links, runs, and gives the correct output, it just doesn't print to the screen. That would rule out control never reaching the print statement and such.

I was trying to debug a difference in output between the windows and linux versions, but I was able to correct that by compiling the linux under gcc3.4 instead of 4.1. Changes to the gcc header files are what "...causeth my head to ache", among other things. So now the app works properly when compiled under linux, but I still can't get anything to print to the screen??? I thought I would try to run that down, since I am sure I will need to be able to do it.

I will try to duplicate the situation in a smaller piece of code I can post. The parent main is in cpp, which forks a cpp child, that calls fortran functions, which in turn call cpp functions, so tracking things down can be a bit dodgy. I am also trying to get a hold of the person who wrote that part of the code, so I will post back if he has anything to add.

LMHmedchem

If it doesn't print to the screen, what does it print to?

There's no mysterious difference between cygwin terminal inheritance and linux terminal inheritance that causes terminals to break. If anything I'd expect it to break in cygwin first since it's generally a poor approximation of UNIX. It comes down to what your program is doing, or maybe what the script running it is doing.

Beyond that I can't help if you can't post code. I've thrown as many darts at as many possible answers as I can think of. I'm done with this thread too.

The parent creates an output file with a printing function.

This is the code that prints the header row of the output.

Code:

void printSfileHeader1ln( std::ostream &ros, const Remapper & re, 
                          char cdelim, int ihowmany, int bLegacy)
{
   int ii, i2, ihowmany2;
   char pszFormat[10]; // beware below
   if(ihowmany > re.max_can_print() ) {
      fprintf(stderr, "printSfileHeader1ln: ihowmany over bounds: %d vs %d\n",
               ihowmany, re.max_can_print() );
      return;
   }
   ihowmany2 = (ihowmany >= re.max_can_print() ) ? re.max_can_print() : ihowmany;

   if( bLegacy & EXTRA_NEWLINES )
      ros << "aname\n";
   else
   {
      ros << "aname";
   }

   if( re.xlations_computed() ) 
      ii = 0;
   else if( bLegacy & NO_SEQUENCE_CT ) 
      ii = 1; // this will suppress the "id" index
   else
      ii = 0;
   for(;ii< ihowmany2; ii++) {
      i2 = ii;
      ros << cdelim << re.desname[i2];
   }
   ros << "\n";
   
   if( bLegacy & EXTRA_NEWLINES )
      ros << "$$$$\n";
}

The same code is used for printing in both windows and linux (same src file).

LMHmedchem

And does it succeed in creating that file?

---------- Post updated at 11:13 AM ---------- Previous update was at 11:01 AM ----------

If the stderr output doesn't appear, it's because some step along the way is redirecting it. Check the script files you're running it with. 2> /dev/null and the like will prevent you from seeing stderr output. It's also possible for code inside your program to alter stderr.

Yes it does successfully create the output file, and I have carefully checked it to see that the content is correct.

I am just running the app with a very simple command line string "./appName -i inputFile -o outputFile". I do re-direct to a file with > or &> when I am generating allot of output, but not in this case.

I will start adding print statements at the beginning of the parent function and work my way through to see if this issue holds true in all parts of the code or is an issue local to some specific function(s).

LMHmedchem

It'd help if you answered some of my questions too...

If I understand you, you want things in outputFile to also appear in the terminal as it goes?

If ros is an output file, and only an output file, I wouldn't have ever expected its output to go anywhere but the output file -- not even in Windows. Things going to stderr should still appear in the terminal of course, and if they're not, please tell me so.

I think something external to the application was following the file and printing its output to terminal. You can print a file being written to to terminal with tail -f by doing something like this:

Code:

# Blank the output file
: > outputFile
exec 5<outputFile
# Run tail -f in the background, save its PID
tail -f <&5 &
PID=$!
# Close the PID in the shell, we don't need it anymore
exec 5<&-

application -o outputFile
# wait a moment for tail to finish
sleep 1
# kill it
kill "$PID"
# wait for tail to quit
wait

If you can convince your application to print to standard output, this becomes far simpler:

Code:

application | tee outputFile

Sorry for the delay in responding, I had to go to the doctors. I have been trying to get rid of an annoying case of bronchitis. It would help if it would just get warm some time soon.

Did I miss something somewhere? I thought I answered everything.

Maybe I wasn't clear in the original post. The issue is not with the output that the program is supposed to make, which goes to the output file (and is working properly), but with additional print statements that I have added for debugging purposes. Since I can't get fortran to work with gdb, I am stuck without a debugger/IDE and have to debug by adding print statements to the code in very, very, old school fashion.

I normally just add,
print*, (fortran)
std::cout << (cpp)
and get the output I need.

This is the code that I can't get to print to the terminal in linux, but prints fine in windows. The normal output file is fine under both platforms.

I would normally just run,

./appName -i inputFile -o outputFile
./appName -i inputFile -o outputFile > stdout.txt (for large output)

and could look at the debugging output in the shell. The program runs, the output is fine, but there is nothing in the shell, or output fie (I tested both).

I have also tried,

./appName -i inputFile -o outputFile &> stdout.txt

in case the output was somehow going to stderr.

The only thing I can think of is that cout is not going to the terminal in this case, but has been redirected elsewhere, like it might be if you were running a gui. I will look carefully through the code and see if I can spot anything that might be a likely candidate. It was also suggested that the problem may be with flushing the o/p buffer, so I will also try adding some cin statements and see if that changes anything.

LMHmedchem