Here's a bit that will change the default text creator for files generated from MacPerl scripts, using MacPerl toolbox calls... if you're afraid of ResEdit or whatever (it's free so there's no reason not to have it ;), you might want to give it a go... it has minimal error/sanity checking, so use at your own risk... I've tested it and it works fine for me, excepting the following: My question/observation is: this works just fine for the MacPerl app, but fails at ChangedResource when invoked in MPW with the perl tool... perl -MMac::Resources -MMac::Memory -e 'print CountResources( "GU·I" )' on the command line prints 1, so it's there somewhere, I just can't seem to act on it. I remember seeing here some time ago that the tool has much less support for the toolbox modules than the app... so, ummm, _how_ much less, and where will this be most noticable? It occurred to me that maybe the script is seeing the tool's GU·I resource, but has the shell's resource fork as the current one... is this the problem? Obviously I could change it to check for and set the proper resource fork to act upon, but the question is essentially, why won't the same script work with both the app and the tool? #!usr/local/bin/perl5 -wl use Mac::Memory; use Mac::Resources; use strict; use vars qw( $creator $gusi ); use subs qw( changeRez ); ( $creator ) = @ARGV; if ( !$creator ) { print "ÈÈ Enter FourCharCode of desired text creator"; print "ÈÈ Alpha (FourCharCode = ALFA) and BBEdit (FourCharCode = R*ch) are two of the more popular ones"; chomp( $creator = <STDIN> ) } $creator =~ s!^["']*(.*)["']*$!$1!g; # we don't need no steenking quotes # of course if you knew the hex code already, # you probably would have done this task long ago with ResEdit ;) # but we try to get a FourCharCode from a (possible) hex code anyway if ( length $creator != 4 ) { $creator = pack ( "H*", $creator ) } length $creator == 4 ? changeRez : die "Invalid creator code [$creator] entered"; sub changeRez { if ( defined( $gusi = GetResource( "GU·I", 10240 ) ) ) { $gusi->set( 4, 4, $creator ); if ( ChangedResource( $gusi ) ) { # fails here with the perl tool if ( WritePartialResource( $gusi, 4, 4 ) ) { print "New text file creator is: ", $gusi->get( 4, 4 ) # get the code from the rez just to be sure it got there, # though I'm not sure how useful this check really is } else { die "Couldn't update GU·I resource, try ResEdit..." } } else { die "Couldn't set resChanged bit on GU·I resource, try ResEdit..." } } else { die "Couldn't get GU·I resource, try ResEdit..." } } END { ReleaseResource( $gusi ) if defined( $gusi ) } __END__ the resource name (GU·I) may be mangled in transit... by keystroke it's: shift-G, shift-U, option-W, shift-I also, how absolutely necessary is the ReleaseResource call? It's unclear in the Mac::Resources pod what sort of cleanup occurs at the exit of a script... I could see the need if I were manipulating lots of resources and resource files in a session, but I want to know if the toolbox modules or MacPerl provide any sort of automagic cleanup at exit... looking at MacPerl in ZoneRanger, I have seen all sorts of unreleased handles hanging about, containing, among other things, scripts that had been executed and exited long before (in the same session of course)... and with that, it's back to the grind for me... cheers, Dave ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch