Rhino for Mac users can also write and execute Python scripts

This will probably work

import System
System.Diagnostics.Process.Start("/Applications/Atom.app/Contents/MacOS/Atom")

OK, that works… Thanks! The new script is:

import System
import rhinoscriptsyntax as rs
System.Diagnostics.Process.Start("/Applications/Atom.app/Contents/MacOS/Atom")
rs.Command("_StartAtomEditorListener")

Now, how do I edit the init script in Atom to open a specific .py file (say something like MacScriptDev.py) when it opens?

–Mitch

import System
System.Diagnostics.Process.Start("/Applications/Atom.app/Contents/MacOS/Atom", "~/Desktop/MacScriptDev.py")

Dang, I almost had it right before I posted, but I had it all in one string without the comma and just a space separator… Cool! --Mitch

Hey Mitch,

You can open a directory instead of a file:

System.Diagnostics.Process.Start("/Applications/Atom.app/Contents/MacOS/Atom", "~/Desktop")

That should give you a tree view pane on the left with all the files in your project. If the tree view isn’t there for some reason cmd+\ will open it.

Also you might want to use the shell commands instead:

 System.Diagnostics.Process.Start("/usr/local/bin/atom", "~/Desktop")

Your path may be different. Type

which atom

in a terminal witdow to view your path to atom.

OK, great info… Got it mostly working as I want, now, the last step - I want to have Mac Rhino default to a different folder for scripts - one in my Dropbox. If I understood correctly, the way to do this is to create a symbolic link via terminal?

Assuming I have a subfolder in my Dropbox folder /Scripts/PythonScripts/MacScripts - is the following correct?

ln -s "~Library/Application\ Support/McNeel/Rhinoceros/scripts" "~Dropbox/Scripts/PythonScripts/MacScripts"

And I guess the important thing to know is once a symlink has been created, how do you remove it if necessary?

Or is there a better, less geeky way to change the default scripts folder path? (doesn’t seem so…) Somehow, not having have a scripts search path setting in Preferences (as does Windows Rhino for rhinoscripts, templates, etc.) seems very unwieldy. Not having “General” and “Files” sections in Preferences makes things painful.

Lastly, back to the Atom editor - it doesn’t appear to have any debugger yet - or did I miss something?

–Mitch

My post above is a bit confusing and having a configurable path would be best (it’s on the todo list) but until then you can still manage your files in a useful way.

In your case you might not need symlinks or anything else. Let’s say you open atom this way:

System.Diagnostics.Process.Start("/usr/local/bin/atom", "~/Dropbox/Scripts/PythonScripts/MacScripts")

You can now right click on any python file in your tree view and send it to Rhino. That’s it you’re done! Unless …

There are special considerations when your files depend on each other, i.e., one file imports another. Let’s say this is your MacScripts directory:

./
  s1.py
  s2.py
  s3.py
  s4.py
mypackage/
  s5.py

Here’s the code:

#s1.py
import s2
s2.p()
#s2.py
def p(): print "s2"

Executing s1.py is no problem even though it imports s2 because s2.py is in the same directory as s1.py

#s3.py
import mypackage.s5
mypackage.s5.p()
#s5.py
def p(): print "s5"

Executing s3.py will only work if you create the __init__.py file (can be an empty file) in the mypackage directory.

Now imagine you have some files in a directory not related to your setup, i.e., that directory is not a subdirectory of ~/Dropbox/Scripts/PythonScripts/MacScripts or ~/Library/Application\ Support/McNeel/Rhinoceros/Scripts. In this case you create a symlink to make it a subdirectory of either one:

# link the directory under my project directory
cd  ~/Dropbox/Scripts/PythonScripts/MacScripts
ln -s /directory/somewhere/on/my/filesystem myotherpackage
#OR link it under the default search directory
cd  ~/Library/Application\ Support/McNeel/Rhinoceros/Scripts
ln -s /directory/somewhere/on/my/filesystem myotherpackage

#don't forget the __init__.py file
cd myotherpackage
touch __init__.py
#s4.py
import myotherpackage.s6
myotherpackage.s6.p()

Executing s4.py works.

Oh yeah, to delete a symlink:

#only deletes the link and not the underlying directory
rm myotherpackage

OK, thanks Alain ! I’m not a fan of importing other scripts as modules to run in a main script because of the portability issues, I prefer to have all self-contained. That’s just a personal preference of course, but I transfer my scripts around and hand them out to others pretty often.

I was mainly interested in the simlink for the ease of running finished scripts via an alias from the Rhino interface (not Atom). In Windows I run my most used scripts from either toolbar buttons or aliases, less used ones I run from the script editor after “looking them up” in my library.

On Mac, I will use Atom in the same way for less frequently used finished scripts and for Mac platform testing (most of my development will still be done on Windows). For more frequently used scripts, initially I will use aliases on Mac, not yet wanting to mess with toolbar modifications. Right now, if you want to use

! _-RunPythonScript Scriptname

as an alias, the script has to be in the default scripts folder. Otherwise, you need to put in the potentially long full path to the file.

So, all I really want to do is create a simlink to a different (Dropbox) folder where I store frequently used Mac-specific scripts for use via alias, I can then continue using the same compact syntax for my aliases…

Thanks, --Mitch

so did you get the symlink working?

something else you may want to do is put the (example) MacScripts folder in your finder sidebar… just drag&drop the folder into the ‘favorites’ section:

doing that, you’ll always have one-click access to the folder anytime a finder window is up… including all open and save dialogs… so if you want to run a non-aliased script via RunPythonScript, you just click on the folder in the sidebar as a shortcut to it instead of searching/navigating to it… the folder will also be available in Atom’s save dialog etc…

to remove the folder from the sidebar, just drag it out of the sidebar until a little puff of smoke appears and release the cursor… (doesn’t delete the folder…just removes it from the sidebar)

[edit]
though i suppose if you have the folder linked to rhino’s scripts folder, there will be no need to use the sidebar since the dropbox folder would open by default… so, maybe nevermind on that bit :blush:

Nope… When I try, all I get is a “No such file or directory” response from Terminal.

I can’t even change directory with cd ~/Library/Application\ Support/McNeel/Rhinoceros/Scripts. Same response. That directory does indeed exist, so something’s wrong there. Well, the Mac will forever remain a mystery to me…

–Mitch

here’s how i was able to get what you want to work…

I’m not 100% sure these naming things are necessary but it’s what i tried first and it worked (i did it this way because i assume rhino is looking for a folder called ‘Scripts’)

• delete the folder named ‘Scripts’ from ~/Library/Application Support/McNeel/Rhinoceros
(obviously, make sure any contents of the scripts folder are backed up elsewhere… after the symlink is created, this folder will be regenerated using one in your dropbox)

• name the folder containing the .pys in your dropbox ‘Scripts’

• in terminal, type ln -s <space> (don’t press enter yet)

• drag&drop the folder named Scripts from your dropbox to the terminal window

• drag&drop the folder ‘Rhinoceros’ to the terminal window (~/library/app support/mcneel/rhinoceros)

• click somewhere in the terminal window to bring focus to it then press return.

the line in terminal looks like:

ln -s /Users/Jeff/Dropbox/Scripts /Users/Jeff/Library/Application\ Support/McNeel/Rhinoceros

(i just drag&drop to terminal so i don’t have to guess at the expected syntax :wink: )
…but no cd necessary when doing it this way…

the symlink will now be created and the Scripts folder from dropbox will now also be in the rhino application support folder… rhino aliases to the scripts can be created the simple way etc…

it’s possible you’ll be able to have the dropbox folder named MacScripts as in your example then rename the linked folder in rhino application support to Scripts and have the link still active… i’ll try that out in a few hours.

–
add-
as far as i can gather, it’s okay if the folders have different names… so your dropbox can have Dropbox/Scripts/PythonScripts/MacScripts then in rhino’s app support, rename MacScripts to Scripts and the link will stay active…
(if you don’t have a folder named Scripts in rhino application support, a new empty Scripts folder will be created upon RunPythonScript while the alias ignores the symlinked folder)

–
fwiw, i did info ln in terminal to see what it wanted…

ln -[option] sourceFile targetFile (or directory)

That’s interesting… I was under the impression that the source file/target file order was the opposite from what you showed above on your system…

I will give it a shot again later, but my impression on all this is it’s just far too complicated to get correct, which is an indication that there is something that really needs to be changed, i.e. make it possible for the user to change the target folder for scripts from inside Rhino without making them jump through all these hoops. :unamused:

–Mitch

[quote=“Helvetosaur, post:33, topic:18150”]
That’s interesting… I was under the impression that the source file/target file order was the opposite from what you showed above on your system…

<img src=“https://global.discourse-cdn.com/mcneel/uploads/default/18383/dce40910c50060d7.png” width=“676” height=“174”> [/quote]

i think that says the same thing… original (source) first – symlink (target) second?

yeah, doing it from within the application would be simpler and more user friendly… that said, i did it to my other computer this morning and it took about 12 seconds… just a matter of figuring out how to do it the first time but once learned, it’s easy and fast.

i used to use a 3rd party utility to make symlinks (it adds ‘make symbolic link’ to the context menu) but i now think going to the terminal is nearly as simple without the need for downloading utilities.

I am like Mitch, I sync to a Dropbox folder from ‘default’ Scripts folder here at home and from work.

I have been using Synkron for the last few days. Just setting up a schedule now. I was looking to do either an iCal alarm Automator workflow or a AppleScript one when I discovered this app. Seems to work well the few times I tried it this weekend.

So until this is implemented, I will try the sync App, seeing it up to sync from home to Dropbox in the mornings I have to go to office and from Work computer to Dropbox in the afternoon.

Thanks all, always fun.
ÂŤRandy

Yeah, except this:

looks more like target – source… But what’s the source and what’s the target?

–Mitch

the source is the scripts folder in Dropbox.
the target is the rhinoceros folder in app support.

Source is the file you want to link from…the folder in Dropbox.

Target is the folder which is reading from the source… in this case, the scripts folder is reading from Dropbox

the first time I tried it, I used the script folder inside rhino app support as the target and it put the Dropbox scripts folder inside the rhino scripts folder…(ended up with two scripts folders) so that’s why I did it with the Rhinoceros folder as the target.

I just fixed the issues causing Mac Rhino to not remember the last folder used for running scripts between sessions.
http://mcneel.myjetbrains.com/youtrack/issue/MR-1153
http://mcneel.myjetbrains.com/youtrack/issue/MR-1387

This should show up in the next WIP (probably on Tuesday).
Happy Easter :rabbit:

1 Like

It looks like symlink (target) is the default Scripts folder ; in Jeff’s case /Users/Jeff/Library/Application\ Support/McNeel/Rhinoceros

and source would be his Dropbox ; /Users/Jeff/Dropbox/Scripts

That way you keep your Dropbox up to date from where ever you are and the default Rhino Scripts folder updates because it is just a link (Alias) of the Dropbox/Scripts.

I am in the process of pruning my scripts here and may actually set this up later. It seems more efficient once setup.

I hope I haven’t stepped on amy toes here and my thinking is correct. Off to enjoy some sun.
ÂŤRandy

OK, so that means if I first run a script from some folder (by browsing to the script manually, let’s say) then it will remember that folder until I run a script from somewhere else? Forever until I change it?

So an alias that looks like ! _-RunPythonScript MyScript will run if MyScript.py happens to be in the last folder used?

I like this idea better than the current situation where it always points to the default folder no matter what you do, but not as much as being able to configure a specific folder as the default folder. Because if it looks in the last used directory and you changed it for some reason, all your script aliases will then fail. :sob:

Sure, but the bug I fixed makes it possible for @Alain to add custom paths to the python plug-in now and these paths will be remembered between sessions.