Doing sumatraPDF "document" opens the document fine, but returns errorlevel 256 to the OS:
perl -wle "$rc = system @ARGV and warn $rc" sumatraPDF "d:\programs\texlive\2021.local\texmf-dist\doc\support\texdoc\texdoc.pdf"
256 at -e line 1.
This gets in the way of programs which use external PDF viewer.
SumatraPDF will report %ErrorLevel%==0 on exit even if the switch or pdf does not exist
echo %errorlevel%
cmd.exe reports 9009 on failure to find the SumatraPDF.exe
256 is a Perl Error code failing to make the call correctly, here is one discussion Perl: system return code is 256 instead of 0 - Stack Overflow
Wrong. (BTW, I wrote a significant part of this subsystem of Perl!) 256 means that the program returned exit code 1. However, just to avoid a tool which is not familiar to you, I do this in CMD:
K:\get>perl -wle "exit 0"|| echo not ok
K:\get>perl -wle "exit 1"|| echo not ok
not ok
K:\get>sumatraPDF Zametki_starogo_MGU_end.pdf|| echo not ok
K:\get>cmd /c "sumatraPDF Zametki_starogo_MGU_end.pdf|| echo not ok"
not ok
CONCLUSION: there is no errorcode when started interactively (as you already checked!), but there is an errorcode when started by a child CMD.
running a CMD as child is variable due to delay for Find 0=success and 1=fail but its always one step behind so all the errorlevels are “wrong”
Using || condition will certainly help with such odd behaviour
here the errorlevel is Unaffected by sumatraPDF running as a child the file does not exist but SumatraPDF exits cleanly so no error raised.
I agree with your observation
CONCLUSION: there is no errorcode when started interactively (as you already checked!), but there is an errorcode when started by a child
CMD.
SumatraPDF only sets command line error code when used as a command-line app for printing
not as a GUI app that does not report to the parent any failures whilst running in graphics mode. It’s any child process running SumatraPDF as a grandchild that returns its child failure errorlevels UNLESS SumatraPDF is invoked as a console app
You need to use the console to test if the file exists prior to launching a non console app.
It is exactly the same for any non console app like notepad. It does not matter if the file exists or not the errorlevel prior to a gui app invocation is the one that is kept in console memory. Notepad does not even raise an error on failing to console print, it is the execute via cmd that reports successful print of nothing.
It seems that you have mind blocks with interpreting CMD as well! (ME TOO! — this is why I started with doing Perl, which has a very simple semantic) There is no delay — just %ENV% is expanded not when you think it is!
Please do not put words in my mouth. I never said this, and what I said is exactly the opposite:
SumatraPDFreturns error code 1 — at least when another copy is already running, and the current copy just passes the filename to the other copy.
CMDis not reporting this errorcode when starting the application interactively, but reports it in a subshell.
This is manifestly wrong. Every GUI application has a different purpose, and it returns its errorcodes according this this purpose. (Again, you are just “not familiar enough” — who is?! — with quirks of how CMD works. Try it with Perl: it has a simple semantic.)
BTW: what is this “Awaiting Approval 13h” on my preceding message?
Awaiting approval is due to spam trapping so if you copy/paste too fast or reference another site it triggers a review flag until a mod like me, comes back to this site to spot it needs acceptance. the notifier of discourse site can be erratic and I may be on another one of many or sleeping.
In deference to your comment above I have corrected my bad for stating your observation without using a direct quote
So to be clearer you are right SumatraPDF has no affect on error-levels it is the child that starts SumatraPDF that throws tantrums as discussed. it does not matter if the executor is using start or cmd /c or cmd /k or cmd /r the error is the windows executors processing reply.