Home > Archive > PERL Miscellaneous > May 2005 > a perl script crashed my mac!
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
a perl script crashed my mac!
|
|
| ioneabu@yahoo.com 2005-05-24, 3:58 pm |
| I have a directory with about 15000 files. About 11000 have .txt
extensions. The files are saved in a directory on an external usb2
hard drive connected to my iBook G4 running OS X 10.4.
I wanted to clear out any files that were not .txt. I ran this script:
#!/usr/bin/perl
use strict;
use warnings;
my $dir = $ARGV[0]; #directory to search under
use File::Find;
find(\&wanted, $dir);
sub wanted
{
unlink if not /\.txt$/
}
Within less than a second, my screen went to a darker shade and a
message appeared telling me that I must turn off my computer by holding
down the power button. I have never seen an OS X computer crash until
now. I repeated the process with the same outcome.
Thanks!
wana
| |
| John W. Krahn 2005-05-24, 8:56 pm |
| ioneabu@yahoo.com wrote:
> I have a directory with about 15000 files. About 11000 have .txt
> extensions. The files are saved in a directory on an external usb2
> hard drive connected to my iBook G4 running OS X 10.4.
>
> I wanted to clear out any files that were not .txt. I ran this script:
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> my $dir = $ARGV[0]; #directory to search under
> use File::Find;
> find(\&wanted, $dir);
>
> sub wanted
> {
> unlink if not /\.txt$/
> }
>
> Within less than a second, my screen went to a darker shade and a
> message appeared telling me that I must turn off my computer by holding
> down the power button. I have never seen an OS X computer crash until
> now. I repeated the process with the same outcome.
It could be because you are trying to unlink directories.
perldoc -f unlink
unlink LIST
unlink Deletes a list of files. Returns the number of files
successfully deleted.
$cnt = unlink 'a', 'b', 'c';
unlink @goners;
unlink <*.bak>;
Note: "unlink" will not delete directories unless you are
superuser and the -U flag is supplied to Perl. Even if these
conditions are met, be warned that unlinking a directory can
inflict damage on your filesystem. Use "rmdir" instead.
If LIST is omitted, uses $_.
Use the file test operators to ensure that only files are being unlinked.
perldoc -f -X
John
--
use Perl;
program
fulfillment
| |
| Christopher Nehren 2005-05-25, 3:58 am |
| On 2005-05-24, John W. Krahn scribbled these
curious markings:
> ioneabu@yahoo.com wrote:
>
> It could be because you are trying to unlink directories.
If attempting to unlink a directory caused the kernel to panic, then I
pity Mac users.
I'd personally solve this problem like so (no real need for perl):
find . -type f -maxdepth 1 -not -iname '*.txt' -print0 | xargs -0 rm
Execute this from within the directory containing the files to remove.
You can remove the -print0 and -0 if your file names don't contain
spaces or other nasty characters (mostly shell metacharacters).
Best Regards,
Christopher Nehren
--
I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated". -- Ken Thompson
If you ask the wrong people questions, you get "Joel on Software".
Unix is user friendly. However, it isn't idiot friendly.
| |
|
| Christopher wrote:
"If attempting to unlink a directory caused the kernel to panic, then I
pity Mac users. "
That's probably not the whole story. What if the OP was inadvertently
trying to unlink the directory containing the script? Or the script
file itself?
But that, I suppose, would not be reproducible
John C.
| |
| Josef Moellers 2005-05-25, 8:56 am |
| John wrote:
> Christopher wrote:
>=20
> "If attempting to unlink a directory caused the kernel to panic, then I=
>=20
> pity Mac users. "
>=20
> That's probably not the whole story. What if the OP was inadvertently
> trying to unlink the directory containing the script? Or the script
> file itself?
>=20
> But that, I suppose, would not be reproducible
"To make an assumption means to fool yourself"
The OP has supplied little information, e.g. he hasn't named the name of =
the directory (could have been important) he hasn't described whether=20
any files were deleted at all, ...
He could have reproduced the problem by re-typing the script (it was=20
little more than a one-liner)!
--=20
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize
-- T. Pratchett
| |
|
| ioneabu@yahoo.com wrote:
> I have a directory with about 15000 files. About 11000 have .txt
> extensions. The files are saved in a directory on an external usb2
> hard drive connected to my iBook G4 running OS X 10.4.
>
> I wanted to clear out any files that were not .txt. I ran this script:
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> my $dir = $ARGV[0]; #directory to search under
> use File::Find;
> find(\&wanted, $dir);
>
> sub wanted
> {
> unlink if not /\.txt$/
> }
>
> Within less than a second, my screen went to a darker shade and a
> message appeared telling me that I must turn off my computer by holding
> down the power button. I have never seen an OS X computer crash until
> now. I repeated the process with the same outcome.
Well, the quoted program - with high probability - did NOT cause your
kernel panic because it doesn't compile, let alone execute.
So you need to tell the entire story ...
Steve
--
@_=map{eval"100${_}"}split/!/,'/5!*2!+$]!/10+$]';use Tk;$m=tkinit;$t='just an'.
'other perl hacker';$z='createText';$c=$m->Canvas(-wi,$_[1],-he,25)->grid;$c->$
z(@_[2,3],-te,$t,-fi,'gray50');$c->$z($_[2]-$],$_[3]-$],-te,$t);$m->bind('<En'.
'ter>',sub{$y=int(rand($m->screenheight));$m->geometry("+$y+$y")});MainLoop;
| |
| Anno Siegel 2005-05-25, 3:56 pm |
| lusol <lusol@iMac-C.CC.lehigh.EDU> wrote in comp.lang.perl.misc:
> ioneabu@yahoo.com wrote:
>
> Well, the quoted program - with high probability - did NOT cause your
> kernel panic because it doesn't compile, let alone execute.
What problems do you see with the code? I don't see any.
Anno
| |
| ioneabu@yahoo.com 2005-05-25, 3:57 pm |
|
John wrote:
> Christopher wrote:
>
> "If attempting to unlink a directory caused the kernel to panic, then I
>
> pity Mac users. "
>
> That's probably not the whole story. What if the OP was inadvertently
> trying to unlink the directory containing the script? Or the script
> file itself?
>
> But that, I suppose, would not be reproducible
>
> John C.
It is likely that the problem was caused by attempting to unlink a
directory. I don't know if the crash would have occurred if I was not
working on the external drive.
Is it possible that even if there were no directories contained in the
working directory that my program would have worked on . and .. and
treated them as directories?
The script was outside of the working directory and was uneffected by
its own actions.
I hate to try it again on my iBook. It's depressing to see it crash.
A flashback to the old days of my Mac SE that I put bad memory chips
into and saw the very  dening ' mac'.
wana
| |
|
| Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> lusol <lusol@iMac-C.CC.lehigh.EDU> wrote in comp.lang.perl.misc:
>
> What problems do you see with the code? I don't see any.
Via copy/aste, I get:
[lusol@dragonfly:/tmp] cat > frog
#!/usr/bin/perl
use strict;
use warnings;
my $dir = $ARGV[0]; #directory to search under
use File::Find;
find(\&wanted, $dir);
sub wanted
{
unlink if not \.txt$
}
[lusol@dragonfly:/tmp] emacs -nw
[1]+ Stopped emacs -nw
[lusol@dragonfly:/tmp] perl frog
syntax error at frog line 12, near "\."
Execution of frog aborted due to compilation errors.
[lusol@dragonfly:/tmp]
Perhaps missing characters when read via tin???
>
> Anno
Steve
--
@_=map{eval"100${_}"}split/!/,'/5!*2!+$]!/10+$]';use Tk;$m=tkinit;$t='just an'.
'other perl hacker';$z='createText';$c=$m->Canvas(-wi,$_[1],-he,25)->grid;$c->$
z(@_[2,3],-te,$t,-fi,'gray50');$c->$z($_[2]-$],$_[3]-$],-te,$t);$m->bind('<En'.
'ter>',sub{$y=int(rand($m->screenheight));$m->geometry("+$y+$y")});MainLoop;
| |
| Sherm Pendley 2005-05-25, 8:56 pm |
| ioneabu@yahoo.com wrote:
> It is likely that the problem was caused by attempting to unlink a
> directory. I don't know if the crash would have occurred if I was not
> working on the external drive.
I tried deleting a directory various different ways on my internal hd
using Perl's unlink() function, and I couldn't cause such a crash. Nor
was I surprised at that - frankly, I would have been surprised if such a
heinous bug *was* present in the core OS.
It's much more likely to be a bug in either the USB2 driver or the file
system driver.
Is the external device a "dual purpose" device that works on both Mac OS
X and Windows? If so, it's probably using FAT32. If that turns out to be
the case, and you don't care about Windows support, try reformatting the
drive with HFS+.
Otherwise, try repeating your experiment on an internal and/or Firewire
drive (if you have one).
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
| |
|
| ione wrote:
Is it possible that even if there were no directories contained in the
working directory that my program would have worked on . and .. and
treated them as directories?
Doesn't seem possible. Like Christopher, I would tackle the original
problem from the shell.
I wouldn't have solved it as elegantly as he did, and I wouldn't have
covered all cases, but if there are no subdirectories to worry about,
this ought to work:
$ mkdir ../temp
$ mv *.txt ../temp
$ rm *
$ mv ../temp/* .
$ rmdir ../temp
- John C.
| |
| Anno Siegel 2005-05-25, 8:56 pm |
| lusol <lusol@iMac-C.CC.lehigh.EDU> wrote in comp.lang.perl.misc:
> Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
[color=darkred]
>
> Via copy/aste, I get:
>
> [lusol@dragonfly:/tmp] cat > frog
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> my $dir = $ARGV[0]; #directory to search under
> use File::Find;
> find(\&wanted, $dir);
>
> sub wanted
> {
> unlink if not \.txt$
^^^^^^
I see the indicated bit differently.
> }
[...]
> Perhaps missing characters when read via tin???
Apparently. For me "\.txt$" is enclosed in //, which makes it a legal
pattern match.
Anno
| |
|
| Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> lusol <lusol@iMac-C.CC.lehigh.EDU> wrote in comp.lang.perl.misc:
>
>
> ^^^^^^
> I see the indicated bit differently.
>
>
> [...]
>
>
> Apparently. For me "\.txt$" is enclosed in //, which makes it a legal
> pattern match.
OK, then it works as advertised. We thus need more info from the OP
because Mac OS X so rarely kernel faults. We assume the OP is not doing
this sudo'ed on system files ;)
Thanks,
| |
| ioneabu@yahoo.com 2005-05-26, 3:59 pm |
|
John wrote:
> ione wrote:
>
> Is it possible that even if there were no directories contained in the
> working directory that my program would have worked on . and .. and
> treated them as directories?
>
> Doesn't seem possible. Like Christopher, I would tackle the original
> problem from the shell.
>
> I wouldn't have solved it as elegantly as he did, and I wouldn't have
> covered all cases, but if there are no subdirectories to worry about,
> this ought to work:
>
> $ mkdir ../temp
> $ mv *.txt ../temp
> $ rm *
> $ mv ../temp/* .
> $ rmdir ../temp
>
>
>
> - John C.
That is precisely the way I solved the problem after two consecutive
crashes with the script. I agree with everyone that the OS X kernel is
not at fault and certainly not Perl. The usb2 driver explanation seems
most likely.
I appreciate the interest in this unusual episode so I am going to
reproduce the experiment in a more controlled way, using two different
models of external hard drives, one with usb2 only and one with usb2
and firewire. I will attempt to unlink a single directory and see if
it happens. Then I will try with both drives, using usb2 and firewire
on the one that has both. I'll document my finding here later.
wana
|
|
|
|
|