• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: how to eject a firewire drive natively
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to eject a firewire drive natively


  • Subject: Re: how to eject a firewire drive natively
  • From: Graff <email@hidden>
  • Date: Sun, 11 Apr 2004 12:50:48 -0400

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.


  • Follow-Ups:
    • Re: how to eject a firewire drive natively
      • From: James Cass <email@hidden>
References: 
 >Re: how to eject a firewire drive natively (From: Paul Berkowitz <email@hidden>)
 >Re: how to eject a firewire drive natively (From: Graff <email@hidden>)
 >Re: how to eject a firewire drive natively (From: James Cass <email@hidden>)

  • Prev by Date: Re: how to eject a firewire drive natively
  • Next by Date: Re: can't make option down into a real
  • Previous by thread: Re: how to eject a firewire drive natively
  • Next by thread: Re: how to eject a firewire drive natively
  • Index(es):
    • Date
    • Thread