Bug 6465

Summary:	fhpd ./gdb does not work as expected
Product:	frysk	Reporter:	Tom Tromey <tromey>
Component:	general	Assignee:	Stan Cox <scox>
Status:	RESOLVED FIXED
Severity:	normal	CC:	pmachata
Priority:	P2
Version:	unspecified
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

Description Tom Tromey 2008-04-28 14:04:02 UTC

I wanted to try a completion test case in fhpd, so I tried running
it on a just-build gdb I have.  To my surprise it picked up the system
gdb instead:

opsy. fhpd ./gdb
[0.0] Loaded executable file: /usr/bin/gdb

If the argument to fhpd has a directory separator, I think it should
be searched for in '.' first.  Note that this is different from 
prepending '.' to PATH... I think fhpd should mimic the shell's lookup
procedure.

Comment 1 Stan Cox 2008-04-30 18:16:21 UTC

Consider relative paths when searching for executable.
    
* SysRoot.java (findExe): Consider relative paths.

Comment 2 Stan Cox 2008-04-30 18:17:57 UTC

*** Bug 6458 has been marked as a duplicate of this bug. ***

Comment 3 Tom Tromey 2008-04-30 18:52:47 UTC

It still seems a little wrong to me.

For example, if 'gdb' is a directory:

opsy. fhpd gdb
Error: gdb is a directory
opsy. fhpd ./gdb
Error: ./gdb is a directory

IMO, the first one should pick gdb from $PATH.
The second one should continue to fail as it does now.

That is, mimic shell behavior.

Comment 4 Stan Cox 2008-05-05 18:18:14 UTC

Follow Unix ./executable convention.
    
* SysRoot.java (findExe): Follow Unix ./executable convention.
* TestSysRoot.java (testExePath): New


% /work/scox/frysk/bld/x86_64-redhat-linux/frysk-core/frysk/bindir/fhpd ./gdb
Error: ./gdb is a directory
% /work/scox/frysk/bld/x86_64-redhat-linux/frysk-core/frysk/bindir/fhpd gdb
[0.0] Loaded executable file: /usr/bin/gdb

Comment 5 Stan Cox 2008-05-05 18:18:49 UTC

*** Bug 6462 has been marked as a duplicate of this bug. ***

Comment 6 Stan Cox 2008-05-05 18:19:28 UTC

*** Bug 6463 has been marked as a duplicate of this bug. ***

Comment 7 Stan Cox 2008-05-05 18:39:09 UTC

*** Bug 6464 has been marked as a duplicate of this bug. ***