patchImprove git-help--browse browser support under OS X

/usr/bin/open <document> is used under OS X to open a document just as if the user had double-clicked on the file's icon. In other words, this will open HTML files with the user's default browser. Note however that whether the document opens in a new window, or in a new tab depends upon the browser configuration.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
 git-web--browse.sh |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

On Fri, Feb 08, 2008 at 04:23:14PM -0500, jaysoffian+git@gmail.com wrote:

This is OS X specific, so the change should be made in such a way that it will not affect anyone else. Because people on other platforms may have "open" to do different things. For example, on Linux, the "open" command is used to open a new virtual terminal. At the same time, other systems may have their own ways to start the default browser. For instance, on Debian based systems, it is usually x-www-browser for X and www-browser for terminal.

Dmitry

On Feb 9, 2008 3:20 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:

I guess I'm confused by the criticism as I thought that's what I did. "open" is only added to the list of browsers to try if the SECURITYSESSIONID environment variable is set (indicating an OS X GUI login environment). I don't see how the change I made could adversely impact the users of other systems.

j.

On Sat, Feb 09, 2008 at 09:15:30PM -0500, Jay Soffian wrote:

Would not be better to use uname instead like this

  if test "$(uname -s)" == "Darwin"; then
    ...
or in addition to SECURITYSESSIONID:

  if test -n "$SECURITYSESSIONID" -a "$(uname -s)" == "Darwin"; then
    ...
?

I think it would be more reliable and more importantly it makes the code easier to understand, because it is clear now for everyone that this is OS X specific.

BTW, should not it be mentioned in the documentation? Probably, in the list of supported web browsers in git-help.txt.

Dmitry

Le dimanche 10 février 2008, Dmitry Potapov a écrit :

I wonder if "open" works on OS X outside the OS X GUI environment. (And do people use OS X outside the OS X GUI environment ?)

In the git "next" branch, "git-help--browse" has been renamed "git-web--browse". And the original patch is against "git-web--browse" except in the title where it is about "git-help--browse".

Anyway now in "next", "git-web--browse" is used by both "git help" and "git instaweb", so the documentation of both commands need an update.

Thanks, Christian.

On Feb 10, 2008 8:45 AM, Christian Couder <chriscool@tuxfamily.org> wrote:

"open" simulates double-clicking on a document icon, so, no it does not make sense to use it unless the GUI is active. What I was referring to though is that you can't ssh into another OS X host and use open, even if there is a user logged into the GUI on that host, for obvious security reasons.

Yeah, my typo in the title.

The git instaweb documentation update should be in a separate patch. Though I think maybe the right way to handle this is add a new doc for git-web--browse and then have the instaweb and help docs refer to that, no?

BTW, what is the reason for the two-dashes in git-web--browse's name?

j.

Le lundi 11 février 2008, Jay Soffian a écrit :

Ok, thanks for this information.

The two-dashes means that it's an helper script, and this means that it may not have it's own documentation. Anyway maybe I will create a documentation for it and move common information from Documentation/git-help.txt and Documentation/git-instaweb.txt into it.

Thanks, Christian.

On Feb 10, 2008 7:43 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:

Sure.

Yep, will do.

j.

From: Jay Soffian <jaysoffian@gmail.com>

/usr/bin/open <document> is used under OS X to open a document as if the user had double-clicked on the file's icon (i.e. HTML files are opened w/the user's default browser).

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
 Documentation/git-help.txt |    1 +
 git-web--browse.sh         |    7 +++++--
 2 files changed, 6 insertions(+), 2 deletions(-)

Because we preprocess git-web--browse.sh to create the final git-web--browse to be installed, something like "open" that is not a user but a platform preference might be better done as a build-time thing, instead of forcing everybody to spawn "uname", perhaps like this?

Also I wonder why the check for SECURITYSESSIONID your original had is not good enough for this Mac specific customization?

 Makefile           |    2 ++
 git-web--browse.sh |   18 +++++++++++++++++-
 2 files changed, 19 insertions(+), 1 deletions(-)

On Feb 10, 2008 10:01 PM, Junio C Hamano <gitster@pobox.com> wrote:

Seems like overkill (over the original patch), but honestly, I'm happy with whatever solution deemed appropriate, just as long as I can use my native browser on OS X. :-)

Well, I thought it was. I was just responding to feedback. I don't have enough experience with the git project to have much of an opinion either way.

Anyway, thanks for the pointers.

j.

On Feb 10, 2008 10:01 PM, Junio C Hamano <gitster@pobox.com> wrote:

Christian,

Any thoughts on Junio's patch vs the original?

http://thread.gmane.org/gmane.comp.version-control.git/73149/focus=73354

j.

Le mardi 12 février 2008, Jay Soffian a écrit :

I think the original was good and Junio's patch is a good improvement on top of yours.

Thanks, Christian.

Christian Couder <chriscool@tuxfamily.org> writes:

I think the original that only checked SECURITYSESSIONID was short, sweet and inexpensive.

Unless somebody comes up with a good reason that the environment check for SECURITYSESSIONID would misidentify (my understanding is that it is a MacOS specific hack^Wenvironment variable and nobody else would have it, but I haven't found authoritative source), I think the original from Jay is good and I can apply it to 'master'.

I very much had trouble with the $(uname -s) thing which unconditionally penalized everybody else, and that was the primary reason I suggested an alternative to make it cheaper.

On Feb 13, 2008, at 11:14 PM, Junio C Hamano wrote:

When I SSH to my mac, the SECURITYSESSIONID variable isn't set, but open will succeed in displaying the page.

Not sure if that is a valid concern though; how often would you do a remote login to your mac to display a webpage?

- Pieter

On Feb 13, 2008 5:46 PM, Pieter de Bie <pdebie@ai.rug.nl> wrote:

That is quite odd, but I've confirmed it under 10.5.2. In 10.5 I can ssh to another Mac and /usr/bin/open a document. If I have a GUI login already established on that Mac, I can see (via screen sharing) the application is launched and the document handled. But here's the odd part -- if I *don't* have a GUI login on that Mac, the application for the document is *still* launched, but I guess it's running in some sort of headless mode. I don't recall 10.4 operating this way.

But this is neither here nor there. AFAIK, SECURITYSESSIONID is unique to OS X and it reliably indicates that the user is sitting in front of the OS X GUI.

j.

Le jeudi 14 février 2008, Jay Soffian a écrit :

Ok, then please add a comment saying that to your original patch before: 

+    if test -n "$SECURITYSESSIONID"; then
+       browser_candidates="open $browser_candidates"
+    fi

and then resend it with "Acked-by: Christian Couder <chriscool@tuxfamily.org>".

Thanks, Christian.