Re: Disowning a stopped job

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx