From Newsgroup: comp.sys.mac.system

I would like to interact with Safari directly, without using 'open -a
Safari' or cocoa, in order to launch Safari with a URL. Unfortunately,
when I do this from my home directory:

/Applications/Safari.app/Contents/MacOS/Safari http://apple.com/

Safari launches with the following address:

file:///Users/davehoover/http://apple.com

Is there any way to prevent Safari from adding the current working
directory from the front of the provided URL?

BTW, I'm on 10.4, MacBook.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2006-04-19, dave.hoover@gmail.com <dave.hoover@gmail.com> wrote:

I would like to interact with Safari directly, without using 'open -a
Safari' or cocoa, in order to launch Safari with a URL.

How about 'open <url>' ?


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

D P Schreber wrote:

How about 'open <url>' ?

No, I don't want to use 'open', I just want to do it via calling Safari directly. Firefox behaves appropriately when called directly and I
don't understand why it won't work for Safari.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2006-04-19, dave.hoover@gmail.com <dave.hoover@gmail.com> wrote:

D P Schreber wrote:

How about 'open <url>' ?

No, I don't want to use 'open', I just want to do it via calling Safari directly. Firefox behaves appropriately when called directly and I
don't understand why it won't work for Safari.

Is there a reason why you don't want to use open ?

--
Martin
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 19 Apr 2006 08:41:32 -0700, dave.hoover@gmail.com wrote:

D P Schreber wrote:

How about 'open <url>' ?

No, I don't want to use 'open', I just want to do it via calling Safari directly. Firefox behaves appropriately when called directly and I
don't understand why it won't work for Safari.

What do you mean, you "just" want to call Safari directly? The word
"just" suggests that you are seeking simplicity. Using "open" is much
simpler than calling Safari directly (no long pathnames), and it works.
What doesn't "open" do that you need to do?



--
Dave Seaman
U.S. Court of Appeals to review three issues
concerning case of Mumia Abu-Jamal.
<http://www.mumia2000.org/>
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

dave.hoover@gmail.com wrote:

D P Schreber wrote:

How about 'open <url>' ?

No, I don't want to use 'open', I just want to do it via calling Safari directly. Firefox behaves appropriately when called directly and I
don't understand why it won't work for Safari.

Safari may not understand the notion of command-line arguments. A
program (console or GUI) is free to ignore the arguments passed to it.
Many GUI apps ignore arguments passed to it from the OS as a matter of
course. That is, you have to explicitly have your app cycle through the option arguments on the command line, verifying them and passing them to appropriate parts of the application. This is not a trivial job.

Alternative behaviour could be considered a feature.

Many OS X bundles do not expect one to reach into them and run an
arbitrary executable. It is typical for many apps to offer a separate
CLI executable for doing this sort of thing (TextMate and the associated "mate" executable spring to mind, only because I use it a fair amount).

I'm not surprised Firefox looks at the command line args, given the multi-platform hardcore hackers that built it. Also, there is a lot of history with older multi-platform browser to support optargs (e.g.,
Netscape).

Bottom line: suggest this feature to Apple.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

"dave.hoover@gmail.com" <dave.hoover@gmail.com> writes:

D P Schreber wrote:

How about 'open <url>' ?

No, I don't want to use 'open', I just want to do it via calling Safari directly. Firefox behaves appropriately when called directly and I
don't understand why it won't work for Safari.

I'm confused about what you want.

If you type the following at the command line:

open http://slashdot.org

then (at least on my computer) safari starts up at slashdot.org.

Is there something you want which this doesn't address?

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <XUt1g.18678$43.11438@nnrp.ca.mci.com!nnrp1.uunet.ca>,
"void * clvrmnky()" <clvrmnky.invalid@hotmail.com.invalid> wrote:

dave.hoover@gmail.com wrote:

D P Schreber wrote:

How about 'open <url>' ?

No, I don't want to use 'open', I just want to do it via calling Safari directly. Firefox behaves appropriately when called directly and I
don't understand why it won't work for Safari.

Safari may not understand the notion of command-line arguments.

Based on his original description of the behavior, Safari *does*
understand command-line arguments. But it apparently treats them like
most Unix applications, as the name of a file, not a URL. That's why

Safari http://whatever

is like accessing the URL file://<path-to-current-dir>/http://whatever.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article
<1145461292.025167.148440@e56g2000cwe.googlegroups.com>,
"dave.hoover@gmail.com" <dave.hoover@gmail.com> wrote:

D P Schreber wrote:

How about 'open <url>' ?

No, I don't want to use 'open', I just want to do it via calling Safari directly. Firefox behaves appropriately when called directly and I
don't understand why it won't work for Safari.

OK. Write a tiny little shell script and put the open inside of
the script. You can call your script safari, and just put it in a
directory that is in your PATH

script looks like

#!/bin/sh
open "$@"

Make the script executable

chmod +x /path/to/your/script/called/safari

Now you can say safari and it will do what you want.

Feel free to add any additional command line arguments you like to
your script.

If you want you can also have your script send applescript
messages to safari

Bob Harris
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

Barry Margolin <barmar@alum.mit.edu> writes:

Based on his original description of the behavior, Safari *does*
understand command-line arguments. But it apparently treats them like
most Unix applications, as the name of a file, not a URL. That's why

Safari http://whatever

is like accessing the URL file://<path-to-current-dir>/http://whatever.

It seems plausible to conjecture that this was included for use during development to check the rendering engine, and that it wasn't thought
of for actual use.

--
Bill Mitchell
Dept of Mathematics, The University of Florida
PO Box 118105, Gainesville, FL 32611--8105
mitchell@math.ufl.edu (352) 392-0281 x284
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2006-04-19, dave.hoover@gmail.com <dave.hoover@gmail.com> wrote:

D P Schreber wrote:

How about 'open <url>' ?

No, I don't want to use 'open', I just want to do it via calling Safari directly.

What possible difference could it make if your goal is as stated in the Subject?

Firefox behaves appropriately when called directly and I
don't understand why it won't work for Safari.

FireFox is a cross-platform browser, and some of those platforms (eg
Linux) don't have 'open'. That's why it needs to support this feature.
In an osx-specific browser like Safari, it isn't useful -- you can do
exactly the same thing with open. In fact you generally _should_ use
open in osx. That's the preferred, standardized way to launch an app
from the command line.

Having said that, I wouldn't be surprised if Safari supports this, given
the right command-line options. But don't ask me what they are. You
really should be using open in any case.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

Here is a useful script, if you don't want to use open:
++++++++++++
exec osascript <<EOF
tell app "safari"
activate
if not (exists document 1) then
make new document at the beginning of documents
end if
if not "$1" = "" then
set the url of the front document to "$1"
end if
end tell
++++++++++++
I call it "safari".

Greg Shenaut

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

I can see what you're saying regarding "alternative behavior could be considered a feature" when comparing Safari to other OS X bundles. But
I'm comparing it to other browsers. Because IE (on Windows) and
Firefox (on Mac and Windows) allow the user to pass an URL in from the
command line, one begins to expect that behavior out of Safari.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

No, I don't want to use 'open', I just want to do it via calling Safari directly.

What possible difference could it make if your goal is as stated in the Subject?

Here's the difference ... I am working on Selenium (http://openqa.org/selenium/), an open-source cross-browser functional
testing tool. We have a config file that allows the tester to specify
which browsers to test with. The tester simply provides the name of
the browser and the path to the browser. Then when Selenium starts up,
it passes its URL to each configured browser. At this point Safari
chokes. So, I wrote some conditional logic (yuck) to check for Safari
and use "open -a Safari" instead. But then another problem comes up.
When we start up the browser, we hang onto its process ID in order to
kill it when the test has completed. Unfortunately 'open' creates its
own process and it is (seemingly) impossible for me to get ahold of
Safari's process ID, so I can't kill it.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <1145565086.898911.172220@u72g2000cwu.googlegroups.com>,
"dave.hoover@gmail.com" <dave.hoover@gmail.com> wrote:

No, I don't want to use 'open', I just want to do it via calling Safari directly.

What possible difference could it make if your goal is as stated in the Subject?

Here's the difference ... I am working on Selenium (http://openqa.org/selenium/), an open-source cross-browser functional testing tool. We have a config file that allows the tester to specify
which browsers to test with. The tester simply provides the name of
the browser and the path to the browser. Then when Selenium starts up,
it passes its URL to each configured browser. At this point Safari
chokes. So, I wrote some conditional logic (yuck) to check for Safari
and use "open -a Safari" instead. But then another problem comes up.
When we start up the browser, we hang onto its process ID in order to
kill it when the test has completed. Unfortunately 'open' creates its
own process and it is (seemingly) impossible for me to get ahold of
Safari's process ID, so I can't kill it.

Try specifying "/Applications/Safari.app/Contents/MacOS/" as the path
and "Safari" as the name of the browser. Make sure that no other copy
of Safari is running at the time.

--
Tom Stiller

PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3
7BDA 71ED 6496 99C0 C7CF
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2006-04-20, dave.hoover@gmail.com <dave.hoover@gmail.com> wrote:

Here's the difference ... I am working on Selenium (http://openqa.org/selenium/), an open-source cross-browser functional testing tool. We have a config file that allows the tester to specify
which browsers to test with. The tester simply provides the name of
the browser and the path to the browser. Then when Selenium starts up,
it passes its URL to each configured browser. At this point Safari
chokes. So, I wrote some conditional logic (yuck) to check for Safari
and use "open -a Safari" instead. But then another problem comes up.
When we start up the browser, we hang onto its process ID in order to
kill it when the test has completed. Unfortunately 'open' creates its
own process and it is (seemingly) impossible for me to get ahold of
Safari's process ID, so I can't kill it.

Your mistake is to think that an open Mac OS X application is
anything like a Unix process. Yes there will generally be one
Unix process associated with each open app but that is a detail
which the user is not expected to concern themselves with.
The idea is that the user interacts with apps in a well defined
way (the Dock, the Finder, AppleScript etc) that is independent
the way you might interact with a Unix process (command line
arguments, job control, sending signals using kill etc).

Once Safari is running I guess you can use AppleScript to tell
it to go to the required URL, and then again to tell it to close
itself - but then I have never used AppleScript so I am only
guessing.

If you are thinking that Mac OS X and Linux are just variants
of Unix then you will run into trouble. For some purposes they
are as different from each other as they both are from Windows.

Ian

--
Ian Gregory
http://www.zenatode.org.uk/ian/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <1145565086.898911.172220@u72g2000cwu.googlegroups.com>,
"dave.hoover@gmail.com" <dave.hoover@gmail.com> wrote:

No, I don't want to use 'open', I just want to do it via calling Safari directly.

What possible difference could it make if your goal is as stated in the Subject?

Here's the difference ... I am working on Selenium (http://openqa.org/selenium/), an open-source cross-browser functional testing tool. We have a config file that allows the tester to specify
which browsers to test with. The tester simply provides the name of
the browser and the path to the browser. Then when Selenium starts up,
it passes its URL to each configured browser. At this point Safari
chokes. So, I wrote some conditional logic (yuck) to check for Safari
and use "open -a Safari" instead. But then another problem comes up.
When we start up the browser, we hang onto its process ID in order to
kill it when the test has completed. Unfortunately 'open' creates its
own process and it is (seemingly) impossible for me to get ahold of
Safari's process ID, so I can't kill it.

Well, there's always "killall Safari".

Having said that, it's hardly impossible to get Safari's PID. If
nothing else you could always start with "ps" and go from there. But
based on your description I'd think killall would be the simplest
approach.

--
Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 2.0: Delocalize, Repair Permissions, lots more.
See http://www.atomicbird.com/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

Tom Stiller wrote:

Try specifying "/Applications/Safari.app/Contents/MacOS/" as the path
and "Safari" as the name of the browser. Make sure that no other copy
of Safari is running at the time.

Unfortunately that doesn't work. The shell complains that "/Applications/Safari.app/Contents/MacOS/" is a directory. Thanks
though.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

Well, there's always "killall Safari".

Ah, that's helpful. That will make my solution feel like less of a
hack. Thanks "Tom".

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <1145643241.450620.8000@v46g2000cwv.googlegroups.com>,
"dave.hoover@gmail.com" <dave.hoover@gmail.com> wrote:

Tom Stiller wrote:

Try specifying "/Applications/Safari.app/Contents/MacOS/" as the path
and "Safari" as the name of the browser. Make sure that no other copy
of Safari is running at the time.

Unfortunately that doesn't work. The shell complains that "/Applications/Safari.app/Contents/MacOS//Applications/Safari.app/Contents/MacOS/" is a directory. Thanks
though.

It *IS* a directory. the executable is "/Applications/Safari.app/Contents/MacOS/Safari". I split them because
you said that you needed a path and command specified separately.

--
Tom Stiller

PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3
7BDA 71ED 6496 99C0 C7CF
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <1145643241.450620.8000@v46g2000cwv.googlegroups.com>, <"dave.hoover@gmail.com"> wrote:

Tom Stiller wrote:

Try specifying "/Applications/Safari.app/Contents/MacOS/" as the path
and "Safari" as the name of the browser. Make sure that no other copy
of Safari is running at the time.

Unfortunately that doesn't work. The shell complains that "/Applications/Safari.app/Contents/MacOS/" is a directory. Thanks
though.

/Applications/Safari.app/Contents/MacOS/Safari
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

dave.hoover@gmail.com wrote:

I can see what you're saying regarding "alternative behavior could be considered a feature" when comparing Safari to other OS X bundles. But
I'm comparing it to other browsers. Because IE (on Windows) and
Firefox (on Mac and Windows) allow the user to pass an URL in from the command line, one begins to expect that behavior out of Safari.

What are you responding to? Please quote some context.

Assuming you are speaking to my comments about applications not
necessarily parsing the command line arguments, I have to disagree.

Safari was a rewrite, which typically means you don't clutter the design
to add extra features a minimal set of users might want. Features that
will have to be designed, debugged and tested. Apple takes UI design
very, very seriously, and a CLI interface like this _is_ a user
interface (and a hard one to get right -- functional CLI coverage
testing is a huge problem space for the application I work on).

The revelation that a single argument is accepted and opened as a local
file points to some minimal functionality needed to (possibly) support a
test of some sort. A general purpose CLI parser would have been
overkill for this purpose.

Additionally, application bundles do not assume there is a console
present. Those other browsers you mention were designed on hybrid
systems that have a long tradition of a built-in console or were
designed multi-platform from the ground up. Not to mention that a lot
of the early browsers borrowed heavily from Mosaic. In these cases we
have test platforms that may make it convenient to have a full
command-line interface or legacy code that we need to maintain that
already does this. Basically, if you expect to run (for example) on X Windows, your "GUI" app will often be a glorified console command that
you can launch from any context and have it find your display.

Most of the functionality you want is already available via the system.

These are all excellent reasons to consider such functionality as a
feature. Anyway, the mere existence of functionality in a similar
application is not proof of anything other than those applications added
those features at some point.

So, my feelings are that while this might be a nice thing for some
people, the majority of the target audience will just never care.
Especially if there is a perfectly good workaround that is based on a
generic system utility that understands system-wide settings. This is a
big win in my books.

Though, I'm still unclear why the general-purpose "open" command is not sufficient for you. It is possible you have a specific purpose in mind
that this functionality will not cover, which is why I suggested posting
a feature request with Apple.

Alternatively, if Safari accepts a file:/// URL, you could have it load
up a local file that has a redirect meta tag, though this is of limited
value without some way of requesting the redirect URL. One hack is to
wrap an application in a script, and have that script set up all the
bits and pieces before launching the application. It's pretty crufty
and old-school, but it often works as a stop-gap until a more robust
solution can be determined.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

dave.hoover@gmail.com wrote:

No, I don't want to use 'open', I just want to do it via calling Safari
directly.

What possible difference could it make if your goal is as stated in the
Subject?

Here's the difference ... I am working on Selenium (http://openqa.org/selenium/), an open-source cross-browser functional testing tool. We have a config file that allows the tester to specify
which browsers to test with. The tester simply provides the name of
the browser and the path to the browser. Then when Selenium starts up,
it passes its URL to each configured browser. At this point Safari
chokes. So, I wrote some conditional logic (yuck) to check for Safari
and use "open -a Safari" instead. But then another problem comes up.
When we start up the browser, we hang onto its process ID in order to
kill it when the test has completed. Unfortunately 'open' creates its
own process and it is (seemingly) impossible for me to get ahold of
Safari's process ID, so I can't kill it.

Hmmm. I can see the problem. Unfortunately, this testing tool is
making some pretty broad assumptions about how applications work on some platforms. Even the assumption that something like a "process ID" is
present is often not to be trusted. I think most modern systems will
provide a pseudo-PID, but you never know.

"open" seems to launch the associated app not controlled by any terminal
(as if you simply double-clicked on the app). Therefore, it will
generally not have any idea of PIDs.

This also seems to preclude any trickery with shells and $!

A hack would be to somehow have the tool invoke "killall Safari" at the appropriate time.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

I assume that when you say that "it passes its URL to each configured
browser", it starts the browser via "browsercommand url"; and then when
it kills it, it does so by sending a signal to the process. What I
suggest is that you write a simple shell script that uses osascript to
start safari with the url passed in "$1". The script should pause and
trap whatever signal is sent to kill the browser and use osascript to
make safari quit before exiting itself.

Greg Shenaut

--- Synchronet 3.18b-Win32 NewsLink 1.113