y-or-n-p and emacs --daemon

y-or-n-p and emacs --daemon

[Ulrich Mueller]

Considering bugs like #1474, I wonder if y-or-n-p DTRT?

Try the following:

   $ emacs-23 -Q --daemon --eval '(y-or-n-p "hello? ")'

1. It hangs indefinitely,
2. it does not detach properly (it forks, but the parent doesn't exit),
3. it doesn't start the server.

Of course 2. and 3. are a consequence of 1. since it doesn't come to
the point where daemon-initialized gets called.

Now the problem is that y-or-n-p is called from many places, so
depending on the configuration there is some chance that Emacs will
ask for user interaction before initialisation is finished. There is
even one in server-start (which AFAICS won't be triggered in daemon
mode, but still...).

Shouldn't y-or-n-p signal an error if there is nobody to answer its
question? (Where necessary, its call could be condition-cased then.)

Same arguments apply to yes-or-no-p, of course.

Ulrich

Re: y-or-n-p and emacs --daemon

[Espen Wiborg]

Ulrich Mueller <ulm@gentoo.org> writes:
> Considering bugs like #1474, I wonder if y-or-n-p DTRT?
>
> Try the following:
>
>    $ emacs-23 -Q --daemon --eval '(y-or-n-p "hello? ")'
>
> 1. It hangs indefinitely,
> 2. it does not detach properly (it forks, but the parent doesn't exit),
> 3. it doesn't start the server.
>
> Of course 2. and 3. are a consequence of 1. since it doesn't come to
> the point where daemon-initialized gets called.
>
> Now the problem is that y-or-n-p is called from many places, so
> depending on the configuration there is some chance that Emacs will
> ask for user interaction before initialisation is finished. There is
> even one in server-start (which AFAICS won't be triggered in daemon
> mode, but still...).

Actually, this yes-or-no-p *is* triggered in daemon mode, but only
(AFAICT) in the case uncovered by bug #1310, where a client's X
connection is lost and the daemon tries to shut down.

-- 
Espen Wiborg <espenhw@grumblesmurf.org> - Veritas vos liberabit
'Pooh?' he said.  'Yes, Piglet?' Pooh replied. 'Nothing,' Piglet
said, taking Pooh's paw, 'I just wanted to throw an exception.'

Re: y-or-n-p and emacs --daemon

[Chong Yidong]

Espen Wiborg <espenhw@grumblesmurf.org> writes:

>>    $ emacs-23 -Q --daemon --eval '(y-or-n-p "hello? ")'
>>
>> 1. It hangs indefinitely,
>> 2. it does not detach properly (it forks, but the parent doesn't exit),
>> 3. it doesn't start the server.
>>
>> Now the problem is that y-or-n-p is called from many places, so
>> depending on the configuration there is some chance that Emacs will
>> ask for user interaction before initialisation is finished. There is
>> even one in server-start (which AFAICS won't be triggered in daemon
>> mode, but still...).
>
> Actually, this yes-or-no-p *is* triggered in daemon mode, but only
> (AFAICT) in the case uncovered by bug #1310, where a client's X
> connection is lost and the daemon tries to shut down.

The only thing I can think of is to make y-or-n-p and yes-or-no-p
default to "no" when only the daemon's dummy terminal is open.  Does
anyone have a better suggestion?

Re: y-or-n-p and emacs --daemon

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Espen Wiborg <espenhw@grumblesmurf.org> writes:
  > 
  > >>    $ emacs-23 -Q --daemon --eval '(y-or-n-p "hello? ")'
  > >>
  > >> 1. It hangs indefinitely,
  > >> 2. it does not detach properly (it forks, but the parent doesn't exit),
  > >> 3. it doesn't start the server.
  > >>
  > >> Now the problem is that y-or-n-p is called from many places, so
  > >> depending on the configuration there is some chance that Emacs will
  > >> ask for user interaction before initialisation is finished. There is
  > >> even one in server-start (which AFAICS won't be triggered in daemon
  > >> mode, but still...).
  > >
  > > Actually, this yes-or-no-p *is* triggered in daemon mode, but only
  > > (AFAICT) in the case uncovered by bug #1310, where a client's X
  > > connection is lost and the daemon tries to shut down.
  > 
  > The only thing I can think of is to make y-or-n-p and yes-or-no-p
  > default to "no" when only the daemon's dummy terminal is open.  

Bad idea:
(unless (y-or-n-p "Stop me from removing all your files") 
        /bin/rm -rf /
        )

  > Does anyone have a better suggestion?

Ignore it, or fix it properly: so that it works like y-or-n-p when using -batch.

Re: y-or-n-p and emacs --daemon

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

>   > The only thing I can think of is to make y-or-n-p and yes-or-no-p
>   > default to "no" when only the daemon's dummy terminal is open.  
>
> Bad idea:
> (unless (y-or-n-p "Stop me from removing all your files") 
>         /bin/rm -rf /
>         )
>
>   > Does anyone have a better suggestion?
>
> Ignore it, or fix it properly: so that it works like y-or-n-p when
> using -batch.

I don't think that would solve the problem either, since AFAIU the
daemon might not have a user accessible terminal at all (as bug#1310).

What we could do is to make y-or-n-p signal an error.  Individual
callers will then have to check for daemon-mode and do something else
before calling y-or-n-p; which is also probably the way to fix bug#1310.

Re: y-or-n-p and emacs --daemon

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > >   > The only thing I can think of is to make y-or-n-p and yes-or-no-p
  > >   > default to "no" when only the daemon's dummy terminal is open.  
  > >
  > > Bad idea:
  > > (unless (y-or-n-p "Stop me from removing all your files") 
  > >         /bin/rm -rf /
  > >         )
  > >
  > >   > Does anyone have a better suggestion?
  > >
  > > Ignore it, or fix it properly: so that it works like y-or-n-p when
  > > using -batch.
  > 
  > I don't think that would solve the problem either, since AFAIU the
  > daemon might not have a user accessible terminal at all (as bug#1310).

Bug#1310 is a long standing Gtk+ bug, Jan has made workarounds for it a
few times, and it is looking at this instance too.  So that bug is not
related to this issue.  BTW, the patch in #1310 is probably correct.

  > What we could do is to make y-or-n-p signal an error.  

IMO redefining the meaning of y-or-n-p is still not a good idea.

Re: y-or-n-p and emacs --daemon

[Stephen J. Turnbull]

Dan Nicolaescu writes:

 > IMO redefining the meaning of y-or-n-p is still not a good idea.

The problem is that y-or-n-p is not defined at all if there's no
interactive terminal.  It's not a redefinition.

Re: y-or-n-p and emacs --daemon

[Stefan Monnier]

>> Bad idea:
>> (unless (y-or-n-p "Stop me from removing all your files") 
>> /bin/rm -rf /
>> )

Such a question would be a bug that we need fixing.  Usually Emacs is
pretty consistent in asking questions in such a way that `n' is
a safe answer.

>> Ignore it, or fix it properly: so that it works like y-or-n-p when
>> using -batch.
> I don't think that would solve the problem either, since AFAIU the
> daemon might not have a user accessible terminal at all (as bug#1310).

Does someone know the reason for this problem?  E.g. it's not clear to
me why the y-or-n-p question is displayed (even though it's after
"Starting Emacs daemon", so stdout should have been closed) but the
answer is ignored (or is it?).

Ideally, either the question comes before detaching and it should then
behave as it does in -batch, or the question comes after detaching and
it should then wait for a frame to be created to display the question
in there.


        Stefan

Re: y-or-n-p and emacs --daemon

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> Bad idea:
  > >> (unless (y-or-n-p "Stop me from removing all your files") 
  > >> /bin/rm -rf /
  > >> )
  > 
  > Such a question would be a bug that we need fixing.  Usually Emacs is
  > pretty consistent in asking questions in such a way that `n' is
  > a safe answer.

That's not safe enough, this might happen for code that is in the user's
.emacs.

  > >> Ignore it, or fix it properly: so that it works like y-or-n-p when
  > >> using -batch.
  > > I don't think that would solve the problem either, since AFAIU the
  > > daemon might not have a user accessible terminal at all (as bug#1310).
  > 
  > Does someone know the reason for this problem?  E.g. it's not clear to
  > me why the y-or-n-p question is displayed (even though it's after
  > "Starting Emacs daemon", so stdout should have been closed) but the

"Starting Emacs daemon" is printed at the beginning of `command-line-1',
before detaching.
--eval is also run before detaching.

  > answer is ignored (or is it?).

It's not ignored, the input is not setup right.  
strace shows:
select(1, [], NULL, NULL, {100000, 0}
          ^^^
          select is waiting on a empty set of descriptors

so noninteractive || IS_DAEMON is probably missing in some place(s).

Re: y-or-n-p and emacs --daemon

[Stefan Monnier]

>> answer is ignored (or is it?).
> It's not ignored, the input is not setup right.  
> strace shows:
> select(1, [], NULL, NULL, {100000, 0}
>           ^^^
>           select is waiting on a empty set of descriptors

Oh, I see.

> so noninteractive || IS_DAEMON is probably missing in some place(s).

Yes sounds right, tho I'd probably use FRAME_INITIAL_P (SELECTED_FRAME ())
isntead.


        Stefan

Re: y-or-n-p and emacs --daemon

[Ulrich Mueller]

>>>>> On Wed, 03 Dec 2008, Stefan Monnier wrote:

> Ideally, either the question comes before detaching and it should then
> behave as it does in -batch,

I think that this is unaccaptable. A daemon shouldn't be interactive
before detaching. Besides, there might not be any terminal associated
with stdin, so this doesn't solve the problem for this case.

Can't y-or-n-p signal an error if it's called before detaching?

Ulrich

Re: y-or-n-p and emacs --daemon

[Thierry Volpiatto]

Ulrich Mueller <ulm@gentoo.org> writes:

>>>>>> On Wed, 03 Dec 2008, Stefan Monnier wrote:
>
>> Ideally, either the question comes before detaching and it should then
>> behave as it does in -batch,
>
> I think that this is unaccaptable. A daemon shouldn't be interactive
> before detaching. Besides, there might not be any terminal associated
> with stdin, so this doesn't solve the problem for this case.
>
> Can't y-or-n-p signal an error if it's called before detaching?

Note:
y-or-n-p is not the only case of interactivity that can happen when
starting daemon:
if desktop save buffer that has been opened as /su:... or /sudo 
it will prompt for password and will hang until user kill process.
 
-- 
A + Thierry Volpiatto
Location: Saint-Cyr-Sur-Mer - France

Re: y-or-n-p and emacs --daemon

[Stefan Monnier]

>> Ideally, either the question comes before detaching and it should then
>> behave as it does in -batch,
> I think that this is unaccaptable.  A daemon shouldn't be interactive
> before detaching.  Besides, there might not be any terminal associated
> with stdin, so this doesn't solve the problem for this case.

My comment was not intended to imply that this will solve all problems.
But it will at least make the code work as close to its intended
behavior as possible.

Now it will indeed be the case that the daemon will often be started
non-interactively, in which case any form of interactivity is
undesirable.  This is a separate problem.  I'm not sure how best to
solve it, tho if we can detect that stdin=/dev/null (i.e. when we reach
EOF on stdin) we might want to signal an error, like you propose.


        Stefan