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
___
Hi,
On Tue, Jul 26, 2011 at 4:42 PM, Lennart Poettering
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 not to
> do that...
..
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, Lenn
On Jul 26, 2011, at 1:34 PM, Ray Strode wrote:
> Hi,
>
> On Tue, Jul 26, 2011 at 4:02 PM, Jeremy Huddleston 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 parted, hence you
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
Hi,
On Tue, Jul 26, 2011 at 4:02 PM, Jeremy Huddleston 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 user at the consol
On Jul 26, 2011, at 12:23 PM, Ray Strode wrote:
> Hi,
>
> On Tue, Jul 26, 2011 at 2:57 PM, Jeremy Huddleston 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 t
Hi,
On Tue, Jul 26, 2011 at 2:57 PM, Jeremy Huddleston 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 point in setti
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,
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
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 calle
Signed-off-by: Matěj Cepl
---
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
+#define OK_EXIT 0
12 matches
Mail list logo
