Hi,
Apparently I wrote this patch like 5 years and promptly forgot about.
Matej tracked me down and asked me to chime in. I don't really
remember the patch, but it sort of makes sense to me so I'll try to
answer any questions about it.
What's the point of setsid(2)? It certainly doesn't fall
On Jul 26, 2011, at 11:28 AM, Ray Strode wrote:
Hi,
Apparently I wrote this patch like 5 years and promptly forgot about.
Matej tracked me down and asked me to chime in. I don't really
remember the patch, but it sort of makes sense to me so I'll try to
answer any questions about it.
Hi,
On Tue, Jul 26, 2011 at 2:57 PM, Jeremy Huddleston jerem...@apple.com wrote:
yick... ok, well I'd suggest making that its own patch rather than squashed
into the stdin one... I dunno how I feel about it and will let others chime
in...
It's two pieces of the same thing. There's not much
On Jul 26, 2011, at 12:23 PM, Ray Strode wrote:
Hi,
On Tue, Jul 26, 2011 at 2:57 PM, Jeremy Huddleston jerem...@apple.com wrote:
yick... ok, well I'd suggest making that its own patch rather than squashed
into the stdin one... I dunno how I feel about it and will let others
chime in...
Hi,
On Tue, Jul 26, 2011 at 4:02 PM, Jeremy Huddleston jerem...@apple.com wrote:
IMO, there is a point to closing stdin aside from the setsid(2).
My point is, it only solves the problem part way.
As an example, say a program wants to ask the user for a password.
The program supports asking the
On Tue, 26.07.11 16:34, Ray Strode (halfl...@gmail.com) wrote:
The example serves to show that redirecting STDIN to /dev/null
partially solves the same problem setsid partially solves.That problem
is detaching X clients from the tty startx was run on.
Or is there another problem being
On Jul 26, 2011, at 1:34 PM, Ray Strode wrote:
Hi,
On Tue, Jul 26, 2011 at 4:02 PM, Jeremy Huddleston jerem...@apple.com wrote:
IMO, there is a point to closing stdin aside from the setsid(2).
My point is, it only solves the problem part way.
Well, the problem you are reporting is 2
We're discussing detaching from the tty that startx(1) was executed on, not the
tyy that the X11 server uses for its VT.
IE, you login to the shell on /dev/tty1, you run startx(1) there, and X11
starts on /dev/tty7. This is about disassociating with /dev/tty1.
On Jul 26, 2011, at 1:42 PM,
Hi,
On Tue, Jul 26, 2011 at 4:42 PM, Lennart Poettering
lenn...@poettering.net wrote:
What I am trying to say here basically: if you are planning to invoke
setsid() or detach from the controlling tty otherwise in the normal X
servers, then you'll break existing code. And I'd like to ask you
Hi,
Well, the problem you are reporting is 2 parted, hence you should have 2
commits. The stdin closing is an issue in its own right and should be a
separate patch.
Okay, i'll look into splitting up the patch and follow up to your
other points later.
--Ray
Signed-off-by: Matěj Cepl mc...@redhat.com
---
xinit.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/xinit.c b/xinit.c
index 42ff008..7f56aab 100644
--- a/xinit.c
+++ b/xinit.c
@@ -91,6 +91,8 @@ char xserverrcbuf[256];
#define TRUE 1
#define FALSE 0
What's the point of setsid(2)? It certainly doesn't fall under the title of
the patch.
Also, you don't need:
+ close (STDIN_FILENO);
That is done for you by dup2(2). Also doing so could result in a problem if
this code were used in a multithreaded application. If another thread
12 matches
Mail list logo
