git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCHv2 6/7] web--browse: use (x-)www-browser if available

From
Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date
Dec 3, 2010, 22:45 UTC
Message-ID
<AANLkTinWD53M2VjiWgeA0Qwx3OHzR2A09Y+AB2B9o1df@mail.gmail.com>
In-Reply-To
<7vaakmmrkj.fsf@alter.siamese.dyndns.org>
On Fri, Dec 3, 2010 at 11:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 14 quoted lines
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> Debian and derivatives have an alternatives-based default browser
>> configuration that uses the /usr/bin/gnome-www-browser,
>> /usr/bin/x-www-browser and /usr/bin/www-browser symlinks.
>>
>> When no browser is selected by the user and the Debian alternatives are
>> available, try to see if they are one of our recognized selection and
>> in the affermative case use it. Otherwise, warn the user about them
>> being unsupported and move on with the previous detection logic.
>
> A "please step back a bit" question.  Does the packaging guideline of
> Debian say that non-browser applications should take these links as "end
> user preference" when opening HTML pages?

I'm not sure this is an actual guideline, and I cannot find much specific information about it online. It _is_ the recommended way to set the default browser in Debian (plus the BROWSER override), but there are quite a few applications that don't actually follow it. (And FWIW, as a Debian user I find this annoying, e.g. when clicking on a link and having konqueror or iceweasel pop up instead of my preferred x-www-browser, that happens to be Opera.)

I do believe that Debian encourages the use of sensible-browser (that does the BROWSER and *www-browser check itself) rather than manually going to look at those specifications. But that means giving up the "do anything we can to open stuff in a new tab" that is among the specified purposes of git-web--browse.

> The behaviour of unconfigured git across platforms would become less
> consistent if we do this, while the behaviour of random programs on one
> particular platform (Debian) would become more consistent.

That's actually the reason why I wasn't so sure it would be appropriate for inclusion.

> I am not saying that is necessarily a bad thing.  I just want to
> understand the motivation.

The motivation is that, lacking an explicit override, I believe git web--browse should try and get the information about the preferred browser from wherever it can. In a way, the *www-browser testing is akin to the use of start in Windows or open under Mac OS X.

Of course, as I only use Debian, I am not aware of what other distributions do (if they do anything at all) to allow a user to specify a preferred browser.

An alternative approach would be to get rid of the *www-browser and BROWSER patches, and just use xdg-open if it's available. Which again raises the issue of how to enforce opening the page in a new tab.

>> +# check if a given executable is a browser we like
>> +valid_exe() {
>
> Call it valid_browser_executable or something, please.
Of course.
Show 5 quoted lines
>> +     testexe="$1"
>> +     basename=$(basename $(readlink -f "$testexe"))
>
> Are we saying "readlink" must exist on the system?  This dependency is
> new, I think.

The only other use I found of readlink is in a specific area of t/test-lib.sh, so this seems like a new requirement indeed. I can either wrap that part in a type readlink check, or I can get rid of that specific section of the test, and just leave the --version check, bringing the code back to the previous patch version.

-- 
Giuseppe "Oblomov" Bilotta
Previous: Junio C HamanoNext: Jonathan Nieder
Message 20 of 25 in “[PATCHv2 0/7] web--browse cleanup and extensions”
  1. Giuseppe BilottaDec 3, 2010
  2. 1/7 CodingGuidelines: mention whitespace preferences for shell scriptsGiuseppe Bilotta, Dec 3, 2010
  3. Junio C HamanoDec 3, 2010
  4. Giuseppe BilottaDec 3, 2010
  5. Junio C HamanoDec 3, 2010
  6. Giuseppe BilottaDec 3, 2010
  7. 2/7 web--browse: coding styleGiuseppe Bilotta, Dec 3, 2010
  8. Junio C HamanoDec 7, 2010
  9. 3/7 web--browse: split valid_tool listGiuseppe Bilotta, Dec 3, 2010
  10. 4/7 web--browse: support opera, seamonkey and elinksGiuseppe Bilotta, Dec 3, 2010
  11. Junio C HamanoDec 3, 2010
  12. Giuseppe BilottaDec 3, 2010
  13. 5/7 web--browse: better support for chromiumGiuseppe Bilotta, Dec 3, 2010
  14. Junio C HamanoDec 3, 2010
  15. Giuseppe BilottaDec 3, 2010
  16. 6/7 web--browse: use (x-)www-browser if availableGiuseppe Bilotta, Dec 3, 2010
  17. Christian CouderDec 3, 2010
  18. Giuseppe BilottaDec 3, 2010
  19. Junio C HamanoDec 3, 2010
  20. Giuseppe BilottaDec 3, 2010
  21. Jonathan NiederDec 4, 2010
  22. Giuseppe BilottaDec 4, 2010
  23. 7/7 web--browse: look at the BROWSER env varGiuseppe Bilotta, Dec 3, 2010
  24. Jonathan NiederDec 3, 2010
  25. Jonathan NiederDec 3, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.