Creation of folder from Ruby on Mac
-
John,
Thanks.
Then the next thing to check if whether a Ruby script can create a directory under the /users/...hierarchy (pointed to by HOME).
If so, then, I'll store the parameters in this part, whether Sketchup is installed in /users or /applications.
Fredo
-
I think this is the crux of the issue,
SU 2013 writes nothing to the
> FileTest.writable_real?("/Library/Application Support/SketchUp 2013/SketchUp") false
plugins are either in the app bundle or written to
> FileTest.writable_real?(File.expand_path("~/Library/Application Support/SketchUp 2013/SketchUp")) true
it also appears that though loaded they don't 'auto run' on load from /Plugins.This does appear to be different, from v8
the same tmp paths are still all accessible, but not immediately on load.
I can get it to auto run on load from "~/Library/Application Support/SketchUp 2013/SketchUp/Tools", but only because I have another script that writes that Directory for me, and SU auto loads/runs my startup files that are in it.
-
Fredo
Of course a user should be able to make a new directory in one of the user's 'own' folders.
After all it would be pointless having permissions set to prevent a user writing things into their own folders. Conversely it's a good idea to protect system/program folders from indiscriminate changes by general users...As I mentioned several posts back, the premade user's folders for making temporary files, OR subfolders within this to keep you files together, is the ../Local/Temp/ folder or the MAC ...xxx/T/ equivalent.
The location one level down from that can be used for the permanent subfolder+files from your tool as this isn't auto-purged during system cleanups... ../Local/ or ...xxx/I don't see you concern, these folders are designed to do exactly what you intend, so permissions should always be OK...
-
@driven said:
I think this is the crux of the issue,
SU 2013 writes nothing to the
> FileTest.writable_real?("/Library/Application Support/SketchUp 2013/SketchUp") false
maybe you didn't give it the proper path? because when i put this in the console:
FileTest.writable_real?("/Users/jeff/Library/Application Support/SketchUp 2013/SketchUp/plugins")
it returnstrue
that's the exact path i was given upon entering the line from TIG--
Sketchup.find_support_file('plugins')
-
@unknownuser said:
maybe you didn't give it the proper path? because when i put this in the console:
@ Jeff, both paths are there, one for the user path [shows true] and one is showing that the 'old' System/Library/path doesn't exist anymore, so it's the same as doing
which returns...
%(#4000BF)[Google SketchUp 6
Google SketchUp 7
Google SketchUp 8
SketchUp 5]where
returns
%(#008000)[Google SketchUp 6
Google SketchUp 7
Google SketchUp 8
SketchUp 2013
SketchUp 5]SketchUp 2013 is only in the User path, as you have shown...
john -
I think it's something else that has changed, I can still write files anywhere I want, if triggered by a user action after SU has loaded.
before, I could just run a script on load, so the simplest example, if saved as hello.rb
UI.messagebox("Hello from Plugins")
it would run as soon as SU loaded it from either Plugins folder, but it doesn't now.if I use
load "/Users/johns_iMac/Library/Application Support/SketchUp 2013/SketchUp/Plugins/hello.rb"
from 'Ruby Console' it runs.If your trying to write to temp 'on load' it won't work from 'Plugins' anymore. It's not the destination that's at fault, it simply won't run.
john
EDIT: found what had changed, but I'll leave this up anyway, I had v2013 Plugins turned 'off', from another script... DOH so it will run and write from the ~/Library/path to 'Plugins' -
@driven said:
@ Jeff, both paths are there, one for the user path [shows true] and one is showing that the 'old' System/Library/path doesn't exist anymore, so it's the same as doing
SketchUp 2013 is only in the User path, as you have shown...
johnright.. i think you missed the point of my post though..
you got FALSE whereas i got TRUE upon using
FileTest.writable_real?
and we were both aiming for the same folder (the 2013 folder)ie- i had /Users/jeff in front of my path and your path started at /Library.. the front end was truncated
[edit].. i'll also point out that using the tilde instead of /users/jeff returns false
> FileTest.writable_real?("~/Library/Application Support/SketchUp 2013/SketchUp/plugins") false
-
@unknownuser said:
[edit].. i'll also point out that using the tilde instead of /users/jeff returns false
that's why I used
FileTest.writable_real?(File.expand_path("~/Library/Application Support/SketchUp 2013/SketchUp"))
which returns
True
, because theFile.expand_path("~/Library/Application Support/SketchUp 2013/SketchUp")
bit returns
/Users/johns_iMac/Library/Application Support/SketchUp 2013/SketchUp
, so when combined it gives the same result as hard coding, but will work for any user.The real point I was trying to make is that any 'Plugin' that's hardcoded to use "/Library/Application Support/SketchUp [n]/SketchUp/" will fail in v2013 because that 'Folder' is not created by v2013.
So, given that the only pathout is from /Users/ why would there be any permission issues at all, unless something has been 'turned' off by 'System' or the user.
Even with
Sketchup.plugins_disabled?
returning
true
FileTest.writable_real?(Sketchup.find_support_file('plugins' || 'Plugins' ))
returns
true
no matter what I try, I can't get this to fail writing a new file in a new folder in 'Plugins'
if saved in ~/Library/Application\ Support/SketchUp\ 2013/SketchUp/Plugins/from_v2013_plugins.rb
begin home = File.expand_path(File.dirname(__FILE__)) test_dir = home + "/!Test_Folder" Dir.mkdir(test_dir) unless FileTest.exists?(test_dir) path = File.join( test_dir, "/from_v2013_plugins_file") file = File.open(path, "w") file.write(Time.now.to_s + "\n" + "FileTest.writable_real?('/tmp') = " + (FileTest.writable_real?("/tmp")).to_s + "\n" + "FileTest.writable_real?(ENV['TMPDIR']) = " + (FileTest.writable_real?(ENV['TMPDIR'])).to_s ) rescue IOError => e #some error occur, dir not writable etc. ensure file.close unless file == nil end
and it's text is
%(#0000FF)[Sun May 26 23:08:59 +0100 2013
FileTest.writable_real?('/tmp') = true
FileTest.writable_real?(ENV['TMPDIR']) = true]
so, all three paths are writable_real? from a ruby script from either /Users/johns_iMac/Applications/SketchUp 2013 or from /Applications/SketchUp 2013 -
yeah.. i don't know..
the question by fredo is
can you create a folder on mac via ruby or not?
@fredo.. can you make a little script or snippet to test with?
-
@unknownuser said:
can you create a folder on mac via ruby or not?
Yes, using the ruby snippet in my last post [ saved as a .rb file ], I can create both a Folder and a file from a ruby script in the Plugins folder.
@Jeff it should work on yours as well.
@Fredo, is there any pattern to what's failing?
john
-
I don't understand Fredo's issues here...
I already make/use different 'personal subfolders' on PC AND MAC to store temporary files, AND also permanent files: they are automatically made for each User in straightforward Ruby Code.
I gave detailed examples in my earlier post - lifted almost verbatim from the SCF tools loader .rb, I just edited out some module specific Constants...
The 'Plugin Store. for example has ..Local/Temp/SCF/ PC||MAC ...xxx/T/SCF/ folders to take the temporary RBZ files etc during auto-install processing and the ..Local/SCF/ PC||MAC ...xxx/SCF/ folders to take the 'encrypted login cookie' that's used so you don't have to login with every visit ! -
All I am trying to figure out is an alternate location where to create the DEFPARAM_Dir folder, since for some Mac users, it seems not to work in the SU Plugins area on Mac.
I was just wondering is the Mac has some sophisticated security whereby certain file operations are prohibited from scripts, even if you can perform them manually (like create a folder).
If not, then we are left with the normal access rules and I imagine that the /users rootpath is normally enabled for writing.
Fredo
PS: thanks to the contributors. I have to ask as I don't have a Mac currently.
-
@fredo6 said:
All I am trying to figure out is an alternate location where to create the DEFPARAM_Dir folder, since for some Mac users, it seems not to work in the SU Plugins area on Mac.
Basically, if you can't write to there, it's hard to find somewhere else with 'lesser' permissions.
I think it will work for more people where it is, as far as I can find, this should only be an issue on 'Guest Accounts' that have file access restrictions enabled by an administrator. [maybe Corporations/Uni's etc..]
You can test for 'admin' quite easily [code below] and use a MB or similar for those without them...@unknownuser said:
I was just wondering is the Mac has some sophisticated security whereby certain file operations are prohibited from scripts, even if you can perform them manually (like create a folder).
It has lots, but for the majority of users, as long as it's in the 'User' domain it's actually a lot more complicated to limit access then allow it. App SandBoxing may come into play in a few cases.
@unknownuser said:
If not, then we are left with the normal access rules and I imagine that the /users rootpath is normally enabled for writing.
I think you should go with that assumption, and maybe add some simple test to you logfile RE:admin
always happy to help keep your plugins working on macs
john
This checks I'm an admin and writes to your folder from wherever I load your folder from.
not the best coding, but works from a variety of accounts that I have access to.def isAdmin user = %x( whoami ).chomp! admins = %x( dscl . read /Groups/admin GroupMembership ).chomp! iSadmin = (admins.scan user) == user.to_a end begin home = (File.dirname(__FILE__)) test_dir = home + "/DEFPARAM_Dir" if not FileTest.writable_real? test_dir UI.messagebox("You need an administrator to modify defaults!") if not isAdmin else path = File.join( test_dir, "/from_v2013_plugins_file") file = File.open(path, "w") file.write( Time.now.to_s ) end #if rescue #some error occur, dir not writable etc. ensure file.close unless file == nil end
-
-
Yes
Dir.mkdir(test_dir) unless FileTest.exists?(test_dir)
works fine,
john -
@driven said:
Yes
Dir.mkdir(test_dir) unless FileTest.exists?(test_dir)
works fine,
john
That is the normal way to test if a folder/file exists and then if not you make it etcBUT I recommend an alternative...
On a PC with the current Ruby version operations like File.exist? etc can report 'false' even when it does exists, consequently causing an error when you try to make it and it's there ! - this occurs when the path contains non-ASCII characters - which is possible in user-names in the path to the Temp folder etc. I think MACs are more tolerant of characters? BUT we want a 'cross-platform' solution...
The simplest way is to always make it, trapping the error if it fails because it exists !begin;Dir.mkdir(test_dir);rescue;p'Dir exists';end
I just added the p 'puts' so you can see what happens in the RC...
-
@TIG,
that works here as well, but it doesn't really tell you why it's failed.can further checks be done in the 'rescue' to pin-point any issue
e.gUI.messagebox("Houston, we have a problem") if not FileTest.writable_real? test_dir UI.messagebox("You are not an administrator on this computer") if not isAdmin?
which brings up a few questions, is there a PC equiv. for?
def isAdmin? user = %x( whoami ).chomp! admins = %x( dscl . read /Groups/admin GroupMembership ).chomp! iSadmin = (admins.scan user) iSadmin == user.to_a end
is
FileTest.writable_real?
any more reliable on a PC?john
-
You normally won't need to know why it failed - of course you can puts the error message into the RC etc BUT why would a users temp folder tree limit writability anyway - it's where apps etc store their temp files ?
All my snippet was doing was avoiding the PC issue - where File.exist? returns 'false' when the file or folder actually exists, but there are non-ASCII characters in its path - like a 'usér-name'.
There's no other way of ensuring you 'make' the missing file / folder otherwise...
If File.exist? says 'false', BUT it really exists then Dir.mkdir will fail as you can't make a directory if it already exists, so isn't it best to always try and make it ? -
@tig said:
You normally won't need to know why it failed
I was thinking more for a standalone debug script to try and find why these edge cases are failing.
john
Advertisement