[9fans] rc bug?
this seems to be a good day for me to be finding old bugs.
i don't think these two bits of rc should behave any differently:
% rc -c 'echo hello /fd/4' [4] /dev/cons
hello
% {echo hello /fd/4} [4] /dev/cons
/fd/4: rc: can't open: '/fd/4' inappropriate use of fd
%
as it happens, the actual file being opened in the second
instance is '#c/cons' (the original rc's stdin).
Re: [9fans] rc bug?
% rc -c 'echo hello /fd/4' [4] /dev/cons
hello
% {echo hello /fd/4} [4] /dev/cons
/fd/4: rc: can't open: '/fd/4' inappropriate use of fd
%
as it happens, the actual file being opened in the second
instance is '#c/cons' (the original rc's stdin).
if you'd used a larger fd, you would have gotten this error
/fd/9: rc (8.out): can't open: '/fd/9' mounted directory forbids creation
this hints at the real problem. redirections are processed in
two steps. opening the file is done by X(read|write|append|rdwr).
assigning the proper fd is done by execexec. (called when running
an external function.) the problem is that your example requires
step two to be done when executing step 1. (that's why the rc -c
trick worked, you forced rc to create fd 4 before using it in the
subshell and it also explains why you got the wrong fd.)
also, since the fd assignment is done only by execexec, you'll notice
that
cd doesnt exist[2=]
still delivers errors to the console.
i don't know of an easy solution to this. maybe a few judicious hacks
could solve a large portion of the problem. byron's shell tended to
solve this problem by forking early.
i've included the rc machine that is generated by code similar
to yours.
- erik
broken! [9]/dev/cons /fd/9 echo
1 Xmark(1)
2 Xword(2) /dev/cons
4 Xglob(1)
5 Xrdwr(2) 9
7 Xmark(1)
8 Xword(2) /fd/9
10 Xglob(1)
11 Xwrite(2) 1
13 Xmark(1)
14 Xword(2) echo
16 Xsimple(1)
17 Xpopredir(1)
18 Xpopredir(1)
19 Xreturn(1)
Xrdwr /dev/cons - fd 5
Xwrite /fd/9 - -1
/fd/9: rc (8.out): can't open: '/fd/9' mounted directory forbids creation
popredir 5, 9
broken!
[9fans] rc bug
rc bug. please put non-9vx bugs in their own threads. thanks. it appears something is going wrong with rc's local assignments. ifs has the usual value. ; font=/lib/font/bit/cyberbit/mod*.font rio rio: can't access /lib/font/bit/cyberbit/mod*.font: bad character in file name: '/lib/font/bit/cyberbit/mod*.font' ; unicode 0001 ; echo /lib/font/bit/cyberbit/mod*.font /lib/font/bit/cyberbit/mod14.font ; x=/lib/font/bit/cyberbit/mod*.font ; whatis x x=/lib/font/bit/cyberbit/mod14.font % diff -c /n/sources/plan9/sys/src/cmd/rc/exec.c . /n/sources/plan9/sys/src/cmd/rc/exec.c:751,759 - ./exec.c:751,761 } deglob(runq-argv-words-word); runq-local = newvar(strdup(runq-argv-words-word), runq-local); - runq-local-val = copywords(runq-argv-next-words, (word *)0); - runq-local-changed = 1; poplist(); + globlist(); + runq-local-val = runq-argv-words; + runq-local-changed = 1; + runq-argv-words = 0; poplist(); } % russ
Re: [9fans] rc bug
rc bug. please put non-9vx bugs in their own threads. thanks. i thought it was. sorry. in any event, 9vx ps has the quirk that it thinks every command that hasn't set its args has 1 argument, argv[0] consisting of the entire argument list. unless my kernel is somehow out-of-date, this is 9vx specific. useless utf-8 here☺/useless utf-8 here - erik
Re: [9fans] rc bug
I saw something similar before, but unfortunately, the patch below
doesn't fix it.
cpu% fn 'file?' { test -f $* }
cpu% 'file?' /LICENSE
cpu% echo $status
cpu% 'file?' /foo
cpu% echo $status
test 145387: false
cpu% rc
cpu% 'file?' /LICENSE
rc: can't open /env/fn#file?: bad character in file name: '/env/fn#file?'
file?: '/bin/file?' file does not exist
cpu% 'file?' /LICENSE
file?: '/bin/file?' file does not exist
cpu% unicode
0001
cpu%
it appears something is going wrong
with rc's local assignments. ifs has the usual
value.
; font=/lib/font/bit/cyberbit/mod*.font rio
rio: can't access /lib/font/bit/cyberbit/mod*.font: bad character in file
name: '/lib/font/bit/cyberbit/mod*.font'
; unicode
0001
; echo /lib/font/bit/cyberbit/mod*.font
/lib/font/bit/cyberbit/mod14.font
; x=/lib/font/bit/cyberbit/mod*.font
; whatis x
x=/lib/font/bit/cyberbit/mod14.font
% diff -c /n/sources/plan9/sys/src/cmd/rc/exec.c .
/n/sources/plan9/sys/src/cmd/rc/exec.c:751,759 - ./exec.c:751,761
}
deglob(runq-argv-words-word);
runq-local = newvar(strdup(runq-argv-words-word), runq-local);
- runq-local-val = copywords(runq-argv-next-words, (word *)0);
- runq-local-changed = 1;
poplist();
+ globlist();
+ runq-local-val = runq-argv-words;
+ runq-local-changed = 1;
+ runq-argv-words = 0;
poplist();
}
%
Re: [9fans] rc bug
I saw something similar before, but unfortunately, the patch below doesn't fix it. I submitted a patch. diff ./io.c /n/sources/plan9/sys/src/cmd/rc/io.c 94c94 for(t = s;*t;t++) if(*t = 0 needsrcquote(*t)) break; --- for(t = s;*t;t++) if(!wordchr(*t)) break; diff ./plan9.c /n/sources/plan9/sys/src/cmd/rc/plan9.c 278c278 pfmt(fd, fn %q %s\n, v-name, v-fn[v-pc-1].s); --- pfmt(fd, fn %s %s\n, v-name, v-fn[v-pc-1].s);
Re: [9fans] rc bug
I submitted a patch.
diff ./io.c /n/sources/plan9/sys/src/cmd/rc/io.c
94c94
for(t = s;*t;t++) if(*t = 0 needsrcquote(*t)) break;
---
for(t = s;*t;t++) if(!wordchr(*t)) break;
diff ./plan9.c /n/sources/plan9/sys/src/cmd/rc/plan9.c
278c278
pfmt(fd, fn %q %s\n, v-name,
v-fn[v-pc-1].s);
---
pfmt(fd, fn %s %s\n, v-name,
v-fn[v-pc-1].s);
i don't think that fixes it. try this test on plan 9
fn 'test?' {echo}
lc /env
- erik
Re: [9fans] rc bug
i don't think that fixes it. try this test on plan 9
fn 'test?' {echo}
lc /env
it does, unless you build an 8.out and test it
without installing it as /386/bin/rc.
when you invoked lc, a shell script, that ran the buggy
/386/bin/rc, which polluted the environment.
in fact you have to run lc twice to cause the problem:
the first rc reads the fn out of the environment and
writes it back incorrectly, and the second one then
gets confused.
vx32% 8.out
broken! rfork e
broken! fn 'test?' {echo}
broken! cat /env/'fn#test?'
fn 'test?' {echo}
broken! /n/sources/plan9/386/bin/rc -c exit
broken! cat /env/'fn#test?'
fn test? {echo}
broken! /n/sources/plan9/386/bin/rc -c exit
rc: can't open /env/fn#test?: bad character in file name: '/env/fn#test?'
broken!
notice the lack of quotes around test? after buggy rc runs.
Re: [9fans] rc bug
- 9fans.
i don't think that fixes it. try this test on plan 9
fn 'test?' {echo}
lc /env
it does, unless you build an 8.out and test it
without installing it as /386/bin/rc.
when you invoked lc, a shell script, that ran the buggy
/386/bin/rc, which polluted the environment.
in fact you have to run lc twice to cause the problem:
the first rc reads the fn out of the environment and
writes it back incorrectly, and the second one then
gets confused.
pfft. i'm feeling so smart today!
doesn't a similar change need to be made in
win32.c and simple.c?
also, does Xfn need to call deglob() on each function
name?
- erik
