discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep "open" tool


From: Dan Pascu
Subject: Re: GNUstep "open" tool
Date: Sat, 24 Nov 2001 06:07:11 +0200 (EET)

On 23 Nov, Nicola Pero wrote:
> 
> 
>> Mac OS X doesn't have openapp (I tried it the last time I had access to an OS
>> X machine), but it does have open. I was rather confused by this, as I'm used
>> to openapp. On OS X, open is how you open both files and apps from the 
>> command
>> line, and it does search for apps (and only apps) in the well-known paths,
>> after the current directory (just like my patch does).
> 
> Ok - thanks - Stefan also told me the same - he'd simply like to have a
> single tool doing the two different things ...
> 
> it might become a simple matter of taste then ... but I'd personally
> prefer to keep them separate ... `real' users are anyway supposed to use a
> GUI interface to open files and run applications ... while `techies'
> probably prefer to have more control on what's happening and would prefer
> having separate commands for separate operations (at least, I do) ...
> openapp for starting system/local/etc applications and gopen for opening
> local files.

making gopen search (for apps only) starting with the current dir and
then with system/local/... seems a reasonable solution.
You can still have openapp separate and working as expected, and gopen
will work as before for non-apps, while if you prefer to use openapp
for system/local/... apps, and gopen for apps in the current dir it
will still work as before for you. It just helps people preferring to
use a single command, by searching for an app in system/local/.. if not
found in the current dir first.

While it makes sense to give a message that there is no such file (in
the current dir) for non-apps, it's not what a user expects when he asks
for an app to start, unless it's nowhere present on the system.
For apps what you want is to run a local copy before a system one (so
you can test a different version/variant of the app), but if no copy of
app XYZ is in the current dir and I call gopen XYZ.app, it's obvious
that I want the system app to start, not that I want to check if the
system gives me the message about the app not being in the current dir
(I can check that with ls)

Anyway, I think the patch doesn't affect behavior for openapp/gopen for
people used with the old way, just adds an extra useful feature.

-- 
Dan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]