From: ruvim.pinka@gmail.com
On 2024-11-08 17:21, Anton Ertl wrote:
> Ruvim writes:
>> On 2024-11-08 12:29, Anton Ertl wrote:
>>> mhx@iae.nl (mhx) writes:
>>>> Same as remarked by minforth: there is a exit-handler chain in
>>>> which the user can plug arbitrary routines.
>>>
>>> In Gforth BYE is a deferred word, with the intention that it can be
>>> extended with cleanup actions.
>>>
>>> The disadvantage of this approach in connection with the non-0 exit is
>>> that we probably also want to do the same cleanup in those cases. The
>>> best way to deal with that is probably the "EXIT-CODE !" approach.
>>
>> I think, this variable, if it is required, should be internal.
>>
>> For example:
>>
>> variable _system-exit-status 0 _system-exit-status !
>>
>> : kernel-bye ( -- never )
>> ... \ other actions
>> _system-exit-status @ (bye)
>> ;
>>
>> defer bye ' kernel-bye is bye
>>
>> : bye-with-status ( n -- never )
>> _system-exit-status ! bye
>> ;
>
> Yes.
>
>> Thus, the old interface is not changed. And `bye-with-status` also does
>> the same cleanup sequence (if any).
>
> Which old interface?
I mean, the Gforth's defer-based interface to "BYE" that allows to
extend it with cleanup actions, like this:
:noname
." (cleanup actions on BYE)" cr
[ action-of bye compile, ]
; is bye
1 bye-with-status
\ the cleanup actions will be executed
>
>>> Concerning the usual discussion about the name: I find that the system
>>> is left in the error case with an uncaught THROW in script-execution
>>> mode; in that case an exit code of 1 is returned by Gforth, so it's
>>> not sufficient for communicating more than a binary result to the
>>> calling script. But I have not used non-binary exit codes for
>>> non-Forth programs, either, and I do quite a bit of shell scripting.
>>
>> Does it mean that "bye" and "bye-failure" is enough?
>
> It means that BYE and THROW (ABORT etc.) is enough. E.g., if I want
> to implement something like the program false:
>
> [/tmp:153395] cat >myfalse < #! /home/anton/gforth/gforth
> abort
> EOF
> [/tmp:153396] cat myfalse
> #! /home/anton/gforth/gforth
> abort
> [/tmp:153402] chmod +x myfalse
> [/tmp:153397] ./myfalse
>
> [/tmp:153398] echo $?
> 255
> [/tmp:153399] false
> [/tmp:153400]
>
> One difference from the behaviour of false is, as you can see, that
> myfalse still produces a newline (probably coming from ABORT, because
> it works if I replace the ABORT with "255 (bye)". Maybe still
> something to work on.
I see. But it depends on application, see below.
>
>>> In any case, while we have (BYE), I don't use it in application
>>> programs.
>>
>>
>> As an example, when a script is used in Make, it is important to return
>> nonzero exit status on error.
>
> Errors tend to result in uncaught THROWs, not in calls to (BYE). And
> these uncaught THROWs actually produce a nonzero exit status. They
> tend to also produce a useful error message without too much work:
>
> [/tmp:153406] gforth -e 's" /etc/passwd" slurp-file type bye'
> root:x:0:0:root:/root:/bin/bash
> ...
> [/tmp:153407] gforth -e 's" /typo/etc/passwd" slurp-file type bye'
>
> *OS command line*:-1: No such file or directory
> s" /typo/etc/passwd" >>>slurp-file<<< type bye
> Backtrace:
> $7FA065165980 throw
> [/tmp:153408] echo $?
> 1
Yes, it is a quick result, without too much work.
But in some applications you cannot output error messages from the Forth
system to the user. You should use the exit status and output
user-friendly application-specific messages (if any). An exception that
cannot be handled (like division by zero, stack overflow, invalid memory
address) means an error in the program, it should be logged into a
special file and perhaps automatically send to the author.
--
Ruvim
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
