Auto-running a Mac '.command' File from Sketchup?

TIG

Thanks Dan, I have already added a #!/bin/bash line to the start of the Mac .command script so it knows it's a 'bourne_again_shell' script.
I have made the file executable using ruby chmod 0777 and I want it to run when opened from Sketchup by UI.openURL(path_to_command_file)...
I am trying out Jim's suggestion and some others I got separately... I'll report back.
It's a pain when you don't have the OS to test and Mac users with Sketchup and the 3rd party application I want to run wit arguments are not so common...

Jim

How to do pass arguments using openURL?

edit: Oh I see, you don't. You are running a script which then runs the app with arguments.

Isn't using system or ` ``` more appropriate?

Dan Rathbun

@jim said:

Isn't using system or ` ``` more appropriate?

using system by itself (on WIN) causes SU's ruby thread to stop until the system call returns. ie SU app will go into ghost-mode.
Does this happen on Mac? (SU stops while the system call is processed.)

you can subthread it:
result = nil t = Thread.new { result = system(cmd, args) }

TIG

Jim, your adding file:/// idea works for Mac.
I can now execute a suitably worded 'cmd' file on a PC OR '.command' file on a Mac (chmod 0777) using UI.openURL(path) - this let's me open an application and give it arguments [paths inside "" on PC and escaped "" on Mac...]

Thanks for the advice - I new it'd be something simple

Dan Rathbun

So what's the diff between chmod 0777 and 0755 ??

TIG

@dan rathbun said:

So what's the diff between chmod 0777 and 0755 ??

Not a lot really... in the way it will be used eventually - there are three levels of 'user' [owner/group/others], with Read/Write/eXecute for each set by 1/2/4 for each, added together for multi-layered options: so for ALL users to be able to RWX its 777, of course even 444 would make it executable by all***, but not readable or writable by any - with 777 anyone can RWX the script even if they don't have some mysterious 'membership' or 'rights' that I've missed: ***it doesn't matter too much as the .command file should be auto-erased after running anyway, but during beta-tests it's retained, so I can read its contents to see if it's getting made as expected; so then on the next run it needs to be 'Writable' by any users, so that's at least a 666 ? so it seems to me that 777 is best as it means absolutely anyone can Read/Write/Execute the script after it's been made [and kept temporarily]... Your suggested 755 would be Writable and Executable by all, but only Readable by its owner, which seems an odd choice since others might want to read it too ?

Ownership and permissions of Unix files are a minefield so I just set mine to the widest possible field of view...

Dan Rathbun

@tig said:

@dan rathbun said:

So what's the diff between chmod 0777 and 0755 ??

Your suggested 0755 would be Writable and Executable by all, but only Readable by its owner, which seems an odd choice since others might want to read it too ?

Are the fields backwards? (like big endian?)
The way I'd read 0755 is:
Executable by owner, group and all
Readable by owner, group and all
Writable by only the third significant value (depending on which is the Least significant value.)

@tig said:

Ownership and permissions of Unix files are a minefield so I just set mine to the widest possible field of view...

0777 makes sense.. of course.

TIG

The RWX order of setting is Owner/Group/Others so 755 is RWX for the file's owner and -WX for the group and also for 'others'.
Whereas 710 would be RWX for the file's owner, for the group [-R-] and no permissions at all for 'others' [---].
Then 744 would be a logical setting for making an executable file [--X] so that all others users can run but they can't alter, or even read - its owner has all permission though [RWX]. It it were owned by root [superuser] then it would be well protected.

Anyway, as you agreed, 777 covers all eventualities for a .command file that will be temporary in the final tool, but might be retained during testing and read/written/executed by anyone then...

driven

@dan rathbun said:

you can subthread it:
result = nil t = Thread.new { result = system(cmd, args) }

Dan this works brilliantly with applescript on a mac....

I've been going around in circles trying to run an applescript that needs to interact with SU, after being launched by SU.

I new I needed a separate thread, I just didn't to look for such a simple solution. cheers.

Something else I found on the 'journey' was to include the shebang, save it as plane txt NO extension, and set chmod ug+wr+x in /usr/local/bin/bht_su

Now it can the be called from terminal with just bht_su or SU with your
result = nil t = Thread.new { result = system("bht_su") }
SU returns
#<Thread:0x5664bc60 sleep>
so the question is, should I kill that thread, or is sleep enough...

t.kill appears to work?
#<Thread:0x5663b360 dead>

john

driven

@dan rathbun said:

If you want your "thing" to work on older SU versions, the API's thread-like UI.start_timer() block method may be a better choice.

I just ran my demo script on v5 and the thread running the shell works fine, funnily though...

The applescript that resizes the windows, for the demo, also runs it's own thread, it launches v8 and resizes it's windows, while, at the same time, v5 is recieving a stream of new messages.
I don't need to do the both at once in use and the Applescript could be Targeted better if needs be.

@unknownuser said:

If YOU get comfy with Threads on Mac (under Sketchup,) a tutorial may help others out.

Everything I've found and tested works so far. The difference's between Thread.new, Thread.fork, Thread.start
are a bit confusing as sometime they behave identically, and at other times only .new will work. When I work out why I'll report back...
john

Dan Rathbun

Well I am NOT an expert on threads.

Doc: http://www.ruby-doc.org/core-1.8.6/Thread.html

What we DO know is that they were CRAP on PC with Ruby v1.8.0

They are better, in v1.8.6-p287, likely even better in v1.8.7 branch.

But they are still Green threads, not native threads (at least on PC.)
I'm not sure if Apple tweeked the Ruby editions they install on Macs, and what 'kind' of threads you get, on Apple platforms.

If you want your "thing" to work on older SU versions, the API's thread-like UI.start_timer() block method may be a better choice.

Otherwise... if the rdocs are too techno.. check out all the books on Ruby. Maybe tutorials on the web.

We've avoided them on PC because they were too problematic (... likely because PC Sketchup was running Ruby v1.8.0 for so many versions.)
I never (on my machine,) ran Sketchup with the obsolete initial release of v1.8.0; always something >= v1.8.6-p111
~
If YOU get comfy with Threads on Mac (under Sketchup,) a tutorial may help others out.