From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.236.50.47 with SMTP id y35csp237521yhb; Tue, 8 May 2012 05:10:04 -0700 (PDT) Return-Path: <9front+bncCIfk-sO2AhCcmqT9BBoEzfUoNg@googlegroups.com> Received-SPF: pass (google.com: domain of 9front+bncCIfk-sO2AhCcmqT9BBoEzfUoNg@googlegroups.com designates 10.224.195.132 as permitted sender) client-ip=10.224.195.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of 9front+bncCIfk-sO2AhCcmqT9BBoEzfUoNg@googlegroups.com designates 10.224.195.132 as permitted sender) smtp.mail=9front+bncCIfk-sO2AhCcmqT9BBoEzfUoNg@googlegroups.com; dkim=pass header.i=9front+bncCIfk-sO2AhCcmqT9BBoEzfUoNg@googlegroups.com Received: from mr.google.com ([10.224.195.132]) by 10.224.195.132 with SMTP id ec4mr1396244qab.7.1336479004518 (num_hops = 1); Tue, 08 May 2012 05:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:message-id:date:from:to:subject :in-reply-to:mime-version:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe:content-type :content-transfer-encoding; bh=KwS0UPl5RuYo4upL/Uw5Yj8U7jiq0E+lr2LkwPd0VZc=; b=uJMQNjGDwfe4gp2ebgEPjh3ChKMLq8xZ3NMkORxBT6F0/LBM7pXH7I6Qd9NWIOvNEC NDThMdKawSWLORF59OcVlPZSJE9mbUcWeWiNNFwFVGo61/LABPYfV1u4SyBDxQuGNfQ5 wGg2M8VCrDNii5YLe4ZleqokBLL+YgLg8xObc= Received: by 10.224.195.132 with SMTP id ec4mr202505qab.7.1336479004450; Tue, 08 May 2012 05:10:04 -0700 (PDT) X-BeenThere: 9front@googlegroups.com Received: by 10.224.33.144 with SMTP id h16ls5639386qad.4.gmail; Tue, 08 May 2012 05:10:04 -0700 (PDT) Received: by 10.224.181.69 with SMTP id bx5mr8186930qab.1.1336479004170; Tue, 08 May 2012 05:10:04 -0700 (PDT) Received: by 10.224.181.69 with SMTP id bx5mr8186929qab.1.1336479004160; Tue, 08 May 2012 05:10:04 -0700 (PDT) Received: from sp.nv ([68.179.132.47]) by gmr-mx.google.com with ESMTP id b22si8433570qcs.3.2012.05.08.05.10.03; Tue, 08 May 2012 05:10:04 -0700 (PDT) Received-SPF: neutral (google.com: 68.179.132.47 is neither permitted nor denied by best guess record for domain of sl@9front.org) client-ip=68.179.132.47; Message-ID: Date: Tue, 8 May 2012 12:10:02 +0000 From: sl@9front.org To: 9front@googlegroups.com Subject: Re: /dev/wsys/*/screen not present for nested rio? In-Reply-To: MIME-Version: 1.0 X-Original-Sender: sl@9front.org X-Original-Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 68.179.132.47 is neither permitted nor denied by best guess record for domain of sl@9front.org) smtp.mail=sl@9front.org Reply-To: 9front@googlegroups.com Precedence: list Mailing-list: list 9front@googlegroups.com; contact 9front+owners@googlegroups.com List-ID: <9front.googlegroups.com> X-Google-Group-Id: 831096995978 List-Post: , List-Help: , List-Archive: Sender: 9front@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > > > windows. If I start a nested rio instance, 'ls' still shows me that > > > the file is present, but on access, it returns back saying file does > > > not exist. > > > > Cannot reproduce. Make sure the screen number you are trying to access > > actually exists in the nested rio. Compare the output of 'ls /dev/wsys' > > in both the main rio and from within the nested rio. > > Thanks, actually cinap_lenrek told me that it is an intended behavior, > that is rio/fsys.c has > if(strcmp(x->wname[i], "screen")==0 && access("/dev/screen", > AEXIST)==0) > break; > and it does not serve the screen in individual /dev/wsys because it is > already provided in the /dev/screen. Though I suppose it would be > interesting if I can get access to it. I was motivated by your example > at http://9fans.net/archive/2012/04/204 to try and make a tiling > window > manager for rio. :) . I think I understand what you're saying, now. The reason I asked you to verify that the screen number you are trying to access actually exists in the nested rio is because from your example: i.e from top: % ls /dev/wsys/1 ... /dev/wsys/1/screen % file /dev/wsys/1/screen plan9 image Now start a rio instance in the term, and do the same, % ls /dev/wsys/2 ... /dev/wsys/2/screen % file /dev/wsys/2/screen Unable to acces, file /dev/wsys/2/screen does not exist it seemed as if /dev/wsys/2/ itself likely did not exist. Had you really started two windows already within the nested rio? This is what happens on my system: term% file /dev/wsys/1/screen /dev/wsys/1/screen: plan 9 image, depth 32 And from within a nested rio: term% file /dev/wsys/1/screen /dev/wsys/1/screen: plan 9 image, depth 32 And from within a third rio, nested within the first nested rio: term% file /dev/wsys/1/screen /dev/wsys/1/screen: plan 9 image, depth 32 In both nested rios there is no /dev/wsys/2/screen because there is no second window at all: term% ls /dev/wsys/2 ls: /dev/wsys/2: '/dev/wsys/2' does not exist -sl