Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`perl -i.bak -pe' works unreliably when a disk gets full #643

p5pRT opened this issue Sep 20, 1999 · 1 comment

`perl -i.bak -pe' works unreliably when a disk gets full #643

p5pRT opened this issue Sep 20, 1999 · 1 comment


Copy link

p5pRT commented Sep 20, 1999

Migrated from (status was 'resolved')

Searchable as RT1516$

Copy link

p5pRT commented Sep 20, 1999


Please note that I am sending this bug report from a different
machine than where I discovered the problem. I ran perlbug on
that machine long enough to just generate the content under
the do-not-edit line, and simply replaced the correct information
with the information from this machine.

And onto the problem​:
I was trying to do a simple command to strip out some information
from all of the log files in my current directory, and used the
following command​:
perl -i.bak -pe 's/^\[.*?\] //' referer.*Aug*

The problem is that each of these logfiles (approximately 50 of
them) are about 8 megs. This shouldn't be a problem in and of
itself, but here is what resulted​: it successfully went through
the first 30 files, creating a .bak as it went, however, when it
got to the 31st, the device they were on ran out of space. From
this point on, I don't feel like I could speculate about what
caused the problem, but here is what happened​: the screen spammed
a bunch of errors about the device being empty, and about not
being able to close <ARGV> successfully. (It seems strange to me
that there would be a FH called `ARGV', but I am pretty sure that
was the message.) What ended up happening was the first 30, as I
said before worked out fine, the next 13 files were all truncated
to zero bytes, and the remaining files were left untouched.

The files which were truncated to zero bytes did not have .bak
files created for them, so they were lost. I really wish I could
have given you the exact error message, but I didn't really think
I had run across soemthing until bringing up the problem in #perl,
where everyone unanimously agreed that I should submit this report.

Anyway, I hope I have given you enough information to replicate
the problem. If not, please feel free to send me an email requesting
more information at jerry@​

Perl Info

Site configuration information for perl 5.00404:

Configured by root at Wed Jun  9 16:27:42 CDT 1999.

Summary of my perl5 (5.0 patchlevel 4 subversion 4) configuration:
    osname=solaris, osvers=2.7, archname=sun4-solaris
    uname='sunos minnie 5.7 generic sun4u sparc sunw,ultra-5_10 '
    hint=recommended, useposix=true, d_sigaction=define
    bincompat3=y useperlio=undef d_sfio=undef
    cc='cc', optimize='-O', gccversion=2.8.1
    ccflags ='-I/usr/local/include'
    stdchar='char', d_stdstdio=define, usevfork=false
    voidflags=15, castflags=0, d_casti32=define, d_castneg=define
    intsize=4, alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -ldl -lm -lc -lcrypt
    libc=/lib/, so=so
    useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-fpic', lddlflags='-G -L/usr/local/lib'

Locally applied patches:

@INC for perl 5.00404:

Environment for perl 5.00404:
    LANG (unset)
    LOGDIR (unset)
    PERL_BADLANG (unset)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant