Double-clicking the EXE (am using the latest Strawberry Perl-based ZIP release) opens a new window that displays the help text as usual with a pause after each page. Ctrl+C makes the window go poof! as expected.
However, typing exiftool at the command-line (cmd) and pressing Ctrl+C makes the program exit immediately with the following message:
^CCan't spawn "cmd.exe": No error at drive:\full\path\to\exiftool.exe\exiftool_files\exiftool.pl line 7526.
Perhaps not a bug, but really seems like something that can be handled better.
P.S. It seems exiftool doesn't clean up after itself, and leaves the %TMP% folder littered with exiftool_ver_doc.txt files?
Thanks for this report. I'll look into it.
You're right about leaving the txt files in the TMP folder, but this is much better than the previous package which unpacked all of the modules there as well. I could maybe delete the txt file but then ExifTool would have to re-create it each time rather than just generating it once.
- Phil
I suggest to create the help text during building the package and bundling it with the other files. No need to create it dynamically in the temp directory
Good point.
I
may have found a clue towards the cause of this bug in this StackOverflow answer (https://stackoverflow.com/a/73322032):
QuoteMake sure your perl 32/64bit version and your starting cmd version match.
I had the same problem, and for me It was executing a 64-bit perl version inside a 32-bit cmd.exe.
Then, the perl script tried to do a system call, and at that point, it failed with the Can't spawn "cmd.exe" message.
When using a 32-bit perl, all worked.
As indicated above, it seems there might be a 32/64-bit mismatch
somewhere, because when I tried the 32-bit ExifTool ZIP package and pressed Ctrl+C while the help text was being displayed, that error didn't show up!
On 64-bit Windows whenever I open a command prompt (not the newer Terminal or PowerShell), the 64-bit cmd.exe runs by default. Inside this Oliver Betz's 64-bit ExifTool launcher is executed by me. However, does the 64-bit ExifTool package bundle 64-bit Strawberry Perl by default, or do both the 32 and 64-bit ExifTool packages bundle the same 32-bit Strawberry Perl version?
Wherein lies the bitness mismatch, and why does the 32-bit version not show me the error on 64-bit Windows, while the 64-bit version does? :o ???
The 64-bit launcher runs a 64-bit perl.
I'm guessing the difference is that you may have 2 different versions of CMD on your system, and you may be running a different version when you open the CMD window manually vs when you double click on ExifTool. ?
Note that newer ExifTool versions no longer create the temporary .txt file.
- Phil
Quote from: Phil Harvey on October 19, 2024, 09:31:01 PMI'm guessing the difference is that you may have 2 different versions of CMD on your system, and you may be running a different version when you open the CMD window manually vs when you double click on ExifTool. ?
64-bit Windows does have 2 different versions of cmd.exe:
1. 64-bit cmd.exe at Windows\System32\cmd.exe
2. 32-bit cmd.exe at Windows\SysWOW64\cmd.exe
(About the inverted folder names, don't ask. ::) Or rather, ask MS about backwards compat.)
Anyway, whenever I open a command prompt window or double-click ExifTool.exe, Task Manager confirms that by default it's the 64-bit Windows\System32\cmd.exe that is running. So why the difference between the 2 ExifTool packages?
Maybe the script's system() call is invoking the 32-bit cmd.exe by mistake? That could explain why the 32-bit version succeeds with no bitness mismatch, but the 64-bit version fails.
Is there a way for me to edit the .PL file to print the full path to the current cmd.exe under which Perl/ExifTool are running?
Quote from: Phil Harvey on October 19, 2024, 09:31:01 PMNote that newer ExifTool versions no longer create the temporary .txt file.
Saw that there's now a copy in the ExifTool_Files folder by default. Good suggestion by Oliver there. :)
I've sent an email to Oliver hoping that he can weigh in here.
- Phil
I wasn't aware that cmd resp. terminal is invoked when starting ExifTool by double-clicking.
BTW, on (current versions of) Windows 11 it's no more cmd.exe but Windows Terminal.
I can terminate the exiftool help also from a terminal window by typing Ctrl-C
I would need to get to a Windows 10 system to investigate this issue.
I couldn't resist looking into this.
Quote from: obetz on October 20, 2024, 01:06:15 PMI wasn't aware that cmd resp. terminal is invoked when starting ExifTool by double-clicking.
See a screenshot from Process Explorer.
Explorer calls Cmd. Cmd Calls Conhost and ExifTool, Exiftool does a 'more windows_exiftool.txt' and that in turn calls cmd that calls more.
x64.jpg
Quote from: obetz on October 20, 2024, 01:06:15 PMBTW, on (current versions of) Windows 11 it's no more cmd.exe but Windows Terminal.
I can terminate the exiftool help also from a terminal window by typing Ctrl-C
I would need to get to a Windows 10 system to investigate this issue.
I can confirm the difference between Windows 11 and Windows 10.
On Windows 10, the 32 bits, the 64 bits and the 'old' perl-packer version show this 'Cant spawn' message.
On Windows 11, it does not.
I think the difference is the errorlevel being set. I created this cmd file and saved it in the ExifTool directory as 'more.cmd'. So it will get executed in stead of the normal 'more.com'
on break goto L10
c:\windows\system32\more.com "C:\Program Files\ExifToolGUI\exiftool_files\windows_exiftool.txt"
:L10
echo %errorlevel%
Windows 10: Gives an error level -1073741510
Copying
exiftool [*OPTIONS*] -tagsFromFile *SRCFILE* [-[*DSTTAG*<]*SRCTAG*...]
*FILE*...
^CTerminate batch job (Y/N)?
C:\Program Files\ExifToolGUI>echo -1073741510
-1073741510
Windows 11: Gives errorlevel=0
DESCRIPTION
A command-line interface to Image::ExifTool, used for reading and
writing meta information in a variety of file types. *FILE* is one or
Terminate batch job (Y/N)?
C:\Program Files\ExifToolGUI>echo 0
0
BTW: The preferred way of closing 'more' is simply 'Q'. It will stop nicely.
@Oliver: I have Windows 11, 10, 8 and 7 versions. If you want me to do some tests let me know.
Frank
Edit: Notice that the
echo %errorlevel% in the cmd file resets the errorlevel to 0. And the message no longer appears. Not even on Windows 10.
@Oliver
I am able to reproduce the 'Cant spawn' message in Windows 11 by setting the 'Default profile' and 'Default terminal application' in the 'Terminal setup'.
(So you dont need Windows 10 perse)
setup.jpg
cmd prompt.jpg
Looking closer at the options I noticed at the 'Actions' tab that ctrl+c is defined as Copy text. When you remove that you get the same behaviour in Windows 11 Terminal.
So my conclusion: Ctrl/C always triggered this message. In older windows versions, older Exiftool versions. Even in Windows 11 with Terminal enabled this message can appear, if CTRL/C is not used to copy to the clipboard.
What to do next? If you ask me: Nothing. Just learn to use Q to quit.
If it needs to be addressed then maybe calling 'SetConsoleCtrlHandler', or 'SetConsoleMode' in the ExifTool launcher could do the trick.
Frank
ctrl-c.jpg
Thanks Frank.
One thing to keep in mind is that ExifTool itself traps ^C while processing to clean up temporary files. Any changes to the ^C handling should be tested to make sure this cleanup still occurs. You shouldn't see any files named "FILE_exiftool_tmp" after interrupting a write process.
- Phil
Quote from: obetz on October 20, 2024, 01:06:15 PMBTW, on (current versions of) Windows 11 it's no more cmd.exe but Windows Terminal.
As per my understanding, apparently cmd.exe is a command-line interpreter/command processor shell for WinNT, and the counterpart of the older command.com in DOS/Win9x. cmd.exe interacts with the user through a command-line interface implemented through the Win32 Console, which used to be conhost.exe but has now been replaced as the default with Windows Terminal since Win11 22H2.
In short, Win11 still has conhost.exe and cmd.exe, but I guess it now uses wt.exe (Terminal) and powershell.exe as the default console host and shell respectively. As Frank noted above, it seems both can still be switched back, so doing that or getting rid of Terminal's Ctrl+C redefinition for copy text results in the same error message as before. From what I've read it seems to me this isn't really a surprise since the real cause seems to be a possible bug in Perl itself (and not a bitness mismatch as I thought initially).
Pressing Ctrl+C apparently generates exit value (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55) 0xC000013A / STATUS_CONTROL_C_EXIT / 3221225786 / -1073741510 (signed 2's complement - this is the value printed by Frank's more.cmd above). As pointed out in these ancient (https://www.perlmonks.org/?node_id=434558) forum posts (https://www.perlmonks.org/?node_id=751460) and this old StackOverflow answer (https://stackoverflow.com/a/32054866), Perl's
win32.c source file (https://github.com/Perl/perl5/blob/cb2baa70118e364c1428dc77cb8f9c614060c26e/win32/win32.c#L727) (
still!) seems to have a bug in such that if you use the built-in
system() (https://perldoc.perl.org/functions/system) function to spawn an executable, and that executable then returns a negative exit value, Perl erroneously assumes that the
spawn didn't work and spews out an erroneous
Can't spawn... message.
Possible workarounds and/or fixes:
- Comment out use warnings; - As far as I can tell this is useful more for developers who'll be editing the exiftool.pl script itself, to help them catch erroneous/unsafe code. Will commenting it out cause any potential issues for end users who're simply going to use the tool as-is?
- Handle the negative exit value returned to system() somehow.
- Stop relying on system() and external utilities such as more.com on Windows, and use Perl code itself to print the help text file.
- File a bug report and hopefully get the issue fixed in the Perl source itself.
Phew, I didn't realize a simple observation of a spurious message would lead to such a detailed investigation by many! ::)
Thanks stan and Frank for the detailed investigation.
Fixing the problem in Perl itself seems to be the cleanest way, but might take a while.
We could also consider using a tiny wrapper around "more" to catch the negative return value (errorlevel).
I currently don't have much time to participate, but I try later in the the week.
Quote from: stan on October 20, 2024, 11:40:12 PMFrom what I've read it seems to me this isn't really a surprise since the real cause seems to be a possible bug in Perl itself (and not a bitness mismatch as I thought initially).
Seems logical, and the thought had crossed my mind. But it was bed time by then.
Quote from: obetz on October 21, 2024, 12:49:14 AMFixing the problem in Perl itself seems to be the cleanest way, but might take a while.
We could also consider using a tiny wrapper around "more" to catch the negative return value (errorlevel).
Agree. If I can be of help let me know.
Thanks all. I'll try wrapping the system "more" call in an eval to see if that helps.
- Phil
I would be happy to test that Phil.
I've tested this on my Windows 7 virtual machine and it seems to work. Replace the last line of code in exiftool.pl with these lines:
# trap warnings and run in eval to avoid Perl bug which gives "Can't spawn" warning on ^C
local $SIG{'__WARN__'} = sub { $evalWarning = $_[0] };
eval { system(qq{more < "$docFile"}) };
I'm sorry I was so slow about this -- I was thinking it would require a change to the launcher, and didn't realize I could patch it in ExifTool so easily.
- Phil
I can confirm that this works on Windows 11. Both in Terminal and Conhost.
Side note: if you leave out the < in
eval { system(qq{more < "$docFile"}) }; (So it is the first parm)
More shows the percentage. (Maybe only on Windows!)
GPS r/w/c | AFCP r/w | Picture Info r
IPTC r/w/c | Kodak Meta r/w | Adobe APP14 r
XMP r/w/c | FotoStation r/w | MPF r
MakerNotes r/w/c | PhotoMechanic r/w | Stim r
-- More (4%) --
Frank
Thanks Frank.
The percent would be useful, but I'll leave it with the "<" to be safe.
- Phil
Quote from: Phil Harvey on October 21, 2024, 08:11:10 AMI've tested this on my Windows 7 virtual machine and it seems to work. Replace the last line of code in exiftool.pl with these lines:
Works quite nicely in Win10 too (naturally)! However, I suggest a slight modification to reintroduce the error message in case windows_exiftool.txt is somehow missing:
# !PLEASE WRITE THE ACTUAL IF CONDITION PERL CODE BELOW!
if($docFile does not exist) {
print "Error opening doc file $docFile\n"; # similar to earlier "Error opening arg file $argFile\n"
} else {
# trap warnings and run in eval to avoid Perl bug which gives "Can't spawn" warning on ^C
local $SIG{'__WARN__'} = sub { $evalWarning = $_[o] };
eval { system(qq{more "$docFile"}) };
}
Quote from: Phil Harvey on October 21, 2024, 09:57:33 AMThe percent would be useful, but I'll leave it with the "<" to be safe.
The description of Perl's
system() states that if there are no shell metacharacters (such as the redirection operator '<') in the argument, then it is split into words and passed directly to
execvp() which is more efficient. So if it doesn't break anything then I agree with Frank that the percentage display thanks to leaving out '<' would be quite useful, and as a bonus possibly more efficient too.
Hi Stan,
These are reasonable suggestions. I will look into implementing them after the planned 13.00 production release. For 13.00 I am only including bug fixes.
- Phil
Thanks Phil; makes no difference to me whether the above code makes its way into ExifTool 13.00 or 13.01. :) Thanks to Frank and Oliver for their valuable inputs too.
Hi Phil, just a gentle reminder that an existence check for the help text file (https://exiftool.org/forum/index.php?msg=89181) is still needed.
Why should this file not exist? There would be more severe consequences with other files, so if we refine your approach, ExifTool should do an integrity check over everything?
Quote from: obetz on November 21, 2024, 05:07:31 AMWhy should this file not exist? There would be more severe consequences with other files, so if we refine your approach, ExifTool should do an integrity check over everything?
Since the help text was moved to an external file, I just thought checking that for its existence before attempting to output its contents was common sense (similar to the various other "error opening ..." in the code). But sure, if none of the other required extracted package files are being similarly verified then let the app crash and burn if any of them have gone missing for any reason.