Re: [9fans] problems with redirection in rc
On Tue May 5 11:46:40 EDT 2009, rogpe...@gmail.com wrote: > in that case, surely it'd be trivial to make a root-suid > executable that allows namespace manipulation in > a non-sensitive area (e.g. /mnt)? maybe it could > be distributed as part of p9p meaning hacks like > $NAMESPACE could go away under linux. > maybe it already has been, and i'm as ignorant as usual. you underestimate the capabilities of the linux guys! i don't think you would need to work that hard. each window already has a window id. you could use that to publish the label in your p9p 9p namespace. in any event, the reason for putting up with xterm escapes is so that label just works in an xterm window and, conversely, regular linux tools that change the label also work. - erik
Re: [9fans] problems with redirection in rc
On Tue, May 5, 2009 at 8:44 AM, roger peppe wrote: > in that case, surely it'd be trivial to make a root-suid > executable that allows namespace manipulation in > a non-sensitive area (e.g. /mnt)? maybe it could > be distributed as part of p9p meaning hacks like > $NAMESPACE could go away under linux. > maybe it already has been, and i'm as ignorant as usual. if you have the fuse kernel module installed, you can run mkdir $HOME/acme acme -m $HOME/acme and acme will mount itself there via 9pfuse. in general i don't view fuse etc as stable enough to warrant throwing away $NAMESPACE. also you'd still have to deal with non-linux systems. finally, in the specific case of label: the echoing trick is sad but also works around the lack of exported file system when you connect to another machine via ssh. (in plan 9, if you cpu somewhere rc can still find the terminal's /dev/label. not so on linux, even in the supposed presence of usable per-process name spaces.) russ
Re: [9fans] problems with redirection in rc
in that case, surely it'd be trivial to make a root-suid executable that allows namespace manipulation in a non-sensitive area (e.g. /mnt)? maybe it could be distributed as part of p9p meaning hacks like $NAMESPACE could go away under linux. maybe it already has been, and i'm as ignorant as usual. 2009/5/5 erik quanstrom : >> yes. it gets around the fact that linux doesn't have per-process namespaces >> (well if it does, plan9port doesn't use them), so there's no easy >> way to have a different /dev/label for each 9term. > > linux does have per-process namespaces. unfortunately, since linux > security depends on the namespace, you are not allowed to use > per process namespaces unless you're the superuser. > > - erik > >
Re: [9fans] problems with redirection in rc
> yes. it gets around the fact that linux doesn't have per-process namespaces > (well if it does, plan9port doesn't use them), so there's no easy > way to have a different /dev/label for each 9term. linux does have per-process namespaces. unfortunately, since linux security depends on the namespace, you are not allowed to use per process namespaces unless you're the superuser. - erik
Re: [9fans] problems with redirection in rc
2009/5/5 Rudolf Sykora : > So if I understand right, this is/was a plan9port related feature, right? yes. it gets around the fact that linux doesn't have per-process namespaces (well if it does, plan9port doesn't use them), so there's no easy way to have a different /dev/label for each 9term.
Re: [9fans] problems with redirection in rc
> > I changed label to write to /dev/tty explicitly, which should > > avoid this problem. > > > > Russ > > So if I understand right, this is/was a plan9port related feature, right? it's a unix-related problem. the feature of setting window labels is shared between plan 9 and p9p, but the plan 9 version uses /dev/label while the p9p version uses xterm escapes. the plan 9 version doesn't have this quirk, but the p9p version plays nicely with unix stuff. it's a compromise, but probablly the best one available. - erik
Re: [9fans] problems with redirection in rc
> You've got the cd implementation from label(1) loaded. > In interactive mode, it echos escape codes that are > supposed to update the label in your terminal window. > Instead it wrote them to the redirected file. > > I changed label to write to /dev/tty explicitly, which should > avoid this problem. > > Russ So if I understand right, this is/was a plan9port related feature, right? thanks ruda
Re: [9fans] problems with redirection in rc
2009/5/5 Anthony Sorace : > // ];/home/sykora/CALC/doing/tests/10_r/-xeon4 10_r ... > > i think these are escape sequences generated by a defined 'cd' > function containing awd. do "fn cd" before you run this to undefine > the function and this should go away. true. thanks ruda
Re: [9fans] problems with redirection in rc
2009/5/5 roger peppe :
> {for (i in *_r) @{cd $i; echo -n $i^' '; grep total otdit | grep -v na}} >
> res
>
with this I get the same as with
for (i in *_r) @{cd $i; echo -n $i^' '; grep total otdit | grep -v na} >> res
which is now reasonable, having read R. Cox' post.
Thanks
ruda
Re: [9fans] problems with redirection in rc
2009/5/5 Anthony Sorace > what's surprising is that this behavior changed based on *only* > changing the > to a >>. you're sure you didn't change placement as > well? i'd have expected your output file in the > case to match the > results for the last _r label from the output file in the >> case. well, yes. The last line of the >> output is the same as the single line got from >. I didn't write it fully in my post, sorry. ruda
Re: [9fans] problems with redirection in rc
// ];/home/sykora/CALC/doing/tests/10_r/-xeon4 10_r ... i think these are escape sequences generated by a defined 'cd' function containing awd. do "fn cd" before you run this to undefine the function and this should go away. what's surprising is that this behavior changed based on *only* changing the > to a >>. you're sure you didn't change placement as well? i'd have expected your output file in the > case to match the results for the last _r label from the output file in the >> case.
Re: [9fans] problems with redirection in rc
On Tue, May 5, 2009 at 6:29 AM, Rudolf Sykora wrote:
> Hello everyone!
>
> To get some useful information from a file I write:
>
> ; for (i in *_r) @{cd $i; echo -n $i^' '; grep total otdit | grep -v na}
>
> to get lines from the 'otdit' files in *_r subdirectories with the
> word 'total' on them, but no 'na' on them. This works to my liking and
> produces sth. like
>
> 10_r total : 9.4105E-01
> 11_r total : 9.3897E-01
> 12_r total : 9.3685E-01
> 13_r total : 9.3446E-01
> 14_r total : 9.3180E-01
> 15_r total : 9.2890E-01
> 16_r total : 9.2589E-01
> 17_r total : 9.2299E-01
> 18_r total : 9.1860E-01
> ...
> 9_r total : 9.4317E-01
>
> Ok, now I wanted to save this, so I naively appended '> res'. But then
> the contents of 'res' was only the last line:
> 9_r total : 9.4317E-01
In
; for (i in *_r) @{cd $i; echo -n $i^' '; grep total otdit | grep -v na} > res
the >res binds tighter than the for loop, so it runs a separate
redirection for each iteration. You need
; { for (i in *_r) @{cd $i; echo -n $i^' '; grep total otdit | grep
-v na}} > res
> Ok, so I thought '>> res' should be used instead. But then I got sth. like
>
> ];/home/sykora/CALC/doing/tests/9_r/-xeon4 9_r total : 9.4317E-01
> ];/home/sykora/CALC/doing/tests/10_r/-xeon4 10_r total :
> 9.4105E-01
> ];/home/sykora/CALC/doing/tests/11_r/-xeon4 11_r total :
> 9.3897E-01
> ];/home/sykora/CALC/doing/tests/12_r/-xeon4 12_r total :
> 9.3685E-01
> ];/home/sykora/CALC/doing/tests/13_r/-xeon4 13_r total :
> 9.3446E-01
> ];/home/sykora/CALC/doing/tests/14_r/-xeon4 14_r total :
> 9.3180E-01
> ];/home/sykora/CALC/doing/tests/15_r/-xeon4 15_r total :
> 9.2890E-01
> ];/home/sykora/CALC/doing/tests/16_r/-xeon4 16_r total :
> 9.2589E-01 ,
>
> which quite surprised me... Can you tell me why this happens? I am running
> p9p.
You've got the cd implementation from label(1) loaded.
In interactive mode, it echos escape codes that are
supposed to update the label in your terminal window.
Instead it wrote them to the redirected file.
I changed label to write to /dev/tty explicitly, which should
avoid this problem.
Russ
Re: [9fans] problems with redirection in rc
where did you put the redirection?
i'd have thought that this would work ok (note the added braces):
{for (i in *_r) @{cd $i; echo -n $i^' '; grep total otdit | grep -v na}} > res
2009/5/5 Rudolf Sykora :
> Hello everyone!
>
> To get some useful information from a file I write:
>
> ; for (i in *_r) @{cd $i; echo -n $i^' '; grep total otdit | grep -v na}
>
> to get lines from the 'otdit' files in *_r subdirectories with the
> word 'total' on them, but no 'na' on them. This works to my liking and
> produces sth. like
>
> 10_r total : 9.4105E-01
> 11_r total : 9.3897E-01
> 12_r total : 9.3685E-01
> 13_r total : 9.3446E-01
> 14_r total : 9.3180E-01
> 15_r total : 9.2890E-01
> 16_r total : 9.2589E-01
> 17_r total : 9.2299E-01
> 18_r total : 9.1860E-01
> ...
> 9_r total : 9.4317E-01
>
> Ok, now I wanted to save this, so I naively appended '> res'. But then
> the contents of 'res' was only the last line:
> 9_r total : 9.4317E-01
>
> Ok, so I thought '>> res' should be used instead. But then I got sth. like
>
> ];/home/sykora/CALC/doing/tests/9_r/-xeon4 9_r total : 9.4317E-01
> ];/home/sykora/CALC/doing/tests/10_r/-xeon4 10_r total :
> 9.4105E-01
> ];/home/sykora/CALC/doing/tests/11_r/-xeon4 11_r total :
> 9.3897E-01
> ];/home/sykora/CALC/doing/tests/12_r/-xeon4 12_r total :
> 9.3685E-01
> ];/home/sykora/CALC/doing/tests/13_r/-xeon4 13_r total :
> 9.3446E-01
> ];/home/sykora/CALC/doing/tests/14_r/-xeon4 14_r total :
> 9.3180E-01
> ];/home/sykora/CALC/doing/tests/15_r/-xeon4 15_r total :
> 9.2890E-01
> ];/home/sykora/CALC/doing/tests/16_r/-xeon4 16_r total :
> 9.2589E-01 ,
>
> which quite surprised me... Can you tell me why this happens? I am running
> p9p.
>
> Thanks
> Ruda
>
>
[9fans] problems with redirection in rc
Hello everyone!
To get some useful information from a file I write:
; for (i in *_r) @{cd $i; echo -n $i^' '; grep total otdit | grep -v na}
to get lines from the 'otdit' files in *_r subdirectories with the
word 'total' on them, but no 'na' on them. This works to my liking and
produces sth. like
10_rtotal: 9.4105E-01
11_rtotal: 9.3897E-01
12_rtotal: 9.3685E-01
13_rtotal: 9.3446E-01
14_rtotal: 9.3180E-01
15_rtotal: 9.2890E-01
16_rtotal: 9.2589E-01
17_rtotal: 9.2299E-01
18_rtotal: 9.1860E-01
...
9_r total: 9.4317E-01
Ok, now I wanted to save this, so I naively appended '> res'. But then
the contents of 'res' was only the last line:
9_r total: 9.4317E-01
Ok, so I thought '>> res' should be used instead. But then I got sth. like
];/home/sykora/CALC/doing/tests/9_r/-xeon49_r total: 9.4317E-01
];/home/sykora/CALC/doing/tests/10_r/-xeon410_r total:
9.4105E-01
];/home/sykora/CALC/doing/tests/11_r/-xeon411_r total:
9.3897E-01
];/home/sykora/CALC/doing/tests/12_r/-xeon412_r total:
9.3685E-01
];/home/sykora/CALC/doing/tests/13_r/-xeon413_r total:
9.3446E-01
];/home/sykora/CALC/doing/tests/14_r/-xeon414_r total:
9.3180E-01
];/home/sykora/CALC/doing/tests/15_r/-xeon415_r total:
9.2890E-01
];/home/sykora/CALC/doing/tests/16_r/-xeon416_r total:
9.2589E-01 ,
which quite surprised me... Can you tell me why this happens? I am running p9p.
Thanks
Ruda
Re: [9fans] ssh v2, using a remote linux server
the "problem" with fgb's ssh2 (last time I used it) was that it didn't do many optional things like -L -R -p I had to fiddle with the source to get it to use port 222 (yay FOSS) So there's still room for some work if anyone's up for it
