Thread: problems calling an executable

we have 2 executables being called exactly the same way:
concorde : user@host:~/vrp/concorde/TSP$ ./concorde -o tsp_out input_file
linkern : user@host:~/vrp/concorde/LINKERN$ ./linkern -o tsp_out input_file

the code to run linkern is:

Code:

void tsp_sol_call(char *exec_path,char *exec_file,char *in_file){

	register int ret,pid;
	int status;

	pid=fork();
	
	if(pid==-1){
		perror("fork");
		exit(1);
	}
	if(pid==0){
		ret=execl(exec_path,exec_file,"-o","tsp_out",in_file,"..",NULL);
		if(ret=-1) perror("execl");
	}
	else wait(&status);	
}

int main(){
       tsp_sol_call("/home/panos/vrp/concorde/LINKERN/linkern","linkern",
			     "/media/hda7/source_vrp/tsp_in.tsp");
}

now,
while tsp_sol_call() causes linkern to run correctly, the same code cant do the same for concorde.

Code:

tsp_sol_call("/home/panos/vrp/concorde/TSP/concorde","concorde",
				     "/media/hda7/source_vrp/tsp_in.tsp");

It just produces some error messages just as if i had called it incorrectly from the console. any suggestions?

notes: input/output filenames are the same and the command lines represented in the code run correctly if inputed in the console.

Originally Posted by Salem

> ret=execl(exec_path,exec_file,"-o","tsp_out",in_file,"..",NULL);
What's the ".." for?
It's not in your example command line.

it just slipped away ignore it.it works fine with or without it

> It just produces some error messages
How about pasting the exact error messages?
Is it from your perror() call perhaps?

nope it's not perror
here's the output

Code:

panos@mate:/media/hda7/source_vrp$ ./project


concorde -o tsp_out /media/hda7/source_vrp/tsp_in.tsp ..
Usage: concorde [-see below-] [dat_file]
   -B    do not branch
   -C #  maximum chunk size in localcuts (default 16)
   -d    use dfs branching instead of bfs
   -D f  edgegen file for initial edge set
   -e f  initial edge file
   -E f  full edge file (must contain initial edge set)
   -f    write optimal tour as edge file (default is tour file)
   -F f  read extra cuts from file
   -g h  be a grunt for boss h
   -h    be a boss for the branching
   -i    just solve the blossom polytope
   -I    just solve the subtour polytope
   -J #  number of tentative branches
   -k #  number of nodes for random problem
   -K h  use cut server h
   -M f  master file
   -m    use multiple passes of cutting loop
   -n s  problem location (just a name or host:name, not a file name)
   -o f  output file name (for optimal tour)
   -P f  cutpool file
   -q    do not cut the root lp
   -r #  use #x# grid for random points, no dups if #<0
   -R f  restart file
   -s #  random seed
   -S f  problem file
   -t f  tour file (in node node node format)
   -u v  initial upperbound
   -U    do not permit branching on subtour inequalities
   -v    verbose (turn on lots of messages)
   -V    just run fast cuts
   -w    just subtours and trivial blossoms
   -x    delete files on completion (sav pul mas)
   -X f  write the last root fractional solution to f
   -y    use simple cutting and branching in DFS
   -z #  dump the #-lowest reduced cost edges to file xxx.rcn
   -N #  norm (must specify if dat file is not a TSPLIB file)
         0=MAX, 1=L1, 2=L2, 3=3D, 4=USER, 5=ATT, 6=GEO, 7=MATRIX,
         8=DSJRAND, 9=CRYSTAL, 10=SPARSE, 11-15=RH-norm 1-5, 16=TOROIDAL
         17=GEOM, 18=JOHNSON

[QUOTE=panos]it just slipped away ignore it.it works fine with or without it
[/QOUTE]

OMG it IS the problem... thanx i didn't really noticed.

many thanx it works fine...

Another question on that. Is there any way to suppress all screen output produced by the executables while runtime??? supposed the execs themselves do not provide this option...

Redirect stdout/stderr ?

Originally Posted by SKeane

Redirect stdout/stderr ?

perhaps into a file or something??? if it is a file it would cost too much because these lines of code run hundreds of times solving a genetic. on the other hand you can't make an omelete if you don't break any eggs.

something that is not a disk file just to save some time?

any other suggestions?

If you don't actually want to see the output, what about /dev/null ?

(Assuming you are using some sort of Unix box)

Originally Posted by CornedBee

On Windows, there ought to be the NUL: device.

i am on linux so i think i can get round this.

thanx!!!

Originally Posted by Salem

Code:

close( 1 );
ret=execl(exec_path,exec_file,"-o","tsp_out",in_file,"..",NULL);

That should be enough to silence stdout, though you might want to do something different for stderr.

what is 1 inside the close() argument???

when applying the above in my code and every executable once, the second produces funny results...

Code:

void tsp_sol_call(char *exec_path,char *exec_file,char *prob_type,char *in_file){

	register int ret,pid;
	int status;

	pid=fork();
	
	if(pid==-1){
		perror("fork");
		exit(1);
	}
	if(pid==0){  //This block chooses among the 2 available solvers (heur. / LP)
		//close(1);       //the first attempt...
		if(prob_type=="LIN_KERN"){
			close(1);
			ret=execl(exec_path,exec_file,"-o","tsp_out",in_file,NULL);
		}
		else if(prob_type=="LP"){
			close(1);
			ret=execl(exec_path,exec_file,"-o","tsp_out","-f",in_file,NULL);
		}
		
		if(ret=-1) perror("execl");
	}
	else wait(&status);

i don't have a clue about close() i only use it to close file pointers. plz help... plz... plz...

close(1) is closing stdout (effectively).