nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Mystery iwperl file?

B80116

TeamSite 6.1, Windows 2000

We encountered an unusual (for us) problem this morning, and I'm posting here to see if anyone can provide any insight into the cause.

Shortly after 10 am this morning, the various Perl scripts we use in our TeamSite workflow external tasks and cgi tasks began hanging. We eventually traced the problem to the existance of a file called "iwperl" (with no file extension, size 0, and a timestamp of 10 am today) in our iw-home/iwperl/bin folder. The file "iwperl.exe" was also there, so it wasn't a case of having the display of file extensions turned off. When we deleted this file, the scripts once again started working.

Our theory is that some sort of system hiccup produced the rogue iwperl file, and our scripts, which begin with "#!d:\interwoven\iw-home/iw-perl/bin/iwperl -w", were trying to use the iwperl file instead of the iwperl.exe file.

Has anyone else encountered this problem, or have any thoughts about what caused it?

Thanks.

Find more posts tagged with

Comments

Migrateduser

Very strange, but are you sure that all of your files have the same shebang line (that is, "#!d:\interwoven\iw-home/iw-perl/bin/iwperl -w")?

Also, have you looked at the iwevents log and other logs?

nipper

TeamSite 6.1, Windows 2000

We encountered an unusual (for us) problem this morning, and I'm posting here to see if anyone can provide any insight into the cause.

Shortly after 10 am this morning, the various Perl scripts we use in our TeamSite workflow external tasks and cgi tasks began hanging. We eventually traced the problem to the existance of a file called "iwperl" (with no file extension, size 0, and a timestamp of 10 am today) in our iw-home/iwperl/bin folder. The file "iwperl.exe" was also there, so it wasn't a case of having the display of file extensions turned off. When we deleted this file, the scripts once again started working.

Our theory is that some sort of system hiccup produced the rogue iwperl file, and our scripts, which begin with "#!d:\interwoven\iw-home/iw-perl/bin/iwperl -w", were trying to use the iwperl file instead of the iwperl.exe file.

Has anyone else encountered this problem, or have any thoughts about what caused it?

Thanks.

Could someone have tried a Unix redirect to a perl script and over-wrote it instead ? I rememer this question a couple years ago, iwperl.exe was replaced with a 0 length file.

Something like:

foo > $iwhome/iwperl/bin/iwperl myscript.ipl

I have seen that happen before

nipper

I remembered this post where someone had a similar issue. It may point you in the correct direction.

He got it working (like you did) and do not know if he ever figured out how.

Andy

stefanmaier

Hi,
we also got this mysterious iwperl error some years ago on our TS5.5 server.
One of our developers created an additional "iwperl" file in the iw-perl\bin directory
(it was something like Andy said before: he piped STDOUT to iwperl ....)

A file named "iwperl" in combination with the windows typical file search mechanism for
executable files (windows first tries to find the given name like "iwperl", then "iwperl.bat",
"iwperl.com", "iwperl.exe" and so on... ) results in a problem running iwperl.

Short solution was to delete the problematic "iwperl" file,
also we rule our developers to use full qualified filenames like "iwperl.exe" in their scripts,
to avoid this error again.

Adam Stoller

Hi,
we also got this mysterious iwperl error some years ago on our TS5.5 server.
One of our developers created an additional "iwperl" file in the iw-perl\bin directory
(it was something like Andy said before: he piped STDOUT to iwperl ....)

A file named "iwperl" in combination with the windows typical file search mechanism for
executable files (windows first tries to find the given name like "iwperl", then "iwperl.bat",
"iwperl.com", "iwperl.exe" and so on... ) results in a problem running iwperl.

Short solution was to delete the problematic "iwperl" file,
also we rule our developers to use full qualified filenames like "iwperl.exe" in their scripts,
to avoid this error again.

If they can pipe something into "iwperl" they can pipe it into "iwperl.exe" just as easily - so that really isn't going to fix anything. You're probably better off having them just use "iwperl" so that if they do it again you still have the .exe in place and can get rid of the erroneous "iwperl" easily.
Also - if you ever switch platforms (not as likely for customers, but very likely for consultants) you don't want to get in the habit of using the .exe extension because that's Windows-specific and won't work on Unix.