git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dario Rodriguez <soft.d4rio@gmail.com>
To: Jeff King <peff@peff.net>
Cc: jrnieder@uchicago.edu, git@vger.kernel.org
Subject: Re: [PATCH/RFC] Fix for default pager
Date: Tue, 8 Jun 2010 09:24:45 -0300	[thread overview]
Message-ID: <AANLkTinxcrIV2TM966EkOC_crR0bHdNllEIdibz4gGjd@mail.gmail.com> (raw)
In-Reply-To: <20100608052929.GA15156@coredump.intra.peff.net>

On Tue, Jun 8, 2010 at 2:29 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Jun 07, 2010 at 08:58:08PM -0300, Dario Rodriguez wrote:
>
>> Default pager was 'less' even when some systems such AIX and other basic
>> or old systems do NOT have 'less' installed. In such case, git just
>> does not display anything in pager-enabled functionalities such as 'git log'
>> or 'git show', exiting with status 0.
>>
>> With this patch, git will not use DEFAULT_PAGER macro anymore, instead,
>> git will look for 'less' and 'more' in the most common paths.
>> If there is no pager, returns NULL as if it's 'cat'.
>
> Run-time pager detection seems like a reasonable goal, I guess, but...
>
>> -const char *git_pager(int stdout_is_tty)
>> +static int is_executable(const char *name)
>> +{
>> +     struct stat st;
>> +
>> +     if (stat(name, &st) ||
>> +         !S_ISREG(st.st_mode))
>> +             return 0;
>> +
>> +#ifdef WIN32
>> +{    /* cannot trust the executable bit, peek into the file instead */
>> +     char buf[3] = { 0 };
>> +     int n;
>> +     int fd = open(name, O_RDONLY);
>> +     st.st_mode &= ~S_IXUSR;
>> +     if (fd >= 0) {
>> +             n = read(fd, buf, 2);
>> +             if (n == 2)
>> +                     /* DOS executables start with "MZ" */
>> +                     if (!strcmp(buf, "#!") || !strcmp(buf, "MZ"))
>> +                             st.st_mode |= S_IXUSR;
>> +             close(fd);
>> +     }
>> +}
>> +#endif
>> +     return st.st_mode & S_IXUSR;
>> +}
>> +
>> +const char *git_pager(int stdout_is_tty)
>>  {
>> +     static const char *pager_bins[] =
>> +             { "less", "more", NULL };
>> +     static const char *common_binary_paths[] =
>> +             { "/bin/","/usr/bin/","/usr/local/bin/",NULL };
>
> ...must we really add code with such ugliness as magic PATHs and DOS
> magic numbers?
>

I copied the function 'is_executable' from 'help.c' so we already have
such code... :p

> Right now we fall back to just exec-ing "less". Could we instead just
> try to exec "less", if that fails then "more", and then finally "cat"?
>

is such a good idea but right now, 'git_pager' is not exec-ing, it's
just setting up a pager. If you set-up the pager based on wich one
fails in it's execution, you must avoid usage of this function, since
it will always return 'less' (or 'more...). What I posted is
transparent to any other function; 'git_pager' will be called
returning an existent, working pager, so the flow is the same, however
I like your proposal too, and should be considered.

> That would have almost the same effect and would be much simpler,
> wouldn't it? The exceptions I can think of are:
>
>  - we would actually run "cat" in the final case, instead of optimizing
>    it out.
>

Actually pager is being set to NULL if it's 'cat'... what's git doing
with a NULL pager?

>  - "git var GIT_PAGER" wouldn't handle this automatically
>
> -Peff
>

Blessing,
Dario

  parent reply	other threads:[~2010-06-08 12:24 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Installing on AIX fails>
2010-06-07 23:58 ` [PATCH/RFC] Fix for default pager Dario Rodriguez
2010-06-08  0:04   ` Ben Walton
2010-06-08  2:14     ` Dario Rodriguez
2010-06-08  5:35       ` Jeff King
2010-06-08 13:49         ` Dario Rodriguez
2010-06-08 14:17           ` Johannes Sixt
2010-06-08 14:39             ` Dario Rodriguez
2010-06-08 15:56               ` Johannes Sixt
2010-06-08 17:28                 ` Dario Rodriguez
2010-06-08 18:59                   ` Johannes Sixt
2010-06-08 20:44                     ` Dario Rodriguez
2010-06-08 21:33                       ` Andreas Ericsson
2010-06-09  9:08                         ` Tor Arntsen
2010-06-09  9:29                           ` Miles Bader
2010-06-10  8:29                           ` Jeff King
2010-06-10  8:48                             ` Tor Arntsen
2010-06-10  8:59                               ` Jeff King
2010-06-10  9:24                                 ` Tor Arntsen
2010-06-10 11:31                                   ` Dario Rodriguez
2010-06-10 14:55                                 ` Junio C Hamano
2010-06-15 16:11                                 ` Brandon Casey
2010-06-15 16:32                                   ` Tor Arntsen
2010-06-16  1:34                                   ` Nazri Ramliy
2010-06-16  6:28                                   ` Jeff King
2010-06-09 18:57                         ` Ævar Arnfjörð Bjarmason
2010-06-08  5:29   ` Jeff King
2010-06-08  6:12     ` Johannes Sixt
2010-06-08 12:24     ` Dario Rodriguez [this message]
2010-06-08 14:04       ` Erik Faye-Lund

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=AANLkTinxcrIV2TM966EkOC_crR0bHdNllEIdibz4gGjd@mail.gmail.com \
    --to=soft.d4rio@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@uchicago.edu \
    --cc=peff@peff.net \
    /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 NNTP newsgroup(s).