Re: how to eject a firewire drive natively
Re: how to eject a firewire drive natively
- Subject: Re: how to eject a firewire drive natively
- From: James Cass <email@hidden>
- Date: Sun, 11 Apr 2004 13:28:52 -0400
You may want to consider "hdiutil" instead of "diskutil", like this:
hdiutil unmount /Volumes/MacOS9
(In the above example, I have a firewire drive with two partitions,
"MacOS9" and "OnFire".)
This will also allow you to unmount individual partitions of a hard
drive without unmounting the entire drive. Check out the man pages for
hdiutil. It's pretty good.
Hope I'm on the same page as you guys now. :-)
-James
On Apr 11, 2004, at 12:50 PM, Graff wrote:
This whole subject is related to a post a few weeks ago where for some
reason the person needed to do this through shell scripting. Yes, you
can eject disks directly in AppleScript but at the time there was some
solid reason for using a shell script. This all came up again simply
because there was buggy or odd behavior related to the "do shell
script" command and a shell tool. At the time I had commented on the
odd behavior and no one had an answer.
Axel recently re-opened the discussion because of the fact that no one
had come up with a decent explanation and he was still curious as to
the source of the bug. This is a good thing because many of us use
the "do shell script" command and a full understanding of the bugs and
issues associated with it will allow us to better debug any problems.
- Ken
On Apr 11, 2004, at 11:19 AM, James Cass wrote:
Please pardon me if I missed something. If all you want to do is
eject a firewire disk why don't you just do it like this:
tell application "Finder"
eject disk "firewire_disk"
end tell
This doesn't leave any ghost when you "ls" the "/Volumes" either.
- James
On Apr 11, 2004, at 2:10 AM, Graff wrote:
On Apr 11, 2004, at 12:59 AM, Paul Berkowitz wrote:
On 4/10/04 9:42 PM, "Graff" <email@hidden> wrote:
To my knowledge no one ever tried to answer it so I'm assuming it
has
everyone stumped or that no one really cares to investigate it.
It certainly seems like buggy behavior to me. I see no really good
reason why this command should react so differently when executed
from
the command line as opposed to through a "do shell script"
command. I
even attempted to duplicate the environment that the "do shell
script
command" uses and I still didn't get the same result as through
AppleScript.
In the Terminal, the shell is whatever it's set to: usually bash in
Panther,
tcsh in Jaguar (? - or maybe that was in 10.1), zsh in OS 10.1 (?
or maybe
that was 10.0). I don't know why they keep changing it. If you did
an
Archive & Install of Panther then you inherited whatever you had in
Jaguar.
I believe default shell for 10.0 - 10.2 was tcsh, it got changed to
bash in 10.3 but only for new user accounts. Existing user accounts
kept their old shell as default. The implementation of the sh shell
was actually a copy of zsh prior to 10.2 and then it was changed to
bash in 10.2 and later. Both zsh and bash have the ability to run
in a "compatibility mode" that makes them act pretty much like sh.
This is mentioned here:
<http://developer.apple.com/technotes/tn2002/tn2065.html>
Anyway, AppleScript doesn't use any of the above: it uses sh. (And
then
there's something about sh emulating one of the others, or vice
versa - I
forget.) Anyway, it's probably a difference to do with which shell.
You
could 'do shell script' on a script file you've created (which you
can also
do in Applescript via the open for access and write commands),
where the
first line is a shebang line that sets the shell to the one you
have in your
Terminal. Then diskutil will probably work as you like.
Then again, it may be due to the result that AppleScript returns
not being
in the correct stream. That's quite likely since you say that
do shell script "diskutil eject " & posixPath & "> /dev/null
2>&1 &"
ending in "> /dev/null 2>&1 &" is what works. It makes no
difference if you
consider it a workaround, if in fact it's actually the solution.
There are
about 500 messages about this in the archives, with this solution
being
presented many times for various shell scripts, several times with
explanations by Chris Nebel and others. Somebody will probably
repeat the
explanation again. Or you could try searching teh archives (yes, I
know).
I tested doing different stream redirections and the only thing that
seemed to matter was that the process got backgrounded. When I did
the redirections and I didn't include the background part (the
trailing &) it still failed to work correctly. So I'm not so sure
that the streams have anything to do with it, although I can't be
positive.
I'm fairly certain that it doesn't have anything directly to do with
the particular shell you are using since I tested the command under
both sh and tcsh and it ran similarly. I noted that in my original
post on the matter. I can also simulate using tcsh directly in
AppleScript by explicitly using it:
this script:
-----------
set diskName to "Jedi Academy Disc 1"
set posixPath to quoted form of ("/Volumes/" & diskName)
do shell script "/bin/tcsh -c \"diskutil eject " & posixPath & "\""
-----------
has the same effect as this script:
-----------
set diskName to "Jedi Academy Disc 1"
set posixPath to quoted form of ("/Volumes/" & diskName)
do shell script "diskutil eject " & posixPath
-----------
Both versions don't work right. The first one uses tcsh and the
second uses the default shell for AppleScript, which is sh (actually
bash but it doesn't really matter).
These next two versions work, the first is tcsh and the second is sh:
this script:
-----------
set diskName to "Jedi Academy Disc 1"
set posixPath to quoted form of ("/Volumes/" & diskName)
do shell script "/bin/tcsh -c \"diskutil eject " & posixPath & "\" >
/dev/null 2>&1 &"
-----------
has the same effect as this script:
-----------
set diskName to "Jedi Academy Disc 1"
set posixPath to quoted form of ("/Volumes/" & diskName)
do shell script "diskutil eject " & posixPath & " > /dev/null 2>&1 &"
-----------
So I believe the answer is more complex than merely being
differences between shells. What is actually going wrong I don't
know, all I know is that it seems to have something to do with the
interaction between a non-backgrounded diskutil process and
AppleScript.
Yeah, this is a bit of an academic question since we seem to have a
decent workaround but figuring out the cause of this buggy behavior
is a good exercise and might expose something that breaks in other
instances and should be fixed.
- Ken
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.