I have a program which uses the OpenCL libraries and produces some output on to stdout. The program accepts some command line arguments depending on which the kernel is run on a CPU or a GPU.
When I run the program on GPU,
$./run 1
$./run 1 > outFile
(a) Without any redirection, the output is seen on the stdout.
(b) With redirection to a file, the output is redirected to a the file specified.
When I run the program on a CPU,
$./run 0
$./run 0 > outFile
(a) Without any redirection, the output is seen on the stdout.
(b) With redirection to a file, no output is seen in the file.
Its a arch linux machine, with bash. If any other information is required, please let me know.
Try this and tell me if it works:
$./run 0 >& outFile
Related
I'm working on a test suite for programs written in C. For this I made a bash script in which I run the submitted programs on all availabe test cases and compare their output to the expected output.
As a last test case, I'd also like to do a check for memory leaks. The idea is to run Valgrind using the last availabe test case as input, and then assign Valgrind's output to a variable (discarding the program's output), which I would then use to look for certain erros using grep in order to output a summary in case some errors or leaks were indeed detected.
I've tried several things, but so far I'm unable to assign Valgrind's output to a variable.
Last thing I tried was:
TEST=$(valgrind ./a.out < "${infiles["$((len-1))"]}" >/dev/null)
I still get Valgrind's report displayed in the terminal and if I try to echo "$TEST" in the bash script, I get nothing.
valgrind is writing its output to stderr, not stdout, but $(...) only captures stdout. So you have to redirect stderr to stdout.
TEST=$(valgrind ./a.out < "${infiles["$((len-1))"]}" 2>&1 >/dev/null)
I would like to know if it's possible to get the output redirection file name as a parameter in bash?
For example :
./myscript.sh parameter1 > outputfile
Is there a way to get "outputfile" as a parameter like $2? In my script I have to do few operations in outputfile but I don't know which file I have to update... The second problem is, this script is already running and used by several tasks so I cannot change the user input...
Best regards
Redirections are not parameters to the program. When a program's output is redirected, the shell opens the file and connects file descriptor 2 to it before running the program. The program then simply writes to fd 2 (aka stdout) and it goes to the file.
On Linux and similar systems you can use /dev/stdout, which is a symbolic link to the process's stdout file.
I want to run some diskpart commands from a text file and save its output to another text file.This is written in my batch file which i want to do it.
DISKPART /S E:\CMD.TXT > E:\OUT.TXT
PAUSE
and when I run it (even as administrator) it doesn't work well and this is written in the black screen of CMD:
DISKPART /S E:\CMD.TXT 1>E:\OUT.TXT
PAUSE
That extra 1 makes it not work correctly. whats that? and how can I solve it dear friends?
Windows supports a number of "standard devices"
0 is standard input (stdin) - normally assigned to the keyboard.
1 is standard output (stdout) - normally assigned to console
2 is standard error (stderr) - normally assigned to console
So, you could write a program which accepts input from stdin and writes results to stdout and errors to stderr (not all programs use stderr)
When you redirect input or output using redirectors (< and >) you can assign the input to a file if you wish, or direct output or errors likewise to a file.
The separate redirection of stdout and stderr is new to the NT-series of Windows (2K,XP,Vista,7,8,10) and > is assumed to mean stdout gets redirected. To redirect stdout explicitly you need to use 1>. To redirect stderr explicitly you need to use 2>.
Windows inserts the 1 to indicate that stdout is being redirected, but not stderr.
So - there's nothing amiss with what is being reported.
What is your command intended to do? COuld it be that windows is objecting to an attempt to create a file on E: when E: is the subject of a diskpart operation?
While debugging I want to display console output both on console and save a backup in file.
Windows doesn't have tee, but you can add one. Say the folder is c:\bin\ and it works fine. And I have added it into system's PATH.
Problem is setting "[ ]| tee[.exe] output.txt" or " | tee[.exe] output.txt" won't work -- the output.txt is just nowhere to be found. I also tried to add the c:\bin\ path explicitly in VC Directories or environment under debugging and merge environment to be yes.
"> output.txt" works fine.
Anyone has any idea how I can resolve this? Many thanks!
I assume that you're putting the | tee.exe output.txt string in the project property "Debugging | Command Argument".
Unfortunately, that property only supports the redirection operators, not the pipe operator. If you have the | tee.exe output.txt string in the preoperty and run a program that dumps the command line arguments, you'll see that that information is just passed on as the arguments. The "Debugging | Command Argument" doesn't actually get processed by a full-fledged shell (such as cmd.exe) - it's just the IDE supporting some simple redirection (actually, it seems to support more than I expected):
From http://msdn.microsoft.com/en-us/library/kcw4dzyf.aspx:
You can use the following redirection operators in this box:
< file
Reads stdin from file.
> file
Writes stdout to file.
>> file
Appends stdout to file.
2> file
Writes stderr to file.
2>> file
Appends stderr to file.
2> &1
Sends stderr (2) output to same location as stdout (1).
1> &2
Sends stdout (1) output to same location as stderr (2).
You can have a limited version of what you're looking for by redirecting the program's output to a file using >> and using a tail-f command to display whatever gets added to the file. If you do this you'll probably want to call setvbuf( stdout, NULL, _IONBF, 0 ) first thing in main() so that I/O is unbuffered. Otherwise tail -f won't see it until the buffer gets flushed, and I imagine that you'd like to see each output operation as it occurs.
Another option is to crank the console window's "Screen Buffer Height" property up to a large number - one of the first things I do when I get a new Windows machine is set that value to 3000 or so - then debug the program normally and copy/paste the contents of the console window before it closes.
You better NOT use printf for this purpose. Instead, write your own function; taking formatted-input, like printf - having variable number of arguments (...). That function will use printf to display on console, get the buffer written on file, would send to output to debug window and all. You may customize it depending on Debug/Release build.
It may go like (may have some minor mistakes):
void PrintDebuggingInfo(const char* pFormatString, ...)
{
va_list arguments;
char OutputString[1024];
va_start(pFormatString, argument);
vsprintf(OutputString, pFormatString, argument); // Generate string
// Now use `OutputString` as you wish!
}
You may use other variant of vsprintf. Infact all formatted-functions use this function only!
I want to put my program's output into a file. I keyed in the following :
./prog > log 2>&1
But there is nothing in the file "log". I am using the Ubuntu 11.10 and the default shell is bash.
Anybody know the cause of this AND how I can debug this?
There are many possible causes:
The program reads the input from log file while you try to redirect into it with truncation (see Why doesn't "sort file1 > file1" work?)
The output is buffered so that you don't see data in the file until the output buffer is flushed. You can manually call fflush or output std::flush if using C++ I/O stream etc.
The program is smart enough and disables output if the output stream is not a terminal.
You look at the wrong file (i.e. in another directory).
You try to dump file's contents incorrectly.
Your program outputs '\0' as the first character so the output appears to be empty, even though there is some data.
Name your own.
Your best bet is to run this application under a debugger (like gdb) or use strace or ptrace (or both) and see what the program is doing. I mean, really, output redirection works for the last like 40 years, so the problem must be somewhere else.