I like the idea of nemiver, but i can't get this basic function of nemiver to work: redirect standard input to program. so as my program needs file input instead of manual input, it usually takes the form:
./program < list.txt
but apparently, nemiver does not recognize this simple redirection. and thinks "<" and "list.txt" as separate arguments. this frustrates me greatly. is there a solution to this? Thank you guys so much!
If you just want to do a postmortem analysis (and don't need to single-step), you can load a crash-dump (core) file which can be generated under any kind of pipelining/redirection scenario.
( ulimit -c unlimited && ./yourapp <in.txt >out.txt ) || nemiver --load-core=core ./yourapp
This only launches the debugger if a crash or assert occurs.
As a quick-and-dirty solution, you can add something like the following at the beginning of main()...
{
// programmatically redirect stdio
const char * stdin_filename="input.txt", * stdout_filename="output.txt";
assert( dup2(open(stdin_filename ,O_RDONLY),0) != -1 );
assert( dup2(open(stdout_filename,O_WRONLY),1) != -1 );
asm(" int3"); // optional breakpoint -- kills program when not debugging
}
Just make sure that you disable this when not debugging (since presumably you want to use the normal method of redirection in that case).
You also need the following...
#include <unistd.h>
#include <fcntl.h>
Related
I made a c program which takes two standard inputs automatically and one manually.
#include <stdio.h>
int main()
{
int i, j;
scanf("%d %d", &i, &j);
printf("Automatically entered %d %d\n", i, j);
int k;
scanf("%d", &k);
printf("Manually entered %d", k);
return 0;
}
I want to run this program using bash script which can input first two inputs automatically and leaves one input that is to be entered manually. This is the script I am using.
#!/bin/bash
./test <<EOF
1
2
EOF
The problem is EOF is passed as third input instead of asking for manual input. I cannot change my c program and I cannot input third input before the two inputs, so how can I do this using bash. I am new to bash scripting please help.
I made a c program which takes two standard inputs automatically and one manually.
No, you didn't. You made a program that attempts to read three whitespace-delimited decimal integers from the standard input stream. The program cannot distinguish between different origins of those integers.
The problem is EOF is passed as third input instead of asking for manual input.
No, the problem is that you are redirecting the program's standard input to be a shell here document. The here document provides the whole standard input, similar to if your program were reading a file with the here document's contents. When it reaches the end, it does not fall back to reading anything else.
I cannot change my c program and I cannot input third input before the two inputs
I take those two statements to be redundant: you cannot alter the program so that the input you characterize as "manual" is the first one it attempts to read. Not that that would help, anyway.
What you need to do is prepend the fixed input to the terminal input in the test program's standard input stream. There are many ways to do that, but the cat command (mnemonic for concatenate) seems like a natural choice. That would work together with process substitution to achieve your objective. For example,
#!/bin/bash
cat <(echo 1 2) - | ./test
The <(echo 1 2) part executes echo 1 2 and provides its standard output as if it were a file. The cat command concatenates that with its own standard input (represented by -), emitting its result to its standard output. The result is piped into program ./test.
This provides a means to prepend fixed input under your control to arbitrary data read from the standard input. That is, the wrapper script doesn't need to know what input the program expects after the fixed initial part.
Your problem is not caused by EOF being passed as third argument, but actually because stdin for your command is closed before third call to scanf.
One way how to solve this, is reading the value inside the script and then passing all three of them.
Something like this:
#!/bin/bash
read value
printf '1 2 %s' "$value" | ./test
I've asked a similar question on Stack Overflow on this link:
Why is it that we can redirect the input of 'less' command, but we can't run less without any arguments?
which leads me to this:
How can we distinguish that input to our program is directed or it is just a user's input ?!
can someone give me a small example on how can i use isatty function ?
Example of isatty:
#include <unistd.h>
#include <stdio.h>
int main()
{
if( isatty(STDIN_FILENO) )
puts("Connected to a terminal");
else
puts("Not connected to a terminal");
return 0;
}
In use:
$ gcc isatty.c
$ ./a.out
Connected to a terminal
$ echo hello | ./a.out
Not connected to a terminal
Doesn't get much simpler than that!
I've set the command line args for my app in the project properties -> debugging -> command arguments section.
If I run the program from command line directly I do:
progname arg1 arg2
So I've set the command line arguments in VS to
arg1 arg2,
as described here.
But, the program doesn't seem to run the same way as in running it from command line. The arguments are text files, and in the command line it can load those text files correctly, in VS2010 it doesn't somehow. Any ideas why?
Edit: update/clarification of post:
I am not getting any exceptions.
I may have oversimplified the problem too much in my explanation. I'm not actually loading text files, I'm loading a physics engine, which should be determined at runtime, so I need command line arguments.
The code used for loading the physics engine, on a high level, is:
if ( argc > 2 )
{
#ifndef PAL_STATIC
PF->LoadPALfromDLL();
#endif
//DebugBreak(); // for debugging ;)
PF->SelectEngine(argv[1]);
if (!pp) {
#ifdef _WIN32
MessageBox(NULL,L"Could not start physics!",L"Error",MB_OK);
/* ^ This is the error I am getting, i.e. pp is NULL,
so "PF->SelectEngine(argv[1]);" is not loading engine correctly */
#else
printf("Could not start physics engine %s!\n",argv[1]);
#endif
return -1;
}
I am using Bullet, which is run like this:
progname.exe arg1 arg2,
arg1 is the physics engine name and arg2 is a physics file to load, but it hangs on arg1.
The specific way I invoke this on the command line is:
progname.exe Bullet filename.
If i do this on command line it works, but if I pass these arguments to the debugger, I get a problem saying could not load physics engine.
This may be a result of the internals of the physics engine loader, which is from another source, but my guess is that this should work the same way whether I pass these arguments in the command line or in the debugger settings of VS.
I will look into the UAC settings and see what they say.
As it says in : https://msdn.microsoft.com/en-us/library/17w5ykft.aspx, you can try adding a backslash to every "\" character, to escape them inside the path. For example :
Before : "C:\somewhere\someplace\physics_engine"
After : "C:\\somewhere\\someplace\\physics_engine"
In bash shell I can get a full path of a script even if the script is called by source, link, ./..., etc.
These magic bash lines:
#Next lines just find the path of the file.
#Works for all scenarios including:
#when called via multiple soft links.
#when script called by command "source" aka . (dot) operator.
#when arg $0 is modified from caller.
#"./script" "/full/path/to/script" "/some/path/../../another/path/script" "./some/folder/script"
#SCRIPT_PATH is given in full path, no matter how it is called.
#Just make sure you locate this at start of the script.
SCRIPT_PATH="${BASH_SOURCE[0]}";
if [ -h "${SCRIPT_PATH}" ]; then
while [ -h "${SCRIPT_PATH}" ]; do SCRIPT_PATH=`readlink "${SCRIPT_PATH}"`; done
fi
pushd `dirname ${SCRIPT_PATH}` > /dev/null
SCRIPT_PATH=`pwd`;
popd > /dev/null
How can you get the script path under the same conditions in TCSH shell? What are these 'magic lines'?
P.S. It is not a duplicate of this and similar questions. I'm aware of $0.
IF your csh script is named test.csh, then this will work:
/usr/sbin/lsof +p $$ | \grep -oE /.\*test.csh
I don't use tcsh and do not claim guru status in it, or any other variant of C shell. I also firmly believe that Csh Programming Considered Harmful contains much truth; I use Korn shell or Bash.
However, I can look at manual pages, and I used the man page for tcsh (tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-apple-darwin) on MacOS 10.7.1 Lion).
As far as I can see, there is no analogue to the variable ${BASH_SOURCE[0]} in tcsh, so the starting point for the script fragment in the question is missing. Thus, unless I missed something in the manual, or the manual is incomplete, there is no easy way to achieve the same result in tcsh.
The original script fragment has some problems, too, as noted in comments. If the script is invoked with current directory /home/user1 using the name /usr/local/bin/xyz, but that is a symlink containing ../libexec/someprog/executable, then the code snippet is going to produce the wrong answer (it will likely say /home/user1 because the directory /home/libexec/someprog does not exist).
Also, wrapping the while loop in an if is pointless; the code should simply contain the while loop.
SCRIPT_PATH="${BASH_SOURCE[0]}";
while [ -h "${SCRIPT_PATH}" ]; do SCRIPT_PATH=`readlink "${SCRIPT_PATH}"`; done
You should look up the realpath() function; there may even be a command that uses it already available. It certainly is not hard to write a command that does use realpath(). However, as far as I can tell, none of the standard Linux commands wrap the realpath() function, which is a pity as it would help you solve the problem. (The stat and readlink commands do not help, specifically.)
At its simplest, you could write a program that uses realpath() like this:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
int main(int argc, char **argv)
{
int rc = EXIT_SUCCESS;
for (int i = 1; i < argc; i++)
{
char *rn = realpath(argv[i], 0);
if (rn != 0)
{
printf("%s\n", rn);
free(rn);
}
else
{
fprintf(stderr, "%s: failed to resolve the path for %s\n%d: %s\n",
argv[0], argv[i], errno, strerror(errno));
rc = EXIT_FAILURE;
}
}
return(rc);
}
If that program is called realpath, then the Bash script fragment reduces to:
SCRIPT_PATH=$(realpath ${BASH_SOURCE[0]})
I read the manual of batch file command and it says by using <& operator to redirect input and duplicate and using the >& operator to redirect output and duplicate.
I'm really confused, I can not understand what does this mean. Can anyone give me some real life scenario? The example put on the website is really hard to understand.
The most common use of this is the following:
pp.bat > caca.txt 2>&1
which means:
Send the standad output of pp.bat (handle 1) to caca,txt and the standard error
(handle 2) to the standard output. Result: both std out & err goto caca.txt
HTH!