{"thread":{"id":"4173","subject":"Git 1.3.2 on Solaris","startedAt":"2006-05-16T23:52:37Z","lastAt":"2006-05-26T03:30:49Z","messageCount":36,"participants":["Stefan Pfetzing","Jason Riedy","Linus Torvalds","Ryan Anderson","Junio C Hamano","Bertrand Jacquin","Edgar Toernig"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"20095","messageId":"f3d7535d0605161652n3b2ec033r874336082755e728@mail.gmail.com","threadId":"4173","inReplyTo":null,"subject":"Git 1.3.2 on Solaris","fromName":"Stefan Pfetzing","fromEmail":"stefan.pfetzing@gmail.com","sentAt":"2006-05-16T23:52:37Z","receivedAt":"2006-05-16T23:52:37Z","isPatch":false,"sender":{"key":"stefan.pfetzing@gmail.com","avatar":null},"body":"Hi,\n\nI've been trying to get git to work on the latest Solaris Express\nrelease (with the help of NetBSD's pkgsrc).\n\nIt mostly miserabely fails because of common \"shell commands\" being\nused with GNU options. (like xargs, diff, tr and prob. some more) On\nmy box (and thats AFAIK the default when you install gnu coreutils on\nSolaris) the commands do have a g prefix.\n\nSo there are 2 possible solutions to get git working on Solaris.\n\n1. fix every single shellscript automatically during the build phase\n2. setup a dir which contains symlinks to the \"right\" binaries and\nput that dir into PATH.\n\nNo matter what solution is chosen to be the best, I'm volunteering to\ncreate a patch for it. :)\n\n(although I personally prefer the second, because its easier...)\n\nbye\n\nStefan\n-- \n http://www.dreamind.de/\nOroborus and Debian GNU/Linux Developer.\n"},{"id":"20096","messageId":"4648.1147829110@lotus.CS.Berkeley.EDU","threadId":"4173","inReplyTo":"f3d7535d0605161652n3b2ec033r874336082755e728@mail.gmail.com","subject":"Re: Git 1.3.2 on Solaris","fromName":"Jason Riedy","fromEmail":"ejr@eecs.berkeley.edu","sentAt":"2006-05-17T01:25:10Z","receivedAt":"2006-05-17T01:25:10Z","isPatch":false,"sender":{"key":"ejr@eecs.berkeley.edu","avatar":"https://gravatar.com/avatar/547fa56f887cab01599edab4e9f813c949c1269e02714f20e0496c56185d9837?d=mp&s=160"},"body":"And \"Stefan Pfetzing\" writes:\n - I've been trying to get git to work on the latest Solaris Express\n - release (with the help of NetBSD's pkgsrc).\n\nI've been using it on Solaris 8 and 9 with the GNU tools\nin pkgsrc for quite a while, as well as on AIX with the\nGNU tools available as modules (but I haven't compiled a\nnew AIX version for a month or two).\n\n - It mostly miserabely fails because of common \"shell commands\" being\n - used with GNU options. (like xargs, diff, tr and prob. some more) On\n - my box (and thats AFAIK the default when you install gnu coreutils on\n - Solaris) the commands do have a g prefix.\n\nIn your pkgsrc mk.conf, use:\nGNU_PROGRAM_PREFIX=\nGTAR_PROGRAM_PREFIX=\n\nI tried your first suggestion (patch all the commands) back\nin February. It's pretty fragile against future changes, and\nI wouldn't recommend it.\n\n - 2. setup a dir which contains symlinks to the \"right\" binaries and\n - put that dir into PATH.\n\nSetting a GIT_COMPAT_PATH in the Makefile and prepending\nit to the path in git.c and git-sh-setup.sh might be more\nsane. A fragment like the following in git.c before adding\nGIT_EXEC_PATH:\n#ifdef GIT_COMPAT_PATH\n\t/* Search for sane external utilities */\n\tprepend_to_path(GIT_COMPAT_PATH, strlen(GIT_COMPAT_PATH));\n#endif\n\nAnd maybe in git-sh-setup.sh to help those of us who\nuse git-foo rather than git foo:\nif [ ! -z \"@GIT_COMPAT_PATH@\" ] ; then\n\tPATH=\"@GIT_COMPAT_PATH@:${PATH}\"\n\texport PATH\nfi\n\nPlus Makefile fun.\n\nJason\n"},{"id":"20098","messageId":"Pine.LNX.4.64.0605161904260.16475@g5.osdl.org","threadId":"4173","inReplyTo":"f3d7535d0605161652n3b2ec033r874336082755e728@mail.gmail.com","subject":"Re: Git 1.3.2 on Solaris","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-17T02:20:30Z","receivedAt":"2006-05-17T02:20:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n[ Junio - see the \"grep\" issue ]\n\nOn Wed, 17 May 2006, Stefan Pfetzing wrote:\n> \n> So there are 2 possible solutions to get git working on Solaris.\n> \n> 1. fix every single shellscript automatically during the build phase\n> 2. setup a dir which contains symlinks to the \"right\" binaries and\n> put that dir into PATH.\n\nIf the biggest issue is git depending on some GNU extensions, I'd really \nsuggest\n (a) install all the normal GNU binaries, and put them in the path before \n git just to get it working (and don't try to change git at all)\n (b) help send in patches that just remove the dependency entirely.\n\nI've been - on and off - trying to libify most of the core git sources, so \nthat the shell scripts can be re-written to be just plain C. Most of the \ntime it's not actually even a huge amount of work, it's just somewhat \nboring.\n\nWriting them as C usually gets rid of any dependencies on any GNU tools, \nand hopefully even cygwin. For example, we got rid of one \"xargs -0\" in \nthe development branch pretty recently, thanks to making \"git grep\" a \nbuilt-in.\n\nOf course, I don't think anybody tried the new \"git grep\" on Solaris, and \nI think the solaris \"grep\" lacks the \"-H\" flag, for example. But that \nshould be easy to fix (for example, replace the use of \"--\" and \"-H\" with \nputting a \"/dev/null\" as the first filename).\n\nI don't think it's worth it trying to add some compatibility layer for the \nshell-scripts. We really do want to get rid of them, and the more people \nthat help, the merrier.\n\nIn many ways, the libification effort isn't even needed. It's perfectly ok \nto turn a stupid shell-script (and they really all _are_ pretty stupid) \ninto a builtin-cmd.c C file that just does something really easy like a \n\"fork + execve()\" translation of the original shell script.\n\nThe complete libification will take some time, and in the meantime, a few \nsilly C files that hard-code the shell logic is probably much preferable \nto using the shell and all the problems that involves (like the whole \nproblem with quoting arguments - just _gone_ when you do it as a execve() \nin a simple C program).\n\nSo anybody can help with this. If you know shell (and the git \nshell-scripts aren't even _advanced_ shell), and know some basic C, you're \nall set to do a trivial conversion from one to the other. And when the \nlibification gets further, your conversion will probably help that (ie \nmaybe libificaiton isn't complete, but a _part_ of the thing can be \nwritten to use the library interfaces instead of spawning an external \nprogram).\n\nThere aren't _that_ many shell programs, and a lot of them are really \nreally trivial (ie they parse the arguments, and then do just a couple of \nexternal git commands).\n\n\t\t\tLinus\n"},{"id":"20101","messageId":"4973.1147836384@lotus.CS.Berkeley.EDU","threadId":"4173","inReplyTo":"Pine.LNX.4.64.0605161904260.16475@g5.osdl.org","subject":"Re: Git 1.3.2 on Solaris","fromName":"Jason Riedy","fromEmail":"ejr@eecs.berkeley.edu","sentAt":"2006-05-17T03:26:24Z","receivedAt":"2006-05-17T03:26:24Z","isPatch":false,"sender":{"key":"ejr@eecs.berkeley.edu","avatar":"https://gravatar.com/avatar/547fa56f887cab01599edab4e9f813c949c1269e02714f20e0496c56185d9837?d=mp&s=160"},"body":"And Linus Torvalds writes:\n - \n - The complete libification will take some time, and in the meantime, a few \n - silly C files that hard-code the shell logic is probably much preferable \n - to using the shell and all the problems that involves (like the whole \n - problem with quoting arguments - just _gone_ when you do it as a execve() \n - in a simple C program).\n\nBut for recommending and using git on these systems _now_...\nSimply translating the shell script into C with execs doesn't\nhelp if you're execing one of the known problems, or if the\nscript has embedded, non-trivial Perl. git-clone is the major\nblocker; a trivial translation would be a great step but won't \nlet people without GNU utilities clone repos.\n\nPlus, alas, Perl modules and Python version drift can be a bit\nof a problem on the same semi-pristine (or unmaintained, or\ntoo-stable) systems, so shell isn't the only thing that needs to\ngo. And that'll take a good deal of effort.\n\nNote that my code snippets weren't a suggested patch. I wouldn't\nwant the easy way out to impede progress on the right thing.\n\nBut some local installations may find it much easier to patch git\nthan to instruct users to change their utilities to match what git\nexpects, especially if users have old scripts that would break\nif they changed their path globally. Luckily, git makes it really\neasy to keep those patches locally...\n\nJason\n"},{"id":"20102","messageId":"Pine.LNX.4.64.0605162047380.10823@g5.osdl.org","threadId":"4173","inReplyTo":"4973.1147836384@lotus.CS.Berkeley.EDU","subject":"Re: Git 1.3.2 on Solaris","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-17T03:49:54Z","receivedAt":"2006-05-17T03:49:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 16 May 2006, Jason Riedy wrote:\n> \n> But for recommending and using git on these systems _now_...\n\nYes. For that, I would literally suggest having people install the GNU \ntools (and/or a recent enough perl) somewhere early in the path.\n\nIf you use the git wrapper, for example, you can already depend on the \nfact that it will prepend the git installation directory to the path, so \nwhile the GNU tools might not _normally_ be on the path, if you put them \nin the same directory as your git install, you'll automatically get them \nas long as you use the \"git cmd\" format (rather than the \"git-cmd\" \nformat).\n\n\t\tLinus\n"},{"id":"20105","messageId":"20060517051505.GD31164@h4x0r5.com","threadId":"4173","inReplyTo":"4973.1147836384@lotus.CS.Berkeley.EDU","subject":"Re: Git 1.3.2 on Solaris","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-05-17T05:15:16Z","receivedAt":"2006-05-17T05:15:16Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Tue, May 16, 2006 at 08:26:24PM -0700, Jason Riedy wrote:\n> Plus, alas, Perl modules and Python version drift can be a bit\n> of a problem on the same semi-pristine (or unmaintained, or\n> too-stable) systems, so shell isn't the only thing that needs to\n> go. And that'll take a good deal of effort.\n\nThe Perl used in core-git is pretty forgiving of older versions of Perl,\nback to at least 5.6. (Going back to 5.005.003 is rather painful,\nhowever, to be honest.)\n\nThe only major tool I can think of that has embedded Perl in the shell\nscript is format-patch. That could probably be redone in pure Perl if\nit would help.\n"},{"id":"20109","messageId":"f3d7535d0605170105j2a6942cfh5a5a8a0d6153046f@mail.gmail.com","threadId":"4173","inReplyTo":"Pine.LNX.4.64.0605162047380.10823@g5.osdl.org","subject":"Re: Git 1.3.2 on Solaris","fromName":"Stefan Pfetzing","fromEmail":"stefan.pfetzing@gmail.com","sentAt":"2006-05-17T08:05:39Z","receivedAt":"2006-05-17T08:05:39Z","isPatch":false,"sender":{"key":"stefan.pfetzing@gmail.com","avatar":null},"body":"Hi Linus,\n\n2006/5/17, Linus Torvalds :\n>\n> On Tue, 16 May 2006, Jason Riedy wrote:\n> >\n> > But for recommending and using git on these systems _now_...\n>\n> Yes. For that, I would literally suggest having people install the GNU\n> tools (and/or a recent enough perl) somewhere early in the path.\n>\n> If you use the git wrapper, for example, you can already depend on the\n> fact that it will prepend the git installation directory to the path, so\n> while the GNU tools might not _normally_ be on the path, if you put them\n> in the same directory as your git install, you'll automatically get them\n> as long as you use the \"git cmd\" format (rather than the \"git-cmd\"\n> format).\n\nWell I guess for my pkgsrc environment this won't work.\nI already (quite some time ago) tried to have gnu coreutils, findutils and\ndiffutils installed without the g prefix.\nThis broke several things on NetBSD and on Solaris.\n\nSo I'd prefer a solution where one could set one flag for the Makefile of git,\nand git would check for the g prefix, create somewhere a directory with\nsymlinks to the \"real\" gnu binaries and put it into $PATH upon startup of\nevery git c-program or shellscript.\n\nI suggest having these gnu \"tools\" dependancies removed can only be a long\nterm goal.\n\nbye\n\ndreamind\n\nP.S.: I had to re-sent this mail, somehow gmail did put html crap into it.\n--\n http://www.dreamind.de/\nOroborus and Debian GNU/Linux Developer.\n"},{"id":"20112","messageId":"7vwtclhxgg.fsf@assigned-by-dhcp.cox.net","threadId":"4173","inReplyTo":"20060517051505.GD31164@h4x0r5.com","subject":"Re: Git 1.3.2 on Solaris","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-17T08:22:55Z","receivedAt":"2006-05-17T08:22:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ryan Anderson writes:\n\n> The only major tool I can think of that has embedded Perl in the shell\n> script is format-patch. That could probably be redone in pure Perl if\n> it would help.\n\nActually, that one is in the process of migrating all C.\n"},{"id":"20114","messageId":"7vpsidhx79.fsf@assigned-by-dhcp.cox.net","threadId":"4173","inReplyTo":"f3d7535d0605161652n3b2ec033r874336082755e728@mail.gmail.com","subject":"Re: Git 1.3.2 on Solaris","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-17T08:28:26Z","receivedAt":"2006-05-17T08:28:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Stefan Pfetzing\" writes:\n\n> 1. fix every single shellscript automatically during the build phase\n> 2. setup a dir which contains symlinks to the \"right\" binaries and\n> put that dir into PATH.\n\nYou forgot 3.\n\n 3. rewrite scripts so that they would require only POSIX;\n for ones that do need GNU extended coreutils to do in\n shell, find other ways, perhaps rewriting the stuff in C.\n\nI am not looking forward to do the g- prefix in the main\nMakefile. The approach to have symlink forest under gitexecdir\n( by Linus) is\nmore palatable, and I am not opposed to host a script to do so\nunder contrib/notgnu perhaps.\n"},{"id":"20117","messageId":"7vejythvkr.fsf@assigned-by-dhcp.cox.net","threadId":"4173","inReplyTo":"Pine.LNX.4.64.0605161904260.16475@g5.osdl.org","subject":"Re: Git 1.3.2 on Solaris","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-17T09:03:32Z","receivedAt":"2006-05-17T09:03:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> [ Junio - see the \"grep\" issue ]\n> ...\n> Of course, I don't think anybody tried the new \"git grep\" on Solaris,...\n\nI haven't tried the new grep on Solaris myself, as the Solaris\nbox I have easy access is badly maintained (unmaintained is\nprobably a better wording).\n\n> ...and \n> I think the solaris \"grep\" lacks the \"-H\" flag, for example. But that \n> should be easy to fix (for example, replace the use of \"--\" and \"-H\" with \n> putting a \"/dev/null\" as the first filename).\n\nYou mean like this, I presume.\n\nBut I think this approach breaks -L; I do not think Solaris\nsupports -L, so it does not matter there, but on platforms that\nknows how to do -L it does.\n\n-- >8 --\n[PATCH] builtin-grep: give /dev/null at the beginning instead of -H\n\n---\ndiff --git a/builtin-grep.c b/builtin-grep.c\nindex 66111de..ff3c1f7 100644\n--- a/builtin-grep.c\n+++ b/builtin-grep.c\n@@ -453,7 +453,6 @@ static int external_grep(struct grep_opt\n \n \tlen = nr = 0;\n \tpush_arg(\"grep\");\n-\tpush_arg(\"-H\");\n \tif (opt->fixed)\n \t\tpush_arg(\"-F\");\n \tif (opt->linenum)\n@@ -503,7 +502,7 @@ static int external_grep(struct grep_opt\n \t\tpush_arg(\"-e\");\n \t\tpush_arg(p->pattern);\n \t}\n-\tpush_arg(\"--\");\n+\tpush_arg(\"/dev/null\");\n \n \thit = 0;\n \targc = nr;\n"},{"id":"20118","messageId":"f3d7535d0605170206y76e24f25w305a688d32f4a0a1@mail.gmail.com","threadId":"4173","inReplyTo":"7vpsidhx79.fsf@assigned-by-dhcp.cox.net","subject":"Re: Git 1.3.2 on Solaris","fromName":"Stefan Pfetzing","fromEmail":"stefan.pfetzing@gmail.com","sentAt":"2006-05-17T09:06:34Z","receivedAt":"2006-05-17T09:06:34Z","isPatch":false,"sender":{"key":"stefan.pfetzing@gmail.com","avatar":null},"body":"Hi Junio,\n\n2006/5/17, Junio C Hamano :\n> \"Stefan Pfetzing\" writes:\n>\n> > 1. fix every single shellscript automatically during the build phase\n> > 2. setup a dir which contains symlinks to the \"right\" binaries and\n> > put that dir into PATH.\n>\n> You forgot 3.\n>\n> 3. rewrite scripts so that they would require only POSIX;\n> for ones that do need GNU extended coreutils to do in\n> shell, find other ways, perhaps rewriting the stuff in C.\n\nYes, thats right, but this can only be a long term goal, because I guess\nthis will take significantly longer. - even \"tr\" and \"diff\" behave different\non Solaris.\n\n> I am not looking forward to do the g- prefix in the main\n> Makefile. The approach to have symlink forest under gitexecdir\n> ( by Linus) is\n> more palatable, and I am not opposed to host a script to do so\n> under contrib/notgnu perhaps.\n\nHm, gitexecdir is also the path where git is installed, right? So if I'd\ninstall git with pkgsrc it will be /usr/pkg/bin, right? - If so,\nputting symlinks\nthere _will_ break pkgsrc.\n\nbye\n\nStefan\n-- \n http://www.dreamind.de/\nOroborus and Debian GNU/Linux Developer.\n"},{"id":"20119","messageId":"7v7j4lhup3.fsf@assigned-by-dhcp.cox.net","threadId":"4173","inReplyTo":"f3d7535d0605170206y76e24f25w305a688d32f4a0a1@mail.gmail.com","subject":"Re: Git 1.3.2 on Solaris","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-17T09:22:32Z","receivedAt":"2006-05-17T09:22:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Stefan Pfetzing\" writes:\n\n> Hm, gitexecdir is also the path where git is installed, right? So if I'd\n> install git with pkgsrc it will be /usr/pkg/bin, right? - If so,\n> putting symlinks\n> there _will_ break pkgsrc.\n\nIf you look at our Makefile, you will see bindir does not have\nto be gitexecdir. The suggestion by Linus is that you set\nbindir to /usr/local/bin or whereever your distribution's\npackaging scheme wants the locally installed software to be that\nis on user's PATH, and gitexecdir to /usr/local/libexec/git\n(again, whereever), _and_ have:\n\n\tln -s /usr/bin/gtr /usr/local/libexec/git/tr\n\tln -s /usr/bin/gxargs /usr/local/libexec/git/xargs\n ...\n\nThen:\n\n\t(1) git and gitk are available in /usr/local/bin;\n\n (2) while git and gitk runs, /usr/local/libexec/git will\n be prepended to the PATH, so when they want xargs,\n they will get gxargs;\n\n (3) but your users will _not_ have /usr/local/libexec/git\n on their PATH, so when they type xargs they will get\n the one that barfs on -0 option.\n\nand train your users and user's scripts to use the officially\nsanctioned way to refer to git subprograms. From interactive\nsessions, say \"git foo\", not \"git-foo\". If your script _really_\ncares about extra exec git wrapper does, use \"git --exec-path\"\nupfront in the script to obtain correct gitexecpath, export\nGIT_EXEC_PATH environment variable with that value, and prepend\nit to PATH so that it can find \"git-foo\" executable (you would\nprobably need to do both, so that git-foo can find git-bar and\nits friends).\n\n\n\t\n"},{"id":"20122","messageId":"7vves5geng.fsf_-_@assigned-by-dhcp.cox.net","threadId":"4173","inReplyTo":"7vejythvkr.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] builtin-grep: workaround for non GNU grep.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-17T09:54:27Z","receivedAt":"2006-05-17T09:54:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Some implementations do not know what to do with -H; define\nNO_H_OPTION_IN_GREP when you build git if your grep lacks -H.\n\nMost of the time, it can be worked around by prepending\n/dev/null to the argument list, but that causes -L and -c to\nslightly misbehave (they both expose /dev/null is given), so\nwhen these options are given, do not run external grep that does\nnot understand -H.\n\nSigned-off-by: Junio C Hamano \n---\n\n Junio C Hamano writes:\n\n > But I think this approach breaks -L; I do not think Solaris\n > supports -L, so it does not matter there, but on platforms that\n > knows how to do -L it does.\n\n So this is an updated version. I am not proud of the handling\n of the new Makefile variable, although I like the C code that\n does not need #ifdef thanks to it.\n\n Makefile | 11 +++++++++++\n builtin-grep.c | 22 +++++++++++++++++++---\n 2 files changed, 30 insertions(+), 3 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 9ba608c..c67108d 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -46,6 +46,8 @@ # Patrick Mauritz).\n #\n # Define NO_MMAP if you want to avoid mmap.\n #\n+# Define NO_H_OPTION_IN_GREP if your grep does not understand -H.\n+#\n # Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3.\n #\n # Define NO_IPV6 if you lack IPv6 support and getaddrinfo().\n@@ -444,6 +446,12 @@ ifdef NO_ACCURATE_DIFF\n \tALL_CFLAGS += -DNO_ACCURATE_DIFF\n endif\n \n+ifdef NO_H_OPTION_IN_GREP\n+\tNO_H_OPTION_IN_GREP=1\n+else\n+\tNO_H_OPTION_IN_GREP=0\n+endif\n+\n # Shell quote (do not use $(call) to accomodate ancient setups);\n \n SHA1_HEADER_SQ = $(subst ','\\'',$(SHA1_HEADER))\n@@ -526,6 +534,9 @@ git$X git.spec \\\n %.o: %.S\n \t$(CC) -o $*.o -c $(ALL_CFLAGS) $<\n \n+builtin-grep.o: builtin-grep.c\n+\t$(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_H_OPTION_IN_GREP=$(NO_H_OPTION_IN_GREP) $<\n+\n exec_cmd.o: exec_cmd.c\n \t$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH=\"$(gitexecdir_SQ)\"' $<\n \ndiff --git a/builtin-grep.c b/builtin-grep.c\nindex 66111de..36512d8 100644\n--- a/builtin-grep.c\n+++ b/builtin-grep.c\n@@ -453,7 +453,6 @@ static int external_grep(struct grep_opt\n \n \tlen = nr = 0;\n \tpush_arg(\"grep\");\n-\tpush_arg(\"-H\");\n \tif (opt->fixed)\n \t\tpush_arg(\"-F\");\n \tif (opt->linenum)\n@@ -503,7 +502,13 @@ static int external_grep(struct grep_opt\n \t\tpush_arg(\"-e\");\n \t\tpush_arg(p->pattern);\n \t}\n-\tpush_arg(\"--\");\n+\n+\tif (NO_H_OPTION_IN_GREP)\n+\t\tpush_arg(\"/dev/null\");\n+\telse {\n+\t\tpush_arg(\"-H\");\n+\t\tpush_arg(\"--\");\n+\t}\n \n \thit = 0;\n \targc = nr;\n@@ -535,8 +540,19 @@ #ifdef __unix__\n \t * Use the external \"grep\" command for the case where\n \t * we grep through the checked-out files. It tends to\n \t * be a lot more optimized\n+\t *\n+\t * Some grep implementations do not understand -H nor --\n+\t * but /dev/null can be used as a substitution in most\n+\t * cases.\n+\t *\n+\t * However -L and -c would slightly misbehave (-L would\n+\t * list /dev/null as a hit, and -c would report 0 hits\n+\t * from /dev/null); so do not use the external one on\n+\t * such platforms.\n \t */\n-\tif (!cached) {\n+\tif (!cached &&\n+\t (!NO_H_OPTION_IN_GREP ||\n+\t (!opt->count && !opt->unmatch_name_only))) {\n \t\thit = external_grep(opt, paths, cached);\n \t\tif (hit >= 0)\n \t\t\treturn hit;\n-- \n1.3.3.g8a24\n"},{"id":"20128","messageId":"f3d7535d0605170341n1a68de90g4deeb3f17a7d9432@mail.gmail.com","threadId":"4173","inReplyTo":"7v7j4lhup3.fsf@assigned-by-dhcp.cox.net","subject":"Re: Git 1.3.2 on Solaris","fromName":"Stefan Pfetzing","fromEmail":"stefan.pfetzing@gmail.com","sentAt":"2006-05-17T10:41:39Z","receivedAt":"2006-05-17T10:41:39Z","isPatch":false,"sender":{"key":"stefan.pfetzing@gmail.com","avatar":null},"body":"Hi Junio,\n\n2006/5/17, Junio C Hamano :\n> If you look at our Makefile, you will see bindir does not have\n> to be gitexecdir. The suggestion by Linus is that you set\n> bindir to /usr/local/bin or whereever your distribution's\n> packaging scheme wants the locally installed software to be that\n> is on user's PATH, and gitexecdir to /usr/local/libexec/git\n> (again, whereever), _and_ have:\n>\n> ln -s /usr/bin/gtr /usr/local/libexec/git/tr\n> ln -s /usr/bin/gxargs /usr/local/libexec/git/xargs\n> ...\n\nNice, that looks like a solution, but will this also \"fix\" the tr usage for\nthe git tests? If so, I'll write a small shellscript to create the links and\nso on, and test it on Solaris later today.\n\nbye\n\ndreamind\n-- \n http://www.dreamind.de/\nOroborus and Debian GNU/Linux Developer.\n"},{"id":"20143","messageId":"Pine.LNX.4.64.0605170722590.10823@g5.osdl.org","threadId":"4173","inReplyTo":"7vves5geng.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] builtin-grep: workaround for non GNU grep.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-17T14:24:04Z","receivedAt":"2006-05-17T14:24:04Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nNo, please don't do it this way.\n\nOn Wed, 17 May 2006, Junio C Hamano wrote:\n>\n> +\t * Some grep implementations do not understand -H nor --\n> +\t * but /dev/null can be used as a substitution in most\n> +\t * cases.\n> +\t *\n> +\t * However -L and -c would slightly misbehave (-L would\n> +\t * list /dev/null as a hit, and -c would report 0 hits\n> +\t * from /dev/null); so do not use the external one on\n> +\t * such platforms.\n> \t */\n> -\tif (!cached) {\n> +\tif (!cached &&\n> +\t (!NO_H_OPTION_IN_GREP ||\n> +\t (!opt->count && !opt->unmatch_name_only))) {\n> \t\thit = external_grep(opt, paths, cached);\n> \t\tif (hit >= 0)\n> \t\t\treturn hit;\n\nThat's the ugliest test ever, and at all the wrong levels.\n\nJust make \"external_grep()\" test for the cases that it cannot handle, and \nreturn -1. That's how it's designed to work.\n\n\t\tLinus\n"},{"id":"20145","messageId":"Pine.LNX.4.64.0605170728520.10823@g5.osdl.org","threadId":"4173","inReplyTo":"f3d7535d0605170105j2a6942cfh5a5a8a0d6153046f@mail.gmail.com","subject":"Re: Git 1.3.2 on Solaris","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-17T14:33:40Z","receivedAt":"2006-05-17T14:33:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 May 2006, Stefan Pfetzing wrote:\n> \n> So I'd prefer a solution where one could set one flag for the Makefile of git,\n> and git would check for the g prefix, create somewhere a directory with\n> symlinks to the \"real\" gnu binaries and put it into $PATH upon startup of\n> every git c-program or shellscript.\n\nSo let me just quote the thing you quoted but apparently didn't read:\n\n> > If you use the git wrapper, for example, you can already depend on the\n> > fact that it will prepend the git installation directory to the path, so\n> > while the GNU tools might not _normally_ be on the path, if you put them\n> > in the same directory as your git install, you'll automatically get them\n> > as long as you use the \"git cmd\" format (rather than the \"git-cmd\"\n> > format).\n\nThere already _is_ such a directory. It's your \"prefix=\" directory plus \n\"bin\".\n\nSo what you can do is make sure you compile with\n\n\tmake prefix=/my/git/installation/prefix\n\nand then install the GNU tools in /my/git/installation/prefix/bin, and \nyou're all set.\n\nAt most you might have to make some of the tests use \"git xyzzy\" instead \nof \"git-xyzzy\", and run \"make install\" before \"make test\". \n\nIt wouldn't be wonderful, but hey, I've given alternatives (like using the \nGNU tools by default, or helping make git more portable in the first \nplace). So it's a hack. \n\n\t\tLinus\n"},{"id":"20149","messageId":"f3d7535d0605170808l21d9f6d0gff1afaa10db17af9@mail.gmail.com","threadId":"4173","inReplyTo":"Pine.LNX.4.64.0605170728520.10823@g5.osdl.org","subject":"Re: Git 1.3.2 on Solaris","fromName":"Stefan Pfetzing","fromEmail":"stefan.pfetzing@gmail.com","sentAt":"2006-05-17T15:08:48Z","receivedAt":"2006-05-17T15:08:48Z","isPatch":false,"sender":{"key":"stefan.pfetzing@gmail.com","avatar":null},"body":"Hi Linus,\n\n2006/5/17, Linus Torvalds :\n>\n> So let me just quote the thing you quoted but apparently didn't read:\n\n[snip]\n\nI did read that.\n\n> There already _is_ such a directory. It's your \"prefix=\" directory plus\n> \"bin\".\n>\n> So what you can do is make sure you compile with\n>\n> make prefix=/my/git/installation/prefix\n>\n> and then install the GNU tools in /my/git/installation/prefix/bin, and\n> you're all set.\n\nOk, if I would do so, my prefix would be /usr/pkg, and the bindir would be\n/usr/pkg/bin. So I would need to have an xargs and so on symlink in\n/usr/pkg/bin.\nBut this is simply not acceptable, because it breaks other NetBSD\npkgsrc scripts.\n\nBesides that, installing git to a different location is not an option\nfor me, because\nI want to have git packaged by pkgsrc.\n\nI suggest Junio's solution will work (gitexecdir) but I have to try\nthat later today.\n\n> At most you might have to make some of the tests use \"git xyzzy\" instead\n> of \"git-xyzzy\", and run \"make install\" before \"make test\".\n>\n> It wouldn't be wonderful, but hey, I've given alternatives (like using the\n> GNU tools by default, or helping make git more portable in the first\n> place). So it's a hack.\n\nYes I know, as far as I can, I'm willing to help with this.\n\nbye\n\ndreamind\n\n-- \n http://www.dreamind.de/\nOroborus and Debian GNU/Linux Developer.\n"},{"id":"20151","messageId":"4fb292fa0605170839r259732dcw1c1bae3f1808db32@mail.gmail.com","threadId":"4173","inReplyTo":"7vves5geng.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] builtin-grep: workaround for non GNU grep.","fromName":"Bertrand Jacquin","fromEmail":"beber.mailing@gmail.com","sentAt":"2006-05-17T15:39:26Z","receivedAt":"2006-05-17T15:39:26Z","isPatch":true,"sender":{"key":"beber.mailing@gmail.com","avatar":null},"body":"On 5/17/06, Junio C Hamano wrote:\n\n> +ifdef NO_H_OPTION_IN_GREP\n> + NO_H_OPTION_IN_GREP=1\n> +else\n> + NO_H_OPTION_IN_GREP=0\n> +endif\n\n> + if (NO_H_OPTION_IN_GREP)\n> + push_arg(\"/dev/null\");\n> + else {\n> + push_arg(\"-H\");\n> + push_arg(\"--\");\n> + }\n\nSorry, maybe a C code beginner question but while you define\nNO_H_OPTION_IN_GREP in Makefile, why don't use a build time ``if''\ninstead of a runtime one ?\n\nLike :\n\n#if NO_H_OPTION_IN_GREP\n push_arg(\"/dev/null\");\n#else\n push_arg(\"-H\");\n push_arg(\"--\");\n#fi\n\n-- \nBeber\n#e.fr@freenode\n"},{"id":"20154","messageId":"Pine.LNX.4.64.0605170919290.10823@g5.osdl.org","threadId":"4173","inReplyTo":"f3d7535d0605170808l21d9f6d0gff1afaa10db17af9@mail.gmail.com","subject":"Re: Git 1.3.2 on Solaris","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-17T16:24:01Z","receivedAt":"2006-05-17T16:24:01Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 May 2006, Stefan Pfetzing wrote:\n> \n> Ok, if I would do so, my prefix would be /usr/pkg, and the bindir would be\n> /usr/pkg/bin. So I would need to have an xargs and so on symlink in\n> /usr/pkg/bin.\n> But this is simply not acceptable, because it breaks other NetBSD\n> pkgsrc scripts.\n\nDON'T USE /usr/pkg then.\n\nUse /usr/pkg/git-core/share/ or something that is normally not on your \npath.\n\nAnd then install _just_ the \"git\" binary in /usr/pkg/bin.\n\nThat must be allowable by whatever solaris packaging rules: it's not like \nother projects don't have their own internal library files.\n\nThen you install the GNU symlinks under that same\n\n\t/usr/pkg/git-core/share/bin\n\nand you're all set. The only binary you can _see_ is \"git\", and when that \nexecutes any scripts or other git binaries, it will set up the path to \ninclude that magic hidden directory.\n\n> Besides that, installing git to a different location is not an option\n> for me, because I want to have git packaged by pkgsrc.\n\nNow, I'm told pkgsrc is horrible, but it can't be so horrid as to not \nallow private directories?\n\n\t\tLinus\n"},{"id":"20156","messageId":"6471.1147883724@lotus.CS.Berkeley.EDU","threadId":"4173","inReplyTo":"Pine.LNX.4.64.0605170919290.10823@g5.osdl.org","subject":"Re: Git 1.3.2 on Solaris","fromName":"Jason Riedy","fromEmail":"ejr@eecs.berkeley.edu","sentAt":"2006-05-17T16:35:24Z","receivedAt":"2006-05-17T16:35:24Z","isPatch":false,"sender":{"key":"ejr@eecs.berkeley.edu","avatar":"https://gravatar.com/avatar/547fa56f887cab01599edab4e9f813c949c1269e02714f20e0496c56185d9837?d=mp&s=160"},"body":"And Linus Torvalds writes:\n - \n - Now, I'm told pkgsrc is horrible, but it can't be so horrid as to not \n - allow private directories?\n\nWorks fine.\n 1) Depend on the GNU tools through the buildlink, um, stuff.\n 2) Add a config.mak via a local patch that sets gitexecprefix.\n 3) Add another local patch that sets up links within that\n gitexecprefix to the GNU tools. Remember to check if the\n GNU tools were installed without the silly g prefix.\n\nAnd pkgsrc itself works just fine without the silly g prefix,\nor at least does for me as a mere user (and as well as it does\nwork). But if you intend on adding the package upstream, it'll\nneed something to cope with the g. And pkgsrc handles local\npatches...\n\nJason\n"},{"id":"20157","messageId":"7vlkt0ft0x.fsf@assigned-by-dhcp.cox.net","threadId":"4173","inReplyTo":"Pine.LNX.4.64.0605170722590.10823@g5.osdl.org","subject":"Re: [PATCH] builtin-grep: workaround for non GNU grep.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-17T17:41:34Z","receivedAt":"2006-05-17T17:41:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n>> -\tif (!cached) {\n>> +\tif (!cached &&\n>> +\t (!NO_H_OPTION_IN_GREP ||\n>> +\t (!opt->count && !opt->unmatch_name_only))) {\n>> \t\thit = external_grep(opt, paths, cached);\n>> \t\tif (hit >= 0)\n>> \t\t\treturn hit;\n>\n> That's the ugliest test ever, and at all the wrong levels.\n>\n> Just make \"external_grep()\" test for the cases that it cannot handle, and \n> return -1. That's how it's designed to work.\n\nAh.... *BLUSH* I was not thinking when I saw that \"if (hit >= 0)\"\nstuff. Yes, you made it to fall back.\n"},{"id":"20158","messageId":"7vhd3ofsyv.fsf@assigned-by-dhcp.cox.net","threadId":"4173","inReplyTo":"4fb292fa0605170839r259732dcw1c1bae3f1808db32@mail.gmail.com","subject":"Re: [PATCH] builtin-grep: workaround for non GNU grep.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-17T17:42:48Z","receivedAt":"2006-05-17T17:42:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Bertrand Jacquin\" writes:\n\n> Sorry, maybe a C code beginner question but while you define\n> NO_H_OPTION_IN_GREP in Makefile, why don't use a build time ``if''\n> instead of a runtime one ?\n>\n> Like :\n>\n> #if NO_H_OPTION_IN_GREP\n> push_arg(\"/dev/null\");\n> #else\n> push_arg(\"-H\");\n> push_arg(\"--\");\n> #fi\n\nExactly because I wanted to avoid conditional compilation using\nC preprocessor directive (#if).\n"},{"id":"20159","messageId":"Pine.LNX.4.64.0605171109170.10823@g5.osdl.org","threadId":"4173","inReplyTo":"7vhd3ofsyv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] builtin-grep: workaround for non GNU grep.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-17T18:12:22Z","receivedAt":"2006-05-17T18:12:22Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 May 2006, Junio C Hamano wrote:\n>\n> \"Bertrand Jacquin\" writes:\n> >\n> > #if NO_H_OPTION_IN_GREP\n> > push_arg(\"/dev/null\");\n> > #else\n> > push_arg(\"-H\");\n> > push_arg(\"--\");\n> > #fi\n> \n> Exactly because I wanted to avoid conditional compilation using\n> C preprocessor directive (#if).\n\nI think this is portable and correct.\n\nOf course, it still ignores the fact that not all grep's support some of \nthe flags like -F/-L/-A/-C etc, but for those cases, the external grep \nitself will happily just say \"unrecognized option -F\" or similar.\n\nSo with this change, \"git grep\" should handle all the flags the native \ngrep handles, which is really quite fine. We don't _need_ to expose \nanything more, and if you do want our extensions, you can get them with \n\"--uncached\" and an up-to-date index.\n\nNo configuration necessary, and we automatically take advantage of any \nnative grep we have, if possible.\n\n\t\tLinus\n\n---\ndiff --git a/builtin-grep.c b/builtin-grep.c\nindex 66111de..d09ddf0 100644\n--- a/builtin-grep.c\n+++ b/builtin-grep.c\n@@ -453,7 +453,6 @@ static int external_grep(struct grep_opt\n \n \tlen = nr = 0;\n \tpush_arg(\"grep\");\n-\tpush_arg(\"-H\");\n \tif (opt->fixed)\n \t\tpush_arg(\"-F\");\n \tif (opt->linenum)\n@@ -503,17 +502,35 @@ static int external_grep(struct grep_opt\n \t\tpush_arg(\"-e\");\n \t\tpush_arg(p->pattern);\n \t}\n-\tpush_arg(\"--\");\n+\n+\t/*\n+\t * To make sure we get the header printed out when we want it,\n+\t * add /dev/null to the paths to grep. This is unnecessary\n+\t * (and wrong) with \"-l\" or \"-L\", which always print out the\n+\t * name anyway.\n+\t *\n+\t * GNU grep has \"-H\", but this is portable.\n+\t */\n+\tif (!opt->name_only && !opt->unmatch_name_only)\n+\t\tpush_arg(\"/dev/null\");\n \n \thit = 0;\n \targc = nr;\n \tfor (i = 0; i < active_nr; i++) {\n \t\tstruct cache_entry *ce = active_cache[i];\n+\t\tconst char *name;\n \t\tif (ce_stage(ce) || !S_ISREG(ntohl(ce->ce_mode)))\n \t\t\tcontinue;\n \t\tif (!pathspec_matches(paths, ce->name))\n \t\t\tcontinue;\n-\t\targv[argc++] = ce->name;\n+\t\tname = ce->name;\n+\t\tif (name[0] == '-') {\n+\t\t\tint len = ce_namelen(ce);\n+\t\t\tname = xmalloc(len + 3);\n+\t\t\tmemcpy(name, \"./\", 2);\n+\t\t\tmemcpy(name + 2, ce->name, len + 1);\n+\t\t}\n+\t\targv[argc++] = name;\n \t\tif (argc < MAXARGS)\n \t\t\tcontinue;\n \t\thit += exec_grep(argc, argv);\n"},{"id":"20167","messageId":"7vodxwcwa1.fsf@assigned-by-dhcp.cox.net","threadId":"4173","inReplyTo":"Pine.LNX.4.64.0605171109170.10823@g5.osdl.org","subject":"Re: [PATCH] builtin-grep: workaround for non GNU grep.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-17T18:59:34Z","receivedAt":"2006-05-17T18:59:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> I think this is portable and correct.\n>\n> Of course, it still ignores the fact that not all grep's support some of \n> the flags like -F/-L/-A/-C etc, but for those cases, the external grep \n> itself will happily just say \"unrecognized option -F\" or similar.\n>\n> So with this change, \"git grep\" should handle all the flags the native \n> grep handles, which is really quite fine. We don't _need_ to expose \n> anything more, and if you do want our extensions, you can get them with \n> \"--uncached\" and an up-to-date index.\n>\n> No configuration necessary, and we automatically take advantage of any \n> native grep we have, if possible.\n\nThis makes -c misbehave in a subtle way.\n\n\tgit grep -c -e no-such-string-anywhere | head -n 1\n\nBut I do not think we care.\n"},{"id":"20175","messageId":"Pine.LNX.4.64.0605171239420.10823@g5.osdl.org","threadId":"4173","inReplyTo":"7vodxwcwa1.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] builtin-grep: workaround for non GNU grep.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-17T19:42:53Z","receivedAt":"2006-05-17T19:42:53Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 May 2006, Junio C Hamano wrote:\n> \n> This makes -c misbehave in a subtle way.\n> \n> \tgit grep -c -e no-such-string-anywhere | head -n 1\n> \n> But I do not think we care.\n\nAhh, yes. That appears to be unfixable without using special GNU \nextensions.\n\nI agree that we probably don't care, though.\n\n\t\tLinus\n"},{"id":"20506","messageId":"f3d7535d0605222020j2d581bd9j602752659a4b3ac2@mail.gmail.com","threadId":"4173","inReplyTo":"6471.1147883724@lotus.CS.Berkeley.EDU","subject":"Re: Git 1.3.2 on Solaris","fromName":"Stefan Pfetzing","fromEmail":"stefan.pfetzing@gmail.com","sentAt":"2006-05-23T03:20:41Z","receivedAt":"2006-05-23T03:20:41Z","isPatch":false,"sender":{"key":"stefan.pfetzing@gmail.com","avatar":null},"body":"Hi Jason,\n\n2006/5/17, Jason Riedy :\n> And pkgsrc itself works just fine without the silly g prefix,\n> or at least does for me as a mere user (and as well as it does\n> work). But if you intend on adding the package upstream, it'll\n> need something to cope with the g. And pkgsrc handles local\n> patches...\n\nWell I had some problems on NetBSD without the g prefix for the\ngnu coreutils - since then I always used that prefix.\n\nBut now I have a completely different problem with the tests on\nsolaris. It seems on solaris access() always returns 0 if a file is\nexistant and the effective uid is 0.\n\nso:\n--- snip ---\n#include \n#include \n\nint\nmain (int argc, char **argv)\n{\n printf (\"access: %d\\n\", access(\"/etc/motd\", X_OK));\n return 0;\n}\n--- snap ---\n\nwill return 0 on solaris - when run as root, even though /etc/motd\nis not executeable. This seems to break hooks on Solaris - but\nI'm not sure if this is only a Solaris Express bug. (I have no Solaris\n10 system to verify it)\n\nbye\n\nStefan\n\n-- \n http://www.dreamind.de/\nOroborus and Debian GNU/Linux Developer.\n"},{"id":"20507","messageId":"8157.1148359875@lotus.CS.Berkeley.EDU","threadId":"4173","inReplyTo":"f3d7535d0605222020j2d581bd9j602752659a4b3ac2@mail.gmail.com","subject":"Re: Git 1.3.2 on Solaris","fromName":"Jason Riedy","fromEmail":"ejr@eecs.berkeley.edu","sentAt":"2006-05-23T04:51:15Z","receivedAt":"2006-05-23T04:51:15Z","isPatch":false,"sender":{"key":"ejr@eecs.berkeley.edu","avatar":"https://gravatar.com/avatar/547fa56f887cab01599edab4e9f813c949c1269e02714f20e0496c56185d9837?d=mp&s=160"},"body":"And \"Stefan Pfetzing\" writes:\n - printf (\"access: %d\\n\", access(\"/etc/motd\", X_OK));\n[...]\n - will return 0 on solaris - when run as root, even though /etc/motd\n - is not executeable.\n\nThis is explicitly allowed by the SUS, even for non-root:\n http://www.opengroup.org/onlinepubs/000095399/functions/access.html\nFor non-root, some ACL systems could allow you to execute\nthe file even if there are no execute bits. What a joy\nACLs are. Or NFS uid mappings could play tricks on you,\nor... And as you've noticed, this kills [ -x ]. (Failing\nto run the hooks in receive-pack.c is noisy but not fatal.\nIt's the shell scripts that stop.)\n\nI think you're stuck. To disable the hooks for all possible\nusers, OSes, file systems, etc., you need to remove them.\n\nOr just don't run as root, and hope that the OS isn't \ncompletely insane.\n\nBTW, ERR_RUN_COMMAND_EXEC is never returned. Any failure\nto exec will produce an exit code of 128 from die. This\nwill be an issue when commit becomes a built-in, right?\n\nJason\n"},{"id":"20534","messageId":"f3d7535d0605230504k51b5fc47yc75cf559cb1cc87b@mail.gmail.com","threadId":"4173","inReplyTo":"8157.1148359875@lotus.CS.Berkeley.EDU","subject":"Re: Git 1.3.2 on Solaris","fromName":"Stefan Pfetzing","fromEmail":"stefan.pfetzing@gmail.com","sentAt":"2006-05-23T12:04:59Z","receivedAt":"2006-05-23T12:04:59Z","isPatch":false,"sender":{"key":"stefan.pfetzing@gmail.com","avatar":null},"body":"Hi Jason,\n\n2006/5/23, Jason Riedy :\n> This is explicitly allowed by the SUS, even for non-root:\n> http://www.opengroup.org/onlinepubs/000095399/functions/access.html\n> For non-root, some ACL systems could allow you to execute\n> the file even if there are no execute bits. What a joy\n> ACLs are. Or NFS uid mappings could play tricks on you,\n> or... And as you've noticed, this kills [ -x ]. (Failing\n> to run the hooks in receive-pack.c is noisy but not fatal.\n> It's the shell scripts that stop.)\n\nYup, but this breaks test t5400 - I think because of the post-update\nhook is failing.\n\n> I think you're stuck. To disable the hooks for all possible\n> users, OSes, file systems, etc., you need to remove them.\n>\n> Or just don't run as root, and hope that the OS isn't\n> completely insane.\n\nAs non-root it works fine.\n\n> BTW, ERR_RUN_COMMAND_EXEC is never returned. Any failure\n> to exec will produce an exit code of 128 from die. This\n> will be an issue when commit becomes a built-in, right?\n\nThink so.\n\nbye\n\nStefan\n\n-- \n http://www.dreamind.de/\nOroborus and Debian GNU/Linux Developer.\n"},{"id":"20549","messageId":"Pine.LNX.4.64.0605230744350.5623@g5.osdl.org","threadId":"4173","inReplyTo":"8157.1148359875@lotus.CS.Berkeley.EDU","subject":"Re: Git 1.3.2 on Solaris","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-23T14:53:55Z","receivedAt":"2006-05-23T14:53:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 22 May 2006, Jason Riedy wrote:\n\n> And \"Stefan Pfetzing\" writes:\n> - printf (\"access: %d\\n\", access(\"/etc/motd\", X_OK));\n> [...]\n> - will return 0 on solaris - when run as root, even though /etc/motd\n> - is not executeable.\n> \n> This is explicitly allowed by the SUS, even for non-root:\n\nWhat kind of CRAP has Solaris become?\n\nYes, it's allowed. That doesn't mean that a quality implementation should \ndo it.\n\nSunOS used to be the best system around - it was, compared to others, \n_nice_ to work with. It wasn't about what was \"allowed by the standards\", \nthat was the HP-SUX and AIX's excuses. It was the highest-quality \nimplementation.\n\nNow, Solaris had some serious problems early on (yes, I was there when \nthey switched, and yes, I hated it), but I thought they had fixed their \nstuff long long ago.\n\nHave Sun people forgotten the difference between \"quality\" and \"crap that \npasses standards tests\"? \n\nNot doing a reasonable job on \"access()\" is a joke. It's like VMS being \n\"posix\". Sure, it's the letter of the law, but it's still not _unix_.\n\nBtw, even SuS says:\n\n \"The sentence concerning appropriate privileges and execute permission \n bits reflects the two possibilities implemented by historical \n implementations when checking superuser access for X_OK.\n\n New implementations are discouraged from returning X_OK unless at \n least one execution permission bit is set.\"\n\nwhich clearly says \"Solaris is CRAP\" to me.\n\nWhat the heck is going on? First the totally broken stdio that doesn't \nretry on EINTR, now access(). And these people think they can compete?\n\nSomebody hit some Solaris engineers with a 2x4 clue-stick, please.\n\n\t\tLinus\n"},{"id":"20550","messageId":"20060523172053.60ec1145.froese@gmx.de","threadId":"4173","inReplyTo":"Pine.LNX.4.64.0605230744350.5623@g5.osdl.org","subject":"Re: Git 1.3.2 on Solaris","fromName":"Edgar Toernig","fromEmail":"froese@gmx.de","sentAt":"2006-05-23T15:20:53Z","receivedAt":"2006-05-23T15:20:53Z","isPatch":false,"sender":{"key":"froese@gmx.de","avatar":null},"body":"Linus Torvalds wrote:\n>\n> > - printf (\"access: %d\\n\", access(\"/etc/motd\", X_OK));\n> > [...]\n> > - will return 0 on solaris - when run as root, even though /etc/motd\n> > - is not executeable.\n> > \n> > This is explicitly allowed by the SUS, even for non-root:\n> \n> New implementations are discouraged from returning X_OK unless at \n> least one execution permission bit is set.\"\n> \n> which clearly says \"Solaris is CRAP\" to me.\n\nJust for the record: firefox's download manager performs exactly this\ntest to decide whether you can 'open with' a file (pretty silly because\nthe test is done on the freshly downloaded file in the temp dir which\nnever has an x-bit set). But I was hit by this effect on my system\nwhich is - surprise surprise - Linux :-) Ok, it's a pretty old one\nwith a 2.0 kernel and libc 5. But nevertheless, access(2) is not the\nright function to portably test the x-bit.\n\nCiao, ET.\n"},{"id":"20551","messageId":"Pine.LNX.4.64.0605230829020.5623@g5.osdl.org","threadId":"4173","inReplyTo":"20060523172053.60ec1145.froese@gmx.de","subject":"Re: Git 1.3.2 on Solaris","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-23T15:31:43Z","receivedAt":"2006-05-23T15:31:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 23 May 2006, Edgar Toernig wrote:\n> \n> But I was hit by this effect on my system which is - surprise surprise - \n> Linux :-) Ok, it's a pretty old one with a 2.0 kernel and libc 5.\n\nYes, we've had that bug too, and yes, I was hit by a clue-stick, and still \nhave the bruise. That's how you teach people.\n\n[ And how the heck does anybody still run 2.0, btw? ]\n\n\t\tLinus\n"},{"id":"20558","messageId":"19270.1148407414@lotus.CS.Berkeley.EDU","threadId":"4173","inReplyTo":"Pine.LNX.4.64.0605230744350.5623@g5.osdl.org","subject":"Re: Git 1.3.2 on Solaris","fromName":"Jason Riedy","fromEmail":"ejr@eecs.berkeley.edu","sentAt":"2006-05-23T18:03:34Z","receivedAt":"2006-05-23T18:03:34Z","isPatch":false,"sender":{"key":"ejr@eecs.berkeley.edu","avatar":"https://gravatar.com/avatar/547fa56f887cab01599edab4e9f813c949c1269e02714f20e0496c56185d9837?d=mp&s=160"},"body":"And Linus Torvalds writes:\n - \n - What kind of CRAP has Solaris become?\n\nBecome? heh. Check mount's output; it's \"mountpoint\non device\". Always has been. I think there might be\na reason why certain other OSes have eaten their lunch,\nand it ain't the price.\n\n - It wasn't about what was \"allowed by the standards\", \n - that was the HP-SUX and AIX's excuses.\n\nNo, AIX's excuse is that it's \"dictated by these three\nstandards over here and disallowed by those two, so\nclearly we have to support both behaviors depending\non some footnote in our 1e9 page manual.\" wheee...\n\n - Have Sun people forgotten the difference between \"quality\" and \"crap that \n - passes standards tests\"? \n\nAs far as I've been told, Sun's more interested in\nnear-perfect backwards compatibility than external\nstandards tests. It worked for Intel, right? ;)\n\n - Btw, even SuS says:\n[...]\n - New implementations are discouraged from returning X_OK unless at \n - least one execution permission bit is set.\"\n\nNow there is one possible, cross-OS problem that I\nhaven't tested. You can chmod a-x and then use\nsetfacl to grant one person execute access. I'm not\nsure if access works in that case, but that might\npossibly just say that current ACL systems are crap.\n\nHmm. Does access handle SELinux or the other systems?\nThat might be interesting for a public git server, but\nI don't know enough about it.\n\n - Somebody hit some Solaris engineers with a 2x4 clue-stick, please.\n\nI think you're targetting the wrong department...\nTheir hands are tied.\n\nJason, wondering if you could resist the SUS bait...\n"},{"id":"20561","messageId":"Pine.LNX.4.64.0605231110230.5623@g5.osdl.org","threadId":"4173","inReplyTo":"19270.1148407414@lotus.CS.Berkeley.EDU","subject":"Re: Git 1.3.2 on Solaris","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-23T18:24:43Z","receivedAt":"2006-05-23T18:24:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 23 May 2006, Jason Riedy wrote:\n>\n> - Btw, even SuS says:\n> [...]\n> - New implementations are discouraged from returning X_OK unless at \n> - least one execution permission bit is set.\"\n> \n> Now there is one possible, cross-OS problem that I\n> haven't tested. You can chmod a-x and then use\n> setfacl to grant one person execute access. I'm not\n> sure if access works in that case, but that might\n> possibly just say that current ACL systems are crap.\n\nI absolutely agree. That is why the OS has a \"access()\" system call. It's \nthere to ask the OS whether the file is executable (or readable/writable).\n\nOtherwise, we'd just do\n\n static inline int executable(const char *path)\n {\n\tstruct stat st;\n\treturn !stat(pathname, &st) &&\n\t\tS_ISREG(st.st_mode) &&\n\t\t(st.st_mode & 0111) != 0;\n }\n\nand be done with it. But exactly because the OS knows what \"executable\" \nmeans, we ask it. We don't know about all the ACL's etc, the OS does.\n\n(Similar issues are true for writability too - the file may be \"writable\" \nin the sense that the write permission bits are on, but if the filesystem \nis mounted read-only, it sure as hell ain't W_OK _anyway_).\n\n> Hmm. Does access handle SELinux or the other systems?\n\nYup. \n\nModulo bugs, of course, but yes, access() on linux should check both \nPOSIX ACL's and SELinux security extensions. It uses exactly the same \ncode-paths that open()/execve() does: it uses the \"vfs_permission()\" \nfunction which is also what execve() uses.\n\nNow, I think access() actually misses a no-exec mount (it doesn't seem to \ncheck MNT_NOEXEC for X_OK), and that looks like it might actually be a \nreal bug.\n\n\t\tLinus\n"},{"id":"20562","messageId":"20060523204321.0f8d2de0.froese@gmx.de","threadId":"4173","inReplyTo":"Pine.LNX.4.64.0605230829020.5623@g5.osdl.org","subject":"Re: Git 1.3.2 on Solaris","fromName":"Edgar Toernig","fromEmail":"froese@gmx.de","sentAt":"2006-05-23T18:43:21Z","receivedAt":"2006-05-23T18:43:21Z","isPatch":false,"sender":{"key":"froese@gmx.de","avatar":null},"body":"Linus Torvalds wrote:\n>\n> [ And how the heck does anybody still run 2.0, btw? ]\n\nWhy not? There was never the need for an upgrade.\nAll connected hardware is well supported. Sure,\nthere are no binary packages for it and you have to\ncompile from sources but most apps can be made to\nrun on it (on the way you learn to hate autoconf).\nAnd I wish the 2.6 system were as reliable as the\n2.0 one ...\n\nCiao, ET.\n"},{"id":"20563","messageId":"Pine.LNX.4.64.0605231144230.5623@g5.osdl.org","threadId":"4173","inReplyTo":"Pine.LNX.4.64.0605231110230.5623@g5.osdl.org","subject":"Re: Git 1.3.2 on Solaris","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-23T18:48:18Z","receivedAt":"2006-05-23T18:48:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 23 May 2006, Linus Torvalds wrote:\n> \n> I absolutely agree. That is why the OS has a \"access()\" system call. It's \n> there to ask the OS whether the file is executable (or readable/writable).\n\nSide note: I'm not claiming that \"access()\" is a wonderful thing. I do \nagree that we might want to replace it with something else inside of git, \nif only because of portability concerns.\n\nSo I'm really just ranting my normal \"standards lawyerese doesn't mean \nmuch\" rant..\n\n(access() also has other isses: X_OK obviously means different things for \ndirectories and for regular files, so quite often you need to do a stat() \non the thing _anyway_ just to determine whether it's \"executable in the \n'execve()' sense\" or \"executable in the 'path lookup' sense\").\n\n\t\tLinus\n"},{"id":"20731","messageId":"f3d7535d0605252030p55f83db9w4bdf436934badb19@mail.gmail.com","threadId":"4173","inReplyTo":"f3d7535d0605222020j2d581bd9j602752659a4b3ac2@mail.gmail.com","subject":"Re: Git 1.3.2 on Solaris","fromName":"Stefan Pfetzing","fromEmail":"stefan.pfetzing@gmail.com","sentAt":"2006-05-26T03:30:49Z","receivedAt":"2006-05-26T03:30:49Z","isPatch":false,"sender":{"key":"stefan.pfetzing@gmail.com","avatar":null},"body":"Hi list,\n\n2006/5/23, Stefan Pfetzing :\n\n> 2006/5/17, Jason Riedy :\n> > And pkgsrc itself works just fine without the silly g prefix,\n> > or at least does for me as a mere user (and as well as it does\n> > work). But if you intend on adding the package upstream, it'll\n> > need something to cope with the g. And pkgsrc handles local\n> > patches...\n>\n> Well I had some problems on NetBSD without the g prefix for the\n> gnu coreutils - since then I always used that prefix.\n\n...\n\nWell finally - after some patching around access() and after figuring\nout \"merge\" was broken in pkgsrc (and still is - I had to open a\nproblem report) - I got all tests to complete successfully.\n\nbye\n\nStefan\n\nP.S.: merge from devel/rcs uses /bin/diff3 on solaris which somehow\nbreaks merge.\n-- \n http://www.dreamind.de/\nOroborus and Debian GNU/Linux Developer.\n"}]}