• 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: Exporting shell variables to AppleScripts
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exporting shell variables to AppleScripts


  • Subject: Re: Exporting shell variables to AppleScripts
  • From: Steve Hayman <email@hidden>
  • Date: Thu, 20 Sep 2007 14:33:18 -0400


On Sep 20, 2007, at 5:23 AM, Doug McNutt wrote:
I'm betting that a new Terminal session does not get my current environment as a starting point even in Tiger, Are we really sure that my environment is transferred to osascript?


As Chris mentioned, environment vars get passed to child processes - but they don't get passed back to parent processes. They're not "global variables." This is a UNIX thing. They can be changed by a process, and will be inherited by its children - but they don't go "back up."

When a new process is launched, it normally is passed the environment of its parent process So when you make a new Terminal window, a shell is launched ("bash", usually), which is a child of Terminal.app itself. If you set some environment variables in that shell, ie. you do

$ export FOO=BAR

you have now set an environment variable called FOO in that bash process. (Not in the Terminal process, just in this one specific bash process.) And if you then do this from the same bash process

$ osascript -e 'system attribute "FOO"'

the osascript process will inherit the changed variable. osascript is a child of bash, which is a child of Terminal, which is a child of - I dunno, the window server or something.

So, yes, environment variables you set in a Terminal session will be passed to any osascript that is launched from that terminal session. But, no, you cannot set an environment variable in terminal window A and expect anything in terminal window B, or even ApplicationC.app, to know about it. (*)

(*) unless you launch ApplicationC by giving its exact path in the terminal window, e.g.

$ export FOO=BAR
-- now double click on Script Editor.app


system attribute "FOO" -> returns nothing, it doesn't know about it
-- and now, in the original terminal window, launch ScriptEditor directly so it is a child of the shell that defined the environment variable


$ /Applications/AppleScript/ScriptEditor.app/Contents/MacOSX/ ScriptEditor

-- now, system attribute "FOO" works.









_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden
References: 
 >Exporting shell variables to AppleScripts (From: Mike <email@hidden>)
 >Re: Exporting shell variables to AppleScripts (From: Brian Johnson <email@hidden>)
 >Re: Exporting shell variables to AppleScripts (From: "Mark J. Reed" <email@hidden>)
 >Re: Exporting shell variables to AppleScripts (From: Steve Hayman <email@hidden>)
 >Re: Exporting shell variables to AppleScripts (From: "Mark J. Reed" <email@hidden>)
 >Re: Exporting shell variables to AppleScripts (From: Doug McNutt <email@hidden>)
 >Re: Exporting shell variables to AppleScripts (From: Christopher Nebel <email@hidden>)

  • Prev by Date: Re: Exporting shell variables to AppleScripts
  • Next by Date: Re: Check if app exists
  • Previous by thread: Re: Exporting shell variables to AppleScripts
  • Next by thread: iTunes' sluggish import
  • Index(es):
    • Date
    • Thread