From: Emily Shaffer <emilyshaffer@google.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Junio C Hamano <gitster@pobox.com>,
"brian m. carlson" <sandals@crustytoothpaste.net>,
Git List <git@vger.kernel.org>
Subject: Re: [PATCH 1/2] help: add shell-path to --build-options
Date: Wed, 13 May 2020 11:45:07 -0700 [thread overview]
Message-ID: <20200513184507.GA196295@google.com> (raw)
In-Reply-To: <CAPig+cRGrExRsucs8pmmiP+Zc2CmR3AU=8ACuiyH9tkz9JSCgQ@mail.gmail.com>
On Wed, May 13, 2020 at 01:10:36AM -0400, Eric Sunshine wrote:
>
> On Wed, May 13, 2020 at 1:02 AM Junio C Hamano <gitster@pobox.com> wrote:
> > "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> > > [...] A value of "/bin/sh" doesn't
> > > necessarily tell us very much on Debian (or on macOS, for that matter).
> >
> > Good point. Perhaps readlink(3) on it, then?
> >
> > lrwxrwxrwx 1 root root 9 Mar 11 2018 /bin/sh -> /bin/bash
>
> That wouldn't help on Mac OS:
>
> $ ls -l /bin/sh /bin/bash
> -r-xr-xr-x 1 root wheel 618448 Mar 18 22:04 /bin/bash
> -r-xr-xr-x 1 root wheel 618512 Mar 18 22:04 /bin/sh
>
> Although /bin/sh is neither a hard link nor a symbolic link to
> /bin/bash, nor is the file size the same, it is nevertheless Bash (in
> some form or another).
Hum. It seems some useful things exist like $BASH_VERSION and
$ZSH_VERSION, but I'm not terribly excited about the idea of making a
list and checking each one in bugreport (as it's sure to be
nonexhaustive). I found a few more heuristics in a SO post[1] but this
approach generally looks like a pain, and somewhat unreliable.
Most other alternatives I found with a cursory Google involve checking
the name of the shell, which I think will have the same issues as
checking $SHELL:
- `ps -p $$` for info about the current process (didn't reveal bash when I `cp
/bin/bash ~/bin/nish && ~/bin/nish`)
- `echo $0` since it's coming from the command line, of course will be
the same as $SHELL
I suppose if we wanted to do the heuristics it'd be a better experience
for us, the bugreport receivers, to have the bugreport library collect
the heuristics and try to make a guess, rather than just dump all the
heuristics and let the humans try to remember which shell has $PS4 and
which shell has $version and so on. But to me that sounds prone to rot
at best.
- Emily
[1]: https://stackoverflow.com/a/3327022
next prev parent reply other threads:[~2020-05-13 18:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 23:42 [PATCH 0/2] bugreport: collect shell settings Emily Shaffer
2020-05-12 23:42 ` [PATCH 1/2] help: add shell-path to --build-options Emily Shaffer
2020-05-12 23:59 ` brian m. carlson
2020-05-13 5:02 ` Junio C Hamano
2020-05-13 5:10 ` Eric Sunshine
2020-05-13 18:45 ` Emily Shaffer [this message]
2020-05-12 23:42 ` [PATCH 2/2] bugreport: include user interactive shell Emily Shaffer
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=20200513184507.GA196295@google.com \
--to=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sandals@crustytoothpaste.net \
--cc=sunshine@sunshineco.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.