[Bug corefiles/22888] gcore shell script fails on some filenames (PATCH)

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22888

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e1e6f073a9f5d7c3183cb8096fb24a42c28ba36b

commit e1e6f073a9f5d7c3183cb8096fb24a42c28ba36b
Author: Georg Sauthoff <mail@georg.so>
Date:   Thu Mar 1 17:23:31 2018 -0500

    Improve gcore shell quoting and portability

    The gcore shell script (gdb/gcore.in) doesn't quote its variables
    enough.

    For example, trying to write a core file with - say - a space
    ungraciously fails like this:

        $ gcore -o 'foo bar' 6270
        /usr/bin/gcore: line 92: [: foo: binary operator expected
        gcore: failed to create foo bar.6270

    Similarly, one can inject meta characters like * (by accident)
    that may yield unexpected results, e.g. as in:

        $ gcore -o foobar '*'

    This change fixes these issues in several places.

    Aso, since the script uses array syntax, the patch changes the
    the shell in the first line from `/bin/sh` to /bin/bash`.

    POSIX doesn't specify the array syntax for shell, thus, the
    script doesn't work on systems where /bin/sh is linked to - say -
    dash.

    Since the source gcore.in already is processed by a pre-processor
    one could even auto-detect the path to bash and thus dynamically
    generate the first line. For systems where bash isn't available
    via /bin/bash. But I think this would be overkill and /bin/bash
    is good enough as most systems probably have it.

    gdb/ChangeLog:

        PR gdb/22888
        * gcore.in: Quote variables and switch interpreter to bash.

-- 
You are receiving this mail because:
You are on the CC list for the bug.