Community
Participate
Working Groups
Build Identifier: 20120614-1722 My program needs some arguments which are normally read from a file, so a call from the terminal looks like user@pc:~/workingdirectory/myprog < paramfile So I created a debug configuration specifying the working directory and "<paramfile" (without quotes) in the arguments tab. If I click debug, everything works fine. If I click run with the same configuration no arguements are read from the file, so I have to enter everything manually. I specify the complete path to paramfile in the "working directory". I would like to understand what actually happens when I click "Run" or "Debug". I would expect Eclipse to do " cd workingdirectory ~/binarypath/binary arguments", however it does not seem to happen. Is it possible to view the command lines Eclipse executes, when Run is pressed? In the Console window I see only the output of my program. Feeling like failing to find a gas pedal in a ferrari )) Thank you in advance! Reproducible: Always Steps to Reproduce: 1. This simple program reproduces the problem: #include <stdio.h> #include <stdlib.h> int main(void) { char text[100]; printf("Enter some text: "); fscanf(stdin,"%s", text); printf("\n %s \n",text); return EXIT_SUCCESS; } 2. Write "Hello" into a text file "textfile" 3. Debug configuration with <textfile in the arguments tab will print the text. Pressing "Run" will display "Enter some text"
Created attachment 219172 [details] simple example to reproduce the bug
(In reply to comment #0) > Build Identifier: 20120614-1722 > > My program needs some arguments which are normally read from a file, so a call > from the terminal looks like user@pc:~/workingdirectory/myprog < paramfile Note that these are not "arguments" but "input". Arguments are passed directly to the program through "argc,argv" while input is being read by the program from stdin. This clarification has an impact on the below explanation > So I created a debug configuration specifying the working directory and > "<paramfile" (without quotes) in the arguments tab. If I click debug, > everything works fine. > > If I click run with the same configuration no arguements are read from the > file, so I have to enter everything manually. I can see this problem too. I believe the reason is that in Debug mode, we pass the arguments to GDB and it is smart enough to realize that the '<' character indicates a redirect instead of an argument. CDT does not seem to be as smart when it does the Run mode directly. The following program helps understand things. The args in the launch are "hello <input": #include <stdio.h> int main(int argc, char **argv) { printf("argc is %d\n", argc); for (int i=0;i<argc;i++) { printf("argv[%d] is: %s\n",i,argv[i]); } return 0; } When running in Debug the output is: argc is 2 argv[0] is: myTestApp argv[1] is: hello while in Run mode it is: argc is 3 argv[0] is: myTestApp argv[1] is: hello argv[2] is: <input Notice how in Debug mode the "<input" is not treated as an argument, but in Run mode it is. Because "<input" is passed to the program as an argument, it explains why redirection is not handled by the OS. There may be a way to have CDT handle this case better.
The way GDB makes this case works is that it runs the program and arguments through a shell, so that things like < get interpreted properly. In my case it does this: /usr/bin/tcsh -c "exec myTestApp hello <input" CDT would have to do something similar
Thank you very much, Marc, for clarifying the case. The command line GDB executes makes much sense to me, so it would be nice if somebody from the CDT team could cast an eye over it. Since you agree with me it is more a bug than a feature, I would really appreciate if it could be fixed. Since it affects a very basic functionality of Eclipse the effort seems sensible. Should I redirect the thread to another component of CDT (which one should it be?) to gain some attention from the respective developers?
Would be nice to fix if someone has time. Contributions would be good.
*** Bug 361751 has been marked as a duplicate of this bug. ***
