Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ruvim <ruvim.pinka@gmail.com>
Newsgroups: comp.lang.forth
Subject: Re: bye with exit status
Date: Fri, 8 Nov 2024 18:39:04 +0400
Organization: A noiseless patient Spider
Lines: 128
Message-ID: <vgl7q8$37p49$1@dont-email.me>
References: <vgfmfe$22uop$1@dont-email.me> <vgg6q4$26lgs$1@dont-email.me>
 <4d5b92710816ddfe2dbbb04a2177b40b@www.novabbs.com>
 <c52c3b51c000c9139d938079e3cfe988@www.novabbs.com>
 <2024Nov8.092913@mips.complang.tuwien.ac.at> <vgl1al$369hb$2@dont-email.me>
 <2024Nov8.142144@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 08 Nov 2024 15:39:05 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e737efc88dec1dd6103f16e7236b5230";
	logging-data="3400841"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18xEDCwux/fqtpieGC5Qsm4"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:IVUajU5pNArR67OINjcJR7m3pAo=
Content-Language: en-US
In-Reply-To: <2024Nov8.142144@mips.complang.tuwien.ac.at>
Bytes: 5187

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