Re: where is this used?

Re: where is this used?

[Sven Wischnowsky]

Richard Coleman wrote:

> 
> The field `other' in the structure `job' appears to
> only be set in execpline() and never used.  Does anyone
> know what this is for?
> 

Once upon a time... when I was fiddling with the execution code I used
this field. It was used for stopping pipelines with loops (and other
shell-internal things) at the end. For doing that the current shell
forked and used the child to represent the end of the pipe. The other
field of the job representing the stopped child held the job number of
the `old' job (the one representing the head of the pipe), so that
both of them could be made runnable.

Since there have been lots of changes in the execution and signal code
I no longer know if it is still needed (maybe the fact that it isn't
used anymore is connected to the fact that several bugs -- like the
infamous never-^C-less-bug -- have reappeared).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: where is this used?

[Richard Coleman]

> > The field `other' in the structure `job' appears to
> > only be set in execpline() and never used.  Does anyone
> > know what this is for?
> 
> Once upon a time... when I was fiddling with the execution code I used
> this field. It was used for stopping pipelines with loops (and other
> shell-internal things) at the end. For doing that the current shell
> forked and used the child to represent the end of the pipe. The other
> field of the job representing the stopped child held the job number of
> the `old' job (the one representing the head of the pipe), so that
> both of them could be made runnable.
> 
> Since there have been lots of changes in the execution and signal code
> I no longer know if it is still needed (maybe the fact that it isn't
> used anymore is connected to the fact that several bugs -- like the
> infamous never-^C-less-bug -- have reappeared).

I just went through some of the older distributions looking into this.
It appears the `other' field first appeared in zsh-2.5.02.  But in all
distributions it was only set and never used.  So it's removal is probably
not the cause of our problem with signals.

rc

cd =5 changed semantics?

[Andreas Koenig]

After installation of beta14 I cannot use the equal substitution as I
was used to with beta13. I haven't changed my dot_zsh_files.

Simple example:

    k@anna:/tmp% dirs
    /tmp / ~
    k@anna:/tmp% setopt | egrep 'auto|equal'
    autolist
    autopushd
    magicequalsubst
    k@anna:/tmp% unsetopt | egrep 'auto|equal'
    autocd
    automenu
    autonamedirs
    autoparamkeys
    autoparamslash
    autoremoveslash
    autoresume
    noequals
    k@anna:/tmp% cd =2
    zsh: 2 not found
^^^^^^^^^^^^^^^^^^^^^^^^^
    k@anna:/tmp% echo $ZSH_VERSION 
    2.6-beta14
    k@anna:/tmp% zsh-2.6-beta13 -f
    anna% pushd /
    / /tmp
    anna% pushd ~
    ~ / /tmp
    anna% cd =2
    anna% pwd
    /tmp
    anna% 

Trying several variations on setopt/unsetopt didn't change
behaviour. What's going on?

Thanks,
andreas

Re: cd =5 changed semantics?

[Zefram]

[beta14]
>    k@anna:/tmp% cd =2
>    zsh: 2 not found
[beta13]
>    anna% cd =2
>    anna% pwd
>    /tmp

The semantics, as you suggest, have changed.  Equals substitution now
only does pathname and alias substitution.  The directory stack
substitution is now done with ~.  See zshexpn(1), specifically the
section headed "FILENAME EXPANSION".

This change was actually discussed and approved last year, but wasn't
implemented until recently.  The rationale is that this makes it
possible to use = to generate the pathname of a command beginning with
a digit (this *is* an issue), and it makes all the expansions to
directory names use ~.

-zefram