Disowning a stopped job

Disowning a stopped job

[Bart Schaefer]

Using "disown" on a stopped job leaves the job stopped.  There should be at
least a warning about this.

Re: Disowning a stopped job

[Sven Wischnowsky]

Bart Schaefer wrote:

> Using "disown" on a stopped job leaves the job stopped.  There should be at
> least a warning about this.

Nobody answered -- or did I miss something?

The patch below makes it print a warning. Simple change, but I'm not
sure I like it. It looks as if disown were complaining, i.e. as if it
didn't actually disown the job. I tried to make that clearer by putting
that `warning' in the message, but still...

The other possibilities would of course be to generate an error, not
disowning the job or to call makerunning() on it before clearing the job
table entry.

Of these, I think I prefer the former. The user can then still call `bg'
and then `disown'.

Bye
  Sven

Index: Src/jobs.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/jobs.c,v
retrieving revision 1.10
diff -u -r1.10 jobs.c
--- Src/jobs.c	2001/02/20 09:16:47	1.10
+++ Src/jobs.c	2001/05/29 09:24:49
@@ -1392,6 +1392,14 @@
 	    printjob(job + jobtab, lng, 2);
 	    break;
 	case BIN_DISOWN:
+	    if (jobtab[job].stat & STAT_STOPPED)
+                zwarnnam(name,
+#ifdef USE_SUSPENDED
+                         "warning: job is suspended",
+#else
+                         "warning: job is stopped",
+#endif
+                         NULL, 0);
 	    deletejob(jobtab + job);
 	    break;
 	}

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

Re: Disowning a stopped job

[Bart Schaefer]

On May 29, 11:28am, Sven Wischnowsky wrote:
} Subject: Re: Disowning a stopped job
}
} Bart Schaefer wrote:
} 
} > Using "disown" on a stopped job leaves the job stopped.  There should be at
} > least a warning about this.
} 
} Nobody answered -- or did I miss something?

It's been difficult to get opinions out of people lately.  I think we're
having -pre-X burnout.

} The other possibilities would of course be to generate an error, not
} disowning the job or to call makerunning() on it before clearing the job
} table entry.
} 
} Of these, I think I prefer the former. The user can then still call `bg'
} and then `disown'.

I suppose the former with an option to do the latter would not work, as
bg/fg/disown have always interpreted their first argument as a string to
match against job names.

Here's the thing to consider:  `disown %1' is equivalent to `%1 &!'.  I
won't go so far as to say it's "intuitive," but the latter certainly looks
as though it should cause the job to run.

Would it be weird (or even possible) to have those two variants work in
different ways in this case?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Disowning a stopped job

[Sven Wischnowsky]

Bart Schaefer wrote:

> On May 29, 11:28am, Sven Wischnowsky wrote:
> } Subject: Re: Disowning a stopped job
> }
> } Bart Schaefer wrote:
> } 
> } > Using "disown" on a stopped job leaves the job stopped.  There should be at
> } > least a warning about this.
> } 
> } Nobody answered -- or did I miss something?
> 
> It's been difficult to get opinions out of people lately.  I think we're
> having -pre-X burnout.

Yes, I feel like that myself.

> } The other possibilities would of course be to generate an error, not
> } disowning the job or to call makerunning() on it before clearing the job
> } table entry.
> } 
> } Of these, I think I prefer the former. The user can then still call `bg'
> } and then `disown'.
> 
> I suppose the former with an option to do the latter would not work, as
> bg/fg/disown have always interpreted their first argument as a string to
> match against job names.

Yep.  I was half-heartedly playing with the idea of a setopt-option,
something like silent_disown or, better, disown_auto_continue.

> Here's the thing to consider:  `disown %1' is equivalent to `%1 &!'.  I
> won't go so far as to say it's "intuitive," but the latter certainly looks
> as though it should cause the job to run.

True.  I had forgotten about this shortcut.

> Would it be weird (or even possible) to have those two variants work in
> different ways in this case?

I would actually prefer it if they would differ.  The only possible way
to implement this is adding a global variable that gets set in execcmd()
and tested in bin_fg().  Not nice, but since execcmd() actually inserts
a `disown' into the list of command words, these cases are
indistinguishable for bin_fg().


Bye
  Sven


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

Re: Disowning a stopped job

[Sven Wischnowsky]

Bart Schaefer wrote:

> On May 29, 11:28am, Sven Wischnowsky wrote:
> } Subject: Re: Disowning a stopped job
> }
> } Bart Schaefer wrote:
> } 
> } > Using "disown" on a stopped job leaves the job stopped.  There should be at
> } > least a warning about this.
> } 
> } Nobody answered -- or did I miss something?
> 
> It's been difficult to get opinions out of people lately.  I think we're
> having -pre-X burnout.

Yes, I feel like that myself.

> } The other possibilities would of course be to generate an error, not
> } disowning the job or to call makerunning() on it before clearing the job
> } table entry.
> } 
> } Of these, I think I prefer the former. The user can then still call `bg'
> } and then `disown'.
> 
> I suppose the former with an option to do the latter would not work, as
> bg/fg/disown have always interpreted their first argument as a string to
> match against job names.

Yep.  I was half-heartedly playing with the idea of a setopt-option,
something like silent_disown or, better, disown_auto_continue.

> Here's the thing to consider:  `disown %1' is equivalent to `%1 &!'.  I
> won't go so far as to say it's "intuitive," but the latter certainly looks
> as though it should cause the job to run.

True.  I had forgotten about this shortcut.

> Would it be weird (or even possible) to have those two variants work in
> different ways in this case?

I would actually prefer it if they would differ.  The only possible way
to implement this is adding a global variable that gets set in execcmd()
and tested in bin_fg().  Not nice, but since execcmd() actually inserts
a `disown' into the list of command words, these cases are
indistinguishable for bin_fg().


Bye
  Sven


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

tag-order problem?

[Tanaka Akira]

I found a problem as follows.

Z(2):akr@flux% Src/zsh -f
flux% echo $ZSH_VERSION 
4.0.1-pre-5
flux% bindkey -e; fpath=(Completion Completion/**/*(/)); autoload -U compinit; compinit -D
flux% zstyle '*' group-name ''
flux% zstyle '*:messages' format '%d'
flux% zstyle '*:descriptions' format '%d'
flux% zstyle ':completion:*' 'tag-order' '*:-non-cvs' '*'
flux% zstyle ':completion:*-non-cvs' 'ignored-patterns' '(*/|)CVS'
flux% compdef _tst tst
flux% _tst () { _arguments -s '-a-:x:' '-b' }
flux% tst -a<TAB>
x
option
-b

I think the option `-b' shouldn't completed here.
-- 
Tanaka Akira

Re: tag-order problem?

[Sven Wischnowsky]

Tanaka Akira wrote:

> I found a problem as follows.
> 
> Z(2):akr@flux% Src/zsh -f
> flux% echo $ZSH_VERSION 
> 4.0.1-pre-5
> flux% bindkey -e; fpath=(Completion Completion/**/*(/)); autoload -U compinit; compinit -D
> flux% zstyle '*' group-name ''
> flux% zstyle '*:messages' format '%d'
> flux% zstyle '*:descriptions' format '%d'
> flux% zstyle ':completion:*' 'tag-order' '*:-non-cvs' '*'
> flux% zstyle ':completion:*-non-cvs' 'ignored-patterns' '(*/|)CVS'
> flux% compdef _tst tst
> flux% _tst () { _arguments -s '-a-:x:' '-b' }
> flux% tst -a<TAB>
> x
> option
> -b
> 
> I think the option `-b' shouldn't completed here.

I know this isn't nice, but I didn't see a good solution and still don't
see one.  This is `caused' by the default value for tag-order which
makes arguments and value be preferred over options (as mentioned in the
docs for the tag-order style).

What one would want here is that the completion system magically knows
that `*' is intended to give the `normal' behaviour.  Unless in those
cases where one really wants to have all tags used at the same time. And
that's the problem...

Bye
  Sven


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

Re: tag-order problem?

[Tanaka Akira]

In article <200105280826.KAA00483@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> I know this isn't nice, but I didn't see a good solution and still don't
> see one.  This is `caused' by the default value for tag-order which
> makes arguments and value be preferred over options (as mentioned in the
> docs for the tag-order style).

Hm.  zsh-4.0.1-pre-3 works as I expected.

Z(2):akr@flux% zsh-4.0.1-pre-3 -f
flux% bindkey -e; autoload -U compinit; compinit -D
flux% zstyle '*' group-name ''
flux% zstyle '*:messages' format '%d'
flux% zstyle '*:descriptions' format '%d'
flux% zstyle ':completion:*' 'tag-order' '*:-non-cvs' '*'
flux% zstyle ':completion:*-non-cvs' 'ignored-patterns' '(*/|)CVS'
flux% compdef _tst tst
flux% _tst () { _arguments -s '-a-:x:' '-b' }
flux% tst -a<TAB>
x


zsh-4.0.1-pre-4 works as zsh-4.0.1-pre-5.  So I suspect the problem is
introduced by some patch between pre-3 and pre-4.  Maybe `-W' related
thing?
-- 
Tanaka Akira

Re: tag-order problem?

[Sven Wischnowsky]

Tanaka Akira wrote:

> In article <200105280826.KAA00483@beta.informatik.hu-berlin.de>,
>   Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> 
> > I know this isn't nice, but I didn't see a good solution and still don't
> > see one.  This is `caused' by the default value for tag-order which
> > makes arguments and value be preferred over options (as mentioned in the
> > docs for the tag-order style).
> 
> Hm.  zsh-4.0.1-pre-3 works as I expected.
> 
> Z(2):akr@flux% zsh-4.0.1-pre-3 -f
> flux% bindkey -e; autoload -U compinit; compinit -D
> flux% zstyle '*' group-name ''
> flux% zstyle '*:messages' format '%d'
> flux% zstyle '*:descriptions' format '%d'
> flux% zstyle ':completion:*' 'tag-order' '*:-non-cvs' '*'
> flux% zstyle ':completion:*-non-cvs' 'ignored-patterns' '(*/|)CVS'
> flux% compdef _tst tst
> flux% _tst () { _arguments -s '-a-:x:' '-b' }
> flux% tst -a<TAB>
> x
> 
> 
> zsh-4.0.1-pre-4 works as zsh-4.0.1-pre-5.  So I suspect the problem is
> introduced by some patch between pre-3 and pre-4.  Maybe `-W' related
> thing?

Hm, yes.  Still the behaviour seems sensible, somehow.

Anyway. Anyone interested could try the patch below, which gives what
you expect in this case. The question is whether this breaks any of the
examples we had for inventing the -w and -W options. I don't think I'll
have the time to test those today.

Bye
  Sven

Index: Completion/Base/Utility/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v
retrieving revision 1.5
diff -u -r1.5 _arguments
--- Completion/Base/Utility/_arguments	2001/04/26 14:40:11	1.5
+++ Completion/Base/Utility/_arguments	2001/05/28 10:29:51
@@ -233,7 +233,7 @@
 	descr="$descrs[anum]"
 	subc="$subcs[anum++]"
 
-        if [[ -n "$matched" ]] || _requested "$subc"; then
+        if [[ -z "$tried" ]] && { [[ -n "$matched" ]] || _requested "$subc" }; then
 
           curcontext="${oldcontext%:*}:$subc"
 
@@ -328,7 +328,8 @@
         fi
       done
       if [[ -z "$hasopts" &&
-            ( -z "$matched" || -n "$alwopt" ) &&
+            -z "$matched" &&
+            ( -z "$tried" || -n "$alwopt" ) &&
             ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] &&
           _requested options &&
           { ! zstyle -T ":completion:${curcontext}:options" prefix-needed ||
@@ -389,7 +390,8 @@
       [[ -n "$tried" && "${${alwopt:+$origpre}:-$PREFIX}" != [-+]* ]] && break
     done
     if [[ -n "$opts" && -z "$aret" &&
-          ( -z "$matched$mesg" || -n "$alwopt" ) &&
+          -z "$matched" &&
+          ( -z "$tried" || -n "$alwopt" ) &&
           nm -eq compstate[nmatches] ]]; then
 
       PREFIX="$origpre"

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

PATCH: Re: tag-order problem?

[Sven Wischnowsky]

Apart from the disown question which probably can't or won't be finally
resolved before the release[1], this is the last thing on my list.

In 14506 I wrote:

> ...
> 
> Anyway. Anyone interested could try the patch below, which gives what
> you expect in this case. The question is whether this breaks any of the
> examples we had for inventing the -w and -W options. I don't think I'll
> have the time to test those today.

I've tested this now and it doesn't seem to break anything.  But I found
and fixed another little ugliness.  With:

  _arguments -w -s '-a:aa:(1)' '-b-:ab:(2)' -x -y

Completion after `-ab<TAB>' didn't complete the `2'.

I'm going to commit it this time.


Bye
  Sven

[1] My only suggestion at this time would be to think about changing the
    warnings to `warning: job is still suspended' (i.e. inserting that
    `still' to make it clearer that the job has been disowned but is
    still sleeping).  Dunno.  Adding a flag to tell bin_fg() that it's a
    `%1 &!' and then calling killjb() there isn't hard to implement
    either, of course, but we got no comments on this, so...

Index: Completion/Base/Utility/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v
retrieving revision 1.5
diff -u -r1.5 _arguments
--- Completion/Base/Utility/_arguments	2001/04/26 14:40:11	1.5
+++ Completion/Base/Utility/_arguments	2001/05/31 12:27:02
@@ -233,7 +233,7 @@
 	descr="$descrs[anum]"
 	subc="$subcs[anum++]"
 
-        if [[ -n "$matched" ]] || _requested "$subc"; then
+        if [[ -z "$tried" ]] && { [[ -n "$matched" ]] || _requested "$subc" }; then
 
           curcontext="${oldcontext%:*}:$subc"
 
@@ -328,7 +328,8 @@
         fi
       done
       if [[ -z "$hasopts" &&
-            ( -z "$matched" || -n "$alwopt" ) &&
+            -z "$matched" &&
+            ( -z "$tried" || -n "$alwopt" ) &&
             ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] &&
           _requested options &&
           { ! zstyle -T ":completion:${curcontext}:options" prefix-needed ||
@@ -389,7 +390,8 @@
       [[ -n "$tried" && "${${alwopt:+$origpre}:-$PREFIX}" != [-+]* ]] && break
     done
     if [[ -n "$opts" && -z "$aret" &&
-          ( -z "$matched$mesg" || -n "$alwopt" ) &&
+          -z "$matched" &&
+          ( -z "$tried" || -n "$alwopt" ) &&
           nm -eq compstate[nmatches] ]]; then
 
       PREFIX="$origpre"
Index: Src/Zle/computil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v
retrieving revision 1.56
diff -u -r1.56 computil.c
--- Src/Zle/computil.c	2001/05/31 09:44:00	1.56
+++ Src/Zle/computil.c	2001/05/31 12:27:03
@@ -1436,7 +1436,7 @@
 	    char *p;
 	    Caopt tmpopt;
 
-	    if (sopts && nonempty(sopts))
+	    if (cur != compcurrent && sopts && nonempty(sopts))
 		state.curopt = (Caopt) uremnode(sopts, firstnode(sopts));
 
 	    if (!state.oargs[state.curopt->num])

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

Re: Disowning a stopped job

[Bart Schaefer]

On May 31,  2:35pm, Sven Wischnowsky wrote:
} Subject: PATCH: Re: tag-order problem?
}
} [1] My only suggestion at this time would be to think about changing the
}     warnings to `warning: job is still suspended' (i.e. inserting that
}     `still' to make it clearer that the job has been disowned but is
}     still sleeping).  Dunno.

Or what about something actually useful, like:

  disown: disowned a stopped job (use `kill -CONT -<pgrp here>')

where <pgrp here> is of course the actual pgrp of the stopped job.  Is
there a reason that won't work?

}     Adding a flag to tell bin_fg() that it's a
}     `%1 &!' and then calling killjb() there isn't hard to implement
}     either, of course, but we got no comments on this, so...

Oops, sorry, I meant to comment on it:

On May 30,  3:42pm, Sven Wischnowsky wrote:
} Subject: Re: Disowning a stopped job
}
} Bart Schaefer wrote:
} 
} > Here's the thing to consider:  `disown %1' is equivalent to `%1 &!'.
} 
} > Would it be weird (or even possible) to have those two variants work in
} > different ways in this case?
} 
} I would actually prefer it if they would differ.  The only possible way
} to implement this is adding a global variable that gets set in execcmd()
} and tested in bin_fg().

As you point out:

} execcmd() actually inserts a `disown' into the list of command words

So don't insert a `disown'.  Insert `bg' and delete the job table entry
in execcmd() the way it's done in execpline2().

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Disowning a stopped job

[Sven Wischnowsky]

Bart Schaefer wrote:

> On May 31,  2:35pm, Sven Wischnowsky wrote:
> } Subject: PATCH: Re: tag-order problem?
> }
> } [1] My only suggestion at this time would be to think about changing the
> }     warnings to `warning: job is still suspended' (i.e. inserting that
> }     `still' to make it clearer that the job has been disowned but is
> }     still sleeping).  Dunno.
> 
> Or what about something actually useful, like:
> 
>   disown: disowned a stopped job (use `kill -CONT -<pgrp here>')
> 
> where <pgrp here> is of course the actual pgrp of the stopped job.  Is
> there a reason that won't work?

The only case I can think of where it wouldn't work is if the job in
question is a super job.  The user would then have to continue the
sub-job, sometimes (see killjb() in signals.c).

> ...
> 
> As you point out:
> 
> } execcmd() actually inserts a `disown' into the list of command words
> 
> So don't insert a `disown'.  Insert `bg' and delete the job table entry
> in execcmd() the way it's done in execpline2().

Hm, yes, I hadn't thought about that.


Bye
  Sven


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