$history[@] doesn't contain last element from $HISTFILE

$history[@] doesn't contain last element from $HISTFILE

[Sebastian Gniazdowski]

typeset -a list
() {
    echo "a" >! phist2.db
    echo "b" >>! phist2.db
    fc -Rap "phist2.db"
    list=( ${history[@]} )
    echo "${history[2]}"
    echo "${history[1]}"
    echo "${#history}";
    integer size="${#history}"
    size+=1
    echo "$size" / "${history[$size]}"
}
print -rl "Now:" "${list[@]}"

b
a
1
2 / b
Now:
a

The output should be:
b
a

My workaround is:
    list=( "${history[$size]}" ${history[@]} )

Best regards,
Sebastian Gniazdowski

Re: $history[@] doesn't contain last element from $HISTFILE

[Bart Schaefer]

This is a side-effect of the implementation of history, specifically
that even with HISTSIZE=0 there is always one line (the immediately
previous command) available for recall with up-history.  Hence that
final line is not actually "committed" into the history until the NEXT
line is read, at which time it either goes into the history "for real"
or is discarded.

I pass no judgement at this time on Sebastian's assertion of whether
the contents of $history[@] "should be" different, though it is
potentially unexpected that $history[$HISTNO] is special-cased.

Re: $history[@] doesn't contain last element from $HISTFILE

[Sebastian Gniazdowski]

On 14 October 2016 at 19:44, Bart Schaefer <schaefer@brasslantern.com> wrote:
> This is a side-effect of the implementation of history, specifically
> that even with HISTSIZE=0 there is always one line (the immediately
> previous command) available for recall with up-history.  Hence that
> final line is not actually "committed" into the history until the NEXT
> line is read, at which time it either goes into the history "for real"
> or is discarded.
>
> I pass no judgement at this time on Sebastian's assertion of whether
> the contents of $history[@] "should be" different, though it is
> potentially unexpected that $history[$HISTNO] is special-cased.

It's fine if it's not an unpredictable thing, I can stick to the
workaround (now not actually a workaround), not having to do an
is-at-least call in return. Although I'm not sure if by
$history[$HISTNO] you mean $history[$size], if there is something
unexpected there, it would be a problem.

Best regards,
Sebastian Gniazdowski

Re: $history[@] doesn't contain last element from $HISTFILE

[Bart Schaefer]

On Fri, Oct 14, 2016 at 11:35 AM, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> It's fine if it's not an unpredictable thing, I can stick to the
> workaround (now not actually a workaround), not having to do an
> is-at-least call in return. Although I'm not sure if by
> $history[$HISTNO] you mean $history[$size], if there is something
> unexpected there, it would be a problem.

$history is not an array, it's a hash whose keys are the history event
numbers.  So (( $#history < HISTSIZE )) is always true but (( HISTNO >
HISTSIZE )) is possible.  The largest possible defined index into
$history is $HISTNO, but of course that's only valid inside ZLE.

If you're manipulating history in an "fc -p" scope or the like there's
really only $(( ${${(k)history[@]}[1]} + 1)) to get the equivalent,
which does seem like an oversight.