|
RUN
Dec 11, 2022 13:09:59 GMT 1
Post by rikky on Dec 11, 2022 13:09:59 GMT 1
I was looking for a BaCon command to use in CATCH ERROR to restart a program in case of : ERROR 29 : Unable to fork process: Too many open files in function EXEC$ in file 'blabla' at line 2763
Just off program kill all the forks that could possibly be there, and cleanly restart. I was hoping to use the RUN command for that. The documentation says: Example:
RUN "ls -l" result: Syntax error: empty RUN at line 1 in file 'run.bac'! Rik.
|
|
|
RUN
Dec 11, 2022 13:44:06 GMT 1
Post by Pjot on Dec 11, 2022 13:44:06 GMT 1
Hi rikky, Thanks for pointing this out! It is a regression which was introduced in release 4.5. The error did not exist for the Shell version of BaCon. Next to this regression, the syntax file for the GTK GUI also contained an error (RUN as function instead of statement). How embarrassing It is fixed in the latest beta: tarball or zip from chiselBest regards Peter
|
|
|
RUN
Dec 18, 2022 11:37:47 GMT 1
Post by rikky on Dec 18, 2022 11:37:47 GMT 1
Yes, .... almost. I can RUN "ls -l" without problem. But if I put this command in a variable, then the program compiles fine, but does not do anything. It get worse if I put the command in two variables: var1$ = "ls" var2$ = " -l" RUN var1$ & var2$ result : error: expected β}β before βvar1$β Rik
|
|
|
RUN
Dec 18, 2022 13:45:29 GMT 1
Post by Pjot on Dec 18, 2022 13:45:29 GMT 1
Hi rikky, Concatenating string variables does not work for the RUN statement. Let me try to explain. There's a chapter in de BaCon documentation about transcompiling. You probably have read this before. Thing is, the RUN statement is implemented with the C library execlp function. This function needs a set of separate arguments, each of which points to the elements of the command you would like to execute. In your case, you would like to execute "ls -l". In C code, this actually should be something like this: execlp("ls", "ls", "-l", NULL);
However, if you put your command into two separate BaCon string variables, of which the contents only are known during runtime, then BaCon, as a code converter, cannot see the result of the concatenation beforehand during conversion time. Hope this clarifies, Peter PS forgot to say that using a variable for RUN also does not work because of the same reason. PS2: you can use variables but it should contain only 1 statement. So sending "ls" will work. But "ls -l" will not work.
|
|
|
RUN
Dec 18, 2022 14:06:53 GMT 1
Post by rikky on Dec 18, 2022 14:06:53 GMT 1
Aha, In that case I have some weird execlp library. For in my case SYSTEM (and also EXEC$()) work with multiple variables, But RUN does NOT work, even with only one single variable. Example: I have a folder with only RUN.bac in it. After compiling I have two files in the folder. RUN.bac : CHANGEDIR DIRNAME$(ME$)
PRINT PRINT "1:"
var$ = "ls -l" SYSTEM var$
PRINT PRINT "2:"
var1$ = "ls" var2$ = " -l"
SYSTEM var1$ & var2$
PRINT PRINT "3:"
var$ = "ls -l" RUN var$
result: 1: total 36 -rwxr-xr-x 1 pi pi 29580 Dec 18 14:01 RUN -rwxrwxrwx 1 pi pi 187 Dec 18 14:01 RUN.bac
2: total 36 -rwxr-xr-x 1 pi pi 29580 Dec 18 14:01 RUN -rwxrwxrwx 1 pi pi 187 Dec 18 14:01 RUN.bac
3:
|
|
|
RUN
Dec 18, 2022 14:10:57 GMT 1
Post by Pjot on Dec 18, 2022 14:10:57 GMT 1
It's all correct, because SYSTEM and EXEC$ are implemented using the libc system call. There, we do not need to break the shell command into separate pieces during conversion time, as we need to do with execlp. Best regards Peter
|
|
|
RUN
Dec 18, 2022 14:24:47 GMT 1
Post by rikky on Dec 18, 2022 14:24:47 GMT 1
Oh, oke ... That means that you have a working RUN var$ and I have not. Life is unfair, I guess.
|
|
|
RUN
Dec 18, 2022 14:34:08 GMT 1
Post by Pjot on Dec 18, 2022 14:34:08 GMT 1
That is not what this means. This code should work for you too (as it works on my system also): var$ = "ls" RUN var$
The following does not work, as BaCon cannot split up beforehand the contents of the variable effectively known at runtime: var$ = "ls -l" RUN var$
The following does not work, as BaCon cannot split up beforehand the contents of a concatenated string of which the result is known at runtime: var1$ = "ls" var2$ = " -l" RUN var1$ & var2$
If this is different for your system then let me know. Having said this, I agree with your statement that life is unfair BR Peter PS the code for RUN was a bit old and messy. I have updated it in the converters but it does the same as before.
|
|
|
RUN
Dec 18, 2022 15:07:50 GMT 1
Post by rikky on Dec 18, 2022 15:07:50 GMT 1
Ah ja, var$ = "ls" works. there is always a workaround then. var$ = "./lsal" RUN var$ And the contents of ./lsal you can probably guess. result: total 48 drwxrwxrwx 2 pi pi 4096 Dec 18 15:02 . drwxrwxrwx 10 pi pi 4096 Dec 18 11:19 .. -rwxrwxrwx 1 pi pi 20 Dec 18 15:00 lsal -rwxr-xr-x 1 pi pi 29580 Dec 18 15:02 RUN -rwxrwxrwx 1 pi pi 188 Dec 18 15:02 RUN.bac Thanks. Rik. Edit: added the result.
|
|