[icedtea-web] RFC: allow alternate means of finding browsers

[Omair Majid]

On 01/04/2011 12:54 PM, Omair Majid wrote:
> On 12/22/2010 06:29 PM, Dr Andrew John Hughes wrote:
>> On 17:15 Wed 22 Dec , Omair Majid wrote:
>>> On 12/22/2010 03:42 PM, Dr Andrew John Hughes wrote:
>>>> On 15:32 Wed 22 Dec , Omair Majid wrote:
>>>>> Hi,
>>>>>
>>>>> The attached patch allows netx to use a browser based on the
>>>>> BROWSER env
>>>>> variable or using xdg-open, as opposed to relying on user-supplied
>>>>> browser command.
>>>>>
>>>>> A new configuration option deployment.browser.source is used to
>>>>> determine where to find the browser. If it is set to "PATH" (the
>>>>> default), the configuration option deployment.browser.path is used. If
>>>>> deployment.browser.source is set to "ENV" then the $BROWSER
>>>>> environment
>>>>> variable is used. If deployment.browser.source is set to "XDG" then
>>>>> the
>>>>> program xdg-open is used to launch the browser.
>>>>>
>>>>
>>>> I would make XDG the default so it works like other applications on
>>>> the system
>>>> (which I presume use either this or $BROWSER) if
>>>> deployment.browser.path is not set.
>>>> Then NetX automatically picks up the system browser rather than
>>>> prompting.
>>>>
>>>
>>> Ah, great idea! Should I keep support for using $BROWSER or remove that
>>> too in favour of xdg-open?
>>>
>>
>> Please keep it. I don't see how it does any harm.
>>
>> You might also want to consider the scenario that xdg-open is not
>> available
>> and fall back to $BROWSER then prompting if that is also empty.
>>
>
> Done.
>
>>>> Shouldn't we do some basic sanity checks on the contents of getEnv?
>>>> (And path too
>>>> if we don't already)
>>>>
>>>
>>> We should, and we dont do it for path either. Actually netx refers to
>>> path as 'command' and that's how it deals with it too - it simply execs
>>> "command url" to open the url. This allows a user to use a program name
>>> (like firefox) instead of the entire path to it. So checking for
>>> file/path existence makes this common case fail:
>>> BROWSER=chromium-browser javaws foo.jnlp
>>> (and similar for path). I dont see any simple way to check if the
>>> command is valid - short of actually running the command. Do you have
>>> any other sanity checks in mind?
>>
>> On *ix systems, you could run 'which command' and then execute the
>> result of that
>> instead. How well that works depends if we want to allow options to be
>> specified
>> to the binary.
>>
>
> I am using the 'type' builtin to check if command is valid rather than
> 'which' since the behaviour of 'type' is a POSIX standard, while 'which'
> may or may not return an error code on failure.
>
>> I would at least check for things like \r and \n which would suggest
>> something fishy to me.
>> It doesn't immediately seem a huge issue as the netx binary is not
>> privileged.
>>
>
> Also done.
>

Ping. Any comments?

Cheers,
Omair