git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Hommey <mh@glandium.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Miles Bader <miles@gnu.org>, Junio C Hamano <gitster@pobox.com>,
	Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] grep: do not do external grep on skip-worktree entries
Date: Mon, 4 Jan 2010 07:06:46 +0100	[thread overview]
Message-ID: <20100104060646.GA14520@glandium.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1001031124420.3630@localhost.localdomain>

On Sun, Jan 03, 2010 at 11:32:24AM -0800, Linus Torvalds wrote:
> 
> 
> On Sun, 3 Jan 2010, Miles Bader wrote:
> > 
> > Since it's a general attribute of solaris that the default (/usr/bin)
> > tools are horrible sysv things and the actual useful tools are in
> > e.g. /usr/xpg4/bin, maybe it would be better to just try and add that
> > directory to the path...?
> 
> There is no generic way to make solaris sane, I'm afraid.
> 
> Everybody agrees that the "normal" Solaris tools are so horrible that they 
> all set up some alternative. However, qutie often the preferred 
> alternative is the GNU versions, mostly installed in /usr/local, and then 
> they put that first in the path.

Or /usr/sfw, where Sun themselves ship some GNU tools

> Which means that if you put /usr/xpg4/bin before other paths in your PATH, 
> you'll totally break such systems, because now you get the (inferior) 
> tools in xpg4 before the preferred tools in /usr/local. Or - this also 
> happens - people end up installing their own versions in $HOME/bin, 
> because the system admin is uncaring or incompetent.
> 
> In other words, there is no single normal or default Solaris installation 
> that we can work around. The normal/default installation is so horrible 
> that it's virtually never used in any environment where people actually 
> have shell access and do development.
> 
> Don't ask me why. EVERYBODY knows that the default /usr/bin is total crap. 
> Even Sun people know. But there's apparently some very deep-seated reason 
> (probably not technical, but mental/historical) why they can't be fixed or 
> replaced, probably relating to "make world" and the whole build system.

There is simply no explanation for these tools to be that crappy at all.
The most common reason that is given for these tools to stay as crappy as
they always have been is for backwards compatibility. But how does that
prevent from adding features is beyond me. And on the other hand, they
*do* add features to their /usr/bin tools, such as -h in (at least) df
and ls.

Anyways, why not generate the hash-bang lines of the shell scripts from a
Makefile variable that would be set to /usr/xpg4/bin/sh on Solaris and
/bin/sh on others ?

Mike

  parent reply	other threads:[~2010-01-04  6:07 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-30 14:11 [PATCH] grep: do not do external grep on skip-worktree entries Nguyễn Thái Ngọc Duy
2009-12-31  7:01 ` Junio C Hamano
2009-12-31  7:09   ` Junio C Hamano
2010-01-02 11:50     ` Nguyen Thai Ngoc Duy
2010-01-02 18:44       ` Junio C Hamano
2010-01-02 19:15         ` Nguyen Thai Ngoc Duy
2010-01-02 19:45           ` Junio C Hamano
2010-01-03  2:35             ` Miles Bader
2010-01-03  2:47               ` Miles Bader
2010-01-03  3:08                 ` Miles Bader
2010-01-03 19:32                   ` Linus Torvalds
2010-01-03 20:49                     ` Junio C Hamano
2010-01-04  5:31                       ` Jeff King
2010-01-04  5:52                         ` Junio C Hamano
2010-01-04  6:44                           ` Jeff King
2010-01-04  7:08                             ` Junio C Hamano
2010-01-04  7:14                               ` Junio C Hamano
2010-01-04  7:29                                 ` Jeff King
2010-01-04  7:26                               ` Jeff King
2010-01-04  8:09                                 ` Jeff King
2010-01-04 16:01                                   ` Linus Torvalds
2010-01-04 15:54                             ` Linus Torvalds
2010-01-04 15:57                               ` Miles Bader
2010-01-04 16:03                                 ` Linus Torvalds
2010-01-11  6:39                                   ` Junio C Hamano
2010-01-11 15:43                                     ` Linus Torvalds
2010-01-11 15:59                                       ` Linus Torvalds
2010-01-11 16:22                                         ` Junio C Hamano
2010-01-11 16:24                                           ` Junio C Hamano
2010-01-11 16:33                                           ` Linus Torvalds
2010-01-12  8:29                                             ` Junio C Hamano
2010-01-12  8:31                                               ` [PATCH] grep: lookahead optimization can be used with -L option Junio C Hamano
2010-01-12  8:32                                               ` [PATCH] grep: -L should show empty files Junio C Hamano
2010-01-12 21:27                                                 ` Sverre Rabbelier
2010-01-13  6:56                                                   ` Junio C Hamano
2010-01-13 16:04                                                     ` Sverre Rabbelier
2010-01-13 19:48                                                       ` Junio C Hamano
2010-01-13  6:48                                               ` [PATCH 1/2] grep: rip out support for external grep Junio C Hamano
2010-01-13  8:29                                                 ` Jay Soffian
2010-01-13  8:59                                                   ` Junio C Hamano
2010-01-13 15:20                                                 ` Linus Torvalds
2010-01-13  6:51                                               ` [PATCH 2/2] grep: rip out pessimization to use fixmatch() Junio C Hamano
2010-01-12 16:21                                         ` [PATCH] grep: do not do external grep on skip-worktree entries Jeff King
2010-01-11 19:26                                     ` Fredrik Kuivinen
     [not found]                                     ` <4c8ef71001111119p253170f8q37bcd3708d894a62@mail.gmail.com>
2010-01-11 19:29                                       ` Linus Torvalds
2010-01-11 19:40                                         ` Fredrik Kuivinen
2010-01-11 20:07                                           ` Linus Torvalds
2010-01-11 21:07                                             ` Fredrik Kuivinen
2010-01-11 21:24                                               ` Linus Torvalds
2010-01-04 16:24                               ` Linus Torvalds
2010-01-04 10:14                           ` Nguyen Thai Ngoc Duy
2010-01-04  6:06                     ` Mike Hommey [this message]
2010-01-04  7:04                       ` Jeff King
2010-01-04 12:34             ` [PATCH 1/2] t7002: set test prerequisite "external-grep" if supported Nguyễn Thái Ngọc Duy
2010-01-07  2:37               ` Junio C Hamano
2010-01-07  4:29                 ` Junio C Hamano
2010-01-07 13:27                   ` Nguyen Thai Ngoc Duy
2010-01-07 14:04                     ` Johannes Sixt
2010-01-07 14:26                       ` Nguyen Thai Ngoc Duy
2010-01-04 12:34             ` [PATCH 2/2] t7002: add tests for skip-worktree fixes in commit a67e281 Nguyễn Thái Ngọc Duy

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=20100104060646.GA14520@glandium.org \
    --to=mh@glandium.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=miles@gnu.org \
    --cc=pclouds@gmail.com \
    --cc=torvalds@linux-foundation.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 NNTP newsgroup(s).