Hidden Characters?

I would be interested in knowing what OS and version you are using, the type of filesystem you're using there, and a clarification that the script you're seeing this error with is a Perl script and not another executable. Seeing your #! line and knowing the location and version of your Perl executable might be interesting also.

Actually, this idea that it might be caused by strange Win32 characters staying in the file might be right. I'm running the script on FreeBSD 4.1.1 with Apache, but I do most of the editing on a Win98 machine using Homesite. I don't ftp the script to the BSD box, because I have Samba running on it, and so access the box through a share.

The error is definitely with the script, not with another executable.

The #! line is:
#!/usr/bin/perl -w
and using Perl 5.

Both of you share this theory, so I suppose it isn't groundless, but it is inconsistent with the nature of the error message itself. The message "Text file busy" is a system error message given exceedingly rarely and under very specific circumstances.

He was running Linux, you're running FreeBSD, so it's unlikely an OS thing or a filesystem thing. "Perl 5" doesn't help nail down a common version there (5.00503? 5.004? 5.6.0?).

Try doing what he did when you get this error message. Try just copying the file to a new name and copying it back (using a simple 'cp'). If the problem goes away, it's very unlikely that it has anything to do with the content. If it doesn't fix it, then it could possibly be content-related.

So if we eliminate the OS, eliminate the filesystem (by eliminating the OS), and eliminate the content, the only thing left is the "way" that the file was saved or a bug with Perl. We'd need to do more investigating.

If you have 'strace' or 'truss' on your system, I would be very interested to see precisely what syscall is involved in that error message. If it's acting on a file descriptor, back-track until you can find the open statement involved.

Linebreaks shouldn't scare the Perl interpreter too much (except with comments), but here's my XP with the troubles Windows pc's have when confronted with Unix textfiles:

They'll appear as one long line in programs like Notepad, with their original linebreaks displayed as a couple of black block-like character.

To solve this, there are two solutions:

• FTP in ASCII mode
• Open and Save the file in EDIT.COM (which is, IMHO, the only 'not-entirely-bad' MS program ;-)

To my knowledge, Windows textfiles (with \n\r) display correctly on Unix systems, but there is usually a script to convert to and fro these formats.

> there is usually a script to convert to and fro these formats

Of course, there's always perl:

perl -pi -e 's/\r//' file.txt      # for windows to unix
perl -pi -e 's/\n/\r\n/g' file.txt # for unix to windows
[download]

If you use this frequently under unix, you can alias it to something like:

alias w2u="perl -pi -e 's/\n/\r\n/g' "

Then you'll be able to just do w2u file every time you want to convert a file.

Please note: I haven't been able to check the unix to dos way as I don't have perl installed on my windows machine at home. Please let me know if it doesn't work.

My usual solution is to open in vim on both platforms.
Perl doesn't care about types of white space, so why should my editor?
I'd assume emacs does the right thing as well.

And I have to ask... Are these programs for the Harris Pagination system??

Well, sometimes. There are three scripts involved in the whole enterprise. The main routine (build.cgi) calls another called buildpag.cgi and buildpag.cgi calls harrisfilter.cgi. I've gotten this error on all three of the scripts at various times. I execute the main script using a web interface, so technically there is a process responsible for executing it too.

No other programs should have pipes to these files.

Yep, one of the child processes is for filtering raw Harris Pagination files. I'm trying to create a content management system for the web, where almost all of our content comes out of Harris. I'm going to give all these suggestions a shot and see if I can eliminate the problem by taking steps to ensure that no windows characters sneak in the files. I think Windows usually inserts a ^M or something like that at the end of each line.

I'll let you know what happens ...

I work for a newspaper that uses Harris, you might have even used my HCGUI program for monitoring. Let me know who you are and I'd love to compare Harris notes.
jmaggard@timesdispatch.com