read command and bom

Scripting Forums AppleScript | Mac OS X
, , , , ,
#21

When I said read as data, it was for when you literally wanted to look in a script editor.

You can do something like:

set y to read file x for 3
if id of y = {212, 170, 248} then -- UTF8 BOM

But if you just use “read file x as «class utf8»”, the BOM is going to be removed for you anyway.

IMO, unless you know the format of a text file, the best thing these days is something like this:

try
	set y to read file x as «class utf8»
on error -- can't be UTF8, so drop back to local encoding
	set y to read file x
end try

If a file uses other than ASCII characters and isn’t UTF8, it’s very, very unlikely not to cause an error in that first read.

#22

Hi Shane,

Wow, interesting scripts. Never knew you could do that with the ‘id’ and that all utf8 boms were the same.

The second script checks for utf8. One thing I was thinking is that I think you can read utf8 and utf16 without error. I’ll check that out tomorrow. The fence knocked me out. Hard to sleep though, when you’re thinking about things as you probably know. I’m a light sleeper.

Thanks,
kel

#23

BOM is really a misnomer for UTF8 – it’s really just an encoding flag.

UTF16 pretty much requires a BOM. But UTF8 without a BOM is easiest recognised by assuming that’s what it is, because you’ll get an error if it’s not (or it will consist of only ASCII characters, which are the same in most encodings).

I lived on a farm for 20 years. I know about fences :wink:

#24

Hello.

I removed the post I wrote here, because the topic, was outside of the forum. It helped to gather the thoughts anyway. (Hopefully :)) I figured it out, binary propertylist data is stored as utf6-BE.

#25

Hi JD Bazzie Wazzie,

I was wondering about that also. Why the creating of the “environment.plist” file in the “.MacOSX” folder didn’t add the path to the PYTHONPATH. So it’s not the bom. Maybe this doesn’t work in OS10.8.

Thanks,
kel

#26

Hello.

You can install at least environment variables with launchctl -setenv PYTHONPATH=PATHTOPYTHON or similiar. (man launchctl). I think you’ll also find a way to set variables local to the user on that page.

#27

You’re correct again! The .MacOSX/environment.plist is no longer supported in Mountain Lion. Every application has it’s own environment variables and should be set with LSEnvironment key. The key needs to be set in the info.plist of an application, so you need to save your script as an application if you want this environment variable only set for your application.

If you want an global environment I suggest you edit the /etc/launchd.conf file and add the line(s):

setenv PYTHONPATH /usr/bin/python

It is possible that you have an clean machine and that this file doesn’t exists.

#28

Hello.

I have a different suggestion, especially when it comes to the python framwork. :slight_smile: And that is to manage to do it accountwise, that way, you can also test python stuff, (that botches with the wrong framework.)

Python is python, but not as bad as perl. :slight_smile:

#29

Hi,

Finished painting the fence. Now I can play with my computer again. :slight_smile:

What I tried in Terminal was:

This works well and last until restart or login to different user. I want it to only work with my account? When I look on the internet I can’t find anything specific to OS10.8. I would think that I have to do something in my home folder or add the script to login items with an AppleScript app. Still reading up on launch daemons.

Thanks,
kel

#30

Hello kel.

The easy way, is to just make a login item, that does it for you, sets up the PythonPath. that is at least what I am going to do.

Great minds think alike.

I am about to paint the picket fence again too. :slight_smile:

#31

Hi McUsr,

I think I’m going with the login items also. Easier to work with for now, but maybe longer login times. Don’t know how I missed this post:

http://stackoverflow.com/questions/15536697/running-python-script-with-launchd-imports-not-found

It had the answer about how to write the plist to /etc/launchd-user.conf for my account.

The weather was great for the paint job. Good luck to you.

kel

#32

Hello kel1.

I figured out that it was easier to, more so, when there is something you launch, that is liable to change. I prefer LaunchAgents, only for stuff that are fairly static. But then LaunchAgents are best I believe.

There should also be a loginHook, at least there is still one on SnowLeopard, which you can “Defaults Write” to.
Just to provide for yet another alternative. You’ll probably find the documentation somewhere at Apple. I first saw it in a post at MacOsXHints by Bruce Phillips.

(BPSystemStartupTopics.pdf in Developer Docs?)

Anyways; I think setting it like you did is the best way, and also from the login items, then you can redit the applet, and run it, without logging back in, and it will work perfectly the next time! That must be the most efficient way, in contrast to using LaunchAgents, loginhooks, or whatever!

Of course you’ll have to restart the apps that are reliant upon the new value of the system variable, but that is a different story from having to close everything, logout, log back in again, and open everything where you left off!
(At least on SnowLeopard it is!)

PS. I read the Stack Overflow topic, I don’t believe that ~/.launchd.conf doesn’t work, before I have really tried it out.

With regards to the paint job: I hope it rains for three months! :smiley:

Cheers

#33

Hi McUsr,

I’ve been trying all morning to add a launch agent to “/Users/kelhome/Library/LaunchAgents/”. Think I did everything. Loaded the LaunchAgent with ‘launchctl load …’ and made a bash script executable (tested in Terminal). In the mean while, adding the AppleScript application to login items was easy. i’ll probably keep trying that launch agent stuff, at least got the login AS app to work. :slight_smile:

Here’s the script to create the launch agent (got help from internet):

set theFile to "/Users/kelhome/Library/LaunchAgents/com.kel.app.plist"
--set theFile to "/Users/kelhome/Desktop/com.kel.app.plist"
tell application "System Events"
	set the parent_dictionary to make new property list item with properties {kind:record}
	set plistFile to make new property list file with properties {name:theFile, contents:parent_dictionary}
	tell plistFile
		make new property list item at end with properties {name:"Label", kind:string, value:"com.kel.app"}
		make new property list item at end with properties {name:"Program", kind:string, value:"/Users/kelhome/MyPython/UnixPYTHONPATH.sh"}
		set r to make new property list item at end with properties {name:"EnvironmentVariables", kind:record}
		tell r
			make new property list item at end with properties {name:"PYTHONPATH", kind:string, value:"/Users/kelhome/MyPython"}
		end tell
	end tell
end tell

Here’s the plist file:

Here’s the script for overkill because the EnvironmentVariables didn’t work:

I’ll solve how to make launch agents one day.

THanks everybody,
kel

#34

Hello.

I think you miss a “launch on load” key for it to work.

I also hope you used “launchctl -w load youragent.” (I’ll have to reread it as well.)

#35

Hi McUsr,

It’s working! I hope. :smiley:

Added the RunAtLoad key with value true.

set theFile to "/Users/kelhome/Library/LaunchAgents/com.kel.app.plist"
--set theFile to "/Users/kelhome/Desktop/com.kel.app.plist"
tell application "System Events"
	set the parent_dictionary to make new property list item with properties {kind:record}
	set plistFile to make new property list file with properties {name:theFile, contents:parent_dictionary}
	tell plistFile
		make new property list item at end with properties {name:"Label", kind:string, value:"com.kel.app"}
		make new property list item at end with properties {name:"Program", kind:string, value:"/Users/kelhome/MyPython/UnixPYTHONPATH.sh"}
		set r to make new property list item at end with properties {name:"EnvironmentVariables", kind:record}
		tell r
			make new property list item at end with properties {name:"PYTHONPATH", kind:string, value:"/Users/kelhome/MyPython"}
		end tell
		make new property list item at end with properties {name:"RunAtLoad", kind:boolean, value:true}
	end tell
end tell

Also, unloaded and reloaded the agent this time:

I couldn’t understand what the launchctl man page meant with the -w flag so left that out:

Now to see if it keeps working. :slight_smile:

Thanks for all the help!
kel

#36

Seems to be working after Restart, etc.

Fixed up the script a little and added some reminders for anyones information.

-- Makes plist file agent to append to PYTHONPATH
set theFile to "/Users/kelhome/Desktop/com.kel.app.plist" -- for test
--set theFile to "/Users/kelhome/Library/LaunchAgents/com.kel.app.plist"
set theJob to "com.kel.app"
set theScript to "/Users/kelhome/MyPython/UnixPYTHONPATH.sh"
set theDirectory to "/Users/kelhome/MyPython"
--
tell application "System Events"
	-- make the root
	set the parentDictionary to make new property list item with properties {kind:record}
	--
	set plistFile to make new property list file with properties {name:theFile, contents:parentDictionary}
	tell plistFile
		make new property list item at end with properties {name:"Label", kind:string, value:theJob}
		make new property list item at end with properties {name:"Program", kind:string, value:theScript}
		-- overkill, redundant?
		set theRecord to make new property list item at end with properties {name:"EnvironmentVariables", kind:record}
		tell theRecord
			make new property list item at end with properties {name:"PYTHONPATH", kind:string, value:theDirectory}
		end tell
		-- not sure if this is needed also
		make new property list item at end with properties {name:"RunAtLoad", kind:boolean, value:true}
	end tell
end tell
(*
Notes:
unload and reload launch agent -
launchctl unload ~/Library/LaunchAgents/PlistFileName
launchctl load ~/Library/LaunchAgents/PlistFileName
Rem:
make script executable
*)

Still smiling. :slight_smile:

Model: MBP
AppleScript: 2.2.3
Browser: Safari 536.26.17
Operating System: Mac OS X (10.8)

#37

Hello.

Launchctl feels a little bit awkward to work with doesn’t it? -I have a copy of Lingon around, to write all the xml tags for me. My approach is that launchctl is telling launchd to run stuff. launchd runs as process nr 0, or talks with it, so everything I am setting in launchd’s environment, is inherited from there.

Anyways, you should think of the -w flag as write it makes the changes your set to be persistent. That is what the gibberish means. :slight_smile: (In order for launchctl to work, it reads the contents of the property list file, so the -w option writes that it is to be launched, or whatever into the property list file.

What I’ll try to do, is set an environment variable. Restart Finder and Terminal app, and then see if the environment variable is changed.

I’ll also try to figure out, if I can make it with a login item after that.

I’'ll do this during the day, when I’m bored of reading. :slight_smile:

Edit

I opened a terminal window, and I executed first myname=McUsr
After that I executed launchctl setenv myvar $myvar
in the same terminal window.

Then I fired up AppleScript editor, and ran

do shell script "echo $myvar"

And I got what I wanted back.
When trying to run this in a new terminal window, I don’t get the correct result back of course, because the environment has alread been read in when Terminal.app started, and the environment is pretty much frozen from the outside at that point.

But this means that login items will work for me.

It beats me that I started AppleScript Editor from Spotlight the first time. Now I’ll start from Finder:
That worked too; it reflected the change of my previous launchctl command. It makes sense, since Finder uses launchservices anyway.

So, I am good by making an applescript login item applet, with the setenv command in it.

And I have time to play more with the AsObj-C global system’s menu app that are “self-editing” that I created yesterday. :smiley:

#38

Yes, my do shell script still doesn’t run scripts by name even with Python. At least now it can load my python modules by name though.

I saw that post about the menu item. It sounded interesting. I need to find it again.

Good night,
kel

#39

Hello.

I was thinking that the way I use this, should work for you, as long as you are using it, to specify a global PYTHONPATH, for setting up the frameworks. There may be other issues as well, as maybe relinking the PYTHONframework?

Well, I am using this only for setting global environment variables, on the fly, without having to log out and back in again, and that seems to work for me.

I like the project, thanks to DJ Bazzie Wazzie.

If you follow the instructions, or see where you need to change stuff here

The project can be downloaded from here

You’ll have to edit the last target in particular, by right click on it, then click “get info”. (XCode 3.2).

In particular you’ll have to adjust the buildpath of XCode in the run script target:

osascript -e "tell application \"SystemMenu\" to quit" cp -r /usr/local/XCodeBuilds/Release/SystemMenu.app ~/Applications open -a ~/Applications/SystemMenu.app
When everything is ok, then when you click the hammer, the project should be built, the menu restarted, and the project should close automagically in XCode. If you don’t use to have any projects open in XCode, then you may quit XCode as well.
Edit

Maybe you should take a trip over to stack overflow, rumors has it that there are many ways to specify PYTHONPATH, and the one using an environment variable not being recommended.

#40

Hi McUsr,

I’m thinking that there is no way around ‘do shell script’ using default values for environment variables. It seems that the only thing that changes using python is the modules search path.

I just thought of a new simple tool bar button. :slight_smile: It moves the selected item in the window to its container’s container. Simple. :smiley:

Edited; the container.

Have a good day.

kel