Re: bye with exit status

On 2024-11-08 17:21, Anton Ertl wrote:

Ruvim <ruvim.pinka@gmail.com> 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 <<EOF
#! /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