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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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.

What about:
	if test "`basename "$0"`" != "$0"; then
	  binary_path="`dirname "$0"`/"
	else
	  binary_path=""
	fi

The first condition I write as:
	if test "${0#*/}" != "$0";then
but I have no idea if MinGW with its \ in paths can run a shell script.



> +	fi
> +
> +	# Add a slash to the path.
> +	binary_path="$binary_path/"
> +
>  	# `</dev/null' to avoid touching interactive terminal if it is
>  	# available but not accessible as GDB would get stopped on SIGTTIN.
> -	@GDB_TRANSFORM_NAME@ </dev/null --nx --batch \
> +	"$binary_path"@GDB_TRANSFORM_NAME@ </dev/null --nx --batch \
>  	    -ex "set pagination off" -ex "set height 0" -ex "set width 0" \
>  	    -ex "attach $pid" -ex "gcore $name.$pid" -ex detach -ex quit
>  


Thanks,
Jan