0

I'm trying to redirect the output of my program to a file. The program prints a few lines in the screen from time to time, and keeps proceeding like that until it terminates. When it terminates, the number of printed lines will be in the thousands.

When executing the program without any redirection directive, it prints all information in the screen as it should. Nevertheless, when trying to use >, or 1> or 2> or several other possibilities, one of two things happens. Either the output file stays completely empty, or it contains only the first 30 lines or so (which is enough to fill a page). I have also trying to redirect using " | cat >" and again nothing happens.

What could be the source of the problem? I'm using ubuntu and executing the program from the terminal. The program is compiled in C++, and text is printed using "cout".

Examples of redirections that I tried to use without success.

  1. ./testProgram > output.txt
  2. ./testProgram 1> output.txt
  3. ./testProgram 2> output.txt
  4. ./testProgram &> output.txt
  5. ./testProgram > output.txt 2>&1
  6. ./testProgram | cat > output.txt
  7. All variations above with >> instead of > also have the same problem

Obs: Since the computation may take some days, I use cat output.txt to see the file from time to time. Nevertheless, as mentioned above, only the first page or so of text is written at the file and that is all I can see. Since this amount of text corresponds to executing the program for a few seconds, it doesn't seem that reading the file is the cause of the problem.

fpmurphy
  • 4,636
Mateus de Oliveira
  • 101
  • 3
    Are you waiting for the program to terminate, or examining the output file while it is still running? if the latter, the issue could just be a matter of buffering – steeldriver Feb 09 '20 at 00:16
  • Try using >> as > overwrites the output.txt on every hit and >> will append to the file. – Mark Stewart Feb 09 '20 at 00:41
  • 4
    You say "my program". So post your script, or your code. "test" is a bad thing to call your program -- it is both a shell built-in, and a /bin/test external command. What do you mean by "works perfectly"? Your terminal is sticky -- if you write to it, the text stays in the terminal. You could be seeking or re-opening your output in the code multiple times, which would mess up the file. – Paul_Pedant Feb 09 '20 at 00:47
  • @Paul_Pedant Unfortunately I cannot post the code, since it is pretty big and it is part of a bigger project involving several other people. – Mateus de Oliveira Feb 09 '20 at 02:23
  • @Mark Stewart, same problem with >>. I updated the question to reflect this. – Mateus de Oliveira Feb 09 '20 at 02:24
  • 1
    Sounds like a programming error within your application. – fpmurphy Feb 09 '20 at 02:34
  • @fpmurphy What kind of programming error could cause this behavior? It prints what should print in the screen. The problem only happens if I redirect the output to a file, which as I understand should be independent of the program. Note that I also have tried redirecting stderr. – Mateus de Oliveira Feb 09 '20 at 02:38
  • 1
    Buffering issue is what comes into mind. If it has a lot of pipelines involve. – Jetchisel Feb 09 '20 at 02:49
  • 2
    If it's a buffering issue, maybe some of the programs mentioned in Turn off buffering in pipe will help. (unbuffer, stdbuf). – Mark Plotnick Feb 09 '20 at 08:09
  • Any terminal control codes involved?Try a hexdump of the output file. And/or pipe through tee and compare file to screen... – RudiC Feb 09 '20 at 11:05
  • 1
    Shell redirection works. Therefore, your C++ code is the problem. It is not unknown for code to check if output is to a terminal, and alter its behaviour Even ls changes columnising, grep suppresses colouring, etc. One of your team has perhaps outsmarted themselves. Also, streams can be buffered differently (automatically) depending on what they are connected to. Consider running the code under stdbuf to disable buffering (although the code can also over-ride this too). You should probably get somebody outside the team to audit it. – Paul_Pedant Feb 09 '20 at 12:57
  • 1
    wrt I cannot post the code, since it is pretty big - you're not expected to post whatever code you first saw the problem in, you're expected to come up with a minimal example that reproduces the problem and post that. See [ask]. – Ed Morton Feb 09 '20 at 16:00
  • It's probably buffering, especially if you're expecting a trickling of output over a long time. Make sure to flush the output stream from within the program at appropriate times in the code. – Kusalananda Feb 11 '20 at 06:18
  • Is it possible that output.txt has control characters in it, which are preventing it being displayed properly (with cat)? For instance, the clear screen codes. This would make cat clear the screen and you miss the preceding output. I almost never use cat - I recommend the use of less or an editor like vi to see the file in the raw. – Gedge Feb 11 '20 at 00:17

0 Answers0