Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001309 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Enhancement Request 2019-12-19 02:26 2024-06-11 09:08
Reporter kre View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Robert Elz
Organization
User Reference
Section 2.9.4
Page Number 2371-4
Line Number 75726-31
Interp Status Approved
Final Accepted Text Note: 0004763
Summary 0001309: Clarity needed for initial value of $? at start of compound-list compound statements
Description Currently, nothing says what the "previous command" is precisely when beginning execution of one of the lists in the body of a compound statement.

This is (fortunately) not controversial, as best I can tell, all shells do
it the same way, so all that is needed is to be explicit in the standard as
to what that way is.

That is, in

    (exit $B); if X=$?; echo X=$X; (exit $X); then Y=$?; echo Y=$Y; (exit $Y);
    else Z=$?; echo Z=$Z; (exit $Z); fi; A=$?; echo A=$A; (exit $A)

what values are assigned to X, Y, and Z (the value for A is already defined)

The reason this might seem tricky, is that when assigning A, the value of
X is completely ignored. Some might reason from that, that the value of
X should be ignored for the purposes of Y and Z as well.

Similar examples can be designed for all of the compound statements.

[Aside: do not treat this example literally - it is obviously designed to
pass through the exit code without changing it ... for more realistic purposes
we should assume that the "echo $Q; (exit $Q)" part (where Q is X Y or Z)
can be any arbitrary sh statements, producing any arbitrary results.]

My intuition would say (and all the tests I have done confirm) that the
"previous" status for X is always the previous command exit status (from
before the compound statement, or 0 if there was none) and that for Y and Z
it is the result from the condition evaluation (if there was one) or for
the compounds that have no condition ('{' '(' 'for' 'case') the initial
exit status for the body is that from before the compound statement.

The two cases where it is possible to observe this in a meaningful way are
in the else clause list of an if statement, and the body of an until

That is, if we have
    (exit 3) ; if (exit 7); then : ; else echo $?; fi
then what will be printed will be 7, and definitely not 3 or 0.

I believe that this should be made explicit in the standard.
Desired Action After line 75731 (the end of the 2.9.4 intro test, just before 2.9.4.1
add a new paragraph something like:

When commencing execution of a compound-list as part of a compound command,
the "last command executed" for the purposes of determining the value of the
special parameter '?' and the default value for the exit and resturn special
built-in commands, shall be the status of the last command executed before the
compound command in the case of the first compound-list executed, and the result
of the previous compound-list executed as part of executing the compound
command in the case where more that one compound-list is executed, or where
compound-lists are repeatedly executed. During execution of a compound-list
the exit status is updated to reflect the results of each command executed,
as is defined for each such command.

The exit status after the compound command has completed is as specified
below for each specific compound command.
Tags issue8
Attached Files

- Relationships
related to 0001150Closed 1003.1(2016/18)/Issue7+TC2 exit status of command substitution not properly specified 
related to 0000051Closedajosey 1003.1(2008)/Issue 7 sh exit status not clear for built-in terminated by a signal 

-  Notes
(0004731)
geoffclare (manager)
2020-01-16 17:42
edited on: 2020-01-16 17:43

 [These are notes I made as a result of discussions in the 2020-01-16 teleconference, but they aren't a formal record, just my personal take on what came out of the discussion]

Regarding:

| That is, if we have
| (exit 3) ; if (exit 7); then : ; else echo $?; fi
| then what will be printed will be 7, and definitely not 3 or 0.

This is clearly already required by the current text in the standard. When "echo $?" is executed, the last command that was executed is the "(exit 7)" subshell and its exit status was 7 so $? must be 7.

As far as I can see there is no ambiguity for until (or while) either. This covers the two cases where kre said it is possible to observe this, and since all shells behave as expected I don't see the need to change the standard.

However, there is one additional aspect that is of interest, and that's what happens on entry to a subshell.

2.12 says "A subshell environment shall be created as a duplicate of the shell environment, except [stuff to do with signal traps]" This means the value of $? must be inherited, and all shells seem to do that. However, as regards a "last command", it is not clear whether the last command in the shell that executed the subshell should be treated as "inherited". Most shells behave as if it is, but ksh does not; it behaves as if there were no last command:
$ for shell in bash dash ksh zsh; do printf "$shell: "; $shell -c 'false; (exit ); echo $?
'; done 
bash: 1
dash: 1
ksh: 0
zsh: 1


(0004732)
kre (reporter)
2020-01-16 20:35

 Wrt the last point of Note: 0004731 for me, ksh93 (Version AJM 93u+ 2012-08-01
anyway) gives '1' (as do bosh, fbsh, yash, mksh, pdksh, and nbsh).

But that suggests another question, In 2..5.2, line 74877 :

   ? Expands to the decimal exit status of the most recent pipeline
     (see Section 2.9.2).

[2.9.2 defines a pipeline] doesn't say what $? should be if there has been
no "most recent pipeliine" and a not-unreasonable interpretation might be
that $? should be unset in that case (as, for example, $! is when there js
been no "most recent background command". Or at least most shells leave $!
unset in that case, yash and zsh produce 0 for $! in

    $SHELL -c 'printf "! %s ? %s\\n" ${!-unset} ${?-unset}'

where all shells I tested produce 0 for $?. This isn't stated in the
standard one way or the other either, but I have seen several scripts that
assume the unset value for $! in that case, and 0 for $? (the common values).

The reason I suggested some clarity for the if/while/until commands, is
because generally the exit status of the condition is not available other
than as it determins whether or not (or which in the case of if with an
else) list is executed next, and that could be mis-interpreted to mean
that inside the list, the "last pipeline executed" (for $?) or "last command
executed" for exit or return might mean the one executed prior to beginning
the if/while/until statement, rather that temporally.

And with that, why is $? defined to be the last "pipeline" whereas exit &
return use the status of the last "command" (and explicitly say it is 0 if
there has been none).

I still believe that we ought to some kind of cleanup of all of this, and
make the language precise.
(0004733)
kre (reporter)
2020-01-16 21:36

 I perhaps should also add, that $! is one of those things that (as best I can
tell) all shells treat as part of the "duplicate of the shell environment"
when creating a sub-shell, even though the value of $! in the subshell is
useless, and it would have arguably been better to revert the special param !
to be unset when a sub-shell is started.

That is, in

     $SHELL -c 'sleep 5 & printf %d\\n $!; ( printf "%s\\n" ${!-unset} )'

all the shells I regularly test print the same value from both printf
statements (I use %d the first time, as there we know $! will have an
integer value, %s the second, in case we were to get "unset").
(0004734)
kre (reporter)
2020-01-17 04:17
edited on: 2020-01-17 04:19

 A variation on the original command (nb: this is all to hopefully get agreement
that we should improve the precision of the relevant wording, not to suggest any
different behaviour than what is commonly expected)

    (exit 3) ; if (exit 7); then : ; fi; echo $?

clearly is intended to produce 0 from the echo, not 3 or 7 (and does
everywhere), but which is the "most recent pipeline", the "if" command
was started before the (exit 7) - it had to be, or the latter would not
have been run at all, and they both completed simultaneously (when the
(exit 7) finished the "if" had nothing more to do, as there is no else
clause and the condition is false.

Or another weirder case

    (exit 5) ; $SHELL -c 'echo $?'

when the echo happens, the most recently completed pipeline is
the (exit 5) - so does the standard require '5' as the output?
Obviously not, but where exactly does it say that? And what
words are correct so this one produces 0 as it should, and yet

   $SHELL -c '(exit 5) ; (echo $?)'

still produces 5 - we cannot merely insert "current execution
environment" or even "current shell process" even if the XCU
permitted us to mention processes.
(0004735)
joerg (reporter)
2020-01-17 09:56

 Are you shure for ksh93u+? I get 0 even for ksh93v.
(0004736)
kre (reporter)
2020-01-17 10:31

 Joerg, you're right, my test setup was borked, somehow in the ksh93 setup
(and just that one) $SHELL is getting altered to /bin/sh - so when I
thought I was testing ksh93 I was actually testing a slightly old
version (well, several years old now) of the NetBSD sh. Sorry
about that (the window in which I ran the command was running ksh93,
so when I checked the version that was correct, just $SHELL was incorrect,
so the wrong shell ran the command).

With SHELL set correctly I get 0 from that test case too.

Now I need to work out what in the startup sequence is altering the $SHELL
that is in the environment (and is the shell started).
(0004737)
geoffclare (manager)
2020-01-17 15:39
edited on: 2020-01-17 16:17

 Re: Note: 0004732 the wording difference "most recent pipeliine" v. "last command" goes all the way back to POSIX.1992. (I was hoping one of them had changed and I'd be able to point to why it changed.) I agree it would be good to make these consistent.

Incidentally the latest text for $? (with bugs applied) is "... most recent pipeline (see ...) that was not within a command substitution (see ...)". Perhaps the part about command substitution should also apply to exit and return.

The value of $? if no pipeline has been executed is currently unspecified. If an application relies on it being 0, that's a bug in the application. Having said that, I would not object to changing the standard to require it to be 0 on entry to the shell (but not on entry to a subshell).

Re: Note: 0004733 The uselessness of inheriting $! is similar to the situation for $$. They are a consequence of a subshell originally being created simply by forking.

Re: Note: 0004734 It seems absurd to me to claim that the (exit 7) and the "if" complete simultaneously. The "if" command has to use the exit status of the (exit 7) in order to decide whether to execute the ":". Thus is must perform some processing after the (exit 7) has completed.

Regarding "(exit 5) ; $SHELL -c 'echo $?'" I really can't see any reader of the standard having a problem understanding that there is no relationship here between the (exit 5) and the $?. (And see above where I talk about the value of $? if no pipeline has been executed.)
(0004738)
joerg (reporter)
2020-01-17 15:53
edited on: 2020-01-17 16:04

 I am not aware of any shell that does not start with $? being 0.

The problem in ksh is that it inherits $? in a sub-shell from the creator of the sub-shell, but at the same time replaces an exit without parameter (if it is the first command in that sub-shell) by exit 0, even in case that $? is != 0.

I would call this at least unexpected.
(0004739)
kre (reporter)
2020-01-18 02:38

 Re Note: 0004737

What I'd suggest for exit/return definitions vs $? rather than attempting
to unify the language, is to first ensure that $? is always defined (no
unspecified cases, none is needed) and then simply make the default 'n'
for exit/return be $?

With that there is just one definition, and if it ever needs correction,
everything gets corrected together.

For $! in a subshell, I know nothing can be done, but I would not equate it
to $$, having $$ work the way it does is useful. The problem is that there
is no standard way to obtain the pid of the current executing (sub-)shell.
Many shells provide a mechanism for this (which is also useful) but there
is no common way yet, so nothing that could be standardised.

However $! could reasonably be specified to be unset before any async command
has been started ... when yash differs from every other shell (zsh excluded,
as it does not really try all that hard to be compatible) it is generally a
sign that the standard is lacking, as yash (as I understand it) was built
to implement the standard, whereas everyone else has attempted to build shells
compatible with the original (which is what the standard should be defining).
When yash does something different than everything else, the normal cause
will be that the standard forgot to specify something - which appears to be
the case here, and we should simply fix it.

It doesn't matter whether the "if" and "(exit 7)" complete at the same time or
not, what matters is whether "most recent" means most recently started, or
most recently completed, which isn't specified anywhere. Once again, what
the results should be isn't in question - it is simply a matter of specifying
it all correctly, and no "it is obvious" is not good enough.

Nor is it good enough to "can't really see" - we need to be precise in all
of this, so mis-interpretation is not just unreasonable or absurd, but
impossible.
(0004741)
geoffclare (manager)
2020-01-20 11:57

 Re: Note: 0004739 Good idea to put the detail in the $? description and have exit and return just refer to that.

Regarding the wording to use, I think using "pipeline" is correct. The use of "last command" is ambiguous because in the case of:

command1 | command2

if command1 completes after command2 this could be taken as requiring the exit status of command1 to be used.

I will try and come up with some proposed wording before today's teleconference.
(0004742)
geoffclare (manager)
2020-01-20 14:54
edited on: 2020-01-20 14:55

 Proposed changes:

On page 2350 line 74877 section 2.5.2 Special Parameters, after applying bug 1150 change:
Expands to the decimal exit status of the most recent pipeline (see [xref to 2.9.2]) that was not within a command substitution (see [xref to 2.6.3]).
Note: In <tt>var=$(some_command); echo $?</tt> the output is the exit status of <tt>some_command</tt> but this is because its exit status becomes the exit status of the assignment command <tt>var=$(some_command)</tt> (see [xref to 2.9.1]) and this assignment command is the most recent pipeline.
to:
Expands to the decimal exit status of the pipeline (see [xref to 2.9.2]) that most recently completed execution and was not executed in a subshell environment. The value shall be set to 0 during initialization of the shell. When a subshell environment is created, it is unspecified whether the value of the special parameter '?' from the invoking shell environment is preserved in the subshell or the value is reset to 0.
Note: In <tt>var=$(some_command); echo $?</tt> the output is the exit status of <tt>some_command</tt>, which is executed in a subshell environment, but this is because its exit status becomes the exit status of the assignment command <tt>var=$(some_command)</tt> (see [xref to 2.9.1]) and this assignment command is the most recently completed pipeline.

On page 2399 line 76788 section 2.14 exit, change:
The exit status shall be n, if specified, except that the behavior is unspecified if n is not an unsigned decimal integer or is greater than 255. Otherwise, the value shall be the exit value of the last command executed, or zero if no command was executed. When exit is executed in a trap action, the last command is considered to be the command that executed immediately preceding the trap action.
to:
The exit status shall be n, if specified, except that the behavior is unspecified if n is not an unsigned decimal integer or is greater than 255. If n is not specified, the result shall be as if n were specified with the current value of the special parameter '?' (see [xref to 2.5.2]), except that when exit is executed in a trap action, the value for the special parameter '?' that is considered ``current'' shall be the value it had immediately preceding the trap action.

On page 2407 line 77039 section 2.14 return, change:
The value of the special parameter '?' shall be set to n, an unsigned decimal integer, or to the exit status of the last command executed if n is not specified. If n is not an unsigned decimal integer, or is greater than 255, the results are unspecified. When return is executed in a trap action, the last command is considered to be the command that executed immediately preceding the trap action.
to:
The exit status shall be n, if specified, except that the behavior is unspecified if n is not an unsigned decimal integer or is greater than 255. If n is not specified, the result shall be as if n were specified with the current value of the special parameter '?' (see [xref to 2.5.2]), except that when return is executed in a trap action, the value for the special parameter '?' that is considered ``current'' shall be the value it had immediately preceding the trap action.
(0004743)
kre (reporter)
2020-01-20 18:37

 This (Note: 0004742) is mostly all good (the two minor issues I have with it are
just below) but note that this is really a side issue that developed from
this bug report, I still believe that it would be good to add (and certainly
harmless) some words to the effect of

    When the list begins execution, the value of the special parameter ?
    shall be that produced by evaluation of the condition-list that
    immediately preceded this execution of the list

applied to if/while/until statements (or somewhere common and stated to apply
to all such commands) - that is, to clarify that even though the exit status
($?) from the condition list is not available after one of these compound
commands completes (regardless of being the last command executed as part of
the compound command) its exit status is available inside the code that is the
body of the compound command.



My reservations with the wording in the note relate first to this part

    Note: In <tt>var=$(some_command); echo $?</tt> the output is the exit
    status of <tt>some_command</tt>,

which is all fine, until

    its exit status becomes the exit status of the assignment command
    <tt>var=$(some_command)</tt>

There is no such thing as an "assignment command". What there is is
variable assignments, and null commands, What 2.9.1 says is ...

    If there is no command name, but the command contained a command
    substitution, the command shall complete with the exit status of the
    last command substitution performed. Otherwise, the command shall
    complete with a zero exit status.

which does not invent an "assignment command" - but even if it did would
not cover cases like

    umask 0; >/tmp/foo; # this is just to create a known environment
    </tmp/foo$(exit 1)

which in all shells except bash and zsh (all I have tested anyway) results
in $? being set to 1 - since on that 2nd line, there is no command name, but
there is a command substitution, so the status of the last of those (here there
is just one) becomes the status of this empty command (as 2.9.1 directs).

2.9.1 also says:

    If there is no command name, any redirections shall be performed in a
    subshell environment; it is unspecified whether this subshell environment
    is the same one as that used for a command substitution within the command.

which, since it says "unspecified" might seem to be relevant, but I don't
believe it is, whether the redirect happens in the same subshell as the
command substitution isn't really relevant, there is no command name
(except exit, which is the command substitution command) and so the exit
status here should be the status of the (last) command substitution performed.

Anyway, inventing a fictional assignment command doesn't help, and I don't
think is needed - I don't believe any reference to
     x=$(whatever)
is needed in this context at all. What is the exit status of various commands
(including simple commands without command names, which is what this is) is
specified elsewhere, and doesn't need to also be specified in the definition
of the ? special parameter.



Second reservation: there is no need for

    When a subshell environment is created, it is unspecified whether the
    value of the special parameter '?' from the invoking shell environment
    is preserved in the subshell or the value is reset to 0.

It is preserved, and if we need say anything at all (I have no issues with
saying something here, more clarity is helpful) it should be

    When a subshell environment is created, the value of the special parameter
    ? shall initially be the value it had in the shell environment immediately
    preceding the creation of the subshell environment.

(or words something like that which better meet the standard language).
Perhaps just:

    Creating a subshell environment does not alter the value of the
    special parameter ?

Joerg already cleared up the apparent issue with ksh and the strange 0
status from the test - it is not $? that is incorrect there, but "exit"
and that is an obvious bug, and not worthy of any mention in the standard
at all.

Note that all shells print 1 for

    (exit 1); (echo $?)

including ksh93 (and I presume ksh88). That makes it clear that it is
not the subshell environment that is causing the 0 from

    (exit 1); (exit) ; echo $?

in ksh, but a bug in the exit command (my guess would be that it is
attempting to do what the standard seems to say, looking for the status of
the "last command" and failing to find one in its current environment,
and consequently defaulting to 0. That's bogus, but practically harmless,
as no-one in real code writes a subshell in which the first command is
exit (without a specific exit value) as all that would be is an expensive
no-op.
(0004744)
geoffclare (manager)
2020-01-23 14:55
edited on: 2020-01-23 15:01

 Update to proposed changes, following email discussion of Note: 0004743 ...

On page 2350 line 74877 section 2.5.2 Special Parameters, after applying bug 1150 change:
Expands to the decimal exit status of the most recent pipeline (see [xref to 2.9.2]) that was not within a command substitution (see [xref to 2.6.3]).
Note: In <tt>var=$(some_command); echo $?</tt> the output is the exit status of <tt>some_command</tt> but this is because its exit status becomes the exit status of the assignment command <tt>var=$(some_command)</tt> (see [xref to 2.9.1]) and this assignment command is the most recent pipeline.
to (OPTION 1):
Expands to the decimal exit status of the pipeline (see [xref to 2.9.2]) that most recently completed execution and was not executed in a subshell environment. The value shall be set to 0 during initialization of the shell. When a subshell environment is created, it is unspecified whether the value of the special parameter '?' from the invoking shell environment is preserved in the subshell or the value is reset to 0.
Note: In <tt>var=$(some_command); echo $?</tt> the output is the exit status of <tt>some_command</tt>, which is executed in a subshell environment, but this is because its exit status becomes the exit status of the assignment command <tt>var=$(some_command)</tt> (see [xref to 2.9.1]) and this assignment command is the most recently completed pipeline. Likewise for any pipeline consisting entirely of a simple command that has no command word, but contains one or more command substitutions. (See [xref to 2.9.1].)
or to (OPTION 2):
Expands to the decimal exit status of the pipeline (see [xref to 2.9.2]) that most recently completed execution and was not executed in a subshell environment. The value shall be set to 0 during initialization of the shell. When a subshell environment is created, the value of the special parameter '?' from the invoking shell environment shall be preserved in the subshell.
Note: In <tt>var=$(some_command); echo $?</tt> the output is the exit status of <tt>some_command</tt>, which is executed in a subshell environment, but this is because its exit status becomes the exit status of the assignment command <tt>var=$(some_command)</tt> (see [xref to 2.9.1]) and this assignment command is the most recently completed pipeline. Likewise for any pipeline consisting entirely of a simple command that has no command word, but contains one or more command substitutions. (See [xref to 2.9.1].)

On page 2371 line 75731 section 2.9.4 Compound Commands, add a new paragraph:
In the descriptions below, the exit status of some compound commands is stated in terms of the exit status of a compound-list. The exit status of a compound-list shall be the value that the special parameter '?' (see [xref to 2.5.2]) would have immediately after execution of the compound-list.

On page 2372 line 75766 section 2.9.4.2 The for Loop, change:
The exit status of a for command shall be the exit status of the last command that executes.
to:
If there is at least one item in the list of items, the exit status of a for command shall be the exit status of the last compound-list executed.

On page 2373 line 75793 section 2.9.4.3 Case Conditional Construct, change:
... the exit status shall be the exit status of the last command executed in the compound-list.
to:
... the exit status shall be the exit status of the executed compound-list.

On page 2373 line 75814 section 2.9.4.4 The if Conditional Construct, add:
Note: Although the exit status of the if or elif compound-list is ignored when determining the exit status of the if command, it is available through the special parameter '?' (see [[xref to 2.5.2]) during execution of the next then, elif, or else compound-list (if any is executed) in the normal way.

On page 2374 line 75827 section 2.9.4.5 The while Loop, add:
Note: Since the exit status of compound-list-1 is ignored when determining the exit status of the while command, it is not possible to obtain the status of the command that caused the loop to exit, other than via the special parameter '?' (see [[xref to 2.5.2]) during execution of compound-list-1, for example: <tt>while some_command; st=$?; false; do ...</tt>. The exit status of compound-list-1 is available through the special parameter '?' during execution of compound-list-2, but is known to be zero at that point anyway.

On page 2374 line 75840 section 2.9.4.6 The until Loop, add:
Note: Although the exit status of compound-list-1 is ignored when determining the exit status of the until command, it is available through the special parameter '?' (see [[xref to 2.5.2]) during execution of compound-list-2 in the normal way.

On page 2399 line 76788 section 2.14 exit, change:
The exit status shall be n, if specified, except that the behavior is unspecified if n is not an unsigned decimal integer or is greater than 255. Otherwise, the value shall be the exit value of the last command executed, or zero if no command was executed. When exit is executed in a trap action, the last command is considered to be the command that executed immediately preceding the trap action.
to:
The exit status shall be n, if specified, except that the behavior is unspecified if n is not an unsigned decimal integer or is greater than 255. If n is not specified, the result shall be as if n were specified with the current value of the special parameter '?' (see [xref to 2.5.2]), except that when exit is executed in a trap action, the value for the special parameter '?' that is considered ``current'' shall be the value it had immediately preceding the trap action.

On page 2407 line 77039 section 2.14 return, change:
The value of the special parameter '?' shall be set to n, an unsigned decimal integer, or to the exit status of the last command executed if n is not specified. If n is not an unsigned decimal integer, or is greater than 255, the results are unspecified. When return is executed in a trap action, the last command is considered to be the command that executed immediately preceding the trap action.
to:
The exit status shall be n, if specified, except that the behavior is unspecified if n is not an unsigned decimal integer or is greater than 255. If n is not specified, the result shall be as if n were specified with the current value of the special parameter '?' (see [xref to 2.5.2]), except that when return is executed in a trap action, the value for the special parameter '?' that is considered ``current'' shall be the value it had immediately preceding the trap action.
(0004763)
geoffclare (manager)
2020-01-30 17:20

 Interpretation response
------------------------
The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale:
-------------
Wording such as "last command" is imprecise.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Implement Note: 0004744 choosing option 2 in the first part.
(0004766)
ajosey (manager)
2020-02-03 21:13

 Interpretation Proposed: 3 February 2020
(0004801)
ajosey (manager)
2020-03-23 15:25

 Interpretation approved: 23 March 2020

- Issue History
Date Modified Username Field Change
2019-12-19 02:26 kre New Issue
2019-12-19 02:26 kre Name => Robert Elz
2019-12-19 02:26 kre Section => 2.9.4
2019-12-19 02:26 kre Page Number => 2371-4
2019-12-19 02:26 kre Line Number => 75726-31
2020-01-16 17:42 geoffclare Note Added: 0004731
2020-01-16 17:43 geoffclare Note Edited: 0004731
2020-01-16 20:35 kre Note Added: 0004732
2020-01-16 21:36 kre Note Added: 0004733
2020-01-17 04:17 kre Note Added: 0004734
2020-01-17 04:19 kre Note Edited: 0004734
2020-01-17 09:56 joerg Note Added: 0004735
2020-01-17 10:31 kre Note Added: 0004736
2020-01-17 15:39 geoffclare Note Added: 0004737
2020-01-17 15:53 joerg Note Added: 0004738
2020-01-17 15:56 joerg Note Edited: 0004738
2020-01-17 16:04 joerg Note Edited: 0004738
2020-01-17 16:17 geoffclare Note Edited: 0004737
2020-01-18 02:38 kre Note Added: 0004739
2020-01-20 11:57 geoffclare Note Added: 0004741
2020-01-20 14:54 geoffclare Note Added: 0004742
2020-01-20 14:55 geoffclare Note Edited: 0004742
2020-01-20 14:58 geoffclare Relationship added related to 0001150
2020-01-20 15:04 geoffclare Relationship added related to 0000051
2020-01-20 18:37 kre Note Added: 0004743
2020-01-23 14:55 geoffclare Note Added: 0004744
2020-01-23 14:56 geoffclare Note Edited: 0004744
2020-01-23 14:59 geoffclare Note Edited: 0004744
2020-01-23 15:01 geoffclare Note Edited: 0004744
2020-01-30 17:20 geoffclare Note Added: 0004763
2020-01-30 17:21 geoffclare Interp Status => Pending
2020-01-30 17:21 geoffclare Final Accepted Text => Note: 0004763
2020-01-30 17:21 geoffclare Status New => Interpretation Required
2020-01-30 17:21 geoffclare Resolution Open => Accepted As Marked
2020-01-30 17:21 geoffclare Tag Attached: issue8
2020-02-03 21:13 ajosey Interp Status Pending => Proposed
2020-02-03 21:13 ajosey Note Added: 0004766
2020-03-23 15:25 ajosey Interp Status Proposed => Approved
2020-03-23 15:25 ajosey Note Added: 0004801
2020-05-05 15:18 geoffclare Status Interpretation Required => Applied
2024-02-19 18:28 salewski Issue Monitored: salewski
2024-06-11 09:08 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker