[9fans] problems with redirection in rc

[9fans] problems with redirection in rc

[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\a9_r	total        :   9.4317E-01
^[];/home/sykora/CALC/doing/tests/10_r/-xeon4\a10_r	total        :   9.4105E-01
^[];/home/sykora/CALC/doing/tests/11_r/-xeon4\a11_r	total        :   9.3897E-01
^[];/home/sykora/CALC/doing/tests/12_r/-xeon4\a12_r	total        :   9.3685E-01
^[];/home/sykora/CALC/doing/tests/13_r/-xeon4\a13_r	total        :   9.3446E-01
^[];/home/sykora/CALC/doing/tests/14_r/-xeon4\a14_r	total        :   9.3180E-01
^[];/home/sykora/CALC/doing/tests/15_r/-xeon4\a15_r	total        :   9.2890E-01
^[];/home/sykora/CALC/doing/tests/16_r/-xeon4\a16_r	total        :   9.2589E-01 ,

which quite surprised me... Can you tell me why this happens? I am running p9p.

Thanks
Ruda

Re: [9fans] problems with redirection in rc

[roger peppe]

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 <rudolf.sykora@gmail.com>:
> 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
>
>

Re: [9fans] problems with redirection in rc

[Russ Cox]

On Tue, May 5, 2009 at 6:29 AM, Rudolf Sykora <rudolf.sykora@gmail.com> 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

[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.

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

[Rudolf Sykora]

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

[Rudolf Sykora]

2009/5/5 roger peppe <rogpeppe@gmail.com>:
> {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

[Rudolf Sykora]

2009/5/5 Anthony Sorace <anothy@gmail.com>:
> //  ];/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

[Rudolf Sykora]

> 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

[erik quanstrom]

> > 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

[roger peppe]

2009/5/5 Rudolf Sykora <rudolf.sykora@gmail.com>:
> 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

[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

[roger peppe]

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 <quanstro@quanstro.net>:
>> 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

[erik quanstrom]

On Tue May  5 11:46:40 EDT 2009, rogpeppe@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

[Russ Cox]

On Tue, May 5, 2009 at 8:44 AM, roger peppe <rogpeppe@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.

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