Aborting a .rbz install
-
On the mac this removes everything, except my main targets
i.e the primary folder is retained containing a [dot] folder containing a mac binary file
I getError: #<Errno::ENOTEMPTY:
The question is, would Windows 'protect' these file types or would they be deleted as well?
if( ( RUBY_PLATFORM =~ /darwin/i) ) UI.messagebox("\n This code is for Mac only! \n It will not run on Windows or Linux \n Loading will now abort \n Contact the Author if you wish to port the source \n ") path = File.expand_path(__FILE__) dirname = path.sub(".rb", "") Dir[(dirname + "{**/**/**/*")].sort.reverse.each do | p | if File.directory? p then Dir.rmdir p elsif File.exists? p then File.delete p else end end File.delete path Dir.rmdir dirname return nil end
john
-
On a PC [and MAC?] this deletes a folder, even with deeply nested folders/files
def self.delete_folder(d) return nil unless File.directory?(d) Dir.entries(d).each{|f| next if f=='.' || f=='..' x=File.join(d, f) if File.directory?(x) self.delete_folder(x) else ### file File.delete(x) end } begin Dir.delete(d) rescue ### fails if it's not empty! self.delete_folder(d) end end
Usage:
self.delete_folder(full_path_to_folder_to_delete)
You can't delete the . or .. entries in a folder, BUT you can delete an empty folder that only contains those two entries... It has the 'self.' only because I had this example in a module... -
cheers,
I got it working by 'naming' the difficult ones
but I'll have a play with your version tomorrow...I think it's worth not loading the binary into a PC, even if it won't hurt...
your up late
john
-
Deleting it seems like overkill, you could employ something like this instead
module AuthorModule def self.is_mac?() # ... end module PluginModule end if is_mac? mac_only_warning unless is_mac? end
Or in the extension file
if is_mac? extension = # ... else mac_only_warning end
-
having 'only works on mac' should be enough, but never is.
I'm just wanting to avoid the 'this isn't working' posts from 'PC' users.
Beside anything else, it would be trivial for SU to pre-screen for files marked as os dependant.
john
-
@driven said:
having 'only works on mac' should be enough, but never is.
I'm just wanting to avoid the 'this isn't working' posts from 'PC' users.
Beside anything else, it would be trivial for SU to pre-screen for files marked as os dependant.
john
Note the
if is_mac?
at the end ofPluginModule
. That will prevent the plugin from "loading" anything more. Same if you just don't register theSketchupExtension
. You could also write a setting to prevent it re-showing the message usingSketchup.write_default
/Sketchup.read_default
Edit: Demo
module MyModule puts "This section will never be executed!" end if false # because of this! puts "But this will!" puts defined?(MyModule)
Gives
But this will! nil
-
BUT we are trying to stop an RBZ install of a plugin onto an incompatible OS [a relatively rare occurrence?]...
So we need to check the OS early on, then tell the user what we are doing and delete the files/subfolders of files that ship in the RBZ [including itself!] ans stop loading anything at all.
It pointless having a plugin installed into an OS where it won't work... -
@aerilius said:
.. or maybe the plugin folder is synced with another system on which the plugin is supposed to be used).
Excellent point I hadn't considered.
I was already leaning towards adding the [ is_mac? ] to the menu/toolbar loader, which which will prevent unusable menu items when on the wrong platform...
As my plugin's 'logic' is dynamically loaded into SU by either of these items being 'clicked', then it will also remain inert without any additional screening.
This, in addition to setting the extension i.e.
Sketchup.register_extension( add_icon_to_mac_skp, false) unless is_mac?
should accommodate a shared Plugin folders.further thoughts?
john
-
If you have mixed OSs on a network which share plugins you are making some issues for yourself...
Only a few plugins ship in PC and MAC 'version's anyway, and handle OS differences within their methods...
So just allow the plugin to install on any OS...
but as suggested... test in the main 'loader' for the appropriate OS and only set up its Extension if there's an OS match...
That way you could have it installed on a shared folder that resides on a PC, that can never actually load it, but it can successfully load from that shared folder if it's called by a MAC etc...
-
Are there no risks when messing around with file deletions?
[If such a method existed] I would prefer to use corresponding API methods for (un)installation, or more generally put:
The same method for uninstallation that was used for installation (by hand, API or EWH).What is the problem of keeping the plugin and just telling the user about the issue. This gives the clearest explanation and the least surprise. Also the user could maybe have reasons to keep the plugin installed without using it actively (like only inspecting how it works, or maybe the plugin folder is synced with another system on which the plugin is supposed to be used). Suddenly disappearing files would rather make a user worried and would blur the line between good software and malware.
Edit: Another thing is: Using ruby to delete files circumvents the trash. If we let the user manage "his" files (that the user installed), there is the chance to restore them.
-
one last idea
what happens on Windows if I add this to the top of each scriptwindows use = nil
If done correctly on a mac it returns nil and the ruby continues.
@unknownuser said:
you cantype non-breaking spaces directly on OS X with Option+Space.
I'm under the impression Windows will see it as a space and error out
Error: #<NoMethodError: undefined method
windows' for #Object:0x56b89ec>`If so, I can add it and even if the file/folders are there, nothing will run unless your on a mac...
pilfered from here:
http://www.rubyinside.com/the-split-is-not-enough-whitespace-shenigans-for-rubyists-5980.html -
@driven said:
I'm under the impression Windows will see it as a space and error out
Error: #<NoMethodError: undefined method
windows' for #Object:0x56b89ec>`Depends what encoding you save it in.
Western (Windows 1252) gives this:
Error; #<SyntaxError; (eval);5231;in `load'; path/to/nbsp.rb;1; Invalid char `\240' in expression>
UTF-8, however, will load and work fine
windows use = "o.~" puts "Success #{windows use.inspect}" # -> load 'path/to/nbsp.rb' Success "o.~" true
Note: Browsers will replace the character in question (160, "non-breaking space") with a regular space (32, "space"), but I did correct for this for this test.
Advertisement