There seems to be a fundamental problem with QB64 Open Com statement at least with my compiler. When I open the com port with OPEN "Com3: 9600,n,8,1,ds0,cs0,rs" FOR RANDOM AS #1 while knowing that there is data in the buffer and print EOF, LOC, LOF. It shows EOF=0 OK fine but LOC and LOF both show 0. If you then exercise a GET statement you get a "bad record length" because LOF=0. If I use OPEN FOR INPUT then I immediately get EOF=-1, LOF and LOC=0. If I then use INPUT# I get an input past end of file error because EOF was already -1.
I know that the buffer contains" Voltage = 1.2* "(no quotes) If I say continue upon the input past end of file error I actually get Part of the message.
Is there a fix for this com port problem?
If you test the com port you will find Windows nicely blocks those ports:
REM test com port keyboard i/o
OPEN "COM3:9600,N,8,1,BIN,CS0,DS0" FOR RANDOM AS #1
DO
IF LOC(1) THEN
GET 1, , x
PRINT CHR$(x);
END IF
x$ = INKEY$
IF LEN(x$) THEN
IF x$ = CHR$(27) THEN END
x = ASC(x$)
PUT 1, , x
END IF
LOOP
END
Related
To test the integrity of PostScript files, I'd like to run Ghostscript in the following way:
Return 1 (or other error code) on error
Return 0 (success) at EOF if stack is empty
Return 1 (or other error code) otherwise
I could run gs in the background, and use a timeout to force termination if gs hangs with items left on the stack. Is there an easier solution?
Ghostscript won't hang if you send files as input (unless you write a program which enters an infinite loop or otherwise fails to reach a halting state). Having items on any of the stacks won't cause it to hang.
On the other hand, it won't give you an error if a PostScript program leaves operands on the operand stack (or dictionaries on the dictionary stack, clips on the clip stack or gstates on the graphics state stack). This is because that's not an error, and since PostScript interpreters normally run in a job server loop its not a problem either. Terminating the job returns control to the job server loop which does a save and restore round the total job, thereby clearing up anything left behind.
I'd suggest that if you really want to do this you need to adopt the same approach, you need to write a PostScript program which executes the PostScript program you want to 'test', then checks the operand stack (and other stacks if required) to see if anything is left. Note that you will want to execute the test program in a stopped context, as an error in the course of the program will clearly potentially leave stuff lying around.
Ghostscript returns 0 on a clean exit and a value less than 0 for errors, if I remember correctly. You would need to use signalerror in your test framework in order to raise an error if items are left at the end of a program.
[EDIT]
Anything supplied to Ghostscript on the command line by either -s or -d is defined in systemdict, so if we do -sInputFileName=/test.pdf then we will find in systemdict a key /InputFileName whose value is a string with the contents (/test.pdf). We can use that to pass the filename to our program.
The stopped operator takes an executable array as an argument, and returns either true or false depending on whether an error occurred while executing the array (3rd Edition PLRM, p 697).
So we need to run the program contained in the filename we've been given, and do it in a 'stopped' context. Something like this:
{InputFileName run} stopped
{
(Error occurred\n) print flush
%% Potentially check $error for more information.
}{
(program terminated normally\n) print flush
%% Here you could check the various stacks
} ifelse
The following, based 90% on KenS's answer, is 99% satisfactory:
Program checkIntegrity.ps:
{Script run} stopped
{
(\n===> Integrity test failed: ) print Script print ( has error\n\n) print
handleerror
(ignore this error which only serves to force a return value of 1) /syntaxerror signalerror
}{
% script passed, now check the stack
count dup 0 eq {
pop (\n===> Integrity test passed: ) print Script print ( terminated normally\n\n) print
} {
(\n===> Integrity test failed: ) print Script print ( left ) print
3 string cvs print ( item(s) on stack\n\n) print
Script /syntaxerror signalerror
} ifelse
} ifelse
quit
Execute with
gs -q -sScript=CodeToBeChecked.ps checkIntegrity.ps ; echo $?
For the last 1% of satisfaction I would need a replacement for
(blabla) /syntaxerror signalerror
It forces exit with return code 1, but is very verbous and distracts from the actual error in the checked script that is reported by handleerror. Therefore a cleaner way to exit(1) would be welcome.
What will happen with a file handle opened via io.lines if something bad happen inside the loop? The documentation says that the file will be automatically closed when the end of file is reached and says nothing for the exceptional cases (something like accesing a nil value in dosomething().
for line in io.lines("myfile.txt") do
dosomething(line);
end
Does anybody know how the lua will handle the situation like this?
The file will be closed when the object referencing it is garbage collected eventually.
If you are on a Unix system you can try that with the following program:
local f = function()
for line in io.lines("myfile.txt") do
print("1")
io.read()
error(line)
end
end
pcall(f)
print("2")
io.read()
collectgarbage("collect")
print("3")
io.read()
If you run lsof at step 1 you will see the file open. At step 2, it will most probably still be open. At step 3 it won' be open anymore.
I'm using valgrind to find faults in my code. The command I use is
valgrind --leak-check=yes ./a.out
and I compile the code with -g code alone. I get many errors pointing to a single write line (The three printed values are initialized and well defined).
write (22,*) avlength, stdlength, avenergy
All with the Conditional jump or move depends on uninitialised value(s) error. The said line is the second line from a bunch of lines printing to a single file. At the end of the errors, I get two more, one pointing to the line opening the file
resStep = int(conf*100/iterate)
if (resStep.lt.10) then
write (resFile, "(A5,I1)") "res00",resStep
elseif (ResStep.lt.100) then
write (resFile, "(A4,I2)") "res0",resStep
else
write (resFile, "(A3,I1)") "res",resStep
endif
open (unit=22,file=trim(resFile),status='replace',
c action='write')
resStep is integer. The error is Syscall param write(buf) points to uninitialised byte(s). Finally, I get an error Address 0x52d83f4 is 212 bytes inside a block of size 8,344 alloc'd when I flush the file (before closing it).
I can't find any logic here. If the problem is with opening the file in a faulty way, wouldn't I get the error at the first line?
I use f95 to compile this and my gcc version is 4.1.2. I can't upgrade any of it.
Wild guess: check the data type of resFile. Is it a string or a unit number?
My Fortran 95 is beyond rusty but try moving the call to open() before the calls to write() and pass an integer resUnit instead of resFile as the first argument to write():
CHARACTER(LEN=20):: resFile
INTEGER(KIND=2) :: resUnit, resStep
resStep = 1
resFile = 'MY-results'
resUnit = 22
open (unit=resUnit, file=trim(resFile), status='replace', action='write')
write(resUnit, "(A5,I1)") "res00", resStep
END
I'm trying to run dos commands within vb.net program and capture output. I have the following code:
Dim CMDServer As Diagnostics.ProcessStartInfo
Dim CMDReply As Diagnostics.Process
CMDServer = New Diagnostics.ProcessStartInfo
CMDServer.FileName = "cmd.exe"
CMDServer.UseShellExecute = False
CMDServer.RedirectStandardOutput = True
CMDServer.CreateNoWindow = True
CMDServer.Arguments = "/C " + command
CMDReply = Process.Start(CMDServer)
Dim Reply As String = CMDReply.StandardOutput.ReadToEnd()
The code runs successfully if command is a valid dos command, and I get the output in Reply. If the command have no output ( eg: cd\ ) Reply is null. The problem is Reply is null even when the command is invalid. How to capture errors like "command is not recognized as an internal or external command...", "The system cannot find the path specified.." etc.. Please help me. Thanks..
Error messages come in a different output stream called StandardError. Just use a StreamReader or read it directly. Of course, the RedirectStandardError-Property of your ProcessStartInfo instance must be set to True.
Also, there is a ExitCode-Property which returns the ExitCode of the program after it has finished. 0 means 'successful'. Other error codes can be found in the MSDN Documentation. Here is a list of the common exit codes. For example, 2 means The system cannot find the file specified..
Errors are probably output on CMDReply.StandardError, not CMDReply.StandardOutput; try reading it, too. (And set CMDServer.RedirectStandardError to True as well.)
In a DOS batch script, I'm running a single command on a remote (also windows) computer using plink. Formerly, this command was only run on the local machine, and was relying on the return code to determine success. Is there a way to easily get this information back through plink?
That's not possible with plink. The current consensus is to have the remote script echo its exit code to a log file, then use pscp to transfer the log file to the local machine.
See http://fixunix.com/ssh/74235-errorlevel-capturing-plink.html.
with plink 0.66
C:\Code>echo Y | "C:\Program Files (x86)\PuTTY\plink.exe" bob#myserver exit 42
C:\Code>echo %ERRORLEVEL%
42
Also for #John Wiersba's concern about when a connection cannot be made, this appears to be fixed
C:\CodeMisc>echo Y | "C:\Program Files (x86)\PuTTY\plink.exe" bob#garbageservername exit 42
Unable to open connection:
Host does not exist
C:\Code>echo %ERRORLEVEL%
1
Also note the piping of echo Y ... this enables you to accept the server fingerprint automatically (a little dangerous to say the least ... but our login server is load balanced, so you are always getting different fingerprints :( )
However as #LeonBloy notes, plink still has some connection conditions which return a zero exit code. If you know your exit code range and you don't have a good way of communicating back to windows via a file. You could either +3 to the exit code (if you know the exit code will never == 253-255) or you could apply a bitwise OR (I'd suggest exit $(($?|128)) - in bash).
Or if you don't care about the exact exit code, you could return 2 for success, and zero for failure. Thus a non-two exit code would indicate failure. In bash this would be: echo $((($?==0) << 1)). This would be by far the most robust general purpose solution, but you should make sure your exit code is logged for debug-ability.