Re: [PATCH] Fix calling gcore when gdb is not in $PATH.

[Luis Machado <lgustavo at codesourcery dot com>]

On 10/11/2013 01:56 PM, Jan Kratochvil wrote:
> On Fri, 11 Oct 2013 18:46:15 +0200, Luis Machado wrote:
> > --- a/gdb/gcore.in
> > +++ b/gdb/gcore.in
> > @@ -49,9 +49,26 @@ rc=0
> >   # Loop through pids
> >   for pid in $*
> >   do
> > +# Attempt to fetch the absolute path to the gcore script that was
> > +# called.
> > +binary_path=`dirname "$0"`
> > +
> > +	if test "x$binary_path" = x. ; then
> > +	  # We got "." back as a path.  This means the user executed
> > +	  # the gcore script locally (i.e. ./gcore) or called the
> > +	  # script via a shell interpreter (i.e. sh gcore).  We use
> > +	  # the "which" command to locate the real path of the gcore
> > +	  # script, disambiguating this situation.
> > +	  binary_path_from_env=`which "$0"`
> > +	  binary_path=`dirname $binary_path_from_env`
>
> In generally OK, just still ... is there some reason for this 'which' search?
> Moreover if one really runs ./gcore then it should IMO take ./gdb (and not some
> other gdb), if we should really pick GDB from the directory of gcore.

Yes. The reason is to pick the gdb binary from the directory that 
contains the gcore script the user invoked.

If the user issued "sh gcore" and /usr/bin/gcore was picked (based on 
$PATH), then we should use /usr/bin/gdb.

Now, if the user issued "./gcore", ./gdb will be picked up, and so on.

Does it make sense?

Luis