I have a Perl script that runs svnversion in backticks and parses the output to produce a VERSIONINFO resource for my Windows app. This week one development machine started getting an empty string from svnversion. Other machines are getting a real version back. Running svnversion from the command line works. I added a where svnversion to the script to see if it was a path problem and that also returns an empty string, which makes me think the backtick operator is failing silently in some way. Any suggestions on how I might further debug this?
Try to find out what changed between when the script last worked and now.
Unless something has changed in your Perl, which seems unlikely given how long you’ve had that particular build (it’s more than 4 years old and can’t get updates from us), the odds are highest that something on the Windows side has changed.
Backticks need permissions to operate. Do any backticks work on that system? If not, look at your antivirus software or any recent Policy setting changes that might prevent execution of a process started by the userID that the Perl script runs under.
Thanks. The user is bringing me the laptop tomorrow so I can do some serious debugging on my own. The script was simple and the only real thing we needed Perl for so it hasn’t been pressing to update the interpreter. He did upgrade to the latest without improvement. I’m very curious to find out why that one machine can’t do something so simple. He’s certain he hasn’t installed anything except Windows updates since the last time he built code, a couple weeks ago. I have two systems that work fine and his desktop system runs it fine.
Solved: It’s a bug in MalwareBytes 4.5.9. Fixed by updating to 4.5.10.
Once I had the machine in hand, I noticed zero-length read-only files in the working directory that matched the names of the first argument of each backtick string: cmd.exe, set, svnversion, where. That gave me something to google, which turned up these explanations: