public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
From: sergiodj+buildbot@sergiodj.net
To: gdb-testers@sourceware.org
Subject: [binutils-gdb] Improve gcore shell quoting and portability
Date: Thu, 01 Mar 2018 22:44:00 -0000	[thread overview]
Message-ID: <e1e6f073a9f5d7c3183cb8096fb24a42c28ba36b@gdb-build> (raw)

*** TEST RESULTS FOR COMMIT e1e6f073a9f5d7c3183cb8096fb24a42c28ba36b ***

Author: Georg Sauthoff <mail@georg.so>
Branch: master
Commit: e1e6f073a9f5d7c3183cb8096fb24a42c28ba36b

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.


             reply	other threads:[~2018-03-01 22:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-01 22:44 sergiodj+buildbot [this message]
2018-03-01 22:44 ` Failures on RHEL-s390x-m64, branch master sergiodj+buildbot
2018-03-01 23:20 ` Failures on Fedora-i686, " sergiodj+buildbot
2018-03-01 23:20 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot
2018-03-01 23:39 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot
2018-03-01 23:42 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot
2018-03-01 23:49 ` Failures on Fedora-x86_64-m64, " sergiodj+buildbot
2018-03-02  0:01 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2018-03-02  0:44 ` Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot
2018-03-02  1:02 ` Failures on Debian-s390x-m64, " sergiodj+buildbot
2018-03-02  1:10 ` Failures on Ubuntu-AArch32-native-gdbserver-m32, " sergiodj+buildbot
2018-03-06 21:22 ` Failures on Ubuntu-AArch64-m64, " sergiodj+buildbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e1e6f073a9f5d7c3183cb8096fb24a42c28ba36b@gdb-build \
    --to=sergiodj+buildbot@sergiodj.net \
    --cc=gdb-testers@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).