From rc-owner Tue May 26 18:25:29 1992 Received: by hawkwind.utcs.toronto.edu id <2716>; Tue, 26 May 1992 18:24:16 -04 00 From: Chris Siebenmann To: rc Subject: another test message Message-Id: <92May26.182416edt.2716@hawkwind.utcs.toronto.edu> Date: Tue, 26 May 1992 18:24:08 -0400 You guessed it! Boy, this mailing list stuff in Zmailer can be confusing some times. - cks From rc-owner Tue May 26 21:30:31 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2694>; Tue, 26 May 1992 21:28:52 -0400 Received: by archone.tamu.edu id <45322>; Tue, 26 May 1992 20:28:25 -0500 From: Byron Rakitzis To: rc@archone.tamu.edu Subject: a patch for /dev/fd users Message-Id: <92May26.202825cdt.45322@archone.tamu.edu> Date: Tue, 26 May 1992 21:28:17 -0400 Sorry, I made a typo in the /dev/fd code that I never got a chance to test. Here's a patch from cks: *** /tmp/,RCSt1a03978 Tue May 26 19:15:21 1992 --- glom.c Tue May 26 19:11:55 1992 *************** *** 343,349 **** } name = nprint("/dev/fd/%d", p[n->u[0].i != rFrom]); efd.fd = p[n->u[0].i != rFrom]; ! except(eFd, efd, &e); close(p[n->u[0].i == rFrom]); ret->w = name; ret->m = NULL; --- 343,349 ---- } name = nprint("/dev/fd/%d", p[n->u[0].i != rFrom]); efd.fd = p[n->u[0].i != rFrom]; ! except(eFd, efd, e); close(p[n->u[0].i == rFrom]); ret->w = name; ret->m = NULL; From rc-owner Tue May 26 21:43:22 1992 Received: from SPARCserve.cs.adfa.oz.au ([131.236.20.3]) by hawkwind.utcs.toron to.edu with SMTP id <2679>; Tue, 26 May 1992 21:42:15 -0400 Received: by SPARCserve.cs.adfa.oz.au (4.1/1.34) id AA01406; Wed, 27 May 92 10:37:06 EST Newsgroups: adfa.rc Path: cjsv_sun!cjsv From: Christopher.Vance@adfa.oz.au (Christopher JS Vance) To: Subject: Re: This is a test message Organization: Someone, Somewhere, Sometimes :-) Distribution: adfa Date: Tue, 26 May 1992 19:39:32 -0400 Message-Id: <1992May26.233932.1198@cjsv_sun.cs.adfa.oz.au> Keywords: test References: <92May26.174806edt.2702@hawkwind.utcs.toronto.edu> Sender: cjsv@SPARCserve.cs.adfa.oz.au (Christopher JS Vance) Lines: 9 Apparently-To: rc@hawkwind.utcs.toronto.edu Apparently-To: cjsv In article <92May26.174806edt.2702@hawkwind.utcs.toronto.edu> Chris Siebenmann writes: | Please ignore this; I want to make sure that the rc list is working on | it's new home before the old one goes away. Does a followup get sent to the right address? Does anybody want this gated into (say) alt.shell.rc? -- Christopher From rc-owner Tue May 26 22:02:59 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Tue, 26 May 1992 22:02:03 -0400 Received: by archone.tamu.edu id <45322>; Tue, 26 May 1992 21:01:42 -0500 From: Byron Rakitzis To: rc@archone.tamu.edu Subject: oh well Message-Id: <92May26.210142cdt.45322@archone.tamu.edu> Date: Tue, 26 May 1992 22:01:41 -0400 I applied the /dev/fd patch and updated the 1.4 archive in place. I hope the 20 or so people who fetched the broken code will not notice the difference! From rc-owner Wed May 27 07:36:16 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Wed, 27 May 1992 07:34:56 -0400 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by archone.t amu.edu with SMTP id <45322>; Wed, 27 May 1992 06:34:35 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.29.0890) id AA23309; Wed, 27 May 92 13:34:03 +0200 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA07059; Wed, 27 May 92 13:34:01 +0200 Date: Wed, 27 May 1992 07:34:01 -0400 From: malte@techfak.uni-bielefeld.de Message-Id: <9205271134.AA07059@dahlie.techfak.uni-bielefeld.de> To: rc@archone.tamu.edu Subject: patches to build rc 1.4 under Minix 1.6 Hello *, as promised, here is the stuff needed to port rc 1.4 to Minix. It includes two unrelated postings: 1) The cdiffs, ready to be fed into patch and since standard Minix lacks some essential tools as yacc and awk and sed isn't working properly, 2) the generated sources for sigmsgs.[ch] and y.tab.[ch] Work was done using gcc 2.1 ported by Rainer Orth (ro@techfak.uni-bielefeld.de) Additional instructions: In file nalloc.c, there is a define for MAXMEM. This sets the ratio between memory segments managed by malloc and nalloc. Since memory is limited, one should set MAXMEM to be ~available_memory/2. 40KB seems to be a reasonable value. If someone finds a clean way to do this dynamically, I'd love to see how. Editline works well and can be used without any changes. Readline will do too, so I'm told. A friend of mine did the port using another C compiler called c68. To do this you will have to add this rule to the Makefile: CPP= /lib/cpp .c.o: $(CPP) -D__minix__ $(CFLAGS) $< | unproto > temp.c &&\ c68 -c temp.c && mv temp.o $@ Also, NULL must be redefined to be ((char *)0) ! All the tools needed will soon be available via anonymous ftp from ftp.thp.uni-koeln.de, somewhere below pub/minix. If Byron allows me to do so, I will put the sources ready to unpack and make there too. Malte. --------------- uuencoded sources for sigmsgs.* and y.tab.* ------------- table !"#$%&'()*+,-./0123456789:;<=>? @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ begin 644 source.tar.Z M'YV0<]*<:3/GS!P78P H7,BPH<.'$"-*G$BQ(HB+-F# '@(@T8-V9PO#CCz MAHR-'2^J!!'C(XV+-63$@&'#Q@R--2[&B&&#AHR.,"H*'4JTJ-&'=>;0"2/Gy M(H V8=C0*7,4(IPT2L.8,5.UJ]>O8,.*'5MU1!HW8]C4(5,&A(B PL>1"-"x M@8(I @D:! '73=0Y6[J Z %BCX($>T2(8)$@@>(^+ XGAHNF#IS%CM&$<7/&w ML@C(DM\*/$L'\^/(B$6?B5,G36G&(EB[_HQZ\F@V;$RGP5WF3%009Y7*J3.&v M3IHW;FB'ADM'3IC+L)N'&=-6^F70J>&&$2/GM>/C=("[$4[<.'+EV076<9.Tu M#!G3<^ P;3OF#5OTML^8@5/&M!DV;X1A'&<@P/$&:2"4@0=U<)B7'';YK;%;t M;K!)R-M[$*J6E!PQF-9>4VR9<99[? GD%QL@C, 2?JK-T9L=\/761AEN+.4@s M"'8B= >&2"(D0<(:Y0A1Y(HTO&&q M>&2D,8::?"T%)@AFA%&'5&R.@08;[\'FZ&YT*O4&'""\T92"LSTI4'TUF@;Jp M@'7TYVF;E\+G)Z9+HNC&&^&9(<<;7-)!1QYLTJ$4=(Y9"@=_&/[(W("FB3'=o M&F?,NAZ=MMXI1QEA!+ORQR;ZQ+ C-@G"''*Z9&ED?.RA UKGHIJONn MNNRV"Y=><[4K;U4J98221R")E%)))XVTDDHMQ0"33#39A)-./,E U#S-AQ6m M4DLUQ1%44E$EUE59;>7PQAQW[/%"MP)[9*'#%5?888XR!8(*?LW(PLIZE=L'l M"'C%95"Y"I+I!LUYR57B&2<"UD6Y(X0X(@A.5-'$$T9,D<013@3!Q!0@R#"#k MN1]GK?767'?M]=?LYN'"4F(@!#;']6KD[T,<*O*#"14& ( 16R!7(5)$O0\46i MHK-R*9\<+KIPY\HOV%7TD4=GD84024SQA!,L720Y"$FP56,:9MQY^1R9:TL'h M''70X<)%*J2NP.I(EI% $$X0 3T1"?B-P_)&)YF $$$,L03WWE=?0P[8LZX]g M]TX<47U&Y3>?P!!!3%'$^C&T/^+[3U3A!!7KRV"_]D2H A36=S7FW:\(4YL?f MW6CP/^<5(7KKJT$#$V $)@2!?W2SP02-X(3UW6"#3Y#"^JYG0.TEP0CK(U\)e MG9>$#LK@!C"88 A#6+T;U&^%"8!"$J"@0)-,4 I%($(21/C" F;/>5, HA")d M> ,&XG *51!"#27XQ"A. 0D(9$(--?C$*R2!"D- 0@T_B$,J>)$(1&!"#TEXc MQ 1< 0E)4&,-5=C&*X20>C+ 00QQB(0JB#&/]5L>&XYV [>,KG2X4MU9TK*6b MMHA #F-P 5V6QSLWA @$@ZQ1 S%)FL;\,@E5(N97Y.!8$@XAw MO:C)KJ I.MVAIA5-65-4D*<\W%0.9) 9"%PW!2ID@8?EHJ09+#DRUS'!J#Q4v M $)#I("+K/2<4LD#?ZJJ$L/\2SSA,GH\(5,IO2K:>6Hu M4KY0'[6TP0WE@FN-,)E/MKHUK_]"T([F6E=s MNTE0*>6SQ+2+ZMKH.B.T4&J-B4$-G,C;+%0P".I+0 MF\$(;L-%\SG/=_K@Gr MOP3,X'J;=!T5I "]*5B0"D5 1Y2 (4H& ]?7%/"L1+7AX0!I @^ %GI3.>q M'4UE"W@0C Y 8),4V.68@NH2FL0QR,.(.SR &15[)#&@@XZK=(,DX)C&0IRSE*A>Yn MQU;6<9:C#&621!C#B)U!#;H9RX:V,J!AS%P^SV#0@E8SHB=-Z$07FM*1l MQO2A";WH2FOZS9N.<:E2DUK4ED[UIR]MZE"[&M2*5G6K83WG4;\:TK>6k M]*QQ3>LUV[K7J[;TKWE-;%_+^M2Y_O.Q78UD'3_Z7TS^UYA[O.=_/?E?)OX7j MD>/V98 U&V DCL&S 19M@$T[;M4&V+4!EFV ;5O#W?;PMSU,8JMU6&'W/K>&i M-4BN_]HHP+8-3R@U%9YSPD$.:!":@_< X2:#(-XD"7&Z5=)NG4!I+SK"XB7S6f MEGRX)5"G =5KL'+AOIPG4K?!O'E2]KIIW;DRCL'/U5WV&YS]!E0ONM9Q4'8/MK6&_3?[ED3>\ATNNX1FLd MW&J*[W/G4ZZP>2OL\S10/ TP3P,3G]5OIH^)XVL^>\:/3P']-N:_41EPOJ"!c MX)Q%N,()PW"5T,#H* \QQ%EBY)@_/./+AW@>E=]AV8=7 G'9-WPEb M'^GP\:F/6.]S7_PK!X%/J ]^[-.\WAQ_?IA)O'XEI__Y2DYZ_37\\HMTG^<@a M(&9-]C?L=W[@QW&K5X 4IX LP7$$V&,7%W,$^'TK,7'\!7$WP8#\E7,1%G+Qz MUWU2!G%B5WWN9WSI5P/85WXA*'Y)!P(Q9P,D9GXJ48(PT8(="'[ZUW_X1V[By M!X P6'T>MX,ZD7Y95W[])UP<>&_]]X/OQX 8EW_5]V0AMX0QN((6IG\^6(4,x M&'E-EG4TUW\OE'/:%X,8>'_2=X(@]X5)2($#$V+IQX0W9X5QF'%[AEAPV(9Lw M*',91X79QX"MUX<0*'X6*(/^%V( 2'9]F((,JH6<,2'MY.%Q1N(GZ]X$#*(HT!X":2',6*(1W0XHWYWR8"!.IV'W]=XHWu M%XOW)H&V:&&:!XOW!G&6:&$ZN'S]5P.YZ&W55X=Y*'JUR(#*R'(:F'03*(D.t MMWS0.(S%2!))IW9*Z(2NAX-;"("J^(0&:&Y;.(F(U1);*(78PX'0P0'4SH74[$7>0Z&UEAX[>!G4:YVU.o M1WA:MXC@]G7VUG66!VZ#UX_KB'5KUV@ XX5#"'6TR!)]UG77I74S0'7A1VYKn MMW\L00-E1P-61P.#EX#DUHTZ,8+F)G5[HW4R*%QEYXGF!G7$B)E.AW-=5Y(Lm M<8=L]W905Q,&Z6\\0I'C$1Z*-3F]AV MPV""P9$7(0(DL!@BH">S(@>\20(3l MTAM1X0*\.3W3PYO@\SW=LP2+H0 B@#Y'P)OP(S_4F3_[PYL!! 6\B4#6R0(Bk M\$!$P)O'107DZ03D&4*\>4+KB9[@.4-2\)PBH$,\Q)M*-$2\F41!A)_@"45"j MD)]6A$5,P 3YZ45@A 2\:49)@$9JQ)MO%$=%X*!WQ)M]A*"1(0(GD (GP)LGi MP 5g MQ5&\.2@NLJ-$2@9&*@*\LQ2[L:4]RIN70@>#\BRO(1IE]4J\J59*P9MS\%.1f M(@)VNJ6TDJ<7VE-\BJ\Z09L8*>""IYI2JB\61?]-@+#%%JZUYH"]IJ^e M!WSGQ"$;^6#G%V8D1W(Q-YCB)X(BZ''C!W[T-W,FB'XLV(."*'[]!YG&AX"Rd MVF24:7P?28*X2G,>=YE-V*MSJ(*)Z(C"BH?#JH>^2JQM"*S':JS%2HB(2',Ac M67W0R&3E=XB'.(B#.(S#Z(#<.I*CZ*TTUZWA"JXWYX 2>*X#B*XTIZZM6'WLb M"A,OZ(NOR%\>1YKT*H9BN)J1BDR32F #AY&7*@.96GPSZ'"@%H1!>+!HEK .a MQ[#_7"(_CZ!%;ZY@,: /!x M.'(U68]-1I<%BVYH:V'Q!X8Q]X>Z>K$?2V8S"9,RF70OJ9) 5Z_NB%@WX',Dw M=@,6"$/5!XX@*:VNBK;E%Z^LJH@'&(.'2W1)1Y84!X!Gt MF8E-Z6$6"+N9:(%ZN;DD,8N>NH742[[HNXHUF72>)[T>QG%LZV1 MXO5.[U;s M2(3L&)<:)K\ R(4AE[KO^W#Z^K2]]Z\%-[5'<@:P\@97JQ/6IV0G>6^5:(%Fr M>V\G:('XIK?Y%G>(V1)E)WD5Z(#2!X8("(!"V;B(1;%S,=XC,B5MV>$G,AW'(<@U\B9n MR+95G,:.K,>&W&'+I-+,I!?,DHm MG',D>S,N_W,AV2,N!?!&;O!)/W+R9B',GO(>(M>:8&_7(%\^ZGSVI(PT7\X8+\>-]S>"6=<^Y\')2]++)Y/&J]3;ZW$*#3!+J=F8K=A =]D^e M2;U)>9. ;=AG)](NV']>J]E8^92[&'5>N:M:^;MU_;Q>29AU/:\VB3"G?9A;d M#=9 -WC*NQ-)5]9V*'6UBA$Y:=OFMIE\FWYE?=8A1]8>9Q(Y%Y5.]\%#:(](c M.Z_=+9CJ*#=S>7;W^]W2S8;BMK5"*&[V6]EHG;5C_=ZY2X/BIKC!NZGH#:KDb MUICVC=Z,:=@MJ+9G!J][QMN!Q\W(>;LP33KWA".&%B+F.9F0F*VU=V-\5:&3FJ[[-=]_+>XX&z MK'ZD2G_I]]]N"]]8JVXT?N*<>[GS?<:Z%H!$N.*<*X !:;XQ;F34J]]%WGY!y MWKH>H>.K>HX<[H1G^XBLJ!.+_;KVR[1&EN0GFXSV36TP;F0RGGP^[KI?^\(Yx MKJK>V.-A^W1*:;EGJ[0''(%!#L1Y9N9WB^8:Z.1L#N4S_N/O6YA3;GQS/KRKw M:N<%R^?"=7%GQZN-_KY$WN=K2^;VI^)GON0N7B]K'F9MGHDFKHJ,SNG@-^([0N[T;3N,[P7'1u M"]_G^.4LD>K2Y^F9:.;0-HTF5^AKKF2G3A+23JONL/N3?CN*C-K]0>.V$WN3;GHE]31+KR^OJ%^[B]^BI^L*QKH#BQK% SN_?s M?8[O#F]HMIC4F."3;N\-CFVB&^P7-^S8'L49=^P:3H<6[\Q\KNY<^X@+[V'4r M3A+I?KX>P8RCCA'WGKZ(GGPAK^K^WNKC3N?2Z+8S;X_-GNDIFW'.Q[LWE^L'q MG(J_7O$(/Z\4+M-#?N$9A^P>[^RS'N0Q .V;+O*J>!(2+:E#+;6.TDYK@-0=p MV7G01[\!Z,%(^:E/Z7%,7KX&2_0BS]6ZGKN6R^P87\!>:8K%7=P#/(S>JX/0o M.Z^ WN\OWW&%'X861JH:#(9"7S7)_N';"*V@3FZ9._DWY]W KF2'.XBF2'^In M&']OJ/3,+H'9"-W=YXM'./HY%[[\%6YZ;MB'68G+)\-EGK]-!KPW6=W%S>RSm MB(&8/7C-6)I-UO,>UMN&G9-J+=Q$)]=:J?3:Q_%*YOM_[MI>^8H[\?OWYG%Rl M?Q%+K=E2Y]*IY'')C,RL/_Y.'-@D9OXLL975']N:+/YW.:_J+V[P__Z":75]k M*6YG%YCD;_]=9^5>Q_[UOP&XW03@^3. QJS\W27@M_\XCOH+?[#O^!6M!.APj M[D\+ D /$ 0\/W1. #O%_1i M3749&;:G A^@RGN -E '74 &!Y-"#(GK9MI/^SF]N 'U3N #K'K##PAF/PS&h MP5A@"#."]6^ZN<#Z=P)O(!7$=R>KQX CHR<"79 (A&+@9N.%P'.$ :^@3G" g M9A %5IXF>(765AF<@O*- E;!],?V&I\-?'+TCN;P0)?4!96@C6-><0/Z8;$#f M> *1(!1<6_RHWD"W%G@"$1__.FO]#['@P#1H!45@\%,_$,_E^;H^^ 6%H!@De M@ATO$A9"-"@"V=(:C$=.T,*\04G(C]J;D8$XD] 2)IU8:.I"W="K72&F_V1 d M)>@!PR (!(76"PZ60&&H81+AVEJ$3Y 0*D,YJ&%XX3(,0#6P#MI"F'#H)MY-c M(H8(8_@-01YT"$10P[Q!8-1D7F ZA(#]$!NUPWRW\G;=a MB[.&^K ==4) F)>&7Q%\AD>0%#9"8X@*0PXC?(:.,"+&P(@8"T5A)IJ%E% 'z M9L(-!!%YDO\KA)XP$(; A(@0V)[Q^.0T%6#FFB02R(E) .6CZ2R/94y M(HM35*A0(2#6#&IM4.A..\P8E%<3;>C!:B %C $w M]&(+N C*9"KP!5I!'VA%E=(3]L11O($\D2EV1GUH S.B1MB3S $&1H!;.0&.(" L*;Z@]VX79,@3SQu M2OS$SA >Q",\9).F8 8T!3P!'FY Q@R!2Y$'P,490 /A 04, ?)">&!7<]PVt MA ?P6(XWH$N&HQQ@)[:"GUB2C"(H# R=F )+ 3= !3=@%U0"%4 #6*% S(IDs M$0:X1'J4%=QD,)H!.G 'YL,.,"?:HDOLDRPE'-* &"@>;<$U:$P'RLC\\B1FH+2\(CD,-]p M+ .NH98TA5A".AA*L_&-*$! X,W2/]B10],?_.!7HQ%FHD+_'I+Q()2D@[\"$J!-MH3V8@44A8\@Dn M"#!02"!_4 $0 #VRP)T, E* N^R/+' ?W>2+G"5E();LC!<9(-]4&B 1.-(Ym MU(@[82//2A,H E(@C$ /*A $8 <3^")^TC?Z%BK@!(K %* :1B"$\$D0 4 l M)15( D.@"E@0*< JJX 4@ )/0'X<#YH1'QGE6;F0&3)). <4T2%39(@.Ak M+?3&IG @1G?i M(EQPBS]A+F5D?*R1-W(^G!4CL"/)0(\,CK@#+;B EV&V2VS)F>3%!)@ $# URTM\8 IC( 60%S[ ![@F=*&:K^5K0I+7XE_,PFAIe M)"" !Q!-U2),CB8(2)H"9W2@DI8)-;LF"F@"4X (Y,JLN36EYMDL+Z^%"MA*d M(? $L"8E>9NEA6( B$B"!E:+T2R1>!,$ $[!.05>AF],G(NS<;X6SHB0IF;5c M# )) NTS45"6MH"#Y"<7X)NIHB#$P8&0K@DFK@%(67.+X ZL0!G?%04,G-Nb MSESI.9L"Z)0"C#-G_D[0$CPG1SCA"WK3:>;.Y@D"GB>P;)K(XVD"S[LY.8AFa M]52:4U-Z1H[)L27M27HTE[M1P'R.-1D>TF/ M!4T JS\"6CA*'YCYMB-7.4.z MU))%"2-+@(L8C\CD"Z3/>;(CG,.-2(_/,SZT$][Q*,TD_VP+7Q(JR $L>1&2y M0'BHC_;D?4Z%G6$GN*-.^8[AD0V,QSIQ)UPC'!@DO8.OH'D.@"%C2!,"FF*0;0 &&%)1VRA"R)UFI-G&E*" &8-+Fs MH4D#)0U) !CM3P!2.; CQ$#]N!TBDC%.4E]**Q4$@P@/9.!/# K0("0A)!E15,PA=UP)_P)M"B1OE(E)!C7P%#\B;E,$G< !,R(q MS:!"R^@RE0(AY&4L2PLY!)KF67D":*$M'(%^BB.L9.:0 =XTG_ %R^!%:P2)p M()(!(7,TFRJJ'W<&!).>EJ6WH$XM DPC6#4-I,44E *1(? $K "F;"%' 60o MEZ@9 H;I,4D*N[1UO([F)$!0@)_($Q!3G:B%,D!>N( "B*:-(:@&59]Z$1#2n M(XVDDC245E*C @*T)F=Y)3NC!Q &72I4B6I72:0&QL'8U,5((U+ R\ J.E6Km MZM12D0*\26.PJBOAG.@4@9%4MTMW^2Z;Y:@:F+):57O,9<&54*"H-">S6E>_l M2C#E+,8"3%@&OCI4$4L?$*I]-4$<3<1:6%<"PQFF2/(MY($:$0;P0(((I)IBk MOPP*-_ \ ^L:&"67H:SV4GPJ!>[C8?6I^G,WM 58ZE] *7AAI@G@AIC24!HHj M2:I"$A\:1*DP%0KI.J" K2P"H%2-8('&@%44A$J=GJSEDO36WUHSFPIFF0)0i MX N4RB 21()K$1BN":"XX@$48 + :E1X&=T5G4S.MED&CJ9UQ:[:E;MZ5S9 h M7IDGB*)P_ N^N3VYY_<,#\L5B!!8A.0Z%!)#c M 7)H@v M8 BL@!5@-GEI%<6HB/2UG),O( ;JP[A$ 48 GS8!%D %G@ +(*GZ@PJD@ 3Pu M,UN#5#@+7V!&M($Q<'2;+@M(ND]@Z4+=_4%>%VM0S9PVUS?J7)[+-RN)S>2Zt M:B$^Q%U9"P*RZ;AM"P>2P#R+00)@VT)]+*=_(@R(QH\I'AZC?# .JW&0& =/s MNR!WAN!EH<7TE=0)JTL'!.[.F)-HP4' 41PQ3K7%FGU/I:+$)O\Q.X%*P*F]I8+q MKZ)-SP!6(!,%1F6H I)&'0O5WD6QC?T-H7>ZV!\[_/M#K>\IH&^ZRW" .#E)Z:W\!I&'I%XV2GC50EG\O'N!@(,<"OOn MF<2\9W3 -$;."RX\;X4-O01!>I;> W%Z4^_J)8[E)?>&CMF;5=?O&]BT>\7[m MVEX%0'RA;_:=OBV8^8(.6@%8;+#T3;X[)3P0!NM[$7PP\MV^W7='.I8L*7Y7l M:_D]OP_G]B(/]LMS"!,'RQYRB8,LHS>51 Y,WS.FX.2R; O6i M5)YZVA\5,NT)C>B[=*)E%E4M"TD-3 PPJRMVR;;8)CLP<:J)U(Y@14^#%e M#6\@GIZ3-T D_T-$WL3/@F@*1D;))>9O&="?>H*9*(^7"7*G1HXM M25QQ9Dd MS/)CL4HR7L;7=N.&8V@,(XGLC2"XUG@E9Y9LC)"CI8-QR?+X&K/D1-R3&S$Hc MQ:MZU7NHA$?*B.& ^?VJH-153JF4+P)3C@]/F;. b MY1;07G.+(V;%!%?=.AB8'&X/DAD N;X5B)SE!J93 (M!?JHZ%;#482XKB6WLa M93')TA4E[UBAO),W"U8)LEHXU@KEHI*(STE>IKD7H;^.4P(<0_U)*]T3ZCC*z M6A5R3&*C0JFPHJ&C0K91Y+!L-?.V%!XC0ME:X[G\5&F$6TY("ZDA/22+6U0Iy MY"/MLW7@#$AA1'%H:X090 &GQ3>]#!$ 'IG"@"@GV>1#B8"R^EXO@B"^PX44x ML+A4&T%((Y)TGJR0.#I+EE:L,I+J)C4J\SCG*HH2&2XS\:+\$^Q$FT8+\6D[w M)D<2J+3&X=(.6X);( Z$0R4=650EK)+0VQA!\2N)C&240I[CS4 G;#)#(;@]v M!LVRSP=90I="$PVQ[;$MO))8@B(4:C2&S@27/8OE^/"3D7$J80G7N2EW:$9,u M-'A'28:N@3DE;^>JW*&C)=%0S+>C0X82?E(]/S*RG0H $SW6S_?8,,6#<[;#t MA ($2,_;\9[Y"365HVE4AL;//) ?0V9X^*:Q%T8.Z.UHH#-'6CXKV;(MJ($Ds MRD[B)_$()4!T,!:(I( >"42XE,;>-"0G"$7I?Z=QLI6>6_8C2V,=D"55P,YUr MQY@"'@/IJ0!^^VUYP=,@P ?HZ4$, GCN<*F'5L=?TJ/I8HNV1DC4[Z\A:&5%\%4FN3"CD&F.2SV"LQ5"UC8ACY(F"[/#:[21.6_^"h M& [#C[:F*%ME[VVY;;*7O.+MCH!VUA789H-K(V&K_[G_AF!4R"OC5M5M3A\O;K8^;M\WFe MW=5;>A/KX,UZRTOR;L'&.R$WF_.M?-,W(V;>N=MY0^^F+#;-=M)&VX-9;?MDd MPG"]AS)/SMY$]D\#Z:T=O[]W>2G*XMNNDN_AS;YW2OI^VLA;>5=K^,U,Y#?Xc MKM8)_%H7$PWN9E]%W.[7%[G&>FX.#;;QM5I>U+ [(>?ILH66=C,YZES8-;@.-FW7P8]@,CI0._.3@'TN%@+N&&>H ;[F&[J!GW*66<4H *z M[-[(TG)[^)V=S0BL-@OQ,N!G=[,1)PU)G ZPA27N%HK ?5:A:)J*6W&Q?(>9y MLP8OC^?$LUH&.@U?B4#@_16SXM "Y%E!'0:Q"C6^BI);>^MV?:,+2O:$KQJ%x MPH9+%NMB*:QY]M,/NT:3B%M]BH,#4?R04A53HTT)4::Z!5_&W!X/,==(T&IJ_6& \u M12FD*X?51CHC@ZF$JF^3A(:^'0M69:1'(&E$->E2#95-89(RC1[C&\.E3B6\t MIUQ=X^T]\1N691O0T*.;.S<%J6K0.>EN-@P\/ O86=F<9V,(%Y_C=;R(]V8Ds M#ISUN'!V"Z$\4)AI>KY?+#=R5=N1]"]?US6>)6_'<'0#1#*L<-7SG(LI.HJPr MZ.7E3 9T#D%>]NE98 OFED 8-5QM+WEY1EW]#W^3-R",HFG2C)O@W4W(-:5LR&/M2NA]R0<++4N_:(7VD__ X'L1O,QW/S8S;,%1LWGS$;;,2+^PBP GD#'H.'.P)n M%2\O_G,Q8%6F )7I0&W"YF>]"S#GU0ZI)76%?.K>\F/6@=^0/L/EW]W$*[W8m MA1:7E#(Y[)931\CS4]:EOG)/=04B:33]K? G$6>B-&-5$.U\/K^G2^?A2I\HZ];&[U]4>V)$X?2?LPSD%.';.?=-5 AO_T3MCk M!>CIM:J7NWGJIS^&W.50#Z9*WM,E1)'O,_D60C+6U'*#Z:HDKC_ P8B5.^;0L]i M0.9Z%.(@,E,)-4^/PT'R"F,]P>-9)0!FI]HRR'/B^0B5I^BGM=$[WJXB#2P/h MG=]CF@BVT%G*W_/P0*0*NC\))6/*X5R$+1V Z8 K7:BG9!0W^2]C( %P>$@2g MON''?UE+O-%EKC7%Z Z>!T3A1MW7'3Q'[RT6))P?AA'OFXII"H^J1GZR$NL1f M/^2I T^_"![93S]2;S[H1;Q''::./DMF=$[?6WX+$]C-I[2?2EMT/CFF 'JZ-%>UPW*1K>G*>TE="?\_C -XMN/HQI4)/^6U' ?[3J[H%d MJ*Q3>OMO!_'"78N;Y?;,4K#"FF(6Y'JHPTE _NK+Y"@A5*/XGL#XYVT&!/=5c MSZIYEJWOYJ6.V;\SH:S3=UJ%M^B\[)>=BM*>X2IY9<1[%JVG-;6TQ]9N5@;3b M\S/;[97$HRVSFN(^:@7D6ZZY2>Q]\S:20H;B2&SNNS@DILYS@+Q,YT$Z!\SOa MB=_30'[" Y81#T^E<5*Y'8[<8I?S46M&;T2-IP^;?*_L^$].SDN\5&#D"+Y#z M4ZUKGLW+P#:7XYN^XG9ZE<#H0>IV./F3(^6'RTKO(';ED6_3>WX8;_=MN2BJy MPY^H]'XW2,+IXN@>B#R=_M%0M4,+B14?HG^#GF[*6R &M(#BVN'OX^TXMZ46x M0/=<SO&X;@NC>6?4V-#NPW,]-T?IJ)W0PVO@T*=]_4IW[?4=MFN46^)#w M"42.6/I5GX923;*[=K:>'%#@B(=8*AM@MSV!P/J:v M]N8R2HZB3>? J!7#20'0J@^\< :GHAP#<538T!N938M/^Aq M<6J<_X=8 (!A0 =8_GV ZH<(Z$0-%R6@04&#H8 JX)? 6I$7&& :IP'.@!S@p M '@#ED@V@ [8%O@P/>#[IXT5)_F?5D7_V7_XWS(!QU6 3$!\(4^M 2B &W#8o ML5#XU148 ]Q_^1]YL5^8@6C@,B%:;8 !H!)H_N$ 3F#K$P6>@(X9%:@%\F]Ln M8!;X.>197* 7V : @6Z $%"DL !]8/Z'"*IP6P ,T :R!6K@0@8'-(*/8!8Gm M ZX$-* -:/[-!'5@37 '_H!Y(!O@!X9\7]DDB 56@1Q=("A?T'^.X"@( JR!l MC& KB H2!JJ@)%C_G8&NX'XQ"(:!AB"8L@BB?:?@,O$+Q@>4X"A8OUV"*D$Fk M* ?B@')#)QB&I6P$A0_8 .I4KN#91PP&@Q0%$!B2K8!#X N8 2*#%X$RZ &6j M2.)&'6A#?(+3H![X.5B#IB NF/\=@9A@$C@.M@4M@3GX&643TN 4* JB@K8@i M-JC_P8$UX#)(#M8 YF!. VV?_E@*%@-?H%A8!!@R0$-PZ I* -4@A%A,9@&h MPH/)H#RX!-*#32! X439'>B@/K@0!)Xc MA08A/B@%MH1[($/H!I"%ST1=N%&DA4SA6N@"M(5O86"($_)L,-NNQPAB@78Ab M4RCTY85[(2KA5(4 ?Z$0J!JR!5!96.@&%H:'80QX.RB&C&$0. 9 AL&$4$49a M"H1M@4S@%3Z#FB$>*!3N@YWA2\@QN0B]X37H#N*$X*!.N!5NA%6# >@3NB ;z MP4&X (*"T^%":!U^@-EA.U@)9H7QX'=8 (: XZ$; Q8.A0Z&=?BEY 'MH44Hy M#"(-LM*IEQ.*@^"APE '"B7W(76X#GJ&0\!^V!_6A+;@30@)#H@[88GD-QR(x M+X%Y: *BA[[A@J@?'H+]X';(&T:([R&%*!]:ABEA?5A(:(@)87HH%H:!1<#1w M1!/. !3A;F@)+H=<81YQ($*'T>!FZ")VAB1A=T@@FG\W01TX$P@,+**/V"$2v MA82@$,"D-(6OH8@():)]$N*-J!4&A%SAD6$DFDP)HGI(""8!9@!-.!&.@G#Au M12@D5H@@H'B8_JT_]V"/*!TNB?DA(<@P,5(T80U0([Z&-"*9:"/"AQGAB5@Bt M>1Y;8H88'7*(^"%A\!+.B6?!C$@1.A-E(G>((X*'2\:6F!FZB82B@L@DAH%7s M 'KT2HB)=R*56"*>B7XB"$@0CH=\0Y+X)A:*GN$4 /ZA 75BIZ@=?HJ/(I'8r M$:Z),\&*."BF@Y9BG!@&7DQJ"JN8" J#>Z*)B"5"BBDBK9B5=(DOHAL0!/!(q MT=(+=@7FB8I@L @J#HM$8D]H+/*("*&2B"J^A$_ WH4=/HNNXB18)?*))F&Hp M>-(8B3,!LE@=$H(D!7_ *;H 44)!(166@:_AF!@OGH8" 7*D*.J)L2"L>"56o MAB721X N(HFWXF#8&9:"_N$?2 L&B((@N_@LF(;18K]H#+Z"(:*_&!]2BSC@n M\8$N(E2F8J6X$"*,5>(6R##*%R]AZ#CQY@LRG9WP%(!,0*+$J.9&"MFC*,BT6@#&(V7XF?8k M!FB-TN+7&##F $9BY$$V6H%=HQ8("(Z,GF$0( <8!%LC;[@G4HR_XL^H-CZ!j M,$#;:#.>A[BBE]@0WHUI5-]X,HJ+%F.?&#,^@3/CT2#>O(TZ8QCXTVUJ[V+$i MJ#)ZC?\BTKZ(.[J'<2'0Z#F.#[#CV-@Q!H_KHN6HA#6-K".:>(' CK8B\,@\f MEHU&@'W1'^J.UB-7J'; CBOA]G@^ZHJ%X+$0![ K\(8!3[NCIXC# ([8HO+e M(V?8/-:/8,+]F#\>7_MC^P@>V@1&XD<@.^Z,!63>N#@FC$ZCXP@U]@0-),%Hd M/@J09:,08#]*D GDW\A?A(TTHT\P.BJ._*/[."N6D(/CAL@]#I!.0%F!4IB&c ML:&[*!I^%&ZAIE4\/HW]8[%80OZ.5>,+20I2A7:*"W '4()"7X=R F0H#6,8b M& 78*>OC_5=$W@$K0+.Q.E*,+V'IJ$-*C%-D%&E$UA0N0!L0/IJ+SD4#J3T6a MC HAZ@A4.!@BP+(D J20"R3;2"JN'EVB&DDG$ 9B2G( 1YI_,$0#&3^BD>FAz M'DG<)&+A6=) _)%381DR3'"$A2@XVD6^"1I9(6x MI.<8DTR2+62+"$N6DIDD'BE'T9+EXN.H :V0DB,/6$D&DKSD&HE'^@' ),P(w M-=H=DZ3RN$A:DIBD,ND6A #-9.M8(@TND^09N4$BD]7D'>D6 '9I/B(=TR2v M?^0W"21^BH%J5$MI$s M8G0I-% ^VIGD1RM ^#:B105NV=F6HN5Oo M824< '_]?8]4V,?1I5]EG?X&EOD Y.36_C+M14C0@I7E;4 J.5Kn M65C<%2U::YE:TA72A&$A6YZ6@X5JZ43Q@1C<$Y,"T);!)6R9)/R63ID/D%S>m MEI!>: F6Z5+(95_!6]H5AX5IV5PR%D+8PW'I379E@.!7P\V6SJ5U2?D1EU59l M98E.T C&974Y5_P59AUY^5SVEK@E>AD?J)=057M97A(6]&5V:>!-ENE,%'#$#V94D]7S47i M3'%X'YIT0050%T6 8,!VX6D-G@"'IB%N&X%356-F=3M-4=$78E4;7L]WFUAAh M>-JZ!_)U:"J>DPE8>&2(18VIIX4(-R8U]Q?IF#PFBW<1D'QRVAV65(!ZV\%^g M0>T-6)G#LX1OJ5"AF B' GY4@I2;E_$A%D2:?*4T107ZG+/03LAM*M3KA8M9f M4R]#%P5\4%1_WB?75OX+\1Y?EEDZ5Y@2:?4%F%3(4ZX$7*EMD-X;QO.!?&)Fe M:4?-57C@W)))S0EZ2:;4)1ED=PB"6F:=97>Q2,#LI80E%:N=P+=Jd M\G=(DF5EG8$ EI6@!YQ-;;]9]3X/ME=W1A*[;A659Ac M7("0#5/5(^7;67WY!7O!<7(T,]EFN=GJ!5E6\\9JP$PMXb M;?8PPYU5T1QP77D "J 7#&=DEC5ETZ&:MIG )^C5 (Q;9;?:X5Y*F';V;S:6a MN69TQFL^>+_F[K9MUB;$IK%9O"6;RV9C<.X]F_A:]C=M,FZKG6HW< H'FYJ\z M61#(FK67T+<1R!>ZG8+ 'YQ1! (8 /W5=)E"4Z!R#G<;Y[LI('B%\%x MELG!W0[W5 @Q:6)*C)/\D!Q"5DJGAHCP 2>,)1N'9AI3:J:;Q6;N#*&8V=VI2;I[D)GFI!CH20)'9?'844u MUA4/=5NSB51I4DR#&6<8PH"OF1M'T@%Q:$47]]>I=*V=7?G\$0&/)U!1[&E[t MQUZRYP)0?QJ=LV?]07OZW;17PZUU2A4GQ=.U>)-#C%@BN4G45'-P@#T+AJ>Ls M%\T-=3V&XMD4H'GS4;$'(X5BTMSDB736F=59 !*>"6SU4ZU&VV&?WMX\\2P r M:/Y7>B1G%GT(!X'V2IR9#F @1;6,6FKF[="M!5*<')K6:7U:X%/@Y0;D ?@2q M@=!##6!'G6]D+G&?M=Z<12'I>OR7C><^S0J4H/!Vp MW@GUT5[!@.)4J-:_8"U!"E/>JF9#"6XP9LVWPUB9U!Z8>$^$22N?5 #C^1/3o MP3-5U]%SGM,:L"L] 4:4FU0B@9CWA M UHUZY,6(=W^><^_5, 5BEIVW Q%Jn M+NV?WYK 9VQ$^Y$B20@;5;/DV9@24A>"VC22=O1G5U<5LG1N6/ (>JYG35Em M'A]6&>:M#.87D%GOX5B;)0U7M;6AWM]9N7J2=FIEKU=:FJ"S6S/Q5\YK]L1+3?"\II!IE!WZ%G7"1ZXMRG=XHNH4O8j M=I;@M5619@@!BXZ:$)Z$]VG^91>>,.IL@@DK'ARG7?2B4D MZD\,4[CHQY=Ii M$J!]UXS9;.X,@AYI>1$X:A"8H??-T:*+GBWJFX"8CYZ#L?9)>G85I;=BXF'1Z8UZ(J-7A:^1=1PZB$6J5XJ94FEGB)=W\?7-9NOI^$7g M>SZ6PEZW!V>*H>99@/?O%1-<16)I6?9[]%Y7:>_A;S2<1&K#L99?PD.ZBJ)If M>II_26;> 28?[O%0II-5HUV0@/U:PP,<-OZI%!%#]34CP9OR)B'X/+( 663Je M* *H (O!ZJCL96KC545Q0!(80]A,>G2]A#=I3FHZBBEFP*'BDZI1/!-SQL8]d M#E1I56J57J7R@MA -D@26&FZD#; #6R#OI"^] LI04/=,!.\!"R!c MW# 3! Y=:;M .$@,3\'A8#&$!8J#5L 5Q*5\:5]*$4P5"D6EE3FH=BM%1+$Rb MO(,P:/*49A%')-@U5BBE%HD=X"3H$RM&!Va MI%!AD!$-;01R D%8#Q/$&:BB<1Q ;Q7:P/7$0;P4%X$" $$>%<3! G1 H!G;H0y M,(0,05K5$+*5:TJ?]!#^ PYQGS 11H1KJI\L$36$<.H^^"=3Q 3AGUP16<06x MH9X:*&'$&#%!*"@,RAHQ03PHJ#AJCJJCu )[J@\:H_JH_ZHt s end --------------- And the diffs: ----------------------------------- *** ../rc-1.4/Makefile Mon May 25 20:13:33 1992 --- Makefile Wed May 27 12:52:16 1992 *************** *** 15,28 **** # useful to more people. #ADDON=addon.o # Use an ANSI compiler (or at least one that groks prototypes and void *): ! CC=gcc -g -O CFLAGS= LDFLAGS= # You may substitute "bison -y" for yacc. (You want to choose the one that # makes a smaller y.tab.c.) ! YACC=yacc OBJS=$(ADDON) builtins.o except.o exec.o $(EXECVE) fn.o footobar.o getopt.o \ glob.o glom.o hash.o heredoc.o input.o lex.o list.o main.o match.o \ --- 15,32 ---- # useful to more people. #ADDON=addon.o + # define SIGNAL_H to point to signal.h + # SIGNAL_H = /usr/include/sys/signal.h + SIGNAL_H = /usr/include/signal.h + # Use an ANSI compiler (or at least one that groks prototypes and void *): ! CC=gcc -O2 -Wall CFLAGS= LDFLAGS= # You may substitute "bison -y" for yacc. (You want to choose the one that # makes a smaller y.tab.c.) ! YACC=bison -y OBJS=$(ADDON) builtins.o except.o exec.o $(EXECVE) fn.o footobar.o getopt.o \ glob.o glom.o hash.o heredoc.o input.o lex.o list.o main.o match.o \ *************** *** 38,44 **** $(CC) -o $@ $(OBJS) $(LDFLAGS) sigmsgs.c: mksignal ! sh mksignal /usr/include/sys/signal.h y.tab.c: parse.y $(YACC) -d parse.y --- 42,48 ---- $(CC) -o $@ $(OBJS) $(LDFLAGS) sigmsgs.c: mksignal ! sh mksignal $(SIGNAL_H) y.tab.c: parse.y $(YACC) -d parse.y *************** *** 50,56 **** ./rc -p < trip.rc clean: force ! rm -f *.o *.tab.* sigmsgs.* history: force cd history; make CC="$(CC)" $(HISTORYMAKEFLAGS) --- 54,60 ---- ./rc -p < trip.rc clean: force ! rm -f *.o *.tab.* rc #sigmsgs.* history: force cd history; make CC="$(CC)" $(HISTORYMAKEFLAGS) *************** *** 62,65 **** $(OBJS): config.h sigmsgs.h: sigmsgs.c lex.o y.tab.o: y.tab.c ! builtins.c fn.c status.c hash.c: sigmsgs.h --- 66,69 ---- $(OBJS): config.h sigmsgs.h: sigmsgs.c lex.o y.tab.o: y.tab.c ! builtins.o fn.o status.o hash.o: sigmsgs.h *** ../rc-1.4/builtins.c Tue May 26 06:42:58 1992 --- builtins.c Wed May 27 12:40:39 1992 *************** *** 21,27 **** extern int umask(int); static void b_break(char **), b_cd(char **), b_eval(char **), b_exit(char **) , ! b_newpgrp(char **), b_return(char **), b_shift(char **), b_umask(char * *), b_wait(char **), b_whatis(char **); #ifndef NOLIMITS --- 21,30 ---- extern int umask(int); static void b_break(char **), b_cd(char **), b_eval(char **), b_exit(char **) , ! #ifndef NOJOB ! b_newpgrp(char **), ! #endif ! b_return(char **), b_shift(char **), b_umask(char **), b_wait(char **), b_whatis(char **); #ifndef NOLIMITS *************** *** 47,53 **** --- 50,58 ---- #ifndef NOLIMITS { b_limit, "limit" }, #endif + #ifndef NOJOB { b_newpgrp, "newpgrp" }, + #endif { b_return, "return" }, { b_shift, "shift" }, { b_umask, "umask" }, *************** *** 385,390 **** --- 390,396 ---- /* put rc into a new pgrp. Used on the NeXT where the Terminal program is bro ken (sigh) */ + #ifndef NOJOB static void b_newpgrp(char **av) { if (av[1] != NULL) { arg_count("newpgrp"); *************** *** 395,400 **** --- 401,407 ---- ioctl(2, TIOCSPGRP, &rc_pid); #endif } + #endif /* NOJOB */ /* Berkeley limit support was cleaned up by Paul Haahr. */ *** ../rc-1.4/config.h-dist Mon May 25 20:12:57 1992 --- config.h-dist Wed May 27 12:42:25 1992 *************** *** 197,202 **** --- 197,216 ---- #define DEFAULTINTERP "/bin/sh" #endif + /* + * suggested settings for Minix ( >= 1.6.16 ), gcc 2.1, 32 bit ints + */ + + #ifdef __minix__ + #define DEFAULTINTERP "/bin/sh" + #undef DEFAULTPATH + #define DEFAULTPATH ".", "/bin", "/usr/bin" + #define PROTECT_ENV + #define NOLIMITS + #define NOJOB + #define SIZE_T unsigned long + #endif /* __minix__ */ + #endif /* CUSTOM */ #ifndef TMPDIR *** ../rc-1.4/nalloc.c Thu Feb 27 08:22:10 1992 --- nalloc.c Wed May 27 13:07:11 1992 *************** *** 62,68 **** --- 62,72 ---- worth of blocks for nalloc. */ + #ifdef __minix__ + #define MAXMEM 20000 + #else #define MAXMEM 500000 + #endif extern void nfree() { SIZE_T count; *** ../rc-1.4/which.c Mon Apr 27 02:19:31 1992 --- which.c Wed May 27 12:35:00 1992 *************** *** 10,16 **** --- 10,18 ---- #include #include + #ifndef __minix__ #include + #endif #include #include "rc.h" From rc-owner Wed May 27 09:58:27 1992 Received: from natalie.ibmpcug.co.uk ([192.68.174.66]) by hawkwind.utcs.toronto .edu with SMTP id <2714>; Wed, 27 May 1992 09:57:32 -0400 Received: from kate.ibmpcug.co.uk by natalie.ibmpcug.co.uk id aa00945; 27 May 92 14:57 BST X-Phone-Work: +44 81 863-1191 X-Fax-Work: +44 81 863-6095 X-Favourite-Colour: black, of course. Newsgroups: list.rc In-Reply-To: <1992May26.233932.1198@cjsv_sun.cs.adfa.oz.au> References: <92May26.174806edt.2702@hawkwind.utcs.toronto.edu> Organization: The IBM PC User Group, UK. X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: rc@hawkwind.utcs.toronto.edu Subject: Re: This is a test message Date: Wed, 27 May 1992 09:54:32 -0400 From: Matthew Farwell Sender: dylan@ibmpcug.co.uk Message-ID: <9205271454.aa20875@kate.ibmpcug.co.uk> In article <1992May26.233932.1198@cjsv_sun.cs.adfa.oz.au> you write: >In article <92May26.174806edt.2702@hawkwind.utcs.toronto.edu> Chris Siebenmann writes: >| Please ignore this; I want to make sure that the rc list is working on >| it's new home before the old one goes away. >Does anybody want this gated into (say) alt.shell.rc? If people want this to happen, then I'd be willing to do it. I already do one way gating into a local newsgroup, so all I would have to do is change the name of the newsgroup. The other way is a bit harder, but I'm sure I'll survive. Dylan. -- It is no coincidence that in no known language does the phrase 'As pretty as an Airport' appear -- Douglas Adams From rc-owner Wed May 27 10:06:24 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2712>; Wed, 27 May 1992 10:05:24 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA02795; Wed, 27 May 92 10:05:15 -0400 Received: by earth.osf.org (5.64/4.7) id AA03724; Wed, 27 May 92 10:05:14 -0400 Date: Wed, 27 May 1992 10:05:14 -0400 From: rsalz@osf.org Message-Id: <9205271405.AA03724@earth.osf.org> To: dylan@ibmpcug.co.uk, rc@hawkwind.utcs.toronto.edu Subject: Re: This is a test message Please do not gateway this to usenet. From rc-owner Wed May 27 10:07:08 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2724>; Wed, 27 May 1992 10:06:30 -0400 Received: from betty.cs.widener.edu ([147.31.254.25]) by archone.tamu.edu with SMTP id <45322>; Wed, 27 May 1992 09:05:18 -0500 Received: by betty.cs.widener.edu id AA10466 (5.65c/Widener-4.1 for rc@archone.tamu.edu); Wed, 27 May 1992 10:04:59 -0400 Date: Wed, 27 May 1992 10:04:59 -0400 From: Brendan Kehoe Message-Id: <199205271404.AA10466@betty.cs.widener.edu> To: Matthew Farwell Cc: rc@archone.tamu.edu Subject: Re: This is a test message Newsgroups: list.rc In-Reply-To: Matthew Farwell's message of Wed, 27 May 1992 09:54:32 -0400 <920 5271454.aa20875@kate.ibmpcug.co.uk> References: <1992May26.233932.1198@cjsv_sun.cs.adfa.oz.au> <9205271454.aa20875@kate.ibmpcug.co.uk> <92May26.174806edt.2702@hawkwind.utcs.toronto.edu> Reply-To: brendan@cs.widener.edu > >Does anybody want this gated into (say) alt.shell.rc? > > If people want this to happen, then I'd be willing to do it. I already > do one way gating into a local newsgroup, so all I would have to do is > change the name of the newsgroup. The other way is a bit harder, but > I'm sure I'll survive. I'd suggest that since there isn't enough traffic on the list itself, and comp.unix.shell hasn't been overflowing, that it wouldn't really be necessary. My 2c. :) -- Brendan Kehoe, Sun Network Manager brendan@cs.widener.edu Widener University Chester, PA In action-oriented shows, TV cops fire their guns in almost every episode; in Chicago, the average police officer fires a gun once every 27 years. From rc-owner Wed May 27 17:27:16 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2714>; Wed, 27 May 1992 17:25:33 -0400 Received: from stolaf.edu ([130.71.128.8]) by archone.tamu.edu with SMTP id <45 322>; Wed, 27 May 1992 16:25:04 -0500 Received: from mari.acc.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA13711; Wed, 27 May 92 16:19:53 CDT Date: Wed, 27 May 1992 17:19:53 -0400 From: quanstro@stolaf.edu (Erik Quanstrom) Message-Id: <9205272119.AA13711@stolaf.edu> To: Subject: bug reports for goosh Apparently-To: OH, I forgot to mention this but please feel free to send your bug reports patches, successes, faulures, random mutterings, religious convictions, missing-features lists, etc. to me (quanstro@stolaf.edu). I will be here all summer and glad to here your feedback. I am working on cleaning up the deparsing (which does not currently work properly, especially when lists are involved). This should be fixed in about a day or so. I put new versions of goosh up for ftp whenever a sufficiently bad bug is fixed, but I will post (or something) if some major progress is made. From rc-owner Thu May 28 12:19:08 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2694>; Thu, 28 May 1992 12:11:16 -0400 Received: from stolaf.edu ([130.71.128.8]) by archone.tamu.edu with SMTP id <45 322>; Thu, 28 May 1992 11:10:55 -0500 Received: from mari.acc.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA29694; Thu, 28 May 92 11:06:50 CDT Date: Thu, 28 May 1992 12:06:50 -0400 From: quanstro@stolaf.edu (Erik Quanstrom) Message-Id: <9205281606.AA29694@stolaf.edu> To: Subject: possible bug in dopipe() [walk.c] Apparently-To: It dopipe, 1 is used as a sentinal to mark fd_pref and fd_out as unused. Is it entirely clear that fd 1 will never be used? I would think that -1 (_never_ a legal value for a fd) would be a better choice for the sentinal, or? 298c298 < fd_prev = fd_out = 1; --- > fd_prev = fd_out = -1; 310c310 < if (fd_prev != 1) --- > if (fd_prev != -1) 316c316 < if (fd_prev != 1) --- > if (fd_prev != -1) From rc-owner Thu May 28 12:33:47 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Thu, 28 May 1992 12:31:49 -0400 Received: by archone.tamu.edu id <45322>; Thu, 28 May 1992 11:31:38 -0500 From: Byron Rakitzis To: rc@archone.tamu.edu Subject: dopipe bug Message-Id: <92May28.113138cdt.45322@archone.tamu.edu> Date: Thu, 28 May 1992 12:31:24 -0400 clearly the wrong answer is to use -1 as a value for fd_out, since this is supposed to be "1" at the end of a pipe. also it's probably a bad idea to debate rc implementation details on this list since 90% of the people don't give a damn. (The solution will probably involve setting up explicit flags for end-of-pipe, and so on, but I'm not going to work on that right now.) From rc-owner Tue Jun 2 22:35:15 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2712>; Tue, 2 Jun 1992 22:11:51 -0400 Received: from Princeton.EDU ([128.112.128.1]) by archone.tamu.edu with SMTP id <45323>; Tue, 2 Jun 1992 21:11:17 -0500 Received: from fs.Princeton.EDU by Princeton.EDU (5.65b/2.90/princeton) id AA22835; Tue, 2 Jun 92 22:11:06 -0400 Received: from cs.Princeton.EDU (atomic.Princeton.EDU) by fs.Princeton.EDU (4.0 /1.105) id AA00526; Tue, 2 Jun 92 22:11:04 EDT Received: by cs.Princeton.EDU (5.57/1.105) id AA26783; Tue, 2 Jun 92 22:11:03 -0400 Date: Tue, 2 Jun 1992 22:11:03 -0400 From: Emin Gun Sirer Message-Id: <9206030211.AA26783@cs.Princeton.EDU> To: rc@archone.tamu.edu Subject: Where is the list ?? I cannot find the new mailing address for rc. Could someone please enlighten me ? I had a question about assignment to $* during function execution that was bugging me. In particular: fn a { $1 = x; echo $*} doesn't work, though I don't see any reason why $* cannot be assigned to just like all the other variables. Hope this doesn't bounce. Gun. From rc-owner Wed Jun 3 00:09:06 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2746>; Tue, 2 Jun 1992 23:48:41 -0400 Received: from Princeton.EDU ([128.112.128.1]) by archone.tamu.edu with SMTP id <45323>; Tue, 2 Jun 1992 22:48:11 -0500 Received: from fs.Princeton.EDU by Princeton.EDU (5.65b/2.90/princeton) id AA07139; Tue, 2 Jun 92 23:47:57 -0400 Received: from cs.Princeton.EDU (dynamic.Princeton.EDU) by fs.Princeton.EDU (4. 0/1.105) id AA00713; Tue, 2 Jun 92 23:47:56 EDT Received: by cs.Princeton.EDU (5.57/1.105) id AA19810; Tue, 2 Jun 92 23:47:55 -0400 Date: Tue, 2 Jun 1992 23:47:55 -0400 From: Emin Gun Sirer Message-Id: <9206030347.AA19810@cs.Princeton.EDU> To: rc@archone.tamu.edu Subject: variable substitution and pattern matching OK, any ideas why this should require an eval : ;touch asdf asdg asdh ;a=asd ;echo $a* ;echo asd* asdf asdg asdh What I'm trying to do is to glob something with a prefix given in a variable. I know I can get around this with an eval, but shouldn't this be possible in one pass ? Gun. From rc-owner Wed Jun 3 01:05:53 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2724>; Wed, 3 Jun 1992 00:45:31 -0400 Received: from munnari.oz.au ([128.250.1.21]) by archone.tamu.edu with SMTP id <45323>; Tue, 2 Jun 1992 23:44:50 -0500 Received: from softway.sw.oz (via basser) by munnari.oz.au with SunIII (5.64+1. 3.1+0.50) id AA13733; Wed, 3 Jun 1992 14:43:20 +1000 (from jeremy@softway.sw.oz.a u) From: jeremy@softway.sw.oz.au (Jeremy Fitzhardinge) Received: by softway.sw.oz.au id AA09224; Wed, 3 Jun 92 14:43:50 est (4.12) (from jeremy@softway.sw.oz.au for rc%archone.tamu.edu@munnari.cs.mu.oz. au) Message-Id: <9206030443.AA09224@softway.sw.oz.au> Subject: Re: variable substitution and pattern matching To: egs@Princeton.EDU (Emin Gun Sirer) Date: Wed, 3 Jun 1992 15:43:47 -0400 Cc: rc@archone.tamu.edu In-Reply-To: <9206030347.AA19810@cs.Princeton.EDU>; from "Emin Gun Sirer" at Ju n 2, 92 11:47 pm Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@ G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k} yqshddFb l[EC}c=;uc%x'}uh3E91p&oE OK, any ideas why this should require an eval : > ;touch asdf asdg asdh > ;a=asd > ;echo $a* > > ;echo asd* > asdf asdg asdh ; echo $a^* asdf asdg asdh ; -- jeremy@softway.sw.oz.au ph:+61 2 698 2322-x122 fax:+61 2 699 9174 From rc-owner Wed Jun 3 14:45:21 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2712>; Wed, 3 Jun 1992 14:41:35 -0400 Received: from relay1.UU.NET ([137.39.1.5]) by archone.tamu.edu with SMTP id <4 5323>; Wed, 3 Jun 1992 13:40:36 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA01836; Wed, 3 Jun 92 14:40:13 -0400 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 143936.7272; Wed, 3 Jun 1992 14:39:36 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa15430; Wed, 3 Jun 92 13:30:21 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@archone.tamu.edu Subject: Minor patch fix... Date: Wed, 3 Jun 1992 13:30:17 -0400 Message-Id: <9206031330.aa01598@ceres.srg.af.mil> There was a minor error in applying the patch I sent to Byron for SIGINT handling with readline under SCO Unix. Here is the correction needed so that it actually does something. *** input.c.old Mon May 25 15:31:28 1992 --- input.c Wed Jun 3 13:12:15 1992 *************** *** 117,123 **** while (1) { #ifdef READLINE if (interactive && istack->fd == 0) { ! rlinebuf = readline(prompt); if (rlinebuf == NULL) { chars_in = 0; } else { --- 117,123 ---- while (1) { #ifdef READLINE if (interactive && istack->fd == 0) { ! rlinebuf = rc_readline(prompt); if (rlinebuf == NULL) { chars_in = 0; } else { From rc-owner Wed Jun 3 17:36:42 1992 Received: from stolaf.edu ([130.71.128.8]) by hawkwind.utcs.toronto.edu with SM TP id <2706>; Wed, 3 Jun 1992 17:35:41 -0400 Received: from mari.acc.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA26086; Wed, 3 Jun 92 16:35:26 CDT Date: Wed, 3 Jun 1992 17:35:26 -0400 From: quanstro@stolaf.edu (Erik Quanstrom) Message-Id: <9206032135.AA26086@stolaf.edu> Received: by mari.acc.stolaf.edu (4.1/SMI-4.1) id AA00369; Wed, 3 Jun 92 16:35:24 CDT To: rc@hawkwind.utcs.toronto.edu Subject: glomming and variable woerdness When rc scans the line echo $a* the star is part of the variable name, so 'a*' is looked up and printed out, for example ; 'a*' = fu ; echo $a* ; fu However, when rc scans the line echo $a ^ * it finds (well, sometimes) a to be the empty string, concatinates that with * and then globs that string. This string is just '*' so printing out all the files in the directory is what rc should do. From rc-owner Wed Jun 3 19:19:33 1992 Received: from stolaf.edu ([130.71.128.8]) by hawkwind.utcs.toronto.edu with SM TP id <2725>; Wed, 3 Jun 1992 19:18:46 -0400 Received: from asgaard.acc.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA27591; Wed, 3 Jun 92 18:17:53 CDT Date: Wed, 3 Jun 1992 19:17:53 -0400 From: quanstro@stolaf.edu (Erik Quanstrom) Message-Id: <9206032317.AA27591@stolaf.edu> To: Subject: $pid Apparently-To: Rc does not update $pid when it forks, only when it is initalized. Consider ; @{echo $pid} 296 ; echo `{echo $pid} 296 ; echo $pid 296 If this is not a bug, then it is certianlly a poor feature. [but, then again sh is guilty of the same.] From rc-owner Wed Jun 3 19:50:32 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2735>; Wed, 3 Jun 1992 19:49:43 -0400 To: rc Subject: Re: $pid In-reply-to: quanstro's message of Wed, 03 Jun 92 19:17:53 -0400. <9206032317.AA27591@stolaf.edu> Date: Wed, 3 Jun 1992 19:49:27 -0400 From: Chris Siebenmann Message-Id: <92Jun3.194943edt.2735@hawkwind.utcs.toronto.edu> Easily fixed, I think; apply the following patch to wait.c. Corrections by those more widely read in rc internals than me gladly welcome. - cks *** /tmp/,RCSt1a17852 Wed Jun 3 19:48:00 1992 --- wait.c Wed Jun 3 19:46:06 1992 *************** *** 44,49 **** --- 44,50 ---- /* NOTREACHED */ case 0: forked = TRUE; + varassign("pid", word(nprint("%d", getpid()), NULL), FALSE); SIGCHK; return 0; default: From rc-owner Thu Jun 4 06:09:57 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2670>; Thu, 4 Jun 1992 06:05:50 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA06735; Thu, 4 Jun 92 12:05:08 +0200 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA01785; Thu, 4 Jun 92 12:05:06 +0200 Date: Thu, 4 Jun 1992 06:05:06 -0400 From: malte@techfak.uni-bielefeld.de Message-Id: <9206041005.AA01785@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: $pid In-Reply-To: Mail from 'Chris Siebenmann ' dated: Thu, 4 Jun 1992 05:07:34 -0400 I don't think echo `{ echo $pid } should be different from echo $pid because I don't really want know that backquote substitution requieres a fork(2). Of course, shell functions and explicit subshell commands "@{ .. }" should. Malte. From rc-owner Thu Jun 4 08:18:15 1992 Received: from stolaf.edu ([130.71.128.8]) by hawkwind.utcs.toronto.edu with SM TP id <2706>; Thu, 4 Jun 1992 08:14:39 -0400 Received: from mari.acc.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA04151; Thu, 4 Jun 92 07:14:19 CDT Date: Thu, 4 Jun 1992 08:14:19 -0400 From: quanstro@stolaf.edu (Erik Quanstrom) Message-Id: <9206041214.AA04151@stolaf.edu> Received: by mari.acc.stolaf.edu (4.1/SMI-4.1) id AA03329; Thu, 4 Jun 92 07:14:18 CDT To: rc@hawkwind.utcs.toronto.edu Subject: re: $pid Malte (9206041005.AA01785@dahlie.techfak.uni-bielefeld.de> writes >I don't think echo `{ echo $pid } should be different from echo $pid because >I don't really want know that backquote substitution requieres a fork(2). >Of course, shell functions and explicit subshell commands "@{ .. }" should. $Pid should always mean the _current_ pid (as per the td's paper and rc's man page), whatever the implementation demands that that me. If this is not the case, then a script like @{ kill -9 $pid } will _not_ behave like a seperate shell, the whole idea behind @ ... in the first place. This is bad. As to the case of backquoting it seems to me a little less clear that changing the pid is the right thing to do. But I still have several reasons for wanting $pid to change. First inconsistency is not a nice thing. Second, it eliminates the difference between the percieved [sic?] behavior of echo `{exit} (1) which does _not_ kill the shell and echo `{kill -9 $pid} (2) which does. Such quirks are really not nice to have around: they cause confusion and cause too much dependence on implementation. Consider an implementation which did not fork (perhaps in the Plan 9 environment). Perhaps $parent should be introduced, being the pid of the rc which is forking off this, that and the other thing. But to be honest, I am not yet clear how to resolve all the complecations of this. From rc-owner Thu Jun 4 12:58:48 1992 Received: from inet-gw-1.pa.dec.com ([16.1.0.22]) by hawkwind.utcs.toronto.edu with SMTP id <2670>; Thu, 4 Jun 1992 12:56:56 -0400 Received: by inet-gw-1.pa.dec.com; id AA16385; Thu, 4 Jun 92 09:56:44 -0700 Received: by mail-relay-1.mv.us.adobe.com; id AA02529; Thu, 4 Jun 92 09:53:31 - 0700 Received: from utopia.adobe.com by adobe.com (4.1/SMI-4.1)id AA23310; Thu, 4 Ju n 92 09:56:35 PDT Received: by utopia.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)id AA2697 3; Thu, 4 Jun 92 09:57:16 PDT Date: Thu, 4 Jun 1992 12:57:16 -0400 From: haahr@adobe.com Message-Id: <9206041657.AA26973@utopia.adobe.com> Received: by NeXT Mailer (1.63) To: rc mailing list Subject: Re: $pid > $Pid should always mean the _current_ pid (as per the td's paper and > rc's man page) as per what? quoting from the v10 manual page:* ``$pid set during initialization to rc's process id.'' quoting from Tom Duff's UKUUG paper, section 26, paragraph 3: ``... $pid, initialized by rc to its process-id...'' in my opinion, rc's current implementation (which matches the above description ) is the more useful version. remember, folks, what the most common use of $pid is: naming of temporary files to avoid collisions. now, if i want to keep referrin g to /tmp/foo.$pid, i should be able to w/o doing tmp=/tmp/foo.$pid and being careful to watch for $pid changing. two other reasons i can think of for keeping pid the same: (1) the bourne shell did it this way and nobody complained (2) the other interpretation can be acheived with a c program getppid: #include extern int getppid(void); int main(void) { printf("%d\n", getppid()); } but nobody's felt the need yet to do this. ---- * this is actually from a version of the v10 manual page that may have preceded the printed manuals. i don't have that version handy. From rc-owner Thu Jun 4 13:01:46 1992 Received: from inet-gw-1.pa.dec.com ([16.1.0.22]) by hawkwind.utcs.toronto.edu with SMTP id <2706>; Thu, 4 Jun 1992 13:01:07 -0400 Received: by inet-gw-1.pa.dec.com; id AA16619; Thu, 4 Jun 92 10:00:58 -0700 Received: by mail-relay-1.mv.us.adobe.com; id AA02545; Thu, 4 Jun 92 09:57:50 - 0700 Received: from utopia.adobe.com by adobe.com (4.1/SMI-4.1)id AA23475; Thu, 4 Ju n 92 10:00:55 PDT Received: by utopia.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)id AA2699 2; Thu, 4 Jun 92 10:01:34 PDT Date: Thu, 4 Jun 1992 13:01:34 -0400 From: haahr@adobe.com Message-Id: <9206041701.AA26992@utopia.adobe.com> Received: by NeXT Mailer (1.63) To: rc mailing list Subject: Re: $pid what i forgot to say in my previous note is that the rc.1 that ships with Byron's rc should be updated to be more precise about what $pid means. From rc-owner Thu Jun 4 20:10:50 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2732>; Thu, 4 Jun 1992 20:08:06 -0400 Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <45323>; Thu, 4 Jun 1992 19:07:48 -0500 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2732>; Thu, 4 Jun 1992 20:07:35 -0400 To: rc@archone.tamu.edu Subject: Re: Where is the list ?? In-reply-to: egs's message of Tue, 02 Jun 92 22:11:03 -0400. <9206030211.AA26783@cs.Princeton.EDU> Date: Thu, 4 Jun 1992 20:07:30 -0400 From: Chris Siebenmann Message-Id: <92Jun4.200735edt.2732@hawkwind.utcs.toronto.edu> $1 is unassignable-to because it's a fake variable; it's really $*(1), and you can't assign to sepperate array elements. It might be an error for rc to not complain. You can assign to $* wholesale, either replacing or augmenting it; I've done this on occasion. - cks From rc-owner Thu Jun 4 21:22:16 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by hawkwind.utcs.toro nto.edu with SMTP id <2647>; Thu, 4 Jun 1992 21:21:17 -0400 Received: by doolittle.vetsci.su.oz.au id <49220>; Fri, 5 Jun 1992 11:20:57 +10 00 From: John (_You_ hide, they seek.) Mackin Date: Thu, 4 Jun 1992 21:16:09 -0400 To: The rc Mailing List Subject: Re: $pid In-Reply-To: <9206032317.AA27591@stolaf.edu> Message-ID: <199206051116.24478.rc.balag@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ This is not a bug. Byron thought about this carefully. Do you really want whatis pid and whatis pid >file to give different pids? That would be one awful consequence of having $pid behave in the way some have been suggesting recently. Now I agree that this is confusing at first, and I will stand 100% behind any proposal to change rc.1 to explain this more fully. But please, _don't_ change the code. I append the mail Byron sent me when I asked him about this. OK, John. From: Byron Rakitzis Date: Thu, 23 Jan 1992 13:54:56 +1100 To: john@vetsci.su.oz.au Subject: Re: rc file descriptor bug Received: from archone.tamu.edu ([128.194.53.42]) by doolittle.vetsci.su.oz.au with SMTP id <49478>; Thu, 23 Jan 1992 14:28:45 +1100 Received: by archone.tamu.edu id <18895>; Wed, 22 Jan 1992 20:55:01 -0600 Message-Id: <92Jan22.205501cst.18895@archone.tamu.edu> $pid is not EXPORTED. Note that this is much different from saying that a subshell of rc has $pid wiped out of its hash table. $pid obeys the following property: ~ $pid `{echo $pid} is true. Do you think it should be otherwise? How about another variable, like $ifs. Do you think that ~ $ifs `{echo $ifs} should be different? (assuming for the moment that the ~ command I wrote is just a convenient way to test the two values) I guess the easiest way to think of this is to notice that $pid never makes its way into the envp argument of an execve. Other than that, it is kept around in rc's data structures. From rc-owner Fri Jun 5 14:00:50 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2721>; Fri, 5 Jun 1992 13:59:01 -0400 Received: from nic.rtc.atk.com ([138.64.20.107]) by archone.tamu.edu with SMTP id <45323>; Fri, 5 Jun 1992 12:58:51 -0500 Received: from finlayson.CRL ([138.64.16.49]) by nic.rtc.atk.com with SMTP id < 46211>; Fri, 5 Jun 1992 12:58:27 -0500 From: To: rc@archone.tamu.edu Subject: sfischer Message-Id: <92Jun5.125827cdt.46211@nic.rtc.atk.com> Date: Fri, 5 Jun 1992 13:58:14 -0400 Please remove Scott Fischer (sfischer@rtc.atk.com) from your mailing lists. He is no longer an employee of Alliant Techsystems. Thanks, ____________________________________________________________________________ | | ________ | | Randy S Johnston | Alliant Techsystems, Inc. | | | | Senior Research Scientist | Research and Technology | | | | johnston@rtc.atk.com | Mail Stop MN11-1610 | ALLIANT|TECHSYSTEMS| | Voice: (612) 931-6084 | 600 2nd St., NE | | | | Fax: (612) 931-6165 | Hopkins, MN 55343 |________| | |___________________________|________________________________________________| From rc-owner Mon Jun 8 16:49:38 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2690>; Mon, 8 Jun 1992 16:42:49 -0400 Received: from postman.osf.org ([130.105.1.152]) by archone.tamu.edu with SMTP id <45323>; Mon, 8 Jun 1992 15:42:26 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA20629; Mon, 8 Jun 92 16:42:08 -0400 Received: by earth.osf.org (5.64/4.7) id AA07590; Mon, 8 Jun 92 16:42:07 -0400 Date: Mon, 8 Jun 1992 16:42:07 -0400 From: rsalz@osf.org Message-Id: <9206082042.AA07590@earth.osf.org> To: rc@archone.tamu.edu Subject: The "sm" program Hey, small and beautiful fans... I just started using John F. Haugh's "sm" program. It seems like just the thing for when you have to dialin. (IT was the only reason I used tcsh; I, sigh, needed job control via the modem.) It was posted to alt.sources a couple of days ago. /r$ From rc-owner Tue Jun 9 15:48:04 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2721>; Tue, 9 Jun 1992 15:35:36 -0400 Received: by groucho.cs.psu.edu id <2538>; Tue, 9 Jun 1992 15:34:59 -0400 From: Scott Schwartz To: rc@hawkwind.utcs.toronto.edu Subject: prompt function Message-Id: <92Jun9.153459edt.2538@groucho.cs.psu.edu> Date: Tue, 9 Jun 1992 15:34:45 -0400 My prompt function looks like this: fn prompt { s=$status {switch($s){case [^'~'^0]*;echo '# status' $s;return $s}} } Previously, I didn't return the old status, which was wrong because it gratuitously destroyed information, just what $status is there to avoid. On the other hand, now each time I hit return after a command that exits with nonzero status, I get a reminder, which is overly noisy. This makes me suspect that 'fn prompt' is not the proper answer to 'set notify'. (And speaking of that, I think it would be sensible for rc to keep track of the statuses of background jobs in $astatus.) (I should also echo to stderr, too, don't you think?) From rc-owner Wed Jun 10 17:20:35 1992 Received: from vlsi.cs.caltech.edu ([131.215.131.129]) by hawkwind.utcs.toronto .edu with SMTP id <2712>; Wed, 10 Jun 1992 17:17:51 -0400 Received: from vulcan.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1) id AA10531; Wed, 10 Jun 92 14:17:47 PDT From: waqar@vlsi.cs.caltech.edu (Waqar A. Malik) Message-Id: <9206102117.AA10531@vlsi.cs.caltech.edu> Subject: error building rc-1.4 on hp9000s300 To: rc@hawkwind.utcs.toronto.edu Date: Wed, 10 Jun 1992 17:17:44 -0400 Reply-To: waqar@vlsi.cs.caltech.edu X-Mailer: ELM [version 2.3 PL11] Hi, Has anybody been able to compile `rc' on hp9000s300 running HP-UX 8.00. It compiles fine but when I `make trip' it says trip took a wrong trun... any help will be appricated. If you need more info on config.h let me know I can mail it to you. Thanks in advance -- Waqar Malik waqar@vlsi.cs.caltech.edu ``The brain is a wonderful organ: it starts working the moment you get up in the morning, and does not stop until you get to school.'' From rc-owner Thu Jun 11 23:56:59 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2718>; Thu, 11 Jun 1992 23:53:46 -0400 Received: by groucho.cs.psu.edu id <2538>; Thu, 11 Jun 1992 23:53:17 -0400 From: Scott Schwartz To: rc@hawkwind.utcs.toronto.edu Subject: pipes Message-Id: <92Jun11.235317edt.2538@groucho.cs.psu.edu> Date: Thu, 11 Jun 1992 23:53:11 -0400 So is this useful? ; cat | ls file1 file2 file3 How about this? ; cat |[3=4] |[4=5] cat (It would be nice to get two pipes connecting the cats?) The null command doesn't seem well defined to me. From rc-owner Mon Jun 15 14:58:39 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2706>; Mon, 15 Jun 1992 14:56:09 -0400 Received: from postman.osf.org ([130.105.1.152]) by archone.tamu.edu with SMTP id <45323>; Mon, 15 Jun 1992 13:53:23 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA27599; Mon, 15 Jun 92 14:53:02 -0400 Received: by earth.osf.org (5.64/4.7) id AA10384; Mon, 15 Jun 92 14:53:01 -0400 Date: Mon, 15 Jun 1992 14:53:01 -0400 From: rsalz@osf.org Message-Id: <9206151853.AA10384@earth.osf.org> To: rc@archone.tamu.edu Subject: Adding the '-s' flag? I'd like to add the -s flag supported by sh and csh. It reads from stdin; all other command-line parameters get set into $*. ; sh -i foo bar sh: foo: cannot open # [Exit 1] ; sh -s foo bar $ echo $* foo bar help? From rc-owner Mon Jun 15 15:53:54 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2706>; Mon, 15 Jun 1992 15:52:25 -0400 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMT P id <45323>; Mon, 15 Jun 1992 14:52:08 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Mon, 15 Jun 1992 15:51:07 -0400 To: rsalz@osf.org cc: rc@archone.tamu.edu Subject: Re: Adding the '-s' flag? In-reply-to: Your message of "Mon, 15 Jun 92 14:53:01 EDT." <9206151853.AA10384@earth.osf.org> Date: Mon, 15 Jun 1992 15:50:53 -0400 From: Scott Schwartz Message-Id: <92Jun15.155107edt.2538@groucho.cs.psu.edu> | I'd like to add the -s flag supported by sh and csh. | It reads from stdin; all other command-line parameters get set into $*. How about: ; rc -i /dev/fd/0 foo bar ; echo $* foo bar (Achieved on SunOS with some shared library hackery... Doesn't OSF/1 have /dev/fd builtin?) From rc-owner Mon Jun 15 17:27:53 1992 Received: from stolaf.edu ([130.71.128.8]) by hawkwind.utcs.toronto.edu with SM TP id <2714>; Mon, 15 Jun 1992 17:25:13 -0400 Received: from loki4.cs.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA23717; Mon, 15 Jun 92 16:24:35 CDT Date: Mon, 15 Jun 1992 17:24:35 -0400 From: quanstro@stolaf.edu (Erik Quanstrom) Message-Id: <9206152124.AA23717@stolaf.edu> To: Subject: pipe semantics. Apparently-To: Perhaps, instead of using the "null command", whatever that might be, it might be possible to do least damage to rc's syntax by allowing more than one redirection assignment inside the square brackets, like fu |[4=5,3=8,9=] bar | blat I don't think that this would be that hard, though it looks like some dorking about in the lexer would be necessary. Just an idea (stolen (partly) from goosh). From rc-owner Tue Jun 16 09:42:56 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2702>; Tue, 16 Jun 1992 09:34:58 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA27208; Tue, 16 Jun 92 09:33:33 -0400 Received: by earth.osf.org (5.64/4.7) id AA21285; Tue, 16 Jun 92 09:33:32 -0400 Date: Tue, 16 Jun 1992 09:33:32 -0400 From: rsalz@osf.org Message-Id: <9206161333.AA21285@earth.osf.org> To: rc@hawkwind.utcs.toronto.edu Subject: Adding -s to rc Cc: boyd@prl.dec.com The following patch adds -s to rc1.4. Thanks to John Mackin for pointing me to Boyd who made the change in 1.2 *** main.c.orig Mon Jun 15 14:50:20 1992 --- main.c Tue Jun 16 09:32:32 1992 *************** *** 3,9 **** #include "rc.h" bool dashdee, dashee, dashvee, dashex, dashell, dasheye, ! dashen, dashpee, interactive; int rc_pid; static bool dashoh; --- 3,9 ---- #include "rc.h" bool dashdee, dashee, dashvee, dashex, dashell, dasheye, ! dashen, dashess, dashpee, interactive; int rc_pid; static bool dashoh; *************** *** 19,25 **** dollarzero = argv[0]; rc_pid = getpid(); dashell = (*argv[0] == '-'); /* Unix tradition */ ! while ((c = rc_getopt(argc, argv, "nolpeivdxc:")) != -1) switch (c) { case 'l': dashell = TRUE; --- 19,25 ---- dollarzero = argv[0]; rc_pid = getpid(); dashell = (*argv[0] == '-'); /* Unix tradition */ ! while ((c = rc_getopt(argc, argv, "nolpeivdxsc:")) != -1) switch (c) { case 'l': dashell = TRUE; *************** *** 39,44 **** --- 39,48 ---- case 'd': dashdee = TRUE; break; + case 's': + /* backwards compatibility with sh(1) and csh(1) */ + dashess = dasheye = interactive = TRUE; + break; case 'c': dashsee[0] = rc_optarg; goto quitopts; *************** *** 78,87 **** null[0] = NULL; starassign(dollarzero, null, FALSE); /* assign $0 to $* */ inithandler(); ! if (dashsee[0] != NULL) { /* input from the -c flag? */ if (*argv != NULL) starassign(dollarzero, argv, FALSE); ! pushstring(dashsee, TRUE); } else if (*argv != NULL) { /* else from a file? */ b_dot(--argv); rc_exit(getstatus()); --- 82,94 ---- null[0] = NULL; starassign(dollarzero, null, FALSE); /* assign $0 to $* */ inithandler(); ! if (dashsee[0] != NULL || dashess) { /* input from -c or -s? */ if (*argv != NULL) starassign(dollarzero, argv, FALSE); ! if (dashess) ! pushfd(0); ! else ! pushstring(dashsee, TRUE); } else if (*argv != NULL) { /* else from a file? */ b_dot(--argv); rc_exit(getstatus()); From rc-owner Wed Jun 17 09:20:23 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by hawkwind.utcs.toro nto.edu with SMTP id <2703>; Wed, 17 Jun 1992 09:18:32 -0400 Received: by doolittle.vetsci.su.oz.au id <49226>; Wed, 17 Jun 1992 23:18:00 +1 000 From: John (_You_ hide, they seek.) Mackin Date: Wed, 17 Jun 1992 09:01:51 -0400 To: The rc Mailing List Subject: Re: Adding the '-s' flag? In-Reply-To: <9206171300.AA13571@earth.osf.org> Message-ID: <199206172301.17232.rc.balek@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ I have been carrying on a discussion with Rich about the -s flag, and he made the following comment: I would like a version of script that took a commandline to run; wold be useful at times. More and more and more I am so excruciatingly glad that I changed over to rc when I did. Sure, the quoting is clean, sure, we have confidence in interactive constructs because we understand the grammar, but never mind all that! The biggest reason to use rc is, it just pays off again and again in total functionality!! If you have a shell which is sophisticated, powerful, understandable _and_ lacking in `dark corners,' well, you really can accomplish anything. You want script to be able to run a command? Absolutely too easy! Don't change the real script, just install this (which I just wrote but have tested) in $path in front of it, called script. Giving it a usage compatible with real script (-a for append, supply script filename) is left as an exercise for the reader. [By the way Rich: unless your version of script has powers and abilities far beyond those of mortal versions, why not trash it and render the -s question moot?] OK, John. #!/full/path/to/rc SHELL = /full/path/to/rc # if you think anyone will run it with $SHELL # set otherwise if ( ! ~ $#* 0 ) eval fn prompt '{' $* ';' exit '}' exec /full/path/to/real/script From rc-owner Wed Jun 17 11:34:54 1992 Received: from betty.cs.widener.edu ([147.31.254.25]) by hawkwind.utcs.toronto. edu with SMTP id <2717>; Wed, 17 Jun 1992 11:29:19 -0400 Received: by betty.cs.widener.edu id AA07486 (5.65c/Widener-4.1 for rc mailing list ); Wed, 17 Jun 1992 11:01:10 -0400 Date: Wed, 17 Jun 1992 11:01:10 -0400 From: Brendan Kehoe Message-Id: <199206171501.AA07486@betty.cs.widener.edu> To: rc mailing list Subject: a quick hack Reply-To: brendan@cs.widener.edu I just threw this together, and thought it might be useful to others. It's the equivalent of /usr/lib/newsyslog, but adds a little more power and pep to it. Comments on style welcome. -- #!/bin/rc # Rotate the logs like /usr/lib/newsyslog, but $compress 'em. (The times # I actually check the old logs are one in a googleplex.) If you'd rather # not compress them, just change compress to `true'. logs=(/var/adm/messages /var/log/syslog) compress=freeze ; ext=F fn rotate { file=$1 ; shift while (! ~ $#* 1) { { ~ ($file.$2^*) $file.$2^'*' || { mv -f $file.^($2 $1)^.$ext || { mv -f $file^(.$2 .$1) && $compress $file.$1 } # we could do: eval ('mv -f $file.$2 ' '&& $compress ')^$file.1 }} >[2] /dev/null shift } } umask 22 # create the new log with mode 644 for (log in $logs) { test -s $log && { rotate $log 7 6 5 4 3 2 1 0 mv -f $file $file.0 && $compress $file.0 > $log } } exit 0 -- Brendan Kehoe, Sun Network Manager brendan@cs.widener.edu Widener University Chester, PA In action-oriented shows, TV cops fire their guns in almost every episode; in Chicago, the average police officer fires a gun once every 27 years. From rc-owner Wed Jun 17 12:40:40 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by hawkwind.utcs.toro nto.edu with SMTP id <2711>; Wed, 17 Jun 1992 12:38:07 -0400 Received: by doolittle.vetsci.su.oz.au id <49226>; Thu, 18 Jun 1992 02:36:23 +1 000 From: John (_You_ hide, they seek.) Mackin Date: Wed, 17 Jun 1992 12:09:14 -0400 To: The rc Mailing List Subject: "pathos" script Message-ID: <199206180209.18162.rc.baler@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ I guess I should mail this one to the list. You know how you often want to do something that does `just that little bit extra'? Like, in that script front-end I sent earlier, you want to call that one "script" too and then have it execute the command by the same name further along $path? In my earlier mail, I wrote "exec /full/path/to/real/script", but I always thought it was a right bummer to have to wire those pathnames in. Of course, if the frontend you are writing is a function, you win since you can just use "builtin" to get to the executable; but there's nothing built-in to rc to help you in the more common case where the frontend you are writing is a script. Naturally, it doesn't have to be built in to rc; here it is. I've been using this one for ages but didn't get around to sending it out until now, so it should be solid. You use it, say in my "script" example, by ending the command with: exec pathos $0 $* As simple as that. It has one known deficiency, which I can't think of a nice fix for: if you are in the directory containing the frontend when you run it, then it gets exec'd with a relative pathname and the script won't work. In practice this doesn't present a problem. It illustrates a neat technique for eliminating export of variables (useful here since I often use pathos in a context that will end up spawning an interactive shell somewhere down the track). The reason the variables all have funky names starting with underscore is to minimise the chances of one of the variables clashing with the name of the command you want to execute (i.e., the name of the frontend), because in that case my trick with "whatis" won't work right. I did try, ages ago, to convince Byron that whatis needed to take options so that I wouldn't need to do this, but he wouldn't wear it, so... (Like: whatis -e shows only an executable whatis -v shows only a variable whatis -f shows only a function Then I could have just used whatis -e and gone to a lot less trouble -- and not needed funky names.) Enjoy. OK, John. #!/full/path/to/rc # # usage: pathos /full/path/to/command [args] # # The idea is that often we want to supersede a command that's further # down the path. This gives us the same function in a script -- pick # up the command of the same name further along -- that we can get by # using `builtin' in a function. # _Vars = ( _Vars _me _dir _cmd _tpath _chop _fatal ) _me = ` { basename $0 } fn _fatal { echo $_me ^ : $* >[1=2] exit 1 } if ( ~ $#* 0 ) _fatal usage: $_me /full/path/to/command '[args]' if ( ! ~ $1 /* ) _fatal first argument must be a full pathname _dir = ` { dirname $1 } _cmd = ` { basename $1 } shift if ( ! ~ $_dir $path ) _fatal can''''t find directory $_dir in path if ( ~ $_cmd $_Vars ) _fatal command name $_cmd matches an internal variable or function fn _chop { shift _tpath = $* } _tpath = $path for ( p in $path ) { _chop $_tpath if ( ~ $p $_dir ) break } p = () if ( ~ $#_tpath 0 ) _fatal directory $_dir is the last one in the path if ( ! path = $_tpath $_cmd = () whatis $_cmd >/dev/null >[2=1] ) _fatal command $_cmd not found in path fragment $_tpath pid = ` { path = $_tpath $_cmd = () whatis $_cmd } # chortle for ( v in $_Vars ) $v = () v = () fn _chop fn _fatal exec $pid $* From rc-owner Wed Jun 17 16:25:26 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2714>; Wed, 17 Jun 1992 16:21:57 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA17935; Wed, 17 Jun 92 16:21:44 -0400 Received: by earth.osf.org (5.64/4.7) id AA24775; Wed, 17 Jun 92 16:21:43 -0400 Date: Wed, 17 Jun 1992 16:21:43 -0400 From: rsalz@osf.org Message-Id: <9206172021.AA24775@earth.osf.org> To: rc@hawkwind.utcs.toronto.edu Subject: Revised editline library I've spent some time working on the editline library. Thanks to Simmy for his help and permission. The README is attached. Source is on ftp.uu.net, ~ftp/tmp/editline.shar.Z; email me if you can't FTP. Once I get feedback I'll post it to the net. To use it, enable the READLINE #define in rc (not EDITLINE). /r$ This is a line-editing library. It can be linked into almost any program to provide command-line editing and history recall. It is call-compatible with the FSF readline library, but it is a fraction of the size (and offers fewer features). It does not use standard I/O. Configuration is done in the Makefile. Type "make testit" to get a small slow shell for testing. An earlier version was distribution with Byron's rc. Principal changes over that version include: Faster. About 10% smaller. Written in K&R C, but ANSI compliant (gcc all warnings) Propagates EOF properly; rc trip test now passes Doesn't need or use or provide memmove. More robust Calling sequence changed to be compatible with readline. Test program, new manpage, better configuration Enjoy, Rich $alz Copyright 1992 Simmule Turner and Rich Salz. All rights reserved. This software is not subject to any license of the American Telephone and Telegraph Company or of the Regents of the University of California. Permission is granted to anyone to use this software for any purpose on any computer system, and to alter it and redistribute it freely, subject to the following restrictions: 1. The authors are not responsible for the consequences of use of this software, no matter how awful, even if they arise from flaws in it. 2. The origin of this software must not be misrepresented, either by explicit claim or by omission. Since few users ever read sources, credits must appear in the documentation. 3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original software. Since few users ever read sources, credits must appear in the documentation. 4. This notice may not be removed or altered. From rc-owner Mon Jun 22 14:05:31 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2680>; Mon, 22 Jun 1992 14:03:16 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA28837; Mon, 22 Jun 92 14:02:57 -0400 Received: by earth.osf.org (5.64/4.7) id AA08821; Mon, 22 Jun 92 14:02:56 -0400 Date: Mon, 22 Jun 1992 14:02:56 -0400 From: rsalz@osf.org Message-Id: <9206221802.AA08821@earth.osf.org> To: rc@hawkwind.utcs.toronto.edu Subject: New version of editline A new version of editline is on ftp.uu.net, ~ftp/tmp/editline.shar.Z or mail me and I will send it to you. Primary changes are due to brendan@cs.widener.edu: 8-bit clean; handles the meta key get TTY width from ioctl or termcap (if enabled) Filename completion doesn't truncate names now, and it's checked into RCS finally. /r$ From rc-owner Mon Jun 22 14:34:38 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2680>; Mon, 22 Jun 1992 14:33:51 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA29990; Mon, 22 Jun 92 14:33:30 -0400 Received: by earth.osf.org (5.64/4.7) id AA08937; Mon, 22 Jun 92 14:33:28 -0400 Date: Mon, 22 Jun 1992 14:33:28 -0400 From: rsalz@osf.org Message-Id: <9206221833.AA08937@earth.osf.org> To: rc@hawkwind.utcs.toronto.edu Subject: bug fix for editline If you picked up editline in the last 30 minutes, apply this patch =================================================================== RCS file: RCS/editline.c,v retrieving revision 1.1 diff -c -r1.1 editline.c *** /tmp/,RCSt1a08925 Mon Jun 22 14:32:46 1992 --- editline.c Mon Jun 22 10:31:27 1992 *************** *** 1,4 **** ! /* $Revision: 1.1 $ ** ** Main editing routines for editline library. */ --- 1,4 ---- ! /* $Revision: 1.2 $ ** ** Main editing routines for editline library. */ *************** *** 87,93 **** STATIC SIZE_T ScreenCount; STATIC SIZE_T ScreenSize; STATIC char Version[] = ! "$Header: /usr/users/rsalz/src/rc/edit/RCS/editline.c,v 1.1 92/06/22 12:3 2:45 rsalz Exp $"; STATIC char *backspace; STATIC int TTYwidth; --- 87,93 ---- STATIC SIZE_T ScreenCount; STATIC SIZE_T ScreenSize; STATIC char Version[] = ! "$Header: /usr/users/rsalz/src/rc/edit/RCS/editline.c,v 1.2 92/06/22 14:3 1:27 rsalz Exp $"; STATIC char *backspace; STATIC int TTYwidth; *************** *** 786,793 **** TTYput(' '); } TTYbackn(i + 1); - return CSmove; *p = '\0'; } if (Point + nchars > End && (nchars = End - Point) <= 0) return CSstay; --- 786,793 ---- TTYput(' '); } TTYbackn(i + 1); *p = '\0'; + return CSmove; } if (Point + nchars > End && (nchars = End - Point) <= 0) return CSstay; From rc-owner Wed Jun 24 15:23:03 1992 Received: from relay2.UU.NET ([137.39.1.7]) by hawkwind.utcs.toronto.edu with S MTP id <2628>; Wed, 24 Jun 1992 15:19:23 -0400 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA07279; Wed, 24 Jun 92 15:19:17 -0400 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 151853.25523; Wed, 24 Jun 1992 15:18:53 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa06331; Wed, 24 Jun 92 15:10:36 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Command execution Date: Wed, 24 Jun 1992 15:10:38 -0400 Message-Id: <9206241510.aa06947@ceres.srg.af.mil> Heres a minor annoyance/inconsistency with Byron's rc that I noticed way back when I first started using it but never bugged me until now. Tom Duff[1] says that in executing commands rc first looks for a function of the given name, then a builtin commands, then if the name CONTAINS a '/' it is taken as a path to an executeable, otherwise it searchs for an executable of that name using the path. This implies a couple of things which I believe are desirable. First, the function: "fn csh /bin/csh { echo 'You''ve got to be kidding!' }" should be a legitimate and useful definition. If you really want to get to csh you can still say "builtin csh". (Unless of course builtin has been overloaded...) Currently "/bin/csh" will not invoke the function. Second, the commands "./bin/thingee" and "bin/thingee" should be treated consistently, and not behave differently, based on the path or function definitions. Currently if you remove "." from your path "bin/thingee" will not be treated as a path name, and "bin/thingee" will invoke a function but "./bin/thingee" will not.) Unfortunately Byron[2] changed these rules somewhat, so that his rc FIRST checks if the command STARTS with "/", "./", or "../" in which case it is taken as a path to an executeable, before going on to check functions, builtins and the path. This means that the function "/bin/csh" will never be seen and that "./bin/thingee" is quite different from "bin/thingee". "Fixing" this should be trivial, in the one case changing the order of checks and in the other checking using strchr(cmdname, '/'). However I assume Byron had a reason for this. Any comments? Tom [1] "Rc - A Shell for Plan 9 and Unix Systems", page 6, section 17 [2] "RC(1)" (Byron's man page), page 1, section "Commands" From rc-owner Wed Jun 24 16:21:15 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2690>; Wed, 24 Jun 1992 16:19:49 -0400 To: rc Subject: Re: Command execution In-reply-to: culliton's message of Wed, 24 Jun 92 15:10:38 -0400. <9206241510.aa06947@ceres.srg.af.mil> Date: Wed, 24 Jun 1992 16:19:25 -0400 From: Chris Siebenmann Message-Id: <92Jun24.161949edt.2690@hawkwind.utcs.toronto.edu> Duff's rc lets you define a function that looks like a full path, and running the full path will run the function (ie, fn /bin/csh ...). I don't think this is a good idea myself; the uses seem limited to trapping standard programs when invoked by explicit paths, and I see more problems as a result than solutions. Contrary to the documentation, Duff's rc and Byron's behave the *same* for 'foo/bar', and at least Rob Pike a) thinks this is a good thing and b) uses this feature. - cks From rc-owner Wed Jun 24 18:49:51 1992 Received: from relay2.UU.NET ([137.39.1.7]) by hawkwind.utcs.toronto.edu with S MTP id <2718>; Wed, 24 Jun 1992 18:45:23 -0400 Received: from uunet.uu.net (via localhost.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11037; Wed, 24 Jun 92 17:41:43 -0400 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 174034.2539; Wed, 24 Jun 1992 17:40:34 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa07804; Wed, 24 Jun 92 17:19:31 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Command execution Date: Wed, 24 Jun 1992 17:19:34 -0400 Message-Id: <9206241719.aa07461@ceres.srg.af.mil> >> Duff's rc lets you define a function that looks like a full path, and >> running the full path will run the function (ie, fn /bin/csh ...). I >> don't think this is a good idea myself; the uses seem limited to trapping >> standard programs when invoked by explicit paths, and I see more problems >> as a result than solutions. This was exactly what I wanted to do. One of my friends likes to run a couple of obnoxious programs on my workstation when he drops by to visit and I'm not in the office. Since they're coming from the file server's shared bin directory a function seemed like a good way to interdict them. I can also see other uses to transparently stick a front end on something, say to translate command line options from one form to another. In any case, it was a fairly minor quibble. >> Contrary to the documentation, Duff's rc >> and Byron's behave the *same* for 'foo/bar', and at least Rob Pike a) >> thinks this is a good thing and b) uses this feature. This iregularity troubles me more, but thats just because odd little gotchas set my teeth on edge, and in almost any other unix context "x/y" is identical to "./x/y". Could you say more about why Pike thinks this is good and what you would use it for? Tom From rc-owner Wed Jun 24 19:12:02 1992 Received: from ucsd.edu ([128.54.16.1]) by hawkwind.utcs.toronto.edu with SMTP id <2659>; Wed, 24 Jun 1992 19:08:50 -0400 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA23357 sendmail 5.64/UCSD-2.2-sun via SMTP Wed, 24 Jun 92 16:05:52 -0700 for rc@hawkwind.utcs.toronto.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA02025 for rc@hawkwind.utcs.toronto.edu; Wed, 24 Jun 92 16:04:58 pd t Date: Wed, 24 Jun 1992 19:04:58 -0400 From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9206242304.AA02025@sdnp1.UCSD.EDU> To: culliton@srg.af.mil (Tom Culliton x2278) Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: Command execution In-Reply-To: Tom Culliton x2278's message of Wed June 24, 191992, at 17:19:34 References: <9206241719.aa07461@ceres.srg.af.mil> Tom Culliton writes: | >> Contrary to the documentation, Duff's rc | >> and Byron's behave the *same* for 'foo/bar', and at least Rob Pike a) | >> thinks this is a good thing and b) uses this feature. | | This iregularity troubles me more, but thats just because odd little | gotchas set my teeth on edge, and in almost any other unix context | "x/y" is identical to "./x/y". Could you say more about why Pike | thinks this is good and what you would use it for? I use this all of the time. At first I found it strange that 'x/y' wasn't './x/y' but I quickly retrained. Also, I don't have '.' in my path so I'm well used to using './' in front of things as needed. Now, the reason I use this. I some subdirectories of binaries that I use occasionally, but don't want to pay the performance hit of leaving them in my path. Also, I just don't want them in my path because of some name conflicts with std programs. Example: I do have '/usr/local/bin' in my path. If I want to run the file '/usr/local/bin/cap/atlook VA', as I do once or twice a week, I just do 'cap/atlook VA' and it does it. I find this very convenient and I like it better than having a function named 'atlook' which knew where to go. I currently have a hosts directory of machines I log into also. I've been thinking of removing this from my path, and just using 'hosts/foo' to get to them. | Tom David -- David Moore - SysAdmin/Programmer UCSD | Dept. of Anesthesiology | V-151 | La Jolla, CA 92093-9151 Work Phone: (619) 552-8585 x7042 "God does not play dice." - A. Einstein "Yes, I do." - D. Moore From rc-owner Thu Jun 25 17:24:21 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2690>; Thu, 25 Jun 1992 17:22:53 -0400 To: rc Subject: Re: Command execution In-reply-to: culliton's message of Wed, 24 Jun 92 17:19:34 -0400. <9206241719.aa07461@ceres.srg.af.mil> Date: Thu, 25 Jun 1992 17:22:40 -0400 From: Chris Siebenmann Message-Id: <92Jun25.172253edt.2690@hawkwind.utcs.toronto.edu> [trapping regular absolute program names with function names:] | This was exactly what I wanted to do. One of my friends likes to run a | couple of obnoxious programs on my workstation when he drops by to | visit and I'm not in the office. This sounds like a social problem, not a software problem; if it's really that bad, patch your own version of rc a bit. I wouldn't want to twist the main rc version to do this; if you invoke the absolute path name, you *mean* the absolute path name. 'x/y' vs. './x/y' has been hashed out before in the mailing list; check the archives. I belive Pike just considered it the right approach. I use it for the same sort of things that David Moore does; to keep infrequently-used stuff off my path. - cks From rc-owner Thu Jun 25 18:12:18 1992 Received: from relay2.UU.NET ([137.39.1.7]) by hawkwind.utcs.toronto.edu with S MTP id <2743>; Thu, 25 Jun 1992 18:11:36 -0400 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA03797; Thu, 25 Jun 92 18:11:30 -0400 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 181006.19271; Thu, 25 Jun 1992 18:10:06 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa09729; Thu, 25 Jun 92 17:56:31 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Command execution Date: Thu, 25 Jun 1992 17:56:35 -0400 Message-Id: <9206251756.aa10707@ceres.srg.af.mil> cks> if you invoke the absolute cks> path name, you *mean* the absolute path name. I can still imagine ways that it might be useful, but no big deal. cks> 'x/y' vs. './x/y' has been hashed out before in the mailing list; cks> check the archives. I belive Pike just considered it the right cks> approach. I use it for the same sort of things that David Moore does; cks> to keep infrequently-used stuff off my path. I probably missed it, having only been on the mailing list since early December. It could definitely be made clearer in the man page, especially since it's rather different from most shells. From rc-owner Thu Jun 25 19:32:33 1992 Received: from relay1.UU.NET ([137.39.1.5]) by hawkwind.utcs.toronto.edu with S MTP id <2703>; Thu, 25 Jun 1992 19:31:22 -0400 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19667; Thu, 25 Jun 92 19:31:08 -0400 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 193010.8526; Thu, 25 Jun 1992 19:30:10 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa10053; Thu, 25 Jun 92 18:29:41 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Another little challenge Date: Thu, 25 Jun 1992 18:29:46 -0400 Message-Id: <9206251829.aa10786@ceres.srg.af.mil> While I've got your brains working it seems like a good time to re-ask a question that never got answered before. There is no hook in rc to have something done when a child shell is started. (like ksh's ENV variable) Has anyone come up with a way to do something like this? What inspired this is firing off a new xterm running rc and wanting to set certain things. (stty, etc.) You can do some of the stty type stuff, but not all of it, using command line options, or you can make every xterm call rc as a login shell which has other problems. It seems like this is something which needs a good general purpose solution. Any ideas? Tom From rc-owner Thu Jun 25 19:36:02 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2702>; Thu, 25 Jun 1992 19:35:25 -0400 To: rc Subject: Re: Another little challenge In-reply-to: culliton's message of Thu, 25 Jun 92 18:29:46 -0400. <9206251829.aa10786@ceres.srg.af.mil> Date: Thu, 25 Jun 1992 19:35:16 -0400 From: Chris Siebenmann Message-Id: <92Jun25.193525edt.2702@hawkwind.utcs.toronto.edu> You can't run something on every subshell, but you can run something on every interactive subshell. For the people who weren't around for my discovery process of this last year: fn prompt { if (! ~ $cpid $pid) {cpid=$pid; ... } } This will let you run something every time a new interactive shell starts up and runs prompt. - cks From rc-owner Thu Jun 25 20:27:15 1992 Received: from vlsi.cs.caltech.edu ([131.215.131.129]) by hawkwind.utcs.toronto .edu with SMTP id <2708>; Thu, 25 Jun 1992 20:25:56 -0400 Received: from klio.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1) id AA20589; Thu, 25 Jun 92 17:26:17 PDT Date: Thu, 25 Jun 1992 20:26:17 -0400 From: drazen@vlsi.cs.caltech.edu (D. Borkovic) Message-Id: <9206260026.AA20589@vlsi.cs.caltech.edu> To: rc@hawkwind.utcs.toronto.edu Subject: subshell, interactive, login, etc What do people out there think about this: Every rc sources .rcrc, but before doing this defines certain variable (say $mode) to have certain values depending on the mode. Then you can do in .rcrc: switch ($mode){ case login; . $home/rc/login; case inter; . $home/rc/inter; case inter_login; . $home/rc/inter; . $home/rc/login; } Well, I did not think much about the values (inter_login looks ugly), but I hope you get the idea. Drazen From rc-owner Thu Jun 25 20:46:52 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2711>; Thu, 25 Jun 1992 20:44:21 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2536>; Thu, 25 Jun 1992 20:43:07 -0400 To: drazen@vlsi.cs.caltech.edu (D. Borkovic) cc: rc@hawkwind.utcs.toronto.edu Subject: Re: subshell, interactive, login, etc In-reply-to: Your message of "Thu, 25 Jun 92 20:26:17 EDT." <9206260026.AA20589@vlsi.cs.caltech.edu> Date: Thu, 25 Jun 1992 20:42:44 -0400 From: Scott Schwartz Message-Id: <92Jun25.204307edt.2536@groucho.cs.psu.edu> | What do people out there think about this: | | Every rc sources .rcrc, but before doing this defines | certain variable (say $mode) to have certain values | depending on the mode. How about this instead: every rc evaluates a function, rc_init, if defined, when it starts up. (Before or after .rcrc, if a login shell?) This would preserve a nice property of the current scheme, that you don't need to read .rcrc just to start a shell. My dream fix: user defined read-eval-print loops. Scheme-shell anyone? From rc-owner Thu Jun 25 21:40:48 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2736>; Thu, 25 Jun 1992 21:39:49 -0400 To: rc Subject: Re: subshell, interactive, login, etc In-reply-to: drazen's message of Thu, 25 Jun 92 20:26:17 -0400. <9206260026.AA20589@vlsi.cs.caltech.edu> Date: Thu, 25 Jun 1992 21:39:42 -0400 From: Chris Siebenmann Message-Id: <92Jun25.213949edt.2736@hawkwind.utcs.toronto.edu> The only problem not currently addressable in rc as it stands is rsh, and I think rsh is its own problem and rc need not try to solve that particular mess. - cks From rc-owner Thu Jun 25 21:42:50 1992 Received: from carson.u.washington.edu ([140.142.52.11]) by hawkwind.utcs.toron to.edu with SMTP id <2717>; Thu, 25 Jun 1992 21:42:10 -0400 Received: by carson.u.washington.edu (5.65/UW-NDC Revision: 2.22 ) id AA07285; Thu, 25 Jun 92 18:41:59 -0700 Date: Thu, 25 Jun 1992 21:41:59 -0400 From: Donn Cave Message-Id: <9206260141.AA07285@carson.u.washington.edu> Sender: donn@carson.u.washington.edu To: rc@hawkwind.utcs.toronto.edu Subject: Re: subshell, interactive, login, etc | Every rc sources .rcrc, but before doing this defines | certain variable (say $mode) to have certain values | depending on the mode. | | Then you can do in .rcrc: | | switch ($mode){ | case login; . $home/rc/login; | case inter; . $home/rc/inter; | case inter_login; . $home/rc/inter; . $home/rc/login; | } I think something like this is needed, recognizing that as we find more alternatives to the console login, properly initializing a new shell process becomes more complex. I think I recall that the original inspiration for this was an stty(1) needed for a new xterm-invoked rc; this process will inherit environment variables, so you wouldn't want to set "path" and so forth as if it were a login, but you wouldn't want to have every interactive rc process run stty(1). The easiest and most general way to handle this one might be to use the ENV concept from ksh. Window managers and the like could set ENV = $home/newtty.rc, and that script would be responsible for clearing ENV so that further rc's aren't plagued by it. ENV would normally not be set, so rc scripts wouldn't source anything at all, but it would probably be good to insure that by having non-interactive shells ignore ENV. I've complained in the past that rshd invokes one's shell without the leading minus sign that would make it a login shell, so .rcrc (or .profile, or whatever) doesn't get run. This makes it hard to invoke something that's not in a system standard execution path, via rsh. There may be no good way to fix that problem, but the best of the bad ways might be to have rc expect a certain environment variable, and run .rcrc if it's not there. Donn Cave, University Computing Services, University of Washington donn@cac.washington.edu From rc-owner Thu Jun 25 22:04:55 1992 Received: from relay2.UU.NET ([137.39.1.7]) by hawkwind.utcs.toronto.edu with S MTP id <2751>; Thu, 25 Jun 1992 22:02:50 -0400 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA12653; Thu, 25 Jun 92 21:51:28 -0400 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 214959.6159; Thu, 25 Jun 1992 21:49:59 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa10803; Thu, 25 Jun 92 20:31:21 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Another little challenge Date: Thu, 25 Jun 1992 20:31:25 -0400 Message-Id: <9206252031.aa11853@ceres.srg.af.mil> Excellent! It struck me that there had to be an elegant solution but I just couldn't see it. That little gem is already in my .rcrc file. :-) My recent rash of questions is prompted by converting a friend to rc and helping him solve the problems encountered. The other thing that reared it's head was the old "everything is exported" problem. Rich produced a partial solution back in May, but it required that you explicitly "unexport" things. I'm currently tinkering with a solution that looks like this: # This code can be fooled by really pathological cases involving embedded # newlines followed by either 'fn ' or '='. Fixing this is left as an # exercise for the reader. ;-) It's already slow enough for me. exported=() fn export { exported=($exported $*) } fn fns_n_vars { i=() tmp=() { fn_list=() var_list=() for (i in `` ($nl) {whatis}) if (~ $i 'fn '*) { tmp=`{echo $i} fn_list=($fn_list $tmp(2)) } else if (~ $i *'='*) { tmp=`` ('=') {echo $i} var_list=($var_list $tmp(1)) } }} fns_n_vars # pre-load should be done after all variable setting in .rcrc # Stuff run by clean_env will only see the exported variables. You can # also give this function multiple names for programs that choke on big # env's. Note that keeping fn_list and var_list up to date needs to be # improved. I thought about something like: # x=`` ($nl) {whatis} if (! ~ $#x $xcnt) { xcnt=$#x; fns_n_vars } # but it could be fooled pretty easily. Ideas? fn clean_env { i=() @{ if (~ $#fn_list 0 && ~ $#var_list 0) { fns_n_vars } for (i in $fn_list) { eval 'fn '^$i } for (i in $var_list) { if (! ~ $i $exported i exported) { eval $i^'=()' } } i=(); fn_list=(); var_list=(); exported=(); fn clean_env if (~ $0 clean_env) exec $* else exec $0 $* }} From rc-owner Thu Jun 25 22:13:22 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2755>; Thu, 25 Jun 1992 22:08:28 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2536>; Thu, 25 Jun 1992 22:07:52 -0400 To: Donn Cave cc: rc@hawkwind.utcs.toronto.edu Subject: Re: subshell, interactive, login, etc In-reply-to: Your message of "Thu, 25 Jun 92 21:41:59 EDT." <9206260141.AA07285@carson.u.washington.edu> Date: Thu, 25 Jun 1992 22:07:30 -0400 From: Scott Schwartz Message-Id: <92Jun25.220752edt.2536@groucho.cs.psu.edu> | I've complained in the past that rshd invokes one's shell without the | leading minus sign that would make it a login shell, so .rcrc (or .profile, | or whatever) doesn't get run. This makes it hard to invoke something | that's not in a system standard execution path, via rsh. I've been using this lately. It seems like an adequate workaround. #!/bin/rc -p # usage: rrc [-n] host cmd bg=(); quietly=(); sanely='>[3=] >[4=] >[5=] >[6=] >[7=]'; host=$1; shift if (~ -n $host) { bg='&' quietly='>[0]/dev/null >[1=0] >[2=0]' host=$1; shift } { whatis PATH DISPLAY TERM TERMCAP TERMINFO >[2]/dev/null echo exec $sanely echo . .rcrc echo '{' $* '}' $quietly $bg exit } | rsh $host exec /bin/rc From rc-owner Thu Jun 25 22:36:17 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2758>; Thu, 25 Jun 1992 22:35:22 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2536>; Thu, 25 Jun 1992 22:34:39 -0400 To: culliton@srg.af.mil (Tom Culliton x2278) cc: rc@hawkwind.utcs.toronto.edu Subject: Re: Another little challenge In-reply-to: Your message of "Thu, 25 Jun 92 20:31:25 EDT." <9206252031.aa11853@ceres.srg.af.mil> Date: Thu, 25 Jun 1992 22:34:11 -0400 From: Scott Schwartz Message-Id: <92Jun25.223439edt.2536@groucho.cs.psu.edu> | # This code can be fooled by really pathological cases involving embedded | # newlines followed by either 'fn ' or '='. Fixing this is left as an | # exercise for the reader. ;-) It's already slow enough for me. Here's where Unix really loses: malappropriate delimiters all over the place. If "whatis" would print an \0 between entries, you could use that to split them. That assumes ifs can deal with \0, and that \0 won't otherwise appear in the output from whatis. (ifs='' seems to work; probably as a side effect of nul terminated strings.) Lisp really wins because the read primative can properly interpret whatever the write primative generates. From rc-owner Thu Jun 25 23:59:02 1992 Received: from uwast.astro.wisc.edu ([128.104.39.203]) by hawkwind.utcs.toronto .edu with SMTP id <2731>; Thu, 25 Jun 1992 23:57:48 -0400 Received: by uwast.astro.wisc.edu; id AA06561; 5.57/42; Thu, 25 Jun 92 22:57:31 -0500 Message-Id: <9206260357.AA06561@uwast.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: subshell, interactive, login, etc Date: Thu, 25 Jun 1992 23:57:30 -0400 From: Alan Watson X-Mts: smtp I have a work-around for the problems with rsh; my `login shell' is actually this rc script (called, unsurprisingly, rc-login): #! /usr/users/alan/bin/rc path = ( /usr/users/alan/bin $path ) exec rc -l $* From rc-owner Fri Jun 26 00:13:08 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2733>; Fri, 26 Jun 1992 00:12:15 -0400 Received: by groucho.cs.psu.edu id <2536>; Fri, 26 Jun 1992 00:11:35 -0400 From: Scott Schwartz To: rc@hawkwind.utcs.toronto.edu Subject: recent -s patch Message-Id: <92Jun26.001135edt.2536@groucho.cs.psu.edu> Date: Fri, 26 Jun 1992 00:11:24 -0400 I don't think -s should imply -i, as the patch does. If I want both I can type both. Is -s going to be standard, or will most people decline to apply the patch? From rc-owner Fri Jun 26 04:16:09 1992 Received: from natalie.ibmpcug.co.uk ([192.68.174.66]) by hawkwind.utcs.toronto .edu with SMTP id <2702>; Fri, 26 Jun 1992 04:14:05 -0400 Received: from kate.ibmpcug.co.uk by natalie.ibmpcug.co.uk id aa25649; 26 Jun 92 9:13 BST X-Phone-Work: +44 81 863-1191 X-Fax-Work: +44 81 863-6095 X-Favourite-Colour: black, of course. Newsgroups: list.rc In-Reply-To: <9206260141.AA07285@carson.u.washington.edu> Organization: The IBM PC User Group, UK. X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: donn@u.washington.edu Subject: Re: subshell, interactive, login, etc Cc: rc@hawkwind.utcs.toronto.edu Date: Fri, 26 Jun 1992 04:10:22 -0400 From: Matthew Farwell Sender: dylan@ibmpcug.co.uk Message-ID: <9206260910.aa07929@kate.ibmpcug.co.uk> In article <9206260141.AA07285@carson.u.washington.edu> you write: >| Every rc sources .rcrc, but before doing this defines >| certain variable (say $mode) to have certain values >| depending on the mode. >| >| Then you can do in .rcrc: >| >| switch ($mode){ >| case login; . $home/rc/login; >| case inter; . $home/rc/inter; >| case inter_login; . $home/rc/inter; . $home/rc/login; >| } > >I think something like this is needed, recognizing that as we find more >alternatives to the console login, properly initializing a new shell process >becomes more complex. > >I think I recall that the original inspiration for this was an stty(1) >needed for a new xterm-invoked rc; this process will inherit environment >variables, so you wouldn't want to set "path" and so forth as if it were >a login, but you wouldn't want to have every interactive rc process run >stty(1). > >The easiest and most general way to handle this one might be to use the >ENV concept from ksh. Window managers and the like could set >ENV = $home/newtty.rc, and that script would be responsible for clearing >ENV so that further rc's aren't plagued by it. ENV would normally not >be set, so rc scripts wouldn't source anything at all, but it would probably >be good to insure that by having non-interactive shells ignore ENV. ; ls -l /bin/rc /bin/-rc -rwxr-xr-x 3 bin bin 63660 Feb 19 13:17 /bin/-rc* -rwxr-xr-x 3 bin bin 63660 Feb 19 13:17 /bin/rc* ; fn rc { mode=subshell -rc $* } Then put something like if (! $mode ~ subshell) { test -f $MAIL && echo You have mail. } else { prompt=('subshell; ' '>') } in your .rcrc. Well, that will work when you do it interactively anyway. Dylan. -- It is no coincidence that in no known language does the phrase 'As pretty as an Airport' appear -- Douglas Adams From rc-owner Fri Jun 26 06:34:23 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2690>; Fri, 26 Jun 1992 06:33:37 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA18474; Fri, 26 Jun 92 12:33:17 +0200 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA05577; Fri, 26 Jun 92 12:33:16 +0200 Date: Fri, 26 Jun 1992 06:33:16 -0400 From: malte@techfak.uni-bielefeld.de Message-Id: <9206261033.AA05577@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: subshell, interactive, login, etc In-Reply-To: Mail from 'drazen@vlsi.cs.caltech.edu (D. Borkovic)' dated: Thu, 25 Jun 1992 20:26:17 -0400 drazen@vlsi.cs.caltech.edu (D. Borkovic) writes: Every rc sources .rcrc, but before doing this defines certain variable (say $mode) to have certain values depending on the mode. If this is seriously considered to be incorporated, the recent rc version will be the last I use. There has never been an uglier, more resource waisting or more problem causing mechanism than that. I fought serious wars to convince csh users to switch to rc and now this ! NEVER! Malte. From rc-owner Fri Jun 26 10:08:36 1992 Received: from natalie.ibmpcug.co.uk ([192.68.174.66]) by hawkwind.utcs.toronto .edu with SMTP id <2690>; Fri, 26 Jun 1992 10:07:21 -0400 Received: by natalie.ibmpcug.co.uk id aa29012; 26 Jun 92 15:04 BST Received: from kate.ibmpcug.co.uk by natalie.ibmpcug.co.uk id aa29004; 26 Jun 92 15:03 BST X-Phone-Work: +44 81 863-1191 X-Fax-Work: +44 81 863-6095 X-Favourite-Colour: black, of course. X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: malte@techfak.uni-bielefeld.de Subject: Re: subshell, interactive, login, etc Cc: rc@hawkwind.utcs.toronto.edu Date: Fri, 26 Jun 1992 09:57:23 -0400 From: Matthew Farwell Sender: dylan@ibmpcug.co.uk Message-ID: <9206261457.aa02134@kate.ibmpcug.co.uk> In article <9206261033.AA05577@dahlie.techfak.uni-bielefeld.de> you write: >drazen@vlsi.cs.caltech.edu (D. Borkovic) writes: > > Every rc sources .rcrc, but before doing this defines > certain variable (say $mode) to have certain values > depending on the mode. > >If this is seriously considered to be incorporated, the recent rc version will >be the last I use. There has never been an uglier, more resource waisting or >more problem causing mechanism than that. I fought serious wars to convince >csh users to switch to rc and now this ! Now that you come to mention it, I think it'd be the same for me too. Dylan. -- It is no coincidence that in no known language does the phrase 'As pretty as an Airport' appear -- Douglas Adams From rc-owner Fri Jun 26 20:53:32 1992 Received: from relay1.UU.NET ([137.39.1.5]) by hawkwind.utcs.toronto.edu with S MTP id <2717>; Fri, 26 Jun 1992 20:49:25 -0400 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA24161; Fri, 26 Jun 92 20:49:09 -0400 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 204828.9492; Fri, 26 Jun 1992 20:48:28 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa03298; Fri, 26 Jun 92 20:15:19 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: costorm@uunet.UU.NET, rc@hawkwind.utcs.toronto.edu Subject: An export solution for rc Date: Fri, 26 Jun 1992 20:15:26 -0400 Message-Id: <9206262015.aa16494@ceres.srg.af.mil> Well after much tinkering here two (tested!) alternatives for dealing with the export problem. Both are implemented entirely with builtins, as indeed they must be, when the enviroment reachs the size where only rc can handle it. ;-) Note that like the orginals these are setup so that you can give them multiple names (e.g. "fn clean_env gmake gcc sh { ...") and they will transparently run the commands with their environments reduced as specified. Each has it's appropriate domain, "clean_env" is easy to use and very thorough but relatively slow. It's not something to run an external command in the inner most loop of a script with. On the other hand strip_env is much faster and simpler, but listing every variable and function to be "unexported" is tedious and messy. Maybe we should put together a FAQ to be sent to new subscribers to the mailing list and eventually distributed with future releases with hints like Chris's prompt trick, and examples like this. I've had to rediscover a bunch of things that "everyone knows" or "we figured out months ago". ------------------------------------------------------------------------------ #!/bin/rc # This code can be fooled by really pathological cases involving embedded # newlines followed by either 'fn ' or '='. Fixing this is left as an # exercise for the reader. ;-) It's already pretty slow. # Usage: clean_env # Only "exported" variables will be passed through exported=() fn export { exported=($exported $*) } fn clean_env { _i=() _n=() _x=() @{ _x=($exported _i _n _x '*') for (_i in `` ($nl) {whatis}) { if (~ $_i 'fn '*) { _n=`` (' ') {echo $_i} fn $_n(2) } else if (~ $_i *'='*) { _n=`` ('=') {echo $_i} if (! ~ $_n(1) $_x) { $_n(1)=() } } } _i=(); _n=(); _x=(); fn clean_env if (~ $0 clean_env) { exec $* } else { exec builtin $0 $* } }} # You can also do it this way, which is MUCH faster, but specifying all # the things to unexport can be a royal pain in the butt. This is # definitely the way to go if the function has to be invoked inside of a # loop. You can also fiddle clean_env above into a function to build the # unexported list. # Usage: strip_env # Variables and functions which are "unexported" will be removed from # the environment before the command is executed unexported=() fn unexport { unexported=($unexported $*) } fn strip_env { _i=() @{ for (_i in $unexported) { $_i=() fn $_i } if (~ $0 strip_env) { exec $* } else { exec builtin $0 $* } }} From rc-owner Sun Jun 28 15:55:45 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by hawkwind.utcs.toro nto.edu with SMTP id <2624>; Sun, 28 Jun 1992 15:54:16 -0400 Received: by doolittle.vetsci.su.oz.au id <49162>; Mon, 29 Jun 1992 05:53:46 +1 000 From: John (_You_ hide, they seek.) Mackin Date: Sun, 28 Jun 1992 15:47:44 -0400 To: The rc Mailing List Subject: Re: recent -s patch In-Reply-To: <92Jun26.001135edt.2536@groucho.cs.psu.edu> Message-ID: <199206290547.18427.rc.balez@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ From: Scott Schwartz I don't think -s should imply -i, as the patch does. If I want both I can type both. Is -s going to be standard, or will most people decline to apply the patch? Scott and all, I don't have a lot of time now, and have more mail to write yet, so please forgive me if I am a little terse. The point of -s is not `how should it work', but rather `how -must- it work'. No one wants to add -s to rc just because they think it's a good idea. They want (in some cases, need) to add -s to rc _in order to be compatible with the de-facto standard for command line arguments to UNIX shells_. That's the point. This is how the -s argument works in sh and csh, and therefore, if rc is to have a -s argument at all, this is how it MUST work in rc. Personally, I have no need for -s and don't care whether it is in or out: but if it is to be in, I insist that it work just as it does in other shells. Equally, rc cannot define new semantics for -c or -e, etc. I hope that's clear. OK, John. From rc-owner Sun Jun 28 16:16:26 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by hawkwind.utcs.toro nto.edu with SMTP id <2720>; Sun, 28 Jun 1992 16:15:53 -0400 Received: by doolittle.vetsci.su.oz.au id <49162>; Mon, 29 Jun 1992 06:15:34 +1 000 From: John (_You_ hide, they seek.) Mackin Date: Sun, 28 Jun 1992 16:00:25 -0400 To: The rc Mailing List Subject: rc initialisation Message-ID: <199206290600.18625.rc.balid@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ A file of rc tricks would be a good idea, especially since everyone seems to have forgotten one of my favourites. Chris's suggestion for getting initialisation to happen on every new interactive rc is: fn prompt { if (! ~ $cpid $pid) {cpid=$pid; ... } } This code is correct, but I think that most of the time this is not what you want. The original poster was looking for a way to get an stty to happen when they fired off a new xterm. If you use this method, then the stty will happen not only at the very beginning of the xterm, but every time a new interactive rc is spawned in the xterm. My counter-proposal is: fn prompt { do the initialisation; fn prompt } This differs from Chris's in that the initialisation is definitely only executed -once-, and in that the prompt function doesn't hang around to clutter the environment and slow your shells down. I think that in the huge majority of cases, these differences will be advantages. For a concrete example, here's the file in $home/bin that spawns my window manager: #!/home/john/bin/rc fn prompt { stty new fn prompt } pathos $0 $* On other matters mentioned recently, very briefly: (1) Chris is 100% correct in his statement that no changes need be made to rc to deal with any initialisation at all, with the possible exception of rsh; and also 100% correct that we shouldn't try to change rc to `work around' rsh. (If we're sufficiently clever we can get rsh to work right most of the time, I think.). (2) Don't even THINK about making all rc's source .rcrc. If we want that kind of braindeath, we can use zsh. The whole point of the way rc works is that subshells -are- completely initialised from the environment. OK, John. From rc-owner Sun Jun 28 16:36:24 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2703>; Sun, 28 Jun 1992 16:35:50 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Sun, 28 Jun 1992 16:35:16 -0400 To: John Mackin (_You_ hide, they seek.) cc: The rc Mailing List Subject: Re: recent -s patch In-reply-to: Your message of "Sun, 28 Jun 92 15:47:44 EDT." <199206290547.18427.rc.balez@vetsci.su.oz.au> Date: Sun, 28 Jun 1992 16:34:49 -0400 From: Scott Schwartz Message-Id: <92Jun28.163516edt.2538@groucho.cs.psu.edu> | Personally, I have no need for -s and don't care whether it is | in or out: but if it is to be in, I insist that it work just as | it does in other shells. Yes, I quite agree. I didn't mention it before, but in csh and sh -s does not imply -i. The current patch for rc does the wrong thing. From rc-owner Sun Jun 28 17:07:57 1992 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by hawkwind.utcs.toro nto.edu with SMTP id <2718>; Sun, 28 Jun 1992 17:07:26 -0400 Received: by doolittle.vetsci.su.oz.au id <49162>; Mon, 29 Jun 1992 07:06:54 +1 000 From: John (_You_ hide, they seek.) Mackin Date: Sun, 28 Jun 1992 17:01:19 -0400 To: The rc Mailing List Subject: Re: recent -s patch In-Reply-To: <92Jun28.163516edt.2538@groucho.cs.psu.edu> Message-ID: <199206290701.19089.rc.balij@vetsci.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Scott is quite right. Just goes to show how little I've ever understood that damned -s option anyway. Someone who cares about it should fix the patch so that -s doesn't imply -i. Hey, can anyone on the list tell us all if they have any reason at all for wanting -s? Inquiring minds want to know. So far, we have Rich's reason, which is that -s is passed to the invoked shell by `the OSF/1 script command'. Any other takers? To put it another way, can anyone show me any real use for -s? That is, why is the damned idea good? Try as I might I can't see any. (This shouldn't be construed as an argument for keeping it out of rc. To the contrary, I will always be willing to entertain rc features that keep it compatible (in appropriate ways) with traditional shells.) OK, John. From rc-owner Sun Jun 28 19:35:41 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2624>; Sun, 28 Jun 1992 19:35:06 -0400 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMT P id <45316>; Sun, 28 Jun 1992 18:34:45 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Sun, 28 Jun 1992 19:34:00 -0400 To: rc@archone.tamu.edu Subject: "whatis" fails to preserve read/write invariance Date: Sun, 28 Jun 1992 19:33:36 -0400 From: Scott Schwartz Message-Id: <92Jun28.193400edt.2538@groucho.cs.psu.edu> The great thing about lisp is that read and write are complementary. Rc is pretty good about that, but not perfect. Consider this: ; touch 'x=foo' ; chmod +x 'x=foo' ; './x'=foo ; whatis './x' ./x=foo ; whatis './x=foo' ./x=foo Tricked! In lisp the equals sign in the filename would have been quoted, like the metacharacter it is. In rc there is no user level read primative, so you can't do that. From rc-owner Sun Jun 28 21:42:28 1992 Received: from yonge.csri.toronto.edu ([128.100.1.2]) by hawkwind.utcs.toronto. edu with SMTP id <2624>; Sun, 28 Jun 1992 21:41:39 -0400 Received: from scocan by yonge.csri.toronto.edu with UUCP id <4975>; Sun, 28 Ju n 1992 21:41:21 -0400 Received: from imp.scocan.sco.COM by scocan.scocan.sco.COM id aa16034; 28 Jun 92 21:36 EDT To: John Mackin (_You_ hide, they seek.) Cc: The rc Mailing List Subject: Re: recent -s patch Date: Sun, 28 Jun 1992 21:36:55 -0400 From: Bob Gibson Message-ID: <9206282136.aa02955@imp.scocan.sco.COM> | Hey, can anyone on the list tell us | all if they have any reason at all for wanting -s? Inquiring minds | want to know. So far, we have Rich's reason, which is that -s is | passed to the invoked shell by `the OSF/1 script command'. Any | other takers? My editor, jove, starts up subshells with the -s option, and obviously fails to do so if the shell doesn't support it. In this case, the correct thing to do would be to fix jove to make this configurable. But if others have a need to add -s to rc, it would save me a bit of work. I realize this is a pretty lame reason for adding a new feature so I won't try to defend it. Then again, you now have two applications which rely on the shell supporting -s. I wonder how many more exist. From rc-owner Mon Jun 29 18:24:54 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2720>; Mon, 29 Jun 1992 18:22:57 -0400 To: The rc Mailing List Subject: Re: rc initialisation In-reply-to: john's message of Sun, 28 Jun 92 16:00:25 -0400. <199206290600.18625.rc.balid@vetsci.su.oz.au> Date: Mon, 29 Jun 1992 18:22:43 -0400 From: Chris Siebenmann Message-Id: <92Jun29.182257edt.2720@hawkwind.utcs.toronto.edu> | fn prompt { do the initialisation; fn prompt } The problem with this for me is that I can start up windows from within other windows, so my prompt function has to stick around. I do something similar to $cpid for xterm windows, where I can check $WINDOW; I've taught everything else to get the stty settings right without help (:)). - cks From rc-owner Mon Jun 29 19:38:50 1992 Received: from mail.uunet.ca ([142.77.1.1]) by hawkwind.utcs.toronto.edu with S MTP id <2721>; Mon, 29 Jun 1992 19:37:29 -0400 Received: from xenitec.on.ca ([192.75.213.1]) by mail.uunet.ca with SMTP id <99 39>; Mon, 29 Jun 1992 19:37:18 -0400 Received: from golem by xenitec.xenitec.on.ca id aa12830; 29 Jun 92 19:34 EDT To: Bob Gibson cc: The rc Mailing List Subject: Re: recent -s patch In-reply-to: Your message of "Sun, 28 Jun 92 21:36:55 EDT." <9206282136.aa02955@imp.scocan.sco.COM> Date: Mon, 29 Jun 1992 19:19:22 -0400 From: "David J. Fiander" Message-ID: <9206291919.aa27683@golem.UUCP> >From: Bob Gibson >| Hey, can anyone on the list tell us >| all if they have any reason at all for wanting -s? Inquiring minds >| want to know. So far, we have Rich's reason, which is that -s is >| passed to the invoked shell by `the OSF/1 script command'. Any >| other takers? > >My editor, jove, starts up subshells with the -s option, and obviously >fails to do so if the shell doesn't support it. In this case, the >correct thing to do would be to fix jove to make this configurable. The reason that jove does this is because is starts the shell with either its command line arguments or the file names associated with its buffers as arguments to the shell. That is, is says $SHELL -s file1 file2 file3 This way you can easily refer to the files you are editting in your subshell. It would be nice if this feature was documented, though. - David From rc-owner Tue Jun 30 04:22:09 1992 Received: from yonge.csri.toronto.edu ([128.100.1.2]) by hawkwind.utcs.toronto. edu with SMTP id <2756>; Tue, 30 Jun 1992 04:21:07 -0400 Received: from redvax by yonge.csri.toronto.edu with UUCP id <5007>; Tue, 30 Ju n 1992 04:21:01 -0400 Received: by redvax.mimosa.com (4.0/SMI-4.0) id AA09921; Tue, 30 Jun 92 02:55:40 EDT Date: Tue, 30 Jun 1992 02:55:40 -0400 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <9206300655.AA09921@redvax.mimosa.com> To: rc@hawkwind.utcs.toronto.edu Subject: -s flag | From: John (_You_ hide, they seek.) Mackin | | Hey, can anyone on the list tell us | all if they have any reason at all for wanting -s? Inquiring minds | want to know. | | ... I will always be willing to entertain rc features | that keep it compatible (in appropriate ways) with traditional shells. | From: Bob Gibson | | My editor, jove, starts up subshells with the -s option, and obviously | fails to do so if the shell doesn't support it. In this case, the | correct thing to do would be to fix jove to make this configurable. I am the person who made JOVE invoke subshells with the -s flag. I did it in about 1984, so I have forgotten some of the subtle details. I will try to reconstruct them. First, a hint from SunOS 4.0.3 sh(1): -s If the -s option is present or if no argu- ments remain commands are read from the stan- dard input. Any remaining arguments specify the positional parameters. Shell output (except for Special Commands) is written to file descriptor 2. Actually, the story goes back to about about 1976, when I was hacking on ed(1). I changed the ! command so that the shell command was invoked in such a way that the current file could be referred to as $1. This was extremely convenient. !cp -p $1 $1.BAK !chmod u+w $1 !pr $1 | lpr !diff $1.BAK $1 When I started hacking on JOVE, I naturally wanted this feature too. The only way that I could get it to work with csh and and all versions of sh was to throw in the -s. [I don't remember which failed without the -s] I want to keep using this feature. I don't want to hack JOVE to allow the suppression of the -s for rc. I think it is better to hack rc to accept -s like other UNIX shells. Hugh Redelmeier hugh@mimosa.com or {utcsri, uunet!attcan, utzoo, scocan}!redvax!hugh When all else fails: hugh@csri.toronto.edu +1 416 482-8253 From rc-owner Tue Jun 30 09:55:53 1992 Received: from natalie.ibmpcug.co.uk ([192.68.174.66]) by hawkwind.utcs.toronto .edu with SMTP id <2703>; Tue, 30 Jun 1992 09:52:57 -0400 Received: by natalie.ibmpcug.co.uk id aa13821; 30 Jun 92 14:48 BST Received: from kate.ibmpcug.co.uk by natalie.ibmpcug.co.uk id aa10439; 30 Jun 92 9:34 BST X-Phone-Work: +44 81 863-1191 X-Fax-Work: +44 81 863-6095 X-Favourite-Colour: black, of course. Newsgroups: list.rc In-Reply-To: <9206300655.AA09921@redvax.mimosa.com> Organization: The IBM PC User Group, UK. X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: hugh@mimosa.com Subject: Re: -s flag Cc: rc@hawkwind.utcs.toronto.edu Date: Tue, 30 Jun 1992 04:26:46 -0400 From: Matthew Farwell Sender: dylan@ibmpcug.co.uk Message-ID: <9206300926.aa22582@kate.ibmpcug.co.uk> In article <9206300655.AA09921@redvax.mimosa.com> you write: >| From: John (_You_ hide, they seek.) Mackin >| Hey, can anyone on the list tell us >| all if they have any reason at all for wanting -s? Inquiring minds >| want to know. >| >| ... I will always be willing to entertain rc features >| that keep it compatible (in appropriate ways) with traditional shells. > >| From: Bob Gibson >| >| My editor, jove, starts up subshells with the -s option, and obviously >| fails to do so if the shell doesn't support it. In this case, the >| correct thing to do would be to fix jove to make this configurable. > >I am the person who made JOVE invoke subshells with the -s flag. I >did it in about 1984, so I have forgotten some of the subtle >details. I will try to reconstruct them. > >First, a hint from SunOS 4.0.3 sh(1): > > -s If the -s option is present or if no argu- > ments remain commands are read from the stan- > dard input. Any remaining arguments specify > the positional parameters. Shell output > (except for Special Commands) is written to > file descriptor 2. > >Actually, the story goes back to about about 1976, when I was >hacking on ed(1). I changed the ! command so that the shell command >was invoked in such a way that the current file could be referred to >as $1. This was extremely convenient. > !cp -p $1 $1.BAK > !chmod u+w $1 > !pr $1 | lpr > !diff $1.BAK $1 > >When I started hacking on JOVE, I naturally wanted this feature >too. The only way that I could get it to work with csh and and all >versions of sh was to throw in the -s. [I don't remember which >failed without the -s] > >I want to keep using this feature. I don't want to hack JOVE to >allow the suppression of the -s for rc. I think it is better to >hack rc to accept -s like other UNIX shells. It's a lot better to fix Jove than to 'fix' rc. You could do this like vi/ex does it. If I execute a subshell command in vi, then any % is replaced by the current filename, ie :!mv % %.bak would be expanded to :!mv foo foo.bak etc. This is a lot better than hacking a kludge into rc for the sake of one editor. Dylan. -- It is no coincidence that in no known language does the phrase 'As pretty as an Airport' appear -- Douglas Adams From rc-owner Tue Jun 30 11:30:00 1992 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.to ronto.edu with SMTP id <2688>; Tue, 30 Jun 1992 11:29:13 -0400 Received: by mail-relay-1.mv.us.adobe.com; id AA04227; Tue, 30 Jun 92 08:28:55 -0700 Received: from utopia.adobe.com by adobe.com (4.1/SMI-4.1) id AA16036; Tue, 30 Jun 92 08:28:53 PDT Received: by utopia.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA11747; Tue, 30 Jun 92 08:29:58 PDT Date: Tue, 30 Jun 1992 11:29:58 -0400 From: haahr@adobe.com Message-Id: <9206301529.AA11747@utopia.adobe.com> To: dylan@ibmpcug.co.uk Subject: Re: -s flag Cc: rc@hawkwind.utcs.toronto.edu > It's a lot better to fix Jove than to 'fix' rc. You could do this like > vi/ex does it. If I execute a subshell command in vi, then any % is > replaced by the current filename, ie > :!mv % %.bak > would be expanded to > :!mv foo foo.bak > etc. This is a lot better than hacking a kludge into rc for the sake of > one editor. i disagree vehemently. shell variable subsitution is a much better defined mechanism than vi's subtituting for %. (e.g., how do you quote %? what if you invoked vi without a filename?) in general, i take issue with any program blindly editing input that the user has typed for another program, even if that other program is a shell. now, one could make the argument that the file should be stored in an environment variable, e.g. $file, and if every editor were coerced to use rc's notion of control-a separated lists, that would even work for multiple files. but $n is a logical place to put the file names, and has no other conventional meaning for subshells invoked from editors. even before Hugh posted his explaination on why jove does what it does, i tended to agree with John that rc should support -s with the same meaning as sh's -s, because it has evolved as a convention among shells, part of the standard options set, like -c and -e. now i'm convinced. paul From rc-owner Tue Jun 30 11:42:15 1992 Received: from yonge.csri.toronto.edu ([128.100.1.2]) by hawkwind.utcs.toronto. edu with SMTP id <2744>; Tue, 30 Jun 1992 11:41:37 -0400 Received: from redvax by yonge.csri.toronto.edu with UUCP id <5029>; Tue, 30 Ju n 1992 11:41:16 -0400 Received: by redvax.mimosa.com (4.0/SMI-4.0) id AA10123; Tue, 30 Jun 92 11:03:42 EDT Date: Tue, 30 Jun 1992 11:03:42 -0400 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <9206301503.AA10123@redvax.mimosa.com> To: dylan@ibmpcug.co.uk, davidf@golem.uucp Subject: Re: -s flag Cc: rc@hawkwind.utcs.toronto.edu | From: Matthew Farwell | | It's a lot better to fix Jove than to 'fix' rc. You could do this like | vi/ex does it. If I execute a subshell command in vi, then any % is | replaced by the current filename, ie | | :!mv % %.bak This is not better for a couple of reasons. The first is that we are talking about an interractive shell, taking over the tty for its command input. For JOVE to do % replacement, it would have to do the command input and feed the shell through a PTY or something. Ugh! The second is that it would be yet another level of magic processing of the command. $1 already has a meaning to the shell, and the shell can determine by its own rules (scope, quoting, etc.) when the substitution is appropriate. | From: "David J. Fiander" | | It would be nice if this feature was documented, though. True. I have just updated the JOVE documentation. Hugh Redelmeier hugh@mimosa.com or {utcsri, uunet!attcan, utzoo, scocan}!redvax!hugh When all else fails: hugh@csri.toronto.edu +1 416 482-8253 From rc-owner Wed Jul 1 09:30:45 1992 Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by hawkwind.utcs.toronto .edu with SMTP id <2624>; Wed, 1 Jul 1992 09:27:56 -0400 Via: uk.ac.newcastle; Wed, 1 Jul 1992 14:27:01 +0100 Received: from ncl.bygate (bygate.ncl.ac.uk) by ncl.ac.uk; Wed, 1 Jul 1992 13:52:50 +0100 From: Gerry.Tomlinson@newcastle.ac.uk Message-Id: Subject: Re: -s flag To: rc@hawkwind.utcs.toronto.edu Date: Wed, 1 Jul 1992 08:52:48 -0400 In-Reply-To: <9206301529.AA11747@utopia.adobe.com>; from "haahr@com.adobe" at J un 30, 92 4:42 pm X-Mailer: ELM [version 2.3 PL11] > > > It's a lot better to fix Jove than to 'fix' rc. You could do this like > > vi/ex does it. If I execute a subshell command in vi, then any % is > > replaced by the current filename, ie > > :!mv % %.bak > > would be expanded to > > :!mv foo foo.bak > > etc. This is a lot better than hacking a kludge into rc for the sake of > > one editor. > > i disagree vehemently. shell variable subsitution is a much better defined > mechanism than vi's subtituting for %. (e.g., how do you quote %? what if > you invoked vi without a filename?) in general, i take issue with any > program blindly editing input that the user has typed for another program, > even if that other program is a shell. > > now, one could make the argument that the file should be stored in an > environment variable, e.g. $file, and if every editor were coerced to > use rc's notion of control-a separated lists, that would even work for > multiple files. but $n is a logical place to put the file names, and > has no other conventional meaning for subshells invoked from editors. > I've been thinking how to reference filenames from shell escapes in my X file display program xp (export.lcs.mit.edu:contrib/xp-1.1.tar.Z). I originally adopted the vi % mechanism, simply using system or popen to execute the command after expanding any %'s, however I was never very happy with this 'cos of the quoting problem & the lack of generalisation. My development version does its own "system" thereby respecting $SHELL so I can use all my rc functions. If instead I execed $SHELL -s with the command line as stdin, with the filenames as the arguments, and set the environment variable i to be that of the current file, then one could reference all files with $*, numbered files with $n, and the current file with $i, without xp having to touch the user's input. Much nicer I think. Until this discussion started I wasn't even aware of the -s option. When did it first appear? I have a V8 manual to hand and it's in there - does anyone know if it's in Tom Duff's rc? Gerry. Gerry.Tomlinson@newcastle.ac.uk Computing Laboratory, The University, Newcastle upon Tyne, UK, NE1 7RU Tel: +44 091 222 8139 From rc-owner Wed Jul 1 15:14:28 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2663>; Wed, 1 Jul 1992 15:13:28 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA08985; Wed, 1 Jul 92 15:13:11 -0400 Received: by earth.osf.org (5.64/4.7) id AA00693; Wed, 1 Jul 92 15:13:11 -0400 Date: Wed, 1 Jul 1992 15:13:11 -0400 From: rsalz@osf.org Message-Id: <9207011913.AA00693@earth.osf.org> To: rc@hawkwind.utcs.toronto.edu Subject: rc and rsh I don't think I understand the problems people are having with rsh and rc. Does this function do the 'right thing' ? fn rsh host1 host2... { flag= host=$0 { ~ $1 -n && { shift ; flag=-n } ~ $0 rsh && { host=$1 ; shift } eval 'rsh $flag $host rc -lc ''' ^ $* ^ '''' } } From rc-owner Wed Jul 1 16:50:33 1992 Received: from milton.u.washington.edu ([128.95.136.1]) by hawkwind.utcs.toront o.edu with SMTP id <2721>; Wed, 1 Jul 1992 16:49:11 -0400 Received: by milton.u.washington.edu (5.65/UW-NDC Revision: 2.22 ) id AA15956; Wed, 1 Jul 92 13:49:03 -0700 Date: Wed, 1 Jul 1992 16:49:03 -0400 From: Donn Cave Message-Id: <9207012049.AA15956@milton.u.washington.edu> Sender: donn@milton.u.washington.edu To: rc@hawkwind.utcs.toronto.edu Subject: Re: rc and rsh | I don't think I understand the problems people are having with rsh and rc. | Does this function do the 'right thing' ? | fn rsh host1 host2... { flag= host=$0 { | ~ $1 -n && { shift ; flag=-n } | ~ $0 rsh && { host=$1 ; shift } | eval 'rsh $flag $host rc -lc ''' ^ $* ^ '''' | } } Well, I can't resist pointing out that there are some implementation details involving quotes. That's supposed to be one of the reasons we like rc, right? Easy, straightforward quoting! Someone who knows the language better than I maybe can straighten this one out so that it doesn't require the user to quote the remote command (I think this is just a matter of discarding the "^"s), and so that the eventual rc -lc actually does get a quoted string. But then, what happens when you use this? ; rsh wherever do something rc not found ; /usr/ucb/rsh wherever whatis path path=('' /usr/ucb /bin /usr/bin) ; rlogin wherever welcome to wherever ; whatis rc /usr/local/bin/rc Not that there aren't ways to work around the problem. Some of them made it onto this list recently, and the most workable of them involved invoking rc differently from /etc/passwd - either as "-rc", or a script that invokes "rc -l". Donn Cave, University Computing Services, University of Washington donn@cac.washington.edu From rc-owner Wed Jul 1 16:59:17 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2703>; Wed, 1 Jul 1992 16:58:20 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA13932; Wed, 1 Jul 92 16:58:18 -0400 Received: by earth.osf.org (5.64/4.7) id AA01093; Wed, 1 Jul 92 16:58:17 -0400 Date: Wed, 1 Jul 1992 16:58:17 -0400 From: rsalz@osf.org Message-Id: <9207012058.AA01093@earth.osf.org> To: donn@u.washington.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: rc and rsh Yeah, fixing the quotes is an exercise for the reader ... >But then, what happens when you use this? > > ; rsh wherever do something > rc not found It seemed to me most of the problems were getting rc to read .rcrc or some other init file at the right time, so this case isn't interesting. /r$ From rc-owner Wed Jul 1 17:01:27 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2724>; Wed, 1 Jul 1992 17:00:37 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Wed, 1 Jul 1992 17:00:00 -0400 To: rsalz@osf.org cc: rc@hawkwind.utcs.toronto.edu Subject: Re: rc and rsh In-reply-to: Your message of "Wed, 01 Jul 92 15:13:11 EDT." <9207011913.AA00693@earth.osf.org> Date: Wed, 1 Jul 1992 16:59:30 -0400 From: Scott Schwartz Message-Id: <92Jul1.170000edt.2538@groucho.cs.psu.edu> | I don't think I understand the problems people are having with rsh and rc. | Does this function do the 'right thing' ? | fn rsh host1 host2... { flag= host=$0 { | ~ $1 -n && { shift ; flag=-n } | ~ $0 rsh && { host=$1 ; shift } | eval 'rsh $flag $host rc -lc ''' ^ $* ^ '''' | } } One (general) problem is that rsh leaves open file descriptors hanging around in its child processes. The solution I posted takes care to close them so that if you ask for 'xterm&' the rshd exits cleanly. From rc-owner Wed Jul 1 17:15:30 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2690>; Wed, 1 Jul 1992 17:14:31 -0400 To: rc Subject: Re: -s flag In-reply-to: Gerry.Tomlinson's message of Wed, 01 Jul 92 08:52:48 -0400. Date: Wed, 1 Jul 1992 17:14:26 -0400 From: Chris Siebenmann Message-Id: <92Jul1.171431edt.2690@hawkwind.utcs.toronto.edu> Duff's rc doesn't seem to have a -s flag, at least not one that means what it means to sh and csh. - cks From rc-owner Wed Jul 1 17:32:44 1992 Received: from yonge.csri.toronto.edu ([128.100.1.2]) by hawkwind.utcs.toronto. edu with SMTP id <2718>; Wed, 1 Jul 1992 17:31:52 -0400 Received: from redvax by yonge.csri.toronto.edu with UUCP id <5046>; Wed, 1 Jul 1992 17:31:29 -0400 Received: by redvax.mimosa.com (4.0/SMI-4.0) id AA10806; Wed, 1 Jul 92 17:30:14 EDT Date: Wed, 1 Jul 1992 17:30:14 -0400 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <9207012130.AA10806@redvax.mimosa.com> To: Gerry.Tomlinson@newcastle.ac.uk, rc@hawkwind.utcs.toronto.edu Subject: Re: -s flag | respecting $SHELL so I can use all my rc functions. If instead I execed | $SHELL -s with the command line as stdin, with the filenames as the | arguments, and set the environment variable i to be that of the current | file, then one could reference all files with $*, numbered files with $n, | and the current file with $i, without xp having to touch the user's | input. Much nicer I think. I suspect that you would be better off using -c. It too allows passing parameters to the command. That way you need not fool with stdin. As a matter of taste, I have misgivings about taking over $i. It is a variable name that I frequently use in scripts. That is the beauty of $1 etc.: those names were already reserved for this mechanism. Of course, $current is a bit tiresome to type. Unfortunately, the positional parameters after -c or -s are not treated the same in different shells (at least under SunOS4.0.3): $ sh -c 'echo $*' one two two $ sh -c 'echo $0 $1' one two one two $ csh -c 'echo $*' one two one two $ csh -c 'echo $0 $1' one two No file for $0. $ rc -c 'echo $*' one two one two $ rc -c 'echo $0 $1' one two rc one [This is an old version of rc; it may have changed.] $ sh -si one two $ echo $* one two $ echo $0 $1 sh one $ exit $ csh -si one two redvax% echo $* one two redvax% echo $0 $1 No file for $0. redvax% exit $ rc -si one two rc: illegal option -- s $ rc -i one two one: No such file or directory For portability reasons, I only promise to set $1, and I do so by passing two copies of the string as positional parameters. Hugh Redelmeier hugh@mimosa.com or {utcsri, uunet!attcan, utzoo, scocan}!redvax!hugh When all else fails: hugh@csri.toronto.edu +1 416 482-8253 From rc-owner Thu Jul 2 08:54:17 1992 Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by hawkwind.utcs.toronto .edu with SMTP id <2664>; Thu, 2 Jul 1992 08:53:00 -0400 Via: uk.ac.newcastle; Thu, 2 Jul 1992 13:52:25 +0100 Received: from ncl.bygate (bygate.ncl.ac.uk) by ncl.ac.uk; Thu, 2 Jul 1992 13:52:22 +0100 From: Gerry.Tomlinson@newcastle.ac.uk Message-Id: Subject: Re: -s flag To: rc@hawkwind.utcs.toronto.edu Date: Thu, 2 Jul 1992 08:52:21 -0400 In-Reply-To: <9207012130.AA10806@redvax.mimosa.com>; from "D._Hugh_Redelmeier" at Jul 1, 92 10:37 pm X-Mailer: ELM [version 2.3 PL11] > > | respecting $SHELL so I can use all my rc functions. If instead I execed > | $SHELL -s with the command line as stdin, with the filenames as the > | arguments, and set the environment variable i to be that of the current > | file, then one could reference all files with $*, numbered files with $n, > | and the current file with $i, without xp having to touch the user's > | input. Much nicer I think. > > I suspect that you would be better off using -c. It too allows > passing parameters to the command. That way you need not fool with > stdin. > yes, if all shells did the same with -c. > As a matter of taste, I have misgivings about taking over $i. It is > a variable name that I frequently use in scripts. That is the > beauty of $1 etc.: those names were already reserved for this > mechanism. Of course, $current is a bit tiresome to type. > being an X program I'd make the variable name a resource so you can chose your own, but won't any clash only occur in functions which don't redeclare the variable locally? > Unfortunately, the positional parameters after -c or -s are not > treated the same in different shells (at least under SunOS4.0.3): > and it's different again on bash and I suspect other shells - on On various machines I have access to I find: ; rc -c 'echo $*' one two one two ; ash -c 'echo $*' one two one two ; csh -c 'echo $*' one two one two ; ksh -c 'echo $*' one two one two ; sh -c 'echo $*' one two two ; bash -c 'echo $*' one two ; back to -s, matty@cs.su.OZ.AU mailed me the Plan 9 manual entry for rc: > Invocation > If rc is started with no arguments it reads commands from > standard input. Otherwise its first non-flag argument is > the name of a file from which to read commands (but see -c > below). Subsequent arguments become the initial value of > $*. Rc accepts the following command-line flags. > -c string Commands are read from string. > -s Print out exit status after any command where the > status is non-null. > -e Exit if $status is non-null after executing a > simple command. > -i If -i is present, or rc is given no arguments and > its standard input is a terminal, it runs inter- > actively. Commands are prompted for using > $prompt. > -I Makes sure rc is not run interactively. > -l If -l is given or the first character of argument > zero is -, rc reads commands from > $home/lib/profile, if it exists, before reading > > Page 8 Plan 9 (printed 7/2/92) > > RC(1) RC(1) > > its normal input. > -p A no-op. > -d A no-op. > -v Echo input on file descriptor 2 as it is read. > -x Print each simple command before executing it. > -r Print debugging information (internal form of > commands as they are executed). > > So, at least the version of rc we are using does not use the -s flag in > the manner of recent discussion. You can post this to the rc group if > you feel people would be interested. > > Matty. seems like you can't win :-(, Gerry. Gerry.Tomlinson@newcastle.ac.uk Computing Laboratory, The University, Newcastle upon Tyne, UK, NE1 7RU Tel: +44 091 222 8139 From rc-owner Thu Jul 2 10:09:43 1992 Received: from odin.INS.CWRU.Edu ([129.22.8.102]) by hawkwind.utcs.toronto.edu with SMTP id <2689>; Thu, 2 Jul 1992 10:08:25 -0400 Received: by odin.INS.CWRU.Edu (5.65b+ida+/CWRU-1.5-ins) id AA16091; Thu, 2 Jul 92 10:07:38 -0400 (from chet for rc@hawkwind.utc s.toronto.edu) Date: Thu, 2 Jul 1992 10:03:11 -0400 From: Chet Ramey To: Gerry.Tomlinson@newcastle.ac.uk Subject: Re: -s flag Cc: rc@hawkwind.utcs.toronto.edu Reply-To: chet@po.CWRU.Edu In-Reply-To: Message from Gerry.Tomlinson@newcastle.ac.uk of Thu, 2 Jul 1992 08 :52:21 -0400 Message-Id: <9207021403.AA15986.SM@odin.INS.CWRU.Edu> Read-Receipt-To: chet@po.CWRU.Edu > ; rc -c 'echo $*' one two > one two > ; ash -c 'echo $*' one two > one two > ; csh -c 'echo $*' one two > one two > ; ksh -c 'echo $*' one two > one two > ; sh -c 'echo $*' one two > two > ; bash -c 'echo $*' one two > > ; This must be an old version of bash; my latest version gives odin(2)$ ./bash -c 'echo $*' one two one two In any event, the standard seems to support the current rc behavior. I don't think you should worry about changing it. Chet -- ``The use of history as therapy means the corruption of history as history.'' -- Arthur Schlesinger Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu From rc-owner Mon Jul 6 00:32:46 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2663>; Mon, 6 Jul 1992 00:31:01 -0400 Received: by groucho.cs.psu.edu id <2563>; Mon, 6 Jul 1992 00:29:54 -0400 From: Scott Schwartz To: rc@hawkwind.utcs.toronto.edu Subject: fun with history Message-Id: <92Jul6.002954edt.2563@groucho.cs.psu.edu> Date: Mon, 6 Jul 1992 00:29:46 -0400 ; @- # more fun than alt.cascade From rc-owner Wed Jul 8 11:46:57 1992 Received: from plg.waterloo.edu ([129.97.140.10]) by hawkwind.utcs.toronto.edu with SMTP id <2699>; Wed, 8 Jul 1992 11:44:30 -0400 Received: by plg.waterloo.edu id <29114>; Wed, 8 Jul 1992 11:44:03 -0400 From: Dave Mason To: The rc Mailing List Subject: getting rc to RISC/0S 4.0 Message-Id: <92Jul8.114403edt.29114@plg.waterloo.edu> Date: Wed, 8 Jul 1992 11:43:54 -0400 Has anybody compiled it successfully on this older version of the OS? This is rc v1.4beta (Where is the latest & greatest?) compiled without the editline stuff. I've been running this version (with editline) on a Sun 4 since it came out, but I haven't poked around the sources much. Thanks ../Dave I ``unproto''ed it, compiled (with warnings about SIG_DFL, etc. being the wrong type: ccom: Warning: walk.c, line 352: illegal pointer combination if (intr && handler != (int (*)())1) -------------------------------------^ ). I seem to get different behaviour when I compile it optimized or debugged! With: CC=cc -systype bsd43 -tp -h./unproto -B -Dconst= -O oak:mason> dbx rc dbx version 2.11 Copyright 1988, 1989 MIPS Computer Systems Inc. Type 'help' for help. reading symbolic information ... [using main.main] main: 15 initprint(); (dbx) run rc panic: unexpected node in treecpy! Program exited with code 1 With: CC=cc -systype bsd43 -tp -h./unproto -B -Dconst= -O oak:mason> dbx rc dbx version 2.11 Copyright 1988, 1989 MIPS Computer Systems Inc. Type 'help' for help. reading symbolic information ... [using main.main] main: 15 initprint(); (dbx) run echo foo Segmentation fault [glom.glom:381 +0xc,0x40508c] while (words != NULL && (words->type == nArgs || words->type == nLappend)) { (dbx) where > 0 glom.glom(0x0, 0x0, 0x0, 0x0, 0x0) ["glom.c":381, 0x40508c] 1 walk.walk(0x1, 0x0, 0x0, 0x0, 0x0) ["walk.c":36, 0x40c040] 2 doit(0x0, 0x0, 0x0, 0x0, 0x0) ["input.c":266, 0x406f6c] 3 main.main(0x7fff9f98, 0x7fff9f9c, 0x0, 0x0, 0x0) ["main.c":85, 0x4 08710] (dbx) From rc-owner Thu Jul 9 18:16:10 1992 Received: from netman.widener.edu ([192.55.239.51]) by hawkwind.utcs.toronto.ed u with SMTP id <2221>; Thu, 9 Jul 1992 18:09:15 -0400 Received: from betty.cs.widener.edu by netman.widener.edu (5.61/1.34) id AA0473 4; Thu, 9 Jul 92 18:08:27 -0400 Received: by betty.cs.widener.edu id AA00518 (5.65c/Widener-4.1 for rc mailing list ); Thu, 9 Jul 1992 18:08:57 -0400 Date: Thu, 9 Jul 1992 18:08:57 -0400 From: Brendan Kehoe Message-Id: <199207092208.AA00518@betty.cs.widener.edu> To: rc mailing list Subject: optimal scripts Reply-To: brendan@cs.widener.edu What's the fastest (most efficient) way to do something like this? for (foo in $bar) { if ( some_test $foo ) { first=($first $foo); } else { second=($second $foo); } } Brendan From rc-owner Fri Jul 10 11:36:19 1992 Received: from linc.cis.upenn.edu ([130.91.6.8]) by hawkwind.utcs.toronto.edu w ith SMTP id <2689>; Fri, 10 Jul 1992 11:29:57 -0400 Received: from SAUL.CIS.UPENN.EDU by linc.cis.upenn.edu id AA03089; Fri, 10 Jul 92 11:29:49 -0400 Return-Path: Received: from LOCALHOST.upenn.edu by saul.cis.upenn.edu id AA02086; Fri, 10 Jul 92 11:29:49 EDT Posted-Date: Fri, 10 Jul 92 11:29:48 -0400 Message-Id: <9207101529.AA02086@saul.cis.upenn.edu> To: rc mailing list Cc: mjd@central.cis.upenn.edu Subject: Y-shaped pipeline In-Reply-To: Your message of "Thu, 09 Jul 92 18:08:57 EDT." <199207092208.AA00518@betty.cs.widener.edu> Date: Fri, 10 Jul 1992 11:29:48 -0400 From: Mark-Jason Dominus I have a program, `why', which expects to write output to file descriptors 4 and 5. why >[4] descriptor-four-log >[5] descriptor-five-log works fine; the data that `why' writes to desriptor 4 winds up in `descriptor-four-log', and the data that `why' writes to descriptor 5 goes to the file `descriptor-five-log'. Now I want the descriptor 4 data to be piped into the stdin of some command, say `rev', and I want the descriptor 5 data to be piped into another command, say `cat -n'. This doesn't work: why |[4] rev |[5] cat -n because that means to connect descriptor 4 of `why' to descriptor 0 of rev, and then to connect descriptor 5 of rev to descriptor 0 of cat -n. How can I connect a command to two pipes at once? From rc-owner Fri Jul 10 12:36:13 1992 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.to ronto.edu with SMTP id <2699>; Fri, 10 Jul 1992 12:34:56 -0400 Received: by mail-relay-1.mv.us.adobe.com; id AA03437; Fri, 10 Jul 92 09:34:44 -0700 Received: from utopia.adobe.com by adobe.com (4.1/SMI-4.1) id AA11090; Fri, 10 Jul 92 09:34:42 PDT Received: by utopia.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA01337; Fri, 10 Jul 92 09:35:34 PDT Date: Fri, 10 Jul 1992 12:35:34 -0400 From: haahr@adobe.com Message-Id: <9207101635.AA01337@utopia.adobe.com> To: mjd@saul.cis.upenn.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Y-shaped pipeline { why |[4] rev } |[5] cat -n # this does mean that the stdout of rev and cat will be intermixed # and you should hope that rev doesn't put anything out on fd 5. From rc-owner Fri Jul 10 13:41:28 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2704>; Fri, 10 Jul 1992 13:40:47 -0400 Received: by groucho.cs.psu.edu id <2581>; Fri, 10 Jul 1992 13:40:12 -0400 From: Scott Schwartz To: rc@hawkwind.utcs.toronto.edu Subject: error messages Message-Id: <92Jul10.134012edt.2581@groucho.cs.psu.edu> Date: Fri, 10 Jul 1992 13:40:06 -0400 Why does rc print things like ``cannot shift'' instead of ``rc: cannot shift''? From rc-owner Fri Jul 10 18:54:50 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2712>; Fri, 10 Jul 1992 18:53:32 -0400 To: rc Subject: Re: Y-shaped pipeline In-reply-to: haahr's message of Fri, 10 Jul 92 12:35:34 -0400. <9207101635.AA01337@utopia.adobe.com> Date: Fri, 10 Jul 1992 18:53:17 -0400 From: Chris Siebenmann Message-Id: <92Jul10.185332edt.2712@hawkwind.utcs.toronto.edu> I thought the natural way to do it would be with '.... >[N]{command}', but that doesn't seem to work. A pity. Anyone care to fix things so it does? - cks From rc-owner Sat Jul 11 20:15:11 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2724>; Sat, 11 Jul 1992 20:14:04 -0400 Received: by groucho.cs.psu.edu id <2604>; Sat, 11 Jul 1992 20:13:18 -0400 From: Scott Schwartz To: rc@hawkwind.utcs.toronto.edu Subject: backquote status? Message-Id: <92Jul11.201318edt.2604@groucho.cs.psu.edu> Date: Sat, 11 Jul 1992 20:13:05 -0400 Is there any way to retrieve the status from a backquote command? It seems that assignments (like x=`false) set status=0. Is that a feature? -- Scott From rc-owner Sun Jul 12 19:03:17 1992 Received: from cortex.physiol.su.oz.au ([129.78.139.131]) by hawkwind.utcs.toro nto.edu with SMTP id <2221>; Sun, 12 Jul 1992 19:02:47 -0400 Received: by cortex.physiol.su.oz.au (5.57/Ultrix3.0-C) id AA01819; Mon, 13 Jul 92 09:02:31 +1000 From: John (_You_ hide, they seek.) Mackin Date: Sun, 12 Jul 1992 18:53:55 -0400 To: The rc Mailing List Subject: Re: backquote status? In-Reply-To: <92Jul11.201318edt.2604@groucho.cs.psu.edu> Message-Id: <199207130853.1648.rc.babap@physiol.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Is there any way to retrieve the status from a backquote command? It seems that assignments (like x=`false) set status=0. Is that a feature? We really need to put together an rc FAQ. I'll volunteer to do it, although I won't be able to start until I get myself properly established in my new job, which will take some weeks. This one has been discussed on the list at least twice already. If you look at the grammar, an assignment is a command. $status reflects the status of the last command. The "false" failed, but the assignment succeeded, so $status is correctly zero. Yes, it is a little surprising. If you want the status from the backquoted command, you can do the usual sh-style trick of putting it on a suitable fd, something like: fred = ` { false; echo $status >[1=2] } That can be elaborated as needed. In some cases, the -e command line option can be used to advantage. Also, rc will print an error message if a backquoted command exits on a signal (Byron once said he wasn't sure if that was a good feature or not -- personally I don't mind it). OK, John. From rc-owner Wed Jul 15 06:47:01 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2221>; Wed, 15 Jul 1992 06:45:14 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA19051; Wed, 15 Jul 92 12:44:47 +0200 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA28299; Wed, 15 Jul 92 12:44:45 +0200 Date: Wed, 15 Jul 1992 06:44:45 -0400 From: malte@techfak.uni-bielefeld.de Message-Id: <9207151044.AA28299@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Question about redirection Could some kind soul explain this to me ? { echo stderr >[1=2]; echo stdout } >[2=1] > /dev/null stderr { echo stderr >[1=2]; echo stdout } |[2=1] cat > /dev/null stdout Malte. From rc-owner Wed Jul 15 07:01:47 1992 Received: from ben.uknet.ac.uk ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2230>; Wed, 15 Jul 1992 07:01:29 -0400 Received: from eros.uknet.ac.uk by ben.uknet.ac.uk via UKIP with SMTP (PP) id ; Wed, 15 Jul 1992 12:00:25 +0100 Received: from localhost.uknet.ac.uk by eros.uknet.ac.uk with SMTP (PP) id <22189-0@eros.uknet.ac.uk>; Wed, 15 Jul 1992 12:00:37 +0100 To: rc@hawkwind.utcs.toronto.edu Subject: Re: Question about redirection In-reply-to: Your message of "Wed, 15 Jul 92 06:44:45 EDT." <9207151044.AA28299 @dahlie.techfak.uni-bielefeld.de> Date: Wed, 15 Jul 1992 07:00:34 -0400 From: Tim.Goodwin@uknet.ac.uk Message-Id: <92Jul15.070129edt.2230@hawkwind.utcs.toronto.edu> >Could some kind soul explain this to me ? > { echo stderr >[1=2]; echo stdout } >[2=1] > /dev/null > stderr > { echo stderr >[1=2]; echo stdout } |[2=1] cat > /dev/null > stdout > Try { echo stderr >[1=2]; echo stdout } |[2=0] cat > /dev/null [ Don't ask how long it took me to realise the mistake :-(. ] Tim. From rc-owner Thu Jul 16 06:14:41 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2221>; Thu, 16 Jul 1992 06:14:15 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA26240; Thu, 16 Jul 92 12:13:38 +0200 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA00612; Thu, 16 Jul 92 12:13:37 +0200 Date: Thu, 16 Jul 1992 06:13:37 -0400 From: malte@techfak.uni-bielefeld.de Message-Id: <9207161013.AA00612@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Question about redirection In-Reply-To: Mail from 'jutta@cs.tu-berlin.de' dated: Thu, 16 Jul 92 2:02:48 MET DST I'm sorry for not being precise with my question. What I want to know is why { echo stderr >[1=2]; echo stdout } >[2=1] > /dev/null and { echo stderr >[1=2]; echo stdout } |[2=1] cat > /dev/null although lexically similar, differ in their semantics, while { echo stderr >[1=2]; echo stdout } |[2=1] cat > /dev/null and { echo stderr >[1=2]; echo stdout } >[2] /dev/null look quite different, but are semantically equal. I became aware of this when I was asked about something similar by a beginner. I feel it is hard to explain why >[n=m] differs from |[n=m]. Malte. From rc-owner Thu Jul 16 12:20:37 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2221>; Thu, 16 Jul 1992 12:19:43 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2581>; Thu, 16 Jul 1992 12:18:58 -0400 To: malte@techfak.uni-bielefeld.de cc: rc@hawkwind.utcs.toronto.edu Subject: Re: Question about redirection In-reply-to: Your message of "Thu, 16 Jul 92 06:13:37 EDT." <9207161013.AA00612@dahlie.techfak.uni-bielefeld.de> Date: Thu, 16 Jul 1992 12:18:27 -0400 From: Scott Schwartz Message-Id: <92Jul16.121858edt.2581@groucho.cs.psu.edu> The strangeness is that >[n=m] means "the thing on the right reads n but gets m", while |[n=m] means "the thing on the right reads m but gets n. Backwards! When I first saw |[n=m] I thought m and n should be swapped so it would work more like >[n=m], or maybe the other way around. From rc-owner Mon Jul 20 20:54:44 1992 Received: from cortex.physiol.su.oz.au ([129.78.139.131]) by hawkwind.utcs.toro nto.edu with SMTP id <2221>; Mon, 20 Jul 1992 20:52:09 -0400 Received: by cortex.physiol.su.oz.au (5.57/Ultrix3.0-C) id AA19000; Tue, 21 Jul 92 10:51:47 +1000 From: John (_You_ hide, they seek.) Mackin Date: Mon, 20 Jul 1992 20:45:52 -0400 To: The rc Mailing List Subject: Re: Question about redirection In-Reply-To: <92Jul16.121858edt.2581@groucho.cs.psu.edu> Message-Id: <199207211045.18924.rc.babat@physiol.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ The strangeness is that >[n=m] means "the thing on the right reads n but gets m", while |[n=m] means "the thing on the right reads m but gets n. Backwards! Not at all. Or at least I don't think so. All it takes is the right way of looking at it; I think I have a right way, and I hope it will answer Malte's question as to how to explain this to an rc novice. When we write >[2=1], we think of that as "create two by duplicating one", and view it like an assignment statement (left receives right). When we write |[2=1], we think "the left process's two gets connected to the right process's one", and don't use the assignment metaphor. I think that as long as we think about this in the right way, there should be no problem. OK, John. From rc-owner Mon Jul 20 22:11:25 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2230>; Mon, 20 Jul 1992 22:07:55 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2583>; Mon, 20 Jul 1992 22:07:10 -0400 To: John Mackin (_You_ hide, they seek.) cc: The rc Mailing List Subject: Re: Question about redirection In-reply-to: Your message of "Mon, 20 Jul 92 20:45:52 EDT." <199207211045.18924.rc.babat@physiol.su.oz.au> Date: Mon, 20 Jul 1992 22:06:33 -0400 From: Scott Schwartz Message-Id: <92Jul20.220710edt.2583@groucho.cs.psu.edu> The point is that |[m=n] is confusing because it uses '=' in such a different way than >[m=n]. Wouldn't |[m|n] have been more obvious? Aside from the deeper semantic issues, it is "m:=n" vs "m->n", but with the same symbol '=' stuck in the middle. Yes, you can "think about it the right way", but why should one have to? Grumble, grumble, grumble. :-) By the way, does anyone miss "if not" (from Tom Duff's rc)? I don't. Anyone really like overloading static to mean both "own" and "private"? I don't. From rc-owner Wed Aug 12 22:11:17 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2221>; Wed, 12 Aug 1992 22:08:33 -0400 Received: by groucho.cs.psu.edu id <2680>; Wed, 12 Aug 1992 22:08:12 -0400 From: Scott Schwartz To: rc@hawkwind.utcs.toronto.edu Subject: memory leaks Message-Id: <92Aug12.220812edt.2680@groucho.cs.psu.edu> Date: Wed, 12 Aug 1992 22:08:12 -0400 Is anyone (besides me) concerned about the memory leaks in rc1.4? If you hit ^C you can watch your process size go up. Depressing. What do other shells do about this? -- Scott From rc-owner Wed Aug 12 23:55:01 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2230>; Wed, 12 Aug 1992 23:54:33 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA00984; Wed, 12 Aug 92 20:53:54 PDT Received: by netapp.netapp (4.1/SMI-4.1) id AA06713; Wed, 12 Aug 92 20:44:29 PDT Date: Wed, 12 Aug 1992 23:44:29 -0400 From: netapp!byron@netcom.com (Byron Rakitzis) Message-Id: <9208130344.AA06713@netapp.netapp> To: rc@hawkwind.utcs.toronto.edu, uunet!groucho.cs.psu.edu!schwartz Subject: Re: memory leaks >Is anyone (besides me) concerned about the memory leaks in rc1.4? I'm always interested in patching up a memory leak in rc. >What do other shells do about this? Presumably they don't leak. >Depressing. Well, instead of being depressed about it you could send me some mail with a full bug report. I just looked at my rc-1.4 and I could not get it to leak on ^C. If you gave described the problem in full (are you using readline, maybe a prompt function doing something funny, etc.?) maybe somebody could do something about it. (BTW, I hate to say this, but it peeves me a bit that you refer to the leak in the plural. Perhaps there is more than one memory leak left in rc, but you only mentioned one in your mail. If you're going to talk about memory leaks in the plural at least you could point out how to tickle them.) Byron. From rc-owner Thu Aug 13 00:41:17 1992 Received: from cortex.physiol.su.oz.au ([129.78.139.131]) by hawkwind.utcs.toro nto.edu with SMTP id <2688>; Thu, 13 Aug 1992 00:40:55 -0400 Received: by cortex.physiol.su.oz.au (5.57/Ultrix3.0-C) id AA12656; Thu, 13 Aug 92 14:40:34 +1000 From: John (_You_ hide, they seek.) Mackin Date: Thu, 13 Aug 1992 00:32:01 -0400 To: The rc Mailing List Subject: Re: memory leaks In-Reply-To: <92Aug12.220812edt.2680@groucho.cs.psu.edu> Message-Id: <199208131432.12476.rc.babef@physiol.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Scott says his rc leaks memory on interrupts. Like Byron, I can't duplicate this. Scott, could it be a startup thing? Don't forget that rc, quite legitimately, grows at first when you do things. That's not a leak, because it doesn't _keep_ growing when you _keep_ doing them. As Byron pointed out to me at one stage: --- begin included message From: Byron Rakitzis Date: Thu, 27 Jun 1991 01:33:33 -0500 To: john@syd.dit.csiro.au Subject: Re: rc memory leaks Received: from ARCHONE.TAMU.EDU by ditsydh.syd.dit.csiro.au with SMTP id AA1709 9 (5.64+/IDA/DIT-0.9 for john); Thu, 27 Jun 91 16:33:56 +1000 Received: by archone.tamu.edu id <22531>; Thu, 27 Jun 1991 01:33:45 -0500 Message-Id: <91Jun27.013345cdt.22531@archone.tamu.edu> Re: sun rc growing slowly. I find that when I start up a copy of rc and type a few things at it, it grows. However, the real test for a memory leak is to type the same command 1000 times. Does the shell grow in this case? (of course, you don't type the same command 1000 times, you . a file with the command written out 1000 times) [...] --- end included message I tried this with 1.4. Do a ps l of your rc, then in another window (to avoid observer effect) run "for (x in `{seq 1000}) kill -2 ". Do another ps. It doesn't grow. How do you reproduce it, Scott? OK, John. From rc-owner Thu Aug 13 03:29:42 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2701>; Thu, 13 Aug 1992 03:29:15 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2686>; Thu, 13 Aug 1992 03:28:57 -0400 To: netapp!byron@netcom.com (Byron Rakitzis) cc: rc@hawkwind.utcs.toronto.edu Subject: Re: memory leaks In-reply-to: Your message of "Wed, 12 Aug 92 23:44:29 EDT." <9208130344.AA06713@netapp.netapp> Date: Thu, 13 Aug 1992 03:28:39 -0400 From: Scott Schwartz Message-Id: <92Aug13.032857edt.2686@groucho.cs.psu.edu> | Well, instead of being depressed about it you could send me some mail | with a full bug report. Sorry. I needed to play empire for a while first. :-) | I just looked at my rc-1.4 and I could not get it to leak on ^C. If you | gave described the problem in full (are you using readline, maybe a | prompt function doing something funny, etc.?) maybe somebody could do | something about it. I'm running vanilla 1.4 on a Sun sparc2 under 4.1.1, configured by typing ``cp config.h-dist config.h''. My prompt just prints status if error. Enclosed are some typescripts, one with an empty environment. My supposition is that rc is longjmping out of an activation record that has dynamically allocated some memory when it handles the sigint. Script started on Thu Aug 13 03:05:27 EDT 1992 ; exec ./rc-1.4-sun4 ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 26690 rf S 0:00 0 8 0 76 320 xx 0.0 2.2 rc ; ^C ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 26690 rf S 0:00 0 15 0 76 324 xx 0.0 2.2 rc ; ^C ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 26690 rf S 0:00 0 22 0 80 320 xx 0.0 2.2 rc ; ^C ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 26690 rf S 0:00 0 30 0 80 324 xx 0.0 2.2 rc ; ^C ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 26690 rf S 0:00 0 36 0 84 324 xx 0.0 2.2 rc ; ^C ; ^C ; ^C ; ^C ; ^C ; ^C ; ^C ; ^C ; ^C ; ^C ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 26690 rf S 0:00 0 51 0 108 348 xx 0.0 2.4 rc ; Script done on Thu Aug 13 03:07:02 EDT 1992 Script started on Thu Aug 13 03:09:45 EDT 1992 ; env - ./rc-1.4-sun4 ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 26717 p6 S 0:00 0 10 0 56 284 xx 0.0 1.9 rc ; ^C ; ^C ; ^C ; ^C ; ^C ; ^C ; ^C ; ^C ; ^C ; ^C ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 26717 p6 S 0:00 0 22 0 80 308 xx 0.0 2.1 rc ; Script done on Thu Aug 13 03:10:23 EDT 1992 | (BTW, I hate to say this, but it peeves me a bit that you refer to the | leak in the plural. Sorry about that. I was speaking in generalities, "memory leaks" being a single concept of which I discovered an instance. From rc-owner Thu Aug 13 03:56:52 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2706>; Thu, 13 Aug 1992 03:56:38 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2686>; Thu, 13 Aug 1992 03:56:14 -0400 To: John Mackin (_You_ hide, they seek.) cc: The rc Mailing List Subject: Re: memory leaks In-reply-to: Your message of "Thu, 13 Aug 92 00:32:01 EDT." <199208131432.12476.rc.babef@physiol.su.oz.au> Date: Thu, 13 Aug 1992 03:56:05 -0400 From: Scott Schwartz Message-Id: <92Aug13.035614edt.2686@groucho.cs.psu.edu> | Scott says his rc leaks memory on interrupts. Like Byron, I can't duplicate | this. Hmmm. Maybe there is something system specific involved? I tested it on a sparc2 with gcc 2.2.2. | Scott, could it be a startup thing? I don't think so. It grows on every ^C. One of the typescripts I just posted starts with an empty environment; no prompt function or other junk. | I tried this with 1.4. Do a ps l of your rc, then in another window | (to avoid observer effect) run "for (x in `{seq 1000}) kill -2 ". | Do another ps. It doesn't grow. Hmmm. It just did for me: Script started on Thu Aug 13 03:45:18 EDT 1992 ; ps v26812 PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 26812 q1 I 0:00 41 99 0 96 340 xx 0.0 2.3 rc ; kill -2 26812 ; ps v26812 PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 26812 q1 S 0:00 3 99 0 96 344 xx 0.0 2.3 rc ; kill -2 26812 ; ps v26812 PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 26812 q1 S 0:00 5 99 0 100 344 xx 0.0 2.3 rc ; Script done on Thu Aug 13 03:45:56 EDT 1992 From rc-owner Thu Aug 13 06:31:45 1992 Received: from linc.cis.upenn.edu ([130.91.6.8]) by hawkwind.utcs.toronto.edu w ith SMTP id <2714>; Thu, 13 Aug 1992 06:30:58 -0400 Received: from SAUL.CIS.UPENN.EDU by linc.cis.upenn.edu id AA16761; Thu, 13 Aug 92 06:30:40 -0400 Return-Path: Received: from LOCALHOST.upenn.edu by saul.cis.upenn.edu id AA17780; Thu, 13 Aug 92 06:30:39 EDT Posted-Date: Thu, 13 Aug 92 06:30:37 -0400 Message-Id: <9208131030.AA17780@saul.cis.upenn.edu> To: Scott Schwartz Cc: The rc Mailing List , mjd@saul.cis.upenn.edu Subject: Re: memory leaks In-Reply-To: Your message of "Thu, 13 Aug 92 03:56:05 EDT." <92Aug13.035614edt.2686@groucho.cs.psu.edu> Date: Thu, 13 Aug 1992 06:30:37 -0400 From: Mark-Jason Dominus > Hmmm. Maybe there is something system specific involved? I tested > it on a sparc2 with gcc 2.2.2. Ditto on our sparc2 and 690MP, with out-of-the-box config.h-dist and gcc v2.1. From rc-owner Thu Aug 13 07:18:58 1992 Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by hawkwind.utcs.toronto .edu with SMTP id <2724>; Thu, 13 Aug 1992 07:18:38 -0400 Via: uk.ac.oxford.prg; Thu, 13 Aug 1992 12:17:48 +0100 Received: from uk.ac.oxford.robots.lucrece.robots (lucrece-gate.robots) by prg.oxford.ac.uk id AA23486; Thu, 13 Aug 92 12:17:35 +0100 Received: from robots.ox.ac.uk (miranda.robots) by uk.ac.oxford.robots.lucrece.robots (4.1/robots.1) id AA29639; Thu, 13 Aug 92 12:17:20 BST Received: by robots.ox.ac.uk (4.1/robots.remoteV2.0) id AA02724; Thu, 13 Aug 92 12:17:17 BST Date: Thu, 13 Aug 1992 07:17:17 -0400 From: peter@robots.oxford.ac.uk Message-Id: <9208131117.AA02724@miranda.robots.ox.ac.uk> To: rc@hawkwind.utcs.toronto.edu Subject: Re: memory leak Yup, I got the memory growth too using editline-d rc-1.4 on sun3's and 4's with sunos4.1.1. I used gcc2.x too. Pete. From rc-owner Thu Aug 13 09:45:42 1992 Received: from saturn.cv.nrao.edu ([192.33.115.71]) by hawkwind.utcs.toronto.ed u with SMTP id <2731>; Thu, 13 Aug 1992 09:44:03 -0400 Received: by saturn.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA00705; Thu, 13 Aug 92 09:44:05 EDT From: dschieb@saturn.CV.NRAO.EDU (Darrell Schiebel) Message-Id: <9208131344.AA00705@saturn.cv.nrao.edu> Subject: Re: memory leak To: rc@hawkwind.utcs.toronto.edu Date: Thu, 13 Aug 1992 09:44:05 -0400 X-Mailer: ELM [version 2.3 PL11] I'm using a Sun IPX with readline 1.1, sunos4.1.1, and iscreen. I have not been able to reproduce the memory leaks. I used the default config.h file (I believe), and compiled with gcc 2.2.2. See below. I also tried it on an IPX running 4.1.2 with no leak. Darrell Script started on Thu Aug 13 09:24:16 1992 ; cat /etc/motd SunOS Release 4.1.1 (AIPSIPX) #1: Tue Jan 21 12:56:08 EST 1992 ; ; echo $pid 659 ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 659 q2 S 0:00 0 38 0 80 392 xx 0.0 1.3 rc ; kill -2 $pid ; kill -2 $pid ; kill -2 $pid ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 659 q2 S 0:00 0 63 0 80 388 xx 0.0 1.3 rc ; kill -2 $pid ; kill -2 $pid ; kill -2 $pid ; kill -2 $pid ; kill -2 $pid ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 659 q2 S 0:00 0 76 0 80 388 xx 0.0 1.3 rc ; for ( i in (1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0) ) ki ll -2 $pid ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 659 q2 S 0:00 1 96 0 80 392 xx 0.0 1.3 rc ; kill -2 $pid ; kill -2 $pid ; kill -2 $pid ; kill -2 $pid ; kill -2 $pid ; kill -2 $pid ; ps v$pid PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 659 q2 S 0:00 1 99 0 80 392 xx 0.0 1.3 rc ; exit [screen is terminating] script done on Thu Aug 13 09:26:52 1992 ; From rc-owner Thu Aug 13 09:47:18 1992 Received: from odin.INS.CWRU.Edu ([129.22.8.102]) by hawkwind.utcs.toronto.edu with SMTP id <2732>; Thu, 13 Aug 1992 09:45:54 -0400 Received: by odin.INS.CWRU.Edu (5.65b+ida+/CWRU-1.5-ins) id AA12001; Thu, 13 Aug 92 09:44:23 -0400 (from chet for rc@hawkwind.ut cs.toronto.edu) Date: Thu, 13 Aug 1992 09:34:59 -0400 From: Chet Ramey To: schwartz@groucho.cs.psu.edu Subject: Re: memory leaks Cc: rc@hawkwind.utcs.toronto.edu, chet@odin.INS.CWRU.Edu Reply-To: chet@po.CWRU.Edu In-Reply-To: Message from schwartz@groucho.cs.psu.edu of Wed, 12 Aug 1992 22:08 :12 -0400 Message-Id: <9208131334.AA02378.SM@odin.INS.CWRU.Edu> Read-Receipt-To: chet@po.CWRU.Edu > Is anyone (besides me) concerned about the memory leaks in rc1.4? If > you hit ^C you can watch your process size go up. Depressing. What do > other shells do about this? Bash has a fairly nice `unwind-protect' mechanism. The interrupt handler runs the unwind-protect list. Bash is full of calls like begin_unwind_frame("tag"); add_unwind_protect(free, string1); add_unwind_protect(close, openfd); add_unwind_protect (restore_signal_mask, oset); ... run_unwind_frame("tag"); Look in the source file `unwind_prot.c' in the bash distribution. ash and sh have a mechanism to `mark the stack' when allocating memory. Then when they want to free it, they just unwind back to the previous mark. Chet -- ``The use of history as therapy means the corruption of history as history.'' -- Arthur Schlesinger Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu From rc-owner Sat Aug 15 20:56:40 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2223>; Sat, 15 Aug 1992 20:54:48 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2613>; Sat, 15 Aug 1992 20:54:25 -0400 To: netapp!byron@netcom.com (Byron Rakitzis) cc: rc@hawkwind.utcs.toronto.edu Subject: Update on memory leaks In-reply-to: Your message of "Sat, 15 Aug 92 01:45:03 EDT." <9208150545.AA17514@netapp.netapp> Date: Sat, 15 Aug 1992 20:54:18 -0400 From: Scott Schwartz Message-Id: <92Aug15.205425edt.2613@groucho.cs.psu.edu> It looks like it is Sun's yacc's fault. It mallocs space for the parse stack at the top of yyparse, and frees it when YYACCEPT or YYABORT is called. Unfortunately, longjmp defeats that strategy. Sun's ansi yacc mallocs once and saves the pointer in global. Berkeley yacc statically allocates things. Bison uses all sorts of techniques, but it seems to work ok. From rc-owner Sat Aug 15 21:17:38 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2688>; Sat, 15 Aug 1992 21:17:20 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA04421; Sat, 15 Aug 92 18:16:03 PDT Received: by netapp.netapp (4.1/SMI-4.1) id AA18161; Sat, 15 Aug 92 01:07:48 PDT Date: Sat, 15 Aug 1992 04:07:48 -0400 From: netapp!byron@netcom.com (Byron Rakitzis) Message-Id: <9208150807.AA18161@netapp.netapp> To: rc@hawkwind.utcs.toronto.edu Subject: ^C leak It appears to be in yacc. Some yacc's call malloc to create their token stack, while some yacc's have a fixed stack size. Now, rc calls yyparse which calls yylex which calls read. An interrupt in read causes the signal to be trapped before any more tokens can be returned to yacc so that it may either call YYABORT or YYACCEPT (the two macros which also free up the yacc stack space). Obviously, the reason why the leak is not apparent at any time but when a command is being typed is because the interrupt must occur while yacc is active. I would argue that this is a bug in yacc, given that it's extremely difficult, if not impossible, to do exception processing given this model. Perhaps yacc should supply a callback function to free memory, or perhaps it should not call malloc in the first place. I'll see what I can do about working around this. The fix is probably odious: exception handling will have to be context-sensitive ("are we in a stack frame containing yyparse?") and there will have to be some automagical way of simulating a ^C through yacc. As I said, I don't know if it's possible to fix. In the meantime, you can always get rid of the leak by compiling rc with a yacc that does not use malloc. (old berkeley yacc is definitely one of these, and it's probably in the bsd-sources tree. I got my y.tab.c from a NeXT running such a yacc) Depressing, eh? Does anyone have any better ideas? From rc-owner Sat Aug 15 21:33:06 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2699>; Sat, 15 Aug 1992 21:32:49 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2613>; Sat, 15 Aug 1992 21:32:30 -0400 To: netapp!byron@netcom.com (Byron Rakitzis) cc: rc@hawkwind.utcs.toronto.edu Subject: Re: ^C leak In-reply-to: Your message of "Sat, 15 Aug 92 04:07:48 EDT." <9208150807.AA18161@netapp.netapp> Date: Sat, 15 Aug 1992 21:32:22 -0400 From: Scott Schwartz Message-Id: <92Aug15.213230edt.2613@groucho.cs.psu.edu> I suggest not altering rc unnecessarily. Given that there are lots of yacc implementations floating around, including a public domain one from corbett@berkeley.edu, you might as well just tell people to use one of those. If you ship a y.tab.[ch] with rc, it may not be necessary to run yacc at all. From rc-owner Fri Aug 28 11:49:04 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2689>; Fri, 28 Aug 1992 11:47:13 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA05839; Fri, 28 Aug 92 17:47:04 +0200 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA01803; Fri, 28 Aug 92 17:47:03 +0200 Date: Fri, 28 Aug 1992 11:47:03 -0400 From: malte@techfak.uni-bielefeld.de Message-Id: <9208281547.AA01803@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: rc 1.4 on solaris 2.0 Ok, here's the story about rc 1.4 on solaris 2.0: builtins.c:444: surround setrlimit with #ifndef __svr4__ proto.h:68: add .. !defined(__svr4__) Using Cygnus Supports gcc port, this one compiles just fine and runs the trip test. EXECPT: when running trip it sometimes gives me kill: exec format error but just sometimes (why? I don't know). When using editline (the provided readline.a does not work), leave out the USE_TERMCAP option. And that's just it. Good work, who ever participated, especially Byron. Makes live much easier now. Malte. From rc-owner Mon Sep 21 04:12:28 1992 Received: from mail.swip.net ([192.71.220.11]) by hawkwind.utcs.toronto.edu wit h SMTP id <2706>; Mon, 21 Sep 1992 04:08:28 -0400 Received: by mail.swip.net (5.65c8/1.2) id AA11674; Mon, 21 Sep 1992 10:08:15 +0200 Received: from lynx.analytikerna by analytikerna.se (4.1/SMI-4.1) id AA05341; Mon, 21 Sep 92 09:25:44 +0200 Date: Mon, 21 Sep 1992 03:25:44 -0400 From: bk@analytikerna.se (Bengt KLEBERG) Message-Id: <9209210725.AA05341@analytikerna.se> To: rc@hawkwind.utcs.toronto.edu Subject: redirection confusion Greetings, With the low volume of traffic I hope that this will not be considered to simple a question to put forth. Could somebody tell me why my rc1.4 (gcc compiled) on a sparcELC does what I want for this (ie sends both stdout and stderr to more) { for ( i in */*.dbf) { ls -l $i ls -l `{echo $i | sed 's/dbf/tab/'} } } | more >[2=1] But not for this (ie does not send stdout and stderr to lpr) { for ( i in */*.dbf) { ls -l $i ls -l `{echo $i | sed 's/dbf/tab/'} } } | lpr >[2=1] Best Wishes, Bengt From rc-owner Mon Sep 21 10:54:27 1992 Received: from relay2.UU.NET ([137.39.1.7]) by hawkwind.utcs.toronto.edu with S MTP id <2712>; Mon, 21 Sep 1992 10:49:11 -0400 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA03450; Mon, 21 Sep 92 10:49:06 -0400 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 104851.4069; Mon, 21 Sep 1992 10:48:51 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa29358; Mon, 21 Sep 92 10:48:12 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: bk@analytikerna.se, rc@hawkwind.utcs.toronto.edu Subject: Re: redirection confusion Date: Mon, 21 Sep 1992 10:48:25 -0400 Message-Id: <9209211048.aa19998@ceres.srg.af.mil> It seems to me that it shouldn't do it in either case. It may just look like it's doing it in the first case. From rc-owner Mon Sep 28 16:58:13 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2701>; Mon, 28 Sep 1992 16:56:12 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA00765; Mon, 28 Sep 92 13:55:24 PDT Received: by netapp.netapp.com (4.1/SMI-4.1) id AA07458; Mon, 28 Sep 92 13:42:10 PDT Date: Mon, 28 Sep 1992 16:42:10 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9209282042.AA07458@netapp.netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: recent rc hacks I've been working on a convenient way to keep my history file trimmed down to a particular size, and yet make the most of the bytes in the history file. I've now got a little history file "compressor" (more like "redundancy eliminator" --- which is what a compressor is, so why am I quibbling?) which I'd like to share with the list. Here's what I run out of my crontab every 4am or so. It's a script I call trimhist: #!/bin/rc -l if (test -f $history) { egrep -v '^(-|; )' $history | tac | onlyfirst | sed 5000q | tac > $history.$pid mv $history.$pid $history echo `{d} `{wc -l < $history} >> $home/lib/histlog } First it prunes the completely uninteresting lines from $history, then reverses the file, then filters out all but the first instance of each command (more later), trims to 5000 lines, reverses and stores. The "d" command is a customized "date" script: I keep a log of the length of my history file. It turns out that it's an interesting number to look at; if you buy the concept of a "working set" of commands, then a trimhisted history file should not change much in size over time. I have not had the chance to test this much, since my line reverser, "tail -r", turns out to be broken. Anyway, before I talk more about "tac", let me quote the "onlyfirst" filter here: #!/usr/local/bin/gawk -f { if (hash[$0] == 0) { hash[$0] = 1 strings[total++] = $0 } } END { for (i = 0; i < total; i++) print strings[i] } The pipeline "tac|onlyfirst|tac" has the property that it keeps only the last instance of whatever command you typed, but preserves the ordering of the commands overall. (In trimhist, putting the "sed q" before the second tac makes sure you keep the *last* n lines!) Anyway, I didn't realize tail -r was broken until very recently (it's actually documented under BUGS in the Sun man pages --- oops). My first pass was an awk program, but the performance was terrible. (I wonder if anyone maintaining gawk might care to see why it's so expensive to append elements to an array?) So to wrap it up, here's my C implementation of tac. It's not very pretty, but it works: /* tac: a tail -r that really works */ #include #include enum {CHUNKSIZE=8192}; static char *readfile(int fd, size_t *size) { size_t nread = 0; char *file; int r; if ((file = malloc(CHUNKSIZE)) == NULL) { perror("malloc"); exit(1); } while (1) { switch (r = read(fd, file + nread, CHUNKSIZE)) { case -1: perror("read"); exit(1); case 0: if (size != NULL) *size = nread; return file; default: nread += r; if ((file = realloc(file, nread + CHUNKSIZE)) == NULL) { perror("realloc"); exit(1); } break; } } } static void tac(char *file, size_t size) { char *end, *last; int nlterm = (file[size-1] == '\n'); for (last = end = &file[size-1-nlterm]; end != &file[-1]; --end) if (*end == '\n') { fwrite(end + 1, 1, last - end, stdout); putchar('\n'); last = end - 1; } fwrite(file, 1, last - end, stdout); if (nlterm) putchar('\n'); } extern int main(int argc, char *argv[]) { size_t size; char *file; if (argc == 1) { file = readfile(0, &size); tac(file, size); } else { while (*++argv != NULL) { int fd = open(*argv, 0); if (fd < 0) perror(*argv); else { file = readfile(fd, &size); close(fd); tac(file, size); } } } return 0; } From rc-owner Mon Sep 28 18:41:24 1992 Received: from pixar.com ([138.72.10.20]) by hawkwind.utcs.toronto.edu with SMT P id <2701>; Mon, 28 Sep 1992 18:41:05 -0400 Received: from copland.pixar.com by pixar.com (4.1/NBN-15/PIX-36) id AA02876; Mon, 28 Sep 92 15:40:58 PDT Received: by copland.pixar.com (/\==/\ Smail3.1.25.1 #25.14) id ; Mon, 28 Sep 92 15:40 PDT Message-Id: To: rc@hawkwind.utcs.toronto.edu Subject: Hacking the history mechanism in rc Date: Mon, 28 Sep 1992 18:40:46 -0400 From: Bruce Perens ------- I wanted to have a way to implement my own history mechanism without hacking rc to bits, so I added a "hook" for an external history mechanism. When my version of rc is about to process a command line, it checks to see if the user has defined an rc function "add_history". If so, it calls the user function with the command line in $1 . A simple definition of add_history is: fn add_history { echo -n $1 >> /usr/people/bruce/history_file } My version is a bit more complicated. It puts the last command in the window title, etc. I think this is a good change because: + It replaces 15 lines of hard-coded C with four lines. + It makes rc more versatile without adding code. + It preserves the existing functionality. I'm also experimenting with a "glob" function. The function is called before globbing a filename, with a list containing the arguments. If it recognizes any special characters that it handles, it calls an external module that expands them and returns the expanded list. I use this to implement ~name expansion as in c-shell without adding code to rc. I was inspired by an old Version 6 or Version 7 Unix shell that used an external "glob" program. I think there is a lot of room for work with "hook" functions. Through them, rc can be made a lot more versatile without adding code to rc itself. Bruce Perens From rc-owner Tue Sep 29 10:38:56 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2714>; Tue, 29 Sep 1992 10:38:19 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA20692; Tue, 29 Sep 92 10:38:05 -0400 Received: by earth.osf.org (5.64/4.7) id AA22337; Tue, 29 Sep 92 10:38:04 -0400 Date: Tue, 29 Sep 1992 10:38:04 -0400 From: rsalz@osf.org Message-Id: <9209291438.AA22337@earth.osf.org> To: byron@netapp.com, rc@hawkwind.utcs.toronto.edu Subject: Re: recent rc hacks I like Byron's idea, but I like even more the idea of not needing these little scripts or programs lying around. And even more perversely, I like the idea of using big monstrous perl to tame the history of small elegant rc. So, the following 45-line perl script. It uses $histlog to say where to write the history log file. I don't know why but if I invoked this directly then my shell stopped adding to the history (actually, I do sort of know why; I'd calll it a bug) Using this function helps: fn trimhist { perl $h/bin/trimhist && history=$history } #! /usr/bin/perl -- $size = 50; $history = $ENV{'history'} || die "No \$history environment variable, stopped"; $old = $history . '~'; rename($history, $old) || die "Can't rename $!, stopped"; open(IN, $old) || die "Can't open $old $!, stopped"; ## Parse $history, filling in @lines with last unique occurence of each ## command. %commands = (); @lines = (); $count = 0; line: while ( ) { chop; next line if /^-/ || /^; / || /^$/; $lines[$commands{$_}] = "" if defined $commands{$_}; $commands{$_} = $count++; push(@lines, $_); } close(IN) || die "Can't close $history $!, stopped"; @lines = grep($_ ne "", @lines); ## Open new output open(OUT, ">$history") || die "Can't open $history $!, stopped"; ## Print last "$count" lines. $start = $#lines - $size; $start = 0 if $start < 0; $count = 0; foreach ( @lines[$start .. $#lines] ) { print OUT $_, "\n"; $count++; } close(OUT) || die "Can't close $history $!, stopped"; unlink($old) || die "Can't remove $old $!, stopped"; ## Update $histlog (unset it to not do that). $log = $ENV{'histlog'} || exit(0); open(OUT, ">>$log") || die "Can't open $log $!, stopped"; ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); printf OUT "%4d/%2.2d/%2.2d %d\n", $year + 1900, $mon + 1, $mday, $count; close(OUT) || die "Can't close $log $!, stopped"; From rc-owner Wed Sep 30 14:36:00 1992 Received: from gatech.edu ([128.61.1.1]) by hawkwind.utcs.toronto.edu with SMTP id <2701>; Wed, 30 Sep 1992 14:34:02 -0400 Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA02617 for rc@hawkwind.utcs.toronto.edu; Wed, 30 Sep 92 14:33:53 ED T Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA22350; for byron@netapp.com; Wed, 30 Sep 92 14:33:50 EDT Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA01662; Wed, 30 Sep 92 14:33:16 EDT From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9209301833.AA01662@penfold.cc.gatech.edu> Date: Wed, 30 Sep 1992 14:33:15 -0400 In-Reply-To: Byron Rakitzis's 150-line message on Sep 28, 4:42pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: byron@netapp.com (Byron Rakitzis) Subject: Re: recent rc hacks Cc: rc@hawkwind.utcs.toronto.edu, david@cs.dal.ca > Date: Mon, 28 Sep 1992 16:42:10 -0400 > From: byron@netapp.com (Byron Rakitzis) > To: rc@hawkwind.utcs.toronto.edu > Subject: recent rc hacks > > Anyway, before I talk more about "tac", let me quote the "onlyfirst" > filter here: > > #!/usr/local/bin/gawk -f > { > if (hash[$0] == 0) { > hash[$0] = 1 > strings[total++] = $0 > } > } > > END { > for (i = 0; i < total; i++) > print strings[i] > } This would probably be better written as { if (! ($0 in strings)) strings[$0]++ } END { for (i in strings) print i } You could modify the print statement in the END block to print a count of commands or whatever other info you might want. > Anyway, I didn't realize tail -r was broken until very recently (it's > actually documented under BUGS in the Sun man pages --- oops). My > first pass was an awk program, but the performance was terrible. > (I wonder if anyone maintaining gawk might care to see why it's > so expensive to append elements to an array?) Arrays are hash tables. The current version uses a fixed size set of buckets. You probably used something like { a[NR] = $0 } END { for (i = NR; i >= 1; i++) print a[i] } to do tac -- gawk has to malloc storage to hold your whole file, and also has to do lots of hash chain following. I also expect that the hash function isn't great on purely numeric strings. I'd be curious what the performance of this program was compared to SunOS nawk or mawk. Arnold From rc-owner Wed Sep 30 19:02:28 1992 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2733>; Wed, 30 Sep 1992 19:01:51 -0400 Received: by mod.civil.su.oz.au id <28683>; Thu, 1 Oct 1992 08:29:53 +1000 From: John (_You_ hide, they seek.) Mackin Date: Wed, 30 Sep 1992 17:54:30 -0400 To: The rc Mailing List Subject: Re: recent rc hacks (+ source for revfile) In-Reply-To: <9209291438.AA22337@earth.osf.org> Message-ID: <199210010754.9370.rc.babor@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Heavy sighs. I should have posted my history compactor to the list ages ago, it seems. And now when I go to check it before posting it, it seems to have bugs. I just about give in, but thought I should point out a few things regarding linewise file reversal (a very useful function in general). #1: Seventh Edition didn't have "tail -r". (It was adopted between Seventh and Ninth -- probably in V8, but I don't have my V8 manual in the office. I don't think that excuses anything.) Hence, in general, one can't rely on "tail -r" being present on your machine. #2: I don't think that the comment in the BUGS section of SunOS 4.1.1 tail(1) either excuses or explains tail -r's behaviour. It is referring to things like "tail -400b", which have never worked. (Although, if you are going to give tail a -r option, which in my view is a stupid plan, there's no reason not to make them work.) I don't know the exact provenance of either the option or the bug, but I do know that on DECstations running Ultrix 4.2, "tail -r file" doesn't exhibit the bug. I'm not really interested in chasing it further since I contend (as stated above) that tail -r should never be used at all in any case. #3: "tac" is a reinvention of the wheel. In 1985, there was a huge debate on net.unix-wizards about the best way to reverse a file line-wise. It lasted for months. The final outcome was a utility called "revfile", written by Stephen J. Muir, Computing Dept., Lancaster University. Check archie for it; also, a copy is appended to this mail. I don't want to seem to be slagging off at you in public, Byron, but _really_, reading the whole file into memory! I hardly think that's a reasonable thing to do. Especially since the kinds of files we're likely to want to deal with in this way are precisely those that are really big. The code in revfile is not what I would call pretty, either; but it's fast, it works, and it doesn't read the whole file before writing anything. (Unless, of course, the input isn't seekable in which case there is no choice: but in that case it copies it to /tmp, clearly the correct solution. We should _never_ assume that an arbitrary file fits in memory.) #4: Line-wise file reversal clearly calls for a purpose-built C program. (One of the other conclusions of the debate.) Things like awk are so general that they're bound to be very slow at this. [perl hackers: Yes, I know perl is ideal for this task, as it is for all others, so please don't bother telling me.] OK, John. # To unbundle, sh this file echo revfile.1 1>&2 sed 's/.//' >revfile.1 <<'//GO.SYSIN DD revfile.1' -.TH REVFILE 1 local -.SH NAME -revfile \- reverse order of lines in file -.SH SYNOPSIS -.B revfile -[ -.I file -\&.\|.\|. ] -.SH DESCRIPTION -.I revfile -copies the named files, or standard input if none are named, -to standard output, reversing the order of lines in each file. -The filename -.B \- -stands for the standard input. -.SH AUTHOR -Stephen J. Muir, Computing Dept., Lancaster University -.SH "SEE ALSO" -rev(1) //GO.SYSIN DD revfile.1 echo revfile.c 1>&2 sed 's/.//' >revfile.c <<'//GO.SYSIN DD revfile.c' -/* Written by Stephen J. Muir, Computing Dept., Lancaster University - * stephen@uk.ac.lancs.comp - * stephen@uk.ac.lancaster.computing - * dcl-cs!stephen - * - - * revfile(1) - reverse order of lines in files - * - - */ - -# include -# include -# include -# include -# include - -# define BUFSIZE 4096 - -extern char *malloc (); - -char *standin = "-", *my_tmpfile = "/tmp/revfileXXXXXX"; - -struct stat mystat; - -struct list -{ - char l_buf [BUFSIZE]; - short l_cnt; - struct list *l_next; -} -*head, *pool; - -/* insert data at beginning of list */ -linsert (buf, size) -char *buf; -{ - register struct list *lp; - if (size == 0) - return; - if (lp = pool) /* try to reuse a list element */ - pool = pool->l_next; - else if ((lp = (struct list *)malloc (sizeof (struct list))) == 0) - { - fprintf (stderr, "Out of memory\n"); - exit (1); - } - bcopy (buf, lp->l_buf, size); - lp->l_cnt = size; - lp->l_next = head; - head = lp; /* insert at head of list */ -} - -lflush (buf, size) -char *buf; -{ - register struct list *lp; - if (size && fwrite (buf, 1, size, stdout) != size) - { - perror ("stdout"); - exit (1); - } - while (head) /* flush list */ - { - if (fwrite (head->l_buf, 1, head->l_cnt, stdout) != head->l_cnt ) - { - perror ("stdout"); - exit (1); - } - head = (lp = head)->l_next; - lp->l_next = pool; - pool = lp; /* add to list of old elements */ - } -} - -revfile (name) -char *name; -{ - static char buf [BUFSIZE]; - register char *cp, *ep; - register int ofd, nfd, i, pos; - long newpos; - long lseek(); - if (strcmp (name, standin)) /* open the file */ - { - if ((ofd = open (name, 0)) == -1) - { - perror (name); - return (1); - } - } - else - ofd = 0; - /* attempt to use original file */ - if (fstat (ofd, &mystat) == -1 || - (mystat.st_mode & S_IFMT) != S_IFREG || /* regular file? */ - (pos = lseek (ofd, 0L, 2)) == -1 /* go to EOF? */ - ) - { - pos = 0; /* failed - copy file * / - if ((nfd = open (my_tmpfile, O_RDWR|O_CREAT, 0)) == -1 || - unlink (my_tmpfile) == -1 - ) - { - perror (my_tmpfile); - goto erroro; - } - while ((i = read (ofd, buf, BUFSIZE)) > 0) - { - if (write (nfd, buf, i) != i) - { - perror (my_tmpfile); - goto errorn; - } - pos += i; - } - if (i == -1) - { - perror (name); - goto errorn; - } - close (ofd); - ofd = nfd; - name = my_tmpfile; - } - while (pos) - { - if ((newpos = pos - BUFSIZE) < 0) - newpos = 0; - i = pos - newpos; - if (lseek (ofd, newpos, 0) != newpos || read (ofd, buf, i) != i ) - { - perror (name); - goto erroro; - } - for (cp = ep = &buf [i]; cp > &buf [0]; ) - if (*--cp == '\n') - { - lflush (cp + 1, ep - (cp + 1)); - ep = cp + 1; - } - linsert (cp, ep - cp); - pos = newpos; - } - lflush (0, 0); - if (ofd) - close (ofd); - return (0); -errorn: - close (nfd); -erroro: - if (ofd) - close (ofd); - return (1); -} - -/*ARGSUSED*/ -main (argc, argv, envp) -char *argv [], *envp []; -{ - register short exitstat = 0; - if (--argc <= 0) - { - argv = &standin; - argc = 1; - } - else - ++argv; - mktemp (my_tmpfile); - while (argc--) - if (revfile (*argv++)) - exitstat = 1; - if (fclose (stdout) == EOF) - { - perror ("stdout"); - exit (1); - } - exit (exitstat); -} -bcopy(from, to, size) -char * from; -char * to; -int size; -{ - register char * cp1 = from; - register char * cp2 = to; - register int n = size; - - while ( n-- ) - *cp2++ = *cp1++; -} //GO.SYSIN DD revfile.c From rc-owner Thu Oct 1 14:20:53 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2714>; Thu, 1 Oct 1992 14:19:41 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA21779; Thu, 1 Oct 92 11:18:57 PDT Received: by netapp.netapp.com (4.1/SMI-4.1) id AA11122; Thu, 1 Oct 92 11:06:02 PDT Date: Thu, 1 Oct 1992 14:06:02 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9210011806.AA11122@netapp.netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: README for es This is the README for es-0.67. INTRO Almost as soon as rc became usable, Paul Haahr and I (Byron Rakitzis) started talking about what a "son of rc" would look like. Es ("extensible shell") represents our combined effort, on and off (mostly off), over the last year or so. We are presenting a paper on es at this Winter's Usenix. We'd naturally like this program to get some exposure from real users before we brag to the whole world about it. Since almost by definition members of the rc list are people who are willing to try something new, this is the first place I am posting. Chris Siebenmann (cks@hawkwind.utcs.toronto.edu) has kindly offered to put the es sources up for ftp (ftp.white.toronto.edu, in pub/es), as well as to maintain a separate es mailing list (send mail to Chris for information and subscription requests). MOTIVATION We wanted to create a shell that looked more like a "real" programming language, so that, e.g., it could be used well in an embedded application the way Tcl can. Hence lexical scoping, for example. We thought that by presenting rc's features (pipes, list manipulation, and so on) as a uniform interface, it would be possible to tailor es carefully to an application. The shell's syntax (which resembles rc's) is just syntactic sugar on top of this interface. We also wanted to try something new :-) HOW TO USE IT Superficially, es resembles rc. This can be used as a zeroth approximation for figuring things out in es. Some differences in syntax are unavoidable. For example, since just about everything has been reduced to a "builtin", control structures like "if" and "while" take both the test and the body in curly braces. Right now, I'm going to punt you to the abstract that we've written, as no user manual yet exists. Unfortunately, this means that you might have to explore the code itself to see what is going on, since the abstract does not tell the whole story. But it should be enough to whet your appetite, we hope. A sample .esrc is also provided. Things that are not documented in the abstract: the hook mechanism for variables of the form "set-foo". See "set-HOME" in initial.es for a use of this. There is a "catch" and a "throw" for implementing user-level exceptions in es. WHERE TO LOOK The source, initial.es (implements the builtins & syntactic sugar) Sample.esrc (Paul's .esrc), trip.es (not a complete trip test!), and the Usenix abstract. Have fun. BUGS Things are very new, and still somewhat incomplete, so all feedback (bug reports, and so on) is warmly appreciated. The file TODO lists incomplete tasks in release-number order. For any comments, please drop a note to haahr@adobe.com or byron@netapp.com The code has been run under SunOS4.1.1 and NeXTOS2.1 with gcc as the compiler, as well as on an RS6000 with AIX3.2 and the IBM compiler. Doubtless there are portability problems we don't know about yet. Please try to let us know about those also. Many thanks, Paul Haahr Byron Rakitzis From rc-owner Thu Oct 1 17:39:26 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2701>; Thu, 1 Oct 1992 17:38:21 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA09614; Thu, 1 Oct 92 14:37:27 PDT Received: by netapp.netapp.com (4.1/SMI-4.1) id AA16833; Thu, 1 Oct 92 13:48:14 PDT Date: Thu, 1 Oct 1992 16:48:14 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9210012048.AA16833@netapp.netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: es availability I should mention that I posted this README and sent the source to Chris at the same time. Please wait until Chris says he's ready before you try to fetch the source. Sorry for the confusion. Byron. From rc-owner Thu Oct 1 18:56:07 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2714>; Thu, 1 Oct 1992 18:54:41 -0400 To: rc Subject: Re: es availability In-reply-to: byron's message of Thu, 01 Oct 92 16:48:14 -0400. <9210012048.AA16833@netapp.netapp.com> Date: Thu, 1 Oct 1992 18:54:27 -0400 From: Chris Siebenmann Message-Id: <92Oct1.185441edt.2714@hawkwind.utcs.toronto.edu> es@hawkwind.utcs.toronto.edu now exists, with the usual side aliases such as es-request, and the source is ftpable from /pub/es on ftp.white.toronto.edu. I'm busy adding people to the mailing list right now. - cks From rc-owner Sat Oct 3 19:24:46 1992 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2749>; Sat, 3 Oct 1992 19:23:17 -0400 Received: by mod.civil.su.oz.au id <28682>; Sun, 4 Oct 1992 09:22:46 +1000 From: John (_You_ hide, they seek.) Mackin Date: Sat, 3 Oct 1992 19:17:33 -0400 To: The rc Mailing List , Boyd Roberts Subject: compact - a history-file compaction command Message-ID: <199210040917.15729.rc.baboz@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Here's my version. I'm sorry I didn't send it out much earlier and save everyone the effort of writing those foul script versions :). Please comment. OK, John. # To unbundle, sh this file echo README 1>&2 sed 's/.//' >README <<'//GO.SYSIN DD README' -This is compact version 0.9, by John Mackin . - --- What is compact? - -compact is a tool which analyses its input line-wise, and only outputs -one copy of each duplicated line. Unlike uniq, compact detects duplicate -lines even if they are not adjacent. Unlike sort | uniq, compact is stable -with respect to the order of the lines; duplicated lines are output in the -most recent (farthest along) position. - --- Why is that any use? - -I admit that I can't think offhand of any application for compact other -than the specific one for which I wrote it. I hope your mileage varies :). - -It was written to compact shell history files. Some shells are able to -simply append each command line to a file after it is read and before -it is executed. This allows very simple, clean, and flexible implementation -of history entirely outside the shell itself. With this kind of history, -people seem to fall into two classes: those who like to throw their -history away frequently (e.g., when a window or a login session dies), -and those who like to keep it forever. I'm one of the latter. Of -course, in that case, unless you do something about it your history -file grows without bound. compact is what I do about it. - -It really helps; for a typical example, it shrinks one raw history file -I have here from 164 000 characters to 67 000. In terms of lines, the -saving is even more impressive, from 12 000 to 4 000 on the same example -file. (This implies that rarer commands are longer, which is as it should -be.) - -A history file that's compacted regularly still grows without bound, -but the growth is much more under control. - --- Why a new program? Why not implement this using existing tools? - -I couldn't think of any way to do what compact does using normal -standard UNIX tools that was even reasonably clean and efficient. -If you _can_ think of one, please tell me. The solutions that I -have since seen don't impress me, efficiency-wise; that matters, -since my history file ends up being pretty big. - --- Why did you pick a command name that was already used? - -I am aware that a `compact' command already exists on some machines. -For those who don't know, it was written at Berkeley, and introduced -in 4.2BSD. It was a file compression command, like pack or compress. -It predated compress and was intended as an alternative to pack. -Unfortunately, on the majority of files, it took far more CPU time than -pack to produce a result that was usually around the same in terms of -disk space. Even before the advent of compress, it was almost -never used. These days, it is effectively totally dead as a command. -(How long has it been since _you_ saw a filename with a .C suffix? -That wasn't C++?) It has even been deprecated at Berkeley, and is -not present in the 4.4BSD sources on ftp.uu.net. Therefore, I have -no qualms about re-using its name. - -The reason I chose to do so is because the idea for compact wasn't -mine. The first `compact' I know of that did what mine does was -written by Bruce Ellis at the University of Sydney (and it predated -the Berkeley `compact'). I never saw the source to Brucee's implementation; -I've just re-implemented his idea. - --- How do I compile and install it? - -Link Makefile.dist to Makefile and type "make". There is no -configuration and I believe it should be 100% portable, with the single -possible exception that you might need to take care of strrchr vs. -rindex. Please tell me if it isn't, or if you have any problems. -Installation is done by hand; strip the executable and copy it to where -you want it. Copy the manual page to wherever it should go. All -done. - -There is one other possible portability glitch: your compiler might -not understand one or both of the declarations "unsigned char" or -"unsigned long". If so, it is truly prehistoric, and you should mail -me because I'm interested (unless you're on some sort of DOS box or such). - --- You're a dope! The algorithm you chose is ludicrously memory-hungry! - I don't have a snowball's chance in hell of compacting any significant - file on my PDP-11. - -Yes, I know. Please accept my apologies. As we are all aware, we have -to constantly decide how to trade off speed for space and vice versa, and -I wanted this program to run quickly. I do have an algorithm in mind for -machines with small memories, but I haven't implemented it yet. When I -get around to that depends in large part on demand: if you have a need for it, -let me know. - --- What is this "flint" business? It looks like something separate. - -Yes, it was going to be. "flint" stands for fast, line-oriented input. -It is part of a library I was developing which I was going to release -publically. Unfortunately, I was beaten to the punch by Phong Vo and -David Korn's sfio package. flint as it stands is still much lighter-weight -and simpler than sfio, but then it only provides one function: efficient, -safe, unlimited length line-oriented file reading. If you want to rip it -off and use it in something else, let me know and I can send you some -documentation. If you're interested in sfio, see <16948@ulysses.att.com> -in comp.lang.c, or if you don't have unlimited access to old netnews (grin) -the package is available from netlib: - - echo send sfio.shar from incoming | mail netlib@research.att.com - --- Why does compact handle null characters (at all, and as it does)? - -Good question. A well-formed UNIX text file consists of zero or more -lines. A line is a sequence of non-null characters terminated by a -newline. Hence, a well-formed UNIX text file never contains null -characters. Since the shell I use is friendly enough to ignore null -characters on input (with a warning) should I happen to type one -accidentally, then null characters will never be written to my -history file, right? Wrong. I run shells on more than one machine, -all appending to the same history file by courtesy of that absolute -_marvel_ of modern software technology, NFS (read: Not a FileSystem). -One of the lovely features that gives me is large chunks of null -characters where I should have data. Hence, compact needs to -ignore lines containing null characters. Come on up to NFS, your -international passport to crossmounting pleasure! You'll be so -glad you did! - --- Where did this version of compact come from? Where can I get - the latest version? - -Version 0.9 of compact is a limited release for portability evaluation and -comments. Please let me know how it works (or doesn't work) for you, -and what you think of it. This version was released by mail to the rc -mailing list and selected other people. The program may be made available -by anonymous ftp, and posted to netnews, later. Version 0.9 was released -in October 1992. - -John Mackin - - If that address should fail (shouldn't happen prior to January - 1993, but who knows!), you could try or - . - -Zero is greater than minus zero, but don't ask by how much. - -- Control Data Corporation 6600 reference manual //GO.SYSIN DD README echo compact.1 1>&2 sed 's/.//' >compact.1 <<'//GO.SYSIN DD compact.1' -.TH COMPACT 1 local -.SH NAME -compact \- shrink a file by eliminating duplicate lines -.SH SYNOPSIS -.B compact -[ -.I file -] -.SH DESCRIPTION -.I compact -reads the named input -file, -or the standard input -if no file is named, and writes a subset of the lines read -to the standard output. Lines are output in the same order that -they appear in the input, but lines which appear in the input -more than once will appear in the output exactly once, -in the position in which they -.I last -appear in the input. -.PP -Blank lines and lines containing null characters are ignored. Should the last -character of the input not be a newline, all characters after -the final newline in the input will be ignored. Input characters -other than null and newline are not distinguished in any way; -in particular, characters with the high bit on will be treated normally. -.SH EXAMPLE -.I compact -is ideal for shrinking shell history files. You might put something -like this in your .profile, if your version of sh supports history: -.PP - trap 'compact $HISTORY >$HOME/.temphist; mv $HOME/.temphist $HISTORY' 0 -.SH AUTHOR -John Mackin, ; original concept by Bruce Ellis -(who had nothing to do with this implementation). -.SH BUGS -\& -.SH "SEE ALSO" -sort(1), uniq(1), comm(1) //GO.SYSIN DD compact.1 echo Makefile.dist 1>&2 sed 's/.//' >Makefile.dist <<'//GO.SYSIN DD Makefile.dist' -CFLAGS = -O -LDFLAGS = # -g -LIBS = - -compact: compact.o memory.o flint.o - cc $(LDFLAGS) compact.o memory.o flint.o -o $@ $(LIBS) - -compact.o: compact.h - -memory.o: compact.h //GO.SYSIN DD Makefile.dist echo compact.h 1>&2 sed 's/.//' >compact.h <<'//GO.SYSIN DD compact.h' -/* - * Header file for compact. Include all random headers & define - * some types. - */ - -#include -#include -#include "flint.h" - -#define SYSERROR (-1) - -#define HASHSIZE 3319 - -struct cmd { - struct cmd * c_next; - struct cmd * c_prev; - struct cmd * c_hlink; - char * c_cmd; - int c_len; -}; - -extern char * Name; - -extern struct cmd * newcmd(); -extern char * newstr(); //GO.SYSIN DD compact.h echo compact.c 1>&2 sed 's/.//' >compact.c <<'//GO.SYSIN DD compact.c' -/* - * History file compaction. Usage: compact history-file. - */ - -#include "compact.h" - -/* - * Head and Tail are the doubly linked list of commands in print - * order. Hash is the hash table. - */ - -struct cmd * Head; -struct cmd * Tail; -struct cmd * Hash[HASHSIZE]; - -char * Name; - -extern char * strrchr(); - -long hashpjw(); - -main(argc, argv) -int argc; -char ** argv; -{ - register char * p; - - Name = argv[0]; - if (p = strrchr(Name, '/')) - Name = ++p; - - if (argc == 1) - compactfd("standard input", 0); - else if (argc == 2) - compact(argv[1]); - else - usage(); - - exit(0); -} - -compact(file) -char * file; -{ - int fd; - - fd = open(file, 0); - if (fd == SYSERROR) { - fprintf(stderr, "%s: can't open ", Name); - perror(file); - exit(1); - } - compactfd(file, fd); - (void)close(fd); -} - -compactfd(file, fd) -char * file; -int fd; -{ - flint f; - register char * s; - register struct cmd * c; - extern int errno; - - if (flopen(&f, fd, 'r') != 0) - fatal("can't flopen"); - - while ((s = flread(&f)) != (char *)0) - if (fllength(&f) > 0) /* ignore blank lines */ - hashprobe(s, fllength(&f)); - - if (flerror(&f)) { - fprintf(stderr, "%s: read error on ", Name); - errno = flerrno(&f); - perror(file); - exit(1); - } - flclose(&f); - - c = Head; - while (c) { - puts(c->c_cmd); - c = c->c_next; - } -} - -hashprobe(cmd, len) -char * cmd; -register int len; -{ - register struct cmd ** bucket; - register struct cmd * c; - register struct cmd * new; - register long hashval; - - hashval = hashpjw(cmd, len); - if (hashval == -1L) /* The line has embedded nulls. */ - return; /* Sodding NFS!! Ignore it. */ - - bucket = &Hash[(int)(hashval % HASHSIZE)]; - c = *bucket; - if (c == (struct cmd *)0) { - new = newcmd(); - *bucket = new; - new->c_cmd = newstr(cmd, len); - new->c_len = len; - new->c_hlink = (struct cmd *)0; - tailadd(new); - } - else { - /* - * This hash bucket has something in it. Search to see - * if this command is there already or not. We only need - * to call strcmp if the length of the strings is the same, - * which cuts down the number of calls by around 2/3 in a - * typical case. - */ - for (;;) { - if (c->c_len == len && strcmp(cmd, c->c_cmd) == 0) - break; - if (c->c_hlink == (struct cmd *)0) { - new = newcmd(); - c->c_hlink = new; - new->c_cmd = newstr(cmd, len); - new->c_len = len; - new->c_hlink = (struct cmd *)0; - tailadd(new); - return; - } - c = c->c_hlink; - } - /* - * This command is already in this bucket. Move it to the - * end of the doubly-linked print order list, unless it is - * already at the end in which case nothing need be done. - */ - if (c->c_next != (struct cmd *)0) { - if (c == Tail) - fatal("can't be Tail"); - if (c->c_prev != (struct cmd *)0) { - if (c == Head) - fatal("can't be Head"); - c->c_prev->c_next = c->c_next; - } - else - Head = c->c_next; - c->c_next->c_prev = c->c_prev; - tailadd(c); - } - } -} - -tailadd(c) -register struct cmd * c; -{ - if (Head == (struct cmd *)0) { /* first time */ - Head = Tail = c; - c->c_prev = c->c_next = (struct cmd *)0; - } - else { - Tail->c_next = c; - c->c_prev = Tail; - c->c_next = (struct cmd *)0; - Tail = c; - } -} - -/* - * Weinberger's hash function. - */ - -long -hashpjw(s, len) -register char * s; -register int len; -{ - register unsigned char * p; - register unsigned long g; - register unsigned long h; - register unsigned char c; - - h = 0; - p = (unsigned char *)s; - while (len-- > 0) { - c = *p++; - if (c == '\0') - return (-1L); - h = (h << 4) + c; - if (g = h & 0xF0000000) { - h = h ^ (g >> 24); - h = h ^ g; - } - } - - return (h); -} - -fatal(s) -{ - fprintf(stderr, "%s: %s\n", Name, s); - exit(1); -} - -usage() -{ - fprintf(stderr, "usage: %s [file]\n", Name); - exit(1); -} //GO.SYSIN DD compact.c echo memory.c 1>&2 sed 's/.//' >memory.c <<'//GO.SYSIN DD memory.c' -/* - * Memory allocation. - */ - -#include "compact.h" - -char * strcpy(); - -static char * salloc(); - -/* - * It's definitely worth not having to call strlen() here, and since we - * know the length anyway, why not? I considered making newstr() allocate - * chunks and dole them out, in order to cut down on calls to malloc(), - * but on the Ultrix MIPS box where I profiled this, malloc came to - * only 3% in the end so I didn't bother. If your mileage varies, - * that might be a good shot. - */ - -char * -newstr(s, len) -char * s; -int len; -{ - char * p; - - p = salloc(len + 1); - strcpy(p, s); - return (p); -} - -static char * -salloc(n) -int n; -{ - register char * s; - extern char * malloc(); - - s = malloc((unsigned)n); - if (s == (char *)0) { - fprintf(stderr, "%s: out of memory\n", Name); - exit(1); - } - - return (s); -} - -/* - * Special-purpose allocator for command struct's. Avoids all that - * time spent in malloc. Freeing them isn't an issue. - */ - -#define CHUNK 512 - -struct cmd * -newcmd() -{ - static int chunk = CHUNK; - static int avail = 0; - static struct cmd * cp; - register int n; - - if (avail <= 0) { - cp = (struct cmd *)salloc(chunk * sizeof (struct cmd)); - avail = chunk; - n = chunk << 1; - if (n > 0) - chunk = n; - } - - avail--; - return (cp++); -} //GO.SYSIN DD memory.c echo flint.h 1>&2 sed 's/.//' >flint.h <<'//GO.SYSIN DD flint.h' -/* - * Header file for flint - fast line oriented input - */ - -/* $Id: flint.h,v 1.2 1991/12/27 12:24:08 john Exp $ */ - -#ifndef _FLINT_H -#define _FLINT_H - -typedef struct _flint { - char * fl_buf; - int fl_bufsize; - char * fl_ptr; - char * fl_end; - int fl_flags; - int fl_fd; - int fl_errno; - int fl_length; -} flint; - -/* flags in fl_flags */ - -#define FLREAD 01 -#define FLEOF 02 -#define FLERROR 04 - -#define FLBUFSIZE 4096 /* initial size */ - -/* publically visible routines */ - -extern int flopen(); -extern char * flread(); -extern void flclose(); -extern void flclear(); -extern long fltell(); -extern void (*flerrset())(); -extern void flreset(); - -/* macros */ - -#define flisopen(f) ((f)->fl_flags & FLREAD) -#define fleof(f) ((f)->fl_flags & FLEOF) -#define flerror(f) ((f)->fl_flags & FLERROR) -#define flerrno(f) ((int)(f)->fl_errno) -#define fllength(f) ((int)(f)->fl_length) -#define flfd(f) ((int)(f)->fl_fd) - -#endif _FLINT_H -/* Don't add anything following the above #endif */ //GO.SYSIN DD flint.h echo flint.c 1>&2 sed 's/.//' >flint.c <<'//GO.SYSIN DD flint.c' -/* - * flint - fast line input - */ - -static char RCSid[] = "$Id: flint.c,v 1.3 1992/06/02 04:01:56 john Exp $"; - -#include "flint.h" - -#ifndef SYSERROR -#define SYSERROR (-1) -#endif - -static void flexpand(); -static void flfill(); -static void flmoveback(); -static char * flmalloc(); -static char * flrealloc(); -static void flfatal(); - -static void (*flerrfunc)() = (void (*)())0; - -int -flopen(f, fd, mode) -register flint * f; -int fd; -int mode; -{ - if (mode != 'r') - return (-1); - f->fl_bufsize = FLBUFSIZE; - f->fl_buf = flmalloc(FLBUFSIZE); - f->fl_ptr = f->fl_end = f->fl_buf; - f->fl_flags = FLREAD; - f->fl_fd = fd; - f->fl_errno = 0; - f->fl_length = 0; - return (0); -} - -void -flclose(f) -register flint * f; -{ - free(f->fl_buf); - f->fl_flags = 0; -} - -void -flclear(f) -register flint * f; -{ - f->fl_flags &= ~(FLEOF | FLERROR); - f->fl_errno = 0; -} - -void -flreset(f) -register flint * f; -{ - f->fl_ptr = f->fl_end = f->fl_buf; -} - -long -fltell(f) -register flint * f; -{ - register long pos; - extern long lseek(); - - if ((f->fl_flags & FLREAD) == 0) - return (-2L); - if (f->fl_flags & FLERROR) - return (-2L); - - pos = lseek(f->fl_fd, 0L, 1); - if (pos == (long)SYSERROR) - return (-1L); - - pos -= f->fl_end - f->fl_ptr; - - if (pos >= 0L) - return (pos); - else - return (-3L); -} - - -char * -flread(f) -register flint * f; -{ - register char * p; - register char * end; - char * line; - - if ((f->fl_flags & FLREAD) == 0) - return ((char *)0); - for (;;) { - p = f->fl_ptr; - end = f->fl_end; - while (p < end) { - if (*p == '\n') - goto break2; - p++; - } - if (f->fl_flags & (FLEOF | FLERROR)) - return ((char *)0); - - if (f->fl_end > f->fl_ptr) { - if (f->fl_ptr == f->fl_buf) - flexpand(f); - else - flmoveback(f); - } - else - f->fl_ptr = f->fl_end = f->fl_buf; - - flfill(f); - } -break2: - /* - * Getting here means that we have found a valid line which - * we can proceed to return to the user. - */ - - line = f->fl_ptr; - f->fl_length = p - line; - *p++ = '\0'; /* null out the newline on the end of the line */ - f->fl_ptr = p; - - return (line); -} - -static void -flexpand(f) -register flint * f; -{ - char * save; - register int n; - - n = f->fl_bufsize << 1; - if (n > 0) - f->fl_bufsize = n; - else - flfatal("buffer tried to grow too large"); - - save = f->fl_buf; - f->fl_buf = flrealloc(f->fl_buf, n); - if (save != f->fl_buf) { /* did it move? */ - f->fl_ptr = f->fl_ptr - save + f->fl_buf; - f->fl_end = f->fl_end - save + f->fl_buf; - } -} - -static void -flfill(f) -register flint * f; -{ - register int n; - register int try; - extern int errno; - - if (f->fl_flags & (FLEOF | FLERROR)) - flfatal("flfill called with eof or error"); - - try = (f->fl_buf + f->fl_bufsize) - f->fl_end; - if (try <= 0) - flfatal("can't happen in flfill"); - n = read(f->fl_fd, f->fl_end, try); - if (n == 0) { - f->fl_flags |= FLEOF; - return; - } - if (n == SYSERROR) { - f->fl_flags |= FLERROR; - f->fl_errno = errno; - return; - } - f->fl_end += n; - if (f->fl_end > f->fl_buf + f->fl_bufsize) - flfatal("buffer overrun in flfill"); -} - -static void -flmoveback(f) -register flint * f; -{ - register int n; - register char * from; - register char * to; - - n = f->fl_end - f->fl_ptr; - if (n < 0 || n >= f->fl_bufsize) - flfatal("can't happen in flmoveback"); - from = f->fl_ptr; - to = f->fl_buf; - while (n-- > 0) - *to++ = *from++; - f->fl_ptr = f->fl_buf; - f->fl_end = to; -} - -static char * -flmalloc(n) -register int n; -{ - register char * p; - extern char * malloc(); - - p = malloc((unsigned)n); - if (p == (char *)0) - flfatal("out of memory for flint buffers"); - return (p); -} - -static char * -flrealloc(old, n) -register char * old; -register int n; -{ - register char * p; - extern char * realloc(); - - p = realloc(old, (unsigned)n); - if (p == (char *)0) - flfatal("out of memory for flint buffers"); - return (p); -} - -static void -flfatal(s) -char * s; -{ - char buf[256]; /* avoid stdio */ - - if (flerrfunc == (void (*)())0) { - strcpy(buf, "fatal error in flint: "); - strcat(buf, s); - strcat(buf, "\n"); - write(2, buf, strlen(buf)); - exit(1); - } - else - (*flerrfunc)(s); -} - -void -(*flerrset(fp))() -void (*fp)(); -{ - void (*ret)(); - - ret = flerrfunc; - flerrfunc = fp; - return (ret); -} //GO.SYSIN DD flint.c From rc-owner Sun Oct 4 01:55:42 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2751>; Sun, 4 Oct 1992 01:55:22 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA29125; Sat, 3 Oct 92 22:52:16 PDT Received: by netapp.netapp.com (4.1/SMI-4.1) id AA16988; Sat, 3 Oct 92 22:50:14 PDT Date: Sun, 4 Oct 1992 01:50:14 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9210040550.AA16988@netapp.netapp.com> To: boyd@prl.dec.com, john@civil.su.oz.au, rc@hawkwind.utcs.toronto.edu Subject: Re: compact - a history-file compaction command >Here's my version. I'm sorry I didn't send it out much earlier and save >everyone the effort of writing those foul script versions :). Please >comment. Ok, I will. I think writing a C program for this utility is wrong for the same reasons that people who aren't fluent with Unix approach such a problem by skipping to C first, rather than trying the tools cat -> tr -> sed -> awk ( or -> perl ) -> C in roughly that order. In this particular case, I would much rather implement this history compactor as tac | onlyfirst | tac since 1) a tac binary is useful in other circumstances, whereas by your admission a history compactor is pretty much that --- a history compactor. So why clutter up my bin directory with yet another binary? 2) it is not much slower than the C program you wrote. And in any case, I have a hard time believing that the performance of the solution is a big deal, esp. if you compact the file out of cron. And it is not so much faster that I would want to use your program, e.g., every time I logged in. 3) a shell solution is generally easier to develop & maintain, as discussed ad nauseam on the various comp.unix.* lists. My awk & rc scripts were written in a matter of minutes. With those three points aside, I'd like to thank you for the code. It's hard to argue with an existing implementation that you just need to compile up, providing you don't care about point #1. (However, I still think you wasted your time writing it.) Byron. From rc-owner Sun Oct 4 02:05:13 1992 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2757>; Sun, 4 Oct 1992 02:05:00 -0400 Received: by mod.civil.su.oz.au id <28682>; Sun, 4 Oct 1992 16:04:29 +1000 From: John (_You_ hide, they seek.) Mackin Date: Sun, 4 Oct 1992 01:57:30 -0400 To: Byron Rakitzis cc: Boyd Roberts , The rc Mailing List Subject: Re: compact - a history-file compaction command In-Reply-To: <9210040550.AA16988@netapp.netapp.com> Message-ID: <199210041557.18168.rc.babuf@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ tac | onlyfirst | tac Sorry, Byron, but I don't buy this (as you already know). Here's why: sure, I already had "revfile". Sure, "revfile"/"tac" is independently useful (_very_ useful). It's the _middle_ of the pipeline I'm against. Are you going to claim that onlyfirst is any more generally useful than compact? If so, please give examples, because I don't think it is. From a slightly abstract point of view, they are nearly the same program (compact could have been called "onlylast"). OK, John. From rc-owner Sun Oct 4 02:25:13 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2754>; Sun, 4 Oct 1992 02:24:56 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA00708; Sat, 3 Oct 92 23:21:54 PDT Received: by netapp.netapp.com (4.1/SMI-4.1) id AA17278; Sat, 3 Oct 92 23:20:41 PDT Date: Sun, 4 Oct 1992 02:20:41 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9210040620.AA17278@netapp.netapp.com> To: john@civil.su.oz.au Subject: Re: compact - a history-file compaction command Cc: boyd@prl.dec.com, rc@hawkwind.utcs.toronto.edu The reason being that onlyfirst is a 10 line (or less) awk script that I could even have inlined into my history-compacting shell-script, had I chosen to (which I happened to have not). From rc-owner Thu Oct 8 17:01:24 1992 Received: from carson.u.washington.edu ([140.142.52.11]) by hawkwind.utcs.toron to.edu with SMTP id <2750>; Thu, 8 Oct 1992 16:58:57 -0400 Received: by carson.u.washington.edu (5.65/UW-NDC Revision: 2.22 ) id AA03054; Thu, 8 Oct 92 13:58:33 -0700 Date: Thu, 8 Oct 1992 16:58:33 -0400 From: Donn Cave Message-Id: <9210082058.AA03054@carson.u.washington.edu> Sender: donn@carson.u.washington.edu To: rc@hawkwind.utcs.toronto.edu Subject: rc and null environ strings Am having this problem with rc version 1.4: ; A = '' ./rc ; whatis A A='' ; A = ralph segmentation violation--core dumped ; In other words, assigning to a zero-length variable is fatal. However, this happens only after reading that (zero-length) value (hence the "whatis" in the example). Trace back looks like this: (gdb) where #0 0xbc2e in free () #1 0x68bc in efree (p=(int *) 0x212d) (nalloc.c line 135) #2 0x5eba in listfree (p=(struct List *) 0x177d8) (list.c line 17) #3 0x3d31 in get_var_place (s=(char *) 0x167d4 , stack=FALSE) (hash.c line 157 )#4 0x8485 in varassign (name=(char *) 0x167d4 , def=(struct List *) 0x16804, stack=FALSE) (var.c line 18) #5 0x3156 in assign (s1=(struct List *) 0x16810, s2=(struct List *) 0x16804, s tack=FALSE) (glom.c line 163) #6 0x9264 in walk (n=(struct Node *) 0x167f8, parent=TRUE) (walk.c line 160) #7 0x4cb6 in doit (execit=TRUE) (input.c line 332) #8 0x63f3 in main (argc=1, argv=(char **) 0x3fffdccc, envp=(char **) 0x3fffdcd 4 Platform is DYNIX/ptx on a Sequent 2000/750. The value of p->w, passed to efree() at list.c line 17, looks uninitialized to me, but that's as far as I have taken it. rc 1.2 doesn't have this problem, although it oddly can't find zero-length variables passed in in the environment. "es" works fine. Donn Cave, University Computing Services, University of Washington donn@cac.washington.edu From rc-owner Mon Oct 12 19:56:13 1992 Received: from carson.u.washington.edu ([140.142.52.11]) by hawkwind.utcs.toron to.edu with SMTP id <2773>; Mon, 12 Oct 1992 19:54:58 -0400 Received: by carson.u.washington.edu (5.65/UW-NDC Revision: 2.22 ) id AA16285; Mon, 12 Oct 92 16:54:44 -0700 Date: Mon, 12 Oct 1992 19:54:44 -0400 From: Donn Cave Message-Id: <9210122354.AA16285@carson.u.washington.edu> Sender: donn@carson.u.washington.edu To: rc@hawkwind.utcs.toronto.edu Subject: segv on 0-length var Following up on this bug: ; Z='' rc ; whatis Z Z='' ; Z = ouch segmentation violation--core dumped ; The appended patch seems to fix it. The problem arises when listfree() attempts to free the variable value. The patch is against version 1.4. Donn Cave, University Computing Services, University of Washington donn@cac.washington.edu ------------------------------- *** footobar.c.dist Fri Feb 14 09:05:01 1992 --- footobar.c Mon Oct 12 15:49:28 1992 *************** *** 260,266 **** top = r = enew(List); extdef = strchr(extdef, '=') + 1; if ((f = getenvw(extdef, FALSE)) == NULL) { ! r->w = ""; r->m = NULL; r->n = NULL; } else { --- 260,267 ---- top = r = enew(List); extdef = strchr(extdef, '=') + 1; if ((f = getenvw(extdef, FALSE)) == NULL) { ! r->w = ealloc (1); ! r->w[0] = 0; r->m = NULL; r->n = NULL; } else { From rc-owner Wed Oct 14 23:09:01 1992 Received: from ssec.ssec.wisc.edu ([144.92.108.61]) by hawkwind.utcs.toronto.ed u with SMTP id <2750>; Wed, 14 Oct 1992 23:07:13 -0400 Received: by ssec.ssec.wisc.edu; id AA20849; AIX 3.2/UCB 5.64/42; Wed, 14 Oct 1992 22:05:14 -0500 Illegal-Object: Syntax error in From: address found on hawkwind.utcs.toronto.ed u: From: DaviD W.Sanderson ^ ^-illegal period in phrase \-phrases containing '.' must be quoted Message-Id: <9210150305.AA20849@ssec.ssec.wisc.edu> Subject: Plan 9 Programmer's Manual available for FTP From: To: rc@hawkwind.utcs.toronto.edu Date: Wed, 14 Oct 1992 23:05:13 -0400 X-Mailer: ELM [version 2.3 PL11] Straight from comp.os.research: From: rob@research.att.com (Rob Pike) Newsgroups: comp.os.research Subject: Plan 9 Manual now available by FTP Date: 14 Oct 92 19:27:55 GMT Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 7 Approved: comp-os-research@ftp.cse.ucsc.edu Message-ID: <1bib2aINNmgu@darkstar.UCSC.EDU> NNTP-Posting-Host: ftp.cse.ucsc.edu Originator: osr@ftp The Programmer's Manual and supporting documentation for Plan 9 from Bell Labs is now available by anonymous FTP from research.att.com, directory dist/plan9man. Rob Pike rob@research.att.com From rc-owner Wed Oct 14 23:18:45 1992 Received: from ssec.ssec.wisc.edu ([144.92.108.61]) by hawkwind.utcs.toronto.ed u with SMTP id <2752>; Wed, 14 Oct 1992 23:18:25 -0400 Received: by ssec.ssec.wisc.edu; id AA28911; AIX 3.2/UCB 5.64/42; Wed, 14 Oct 1992 22:16:33 -0500 From: DaviD Sanderson Message-Id: <9210150316.AA28911@ssec.ssec.wisc.edu> Subject: Plan 9 Programmer's Manual available by FTP To: rc@hawkwind.utcs.toronto.edu Date: Wed, 14 Oct 1992 23:16:33 -0400 X-Mailer: ELM [version 2.3 PL11] Straight from comp.os.research: From: rob@research.att.com (Rob Pike) Newsgroups: comp.os.research Subject: Plan 9 Manual now available by FTP Date: 14 Oct 92 19:27:55 GMT Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 7 Approved: comp-os-research@ftp.cse.ucsc.edu Message-ID: <1bib2aINNmgu@darkstar.UCSC.EDU> NNTP-Posting-Host: ftp.cse.ucsc.edu Originator: osr@ftp The Programmer's Manual and supporting documentation for Plan 9 from Bell Labs is now available by anonymous FTP from research.att.com, directory dist/plan9man. Rob Pike rob@research.att.com From rc-owner Wed Oct 14 23:19:38 1992 Received: from noao.edu ([140.252.1.54]) by hawkwind.utcs.toronto.edu with SMTP id <2757>; Wed, 14 Oct 1992 23:19:22 -0400 Received: from bordeaux.kpno.noao.edu by noao.edu (4.1/SAG-Noao.G83) id AA17930; Wed, 14 Oct 92 20:19:09 MST; for rc@hawkwind.utcs.toronto.e du Received: by bordeaux.kpno.noao.edu (4.1/SMI-4.1) id AA12207; Wed, 14 Oct 92 20:19:08 MST Date: Wed, 14 Oct 1992 23:19:06 -0400 From: Jim Davis To: rc@hawkwind.utcs.toronto.edu Subject: Re: Plan 9 Programmer's Manual available for FTP In-Reply-To: Your message of Wed, 14 Oct 1992 23:05:13 -0400 Message-Id: It is big, though... 548 pages! The people I share a LaserWriter with did grumble a bit. I've only had time for a cursory look, but there's some fascinating stuff... -- Jim Davis | "Revenge!" jdavis@noao.edu | -- Pete's brother Pete Jim Davis | "Revenge!" jdavis@noao.edu | -- Pete's brother Pete From rc-owner Tue Oct 27 06:04:26 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2771>; Tue, 27 Oct 1992 05:52:44 -0500 To: rc Subject: Interesting things from the Plan 9 rc manpage Date: Tue, 27 Oct 1992 05:52:30 -0500 From: Chris Siebenmann Message-Id: <92Oct27.055244est.2771@hawkwind.utcs.toronto.edu> $" is the Plan 9 rc syntax for Byron's $^ string flattening operator. 'if not' is still there. The Plan 9 rc has a number of interesting options: -s: Print out exit status after any command where the status is non-null (false). -I: Do not run interactively, regardless of whether or not standard input is attached to a terminal. -p is listed as a no-op; presumably no one has bothered implementing it. There's a 'flag' builtin that lets you test, set, and clear the status of command-line flags. The manual page doesn't have a FILES section, so I don't know if the Plan 9 rc has abandoned the 'source a file on startup' approach (the copy of Duff's rc I have sources a file, but it's moderately old). Interestingly, one of the entries in the BUGS section is It's too slow and too big. (as well as There should be a way to match patterns against whole lists rather than just single strings. which I think some people here have wanted in the past.) - cks From rc-owner Tue Oct 27 08:38:12 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2776>; Tue, 27 Oct 1992 08:35:05 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA01081; Tue, 27 Oct 92 08:34:48 -0500 Received: by earth.osf.org (5.64/4.7) id AA02082; Tue, 27 Oct 92 08:34:47 -0500 Date: Tue, 27 Oct 1992 08:34:47 -0500 From: rsalz@osf.org Message-Id: <9210271334.AA02082@earth.osf.org> To: rc@hawkwind.utcs.toronto.edu Subject: Revised readline package available The revised readline is now on the ftp site. err, I forgot. hawkwind? "cant set guest permissions" From rc-owner Tue Oct 27 10:35:11 1992 Received: from plg.uwaterloo.ca ([129.97.140.10]) by hawkwind.utcs.toronto.edu with SMTP id <2778>; Tue, 27 Oct 1992 10:33:48 -0500 Received: by plg.uwaterloo.ca id <29146>; Tue, 27 Oct 1992 10:33:08 -0500 CC: rsalz@osf.org From: Dave Mason To: rc@hawkwind.utcs.toronto.edu In-reply-to: <9210271334.AA02082@earth.osf.org> (rsalz@osf.org) Subject: Revised readline package available X-Face: AIhKpNgOq"]N605xNB+orT]rLNWK$J<}qa|0lQ0B2j[nV{f6p[rts{~dP03$Nc'O|KTqvi2 a@~=X4wtyx17qU]8GrH3Z4e/PHS4+9J#jBI4qoR5_A[VwN u,gG$~mRI1#AayDR Date: Tue, 27 Oct 1992 10:32:59 -0500 > Date: Tue, 27 Oct 1992 08:34:47 -0500 > From: rsalz@osf.org > > The revised readline is now on the ftp site. > err, I forgot. hawkwind? "cant set guest permissions" ftp.white.toronto.edu I don't suppose anyone has written the history/command-editing/completion program that I really want. I don't want readline in my rc (or es), but I do want easy filename completion. So what I plan to do is set eol (an altenate terminater in cooked mode) to TAB and eol2 (another alternate) to ESC, then make rc call my history program if it gets a line that doesn't end in \n (after writing what it got to $history). Then my history program will read $history and see what the trailing character is. If it's not a printable character it will push it back and call readline (or possibly make Input point at the whole line - I haven't written it yet). Then readline will do completion or history or whatever until it has a \n and then hand the line back to rc (i.e. print it on stdout) to do with what it will (which will treat it as if it had just been returned from read. Note that with this description, you can also type: foo^D and you will be handed to the history/completion program, in addition to: foo^I or foo or This looks pretty straightforward, but I'm very busy this week, so I probably won't do it until next week. (If anybody else likes the idea & does it beforehand, great!) I'm open to comments or better ideas. ../Dave (BTW, I wish the small readline didn't have an 80 character limit.) From rc-owner Tue Oct 27 10:39:26 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2780>; Tue, 27 Oct 1992 10:39:07 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA07292; Tue, 27 Oct 92 10:38:54 -0500 Received: by earth.osf.org (5.64/4.7) id AA02667; Tue, 27 Oct 92 10:38:53 -0500 Date: Tue, 27 Oct 1992 10:38:53 -0500 From: rsalz@osf.org Message-Id: <9210271538.AA02667@earth.osf.org> To: dmason@plg.uwaterloo.ca, rc@hawkwind.utcs.toronto.edu Subject: Re: Revised readline package available Cc: rsalz@osf.org ILE can do what you want. It spawns a specified program on a pty and sits between you and it. The only hack is that you have to tell it when you chdir, which you can easily do by a function that sends an escape sequence. From rc-owner Tue Oct 27 11:10:13 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2782>; Tue, 27 Oct 1992 11:09:27 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2613>; Tue, 27 Oct 1992 11:08:46 -0500 To: Chris Siebenmann cc: rc@hawkwind.utcs.toronto.edu Subject: Re: Interesting things from the Plan 9 rc manpage In-reply-to: Your message of "Tue, 27 Oct 92 05:52:30 EST." <92Oct27.055244est.2771@hawkwind.utcs.toronto.edu> Date: Tue, 27 Oct 1992 11:08:26 -0500 From: Scott Schwartz Message-Id: <92Oct27.110846est.2613@groucho.cs.psu.edu> | The manual page doesn't have a FILES section, so I don't know if the | Plan 9 rc has abandoned the 'source a file on startup' approach (the | copy of Duff's rc I have sources a file, but it's moderately old). Other manpages mention rcmain, so that's probably still in use. | Interestingly, one of the entries in the BUGS section is | It's too slow and too big. You've used both: how does it compare to Byron's? From rc-owner Tue Oct 27 16:45:44 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2785>; Tue, 27 Oct 1992 16:44:51 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA01466; Tue, 27 Oct 1992 10:48:13 -0600 Message-Id: <9210271648.AA01466@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: flag Date: Tue, 27 Oct 1992 11:48:12 -0500 From: Alan Watson X-Mts: smtp A flag primitive would be useful: I would like to be able to set the -x flag for short sections of code whilst debugging. Alan. From rc-owner Tue Oct 27 20:54:40 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2789>; Tue, 27 Oct 1992 20:50:04 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA07150; Tue, 27 Oct 92 18:46:55 PPE Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA25914; Tue, 27 Oct 92 17:17:47 PST Date: Tue, 27 Oct 1992 20:17:47 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9210280117.AA25914@netapp.netapp.com> To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Interesting things from the Plan 9 rc manpage -s: Print out exit status after any command where the status is non-null (false). This can be done with an appropriate fn prompt in my rc. -I: Do not run interactively, regardless of whether or not standard input is attached to a terminal. This can be done with "rc /dev/tty". What do they use this option for anyway? It's too slow and too big. I think that's just a Bell Labs pissing contest. Over there your macho- ness as a programmer is measured in inverse proportion to the number of lines of code you produce for a given task. My money says Duff's rc is smaller and faster than any than ksh, bash, etc. :-) (Though I would not be surprised if an implementation of rc that did not lazily parse functions from the environment were perceived as being slow on startup. This was a key optimization in my implementation.) From rc-owner Tue Oct 27 21:02:29 1992 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu w ith SMTP id <2788>; Tue, 27 Oct 1992 21:00:13 -0500 Received: by quux.es.su.oz.au id <14632>; Wed, 28 Oct 1992 12:59:06 +1100 From: noel@es.su.oz.au Date: Tue, 27 Oct 1992 20:57:28 -0500 To: byron@netapp.com (Byron Rakitzis), cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Interesting things from the Plan 9 rc manpage In-Reply-To: <9210280117.AA25914@netapp.netapp.com> Message-ID: <199210280157.18185.out.babes@es.su.oz.au> From: byron@netapp.com (Byron Rakitzis) It's too slow and too big. I think that's just a Bell Labs pissing contest. Over there your macho- ness as a programmer is measured in inverse proportion to the number of lines of code you produce for a given task. My money says Duff's rc is smaller and faster than any than ksh, bash, etc. :-) and what a FINE measure of a programmer's competence! From rc-owner Tue Oct 27 21:03:23 1992 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu w ith SMTP id <2790>; Tue, 27 Oct 1992 21:02:42 -0500 Received: by quux.es.su.oz.au id <14632>; Wed, 28 Oct 1992 13:00:39 +1100 From: noel@es.su.oz.au Date: Tue, 27 Oct 1992 20:59:24 -0500 To: byron@netapp.com (Byron Rakitzis), cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Interesting things from the Plan 9 rc manpage In-Reply-To: <9210280117.AA25914@netapp.netapp.com> Message-ID: <199210280159.21062.out.babet@es.su.oz.au> From: byron@netapp.com (Byron Rakitzis) It's too slow and too big. I think that's just a Bell Labs pissing contest. Over there your macho- ness as a programmer is measured in inverse proportion to the number of lines of code you produce for a given task. My money says Duff's rc is smaller and faster than any than ksh, bash, etc. :-) i am glad that you, Byron, adhere to these lofty ideals. From rc-owner Tue Oct 27 22:21:15 1992 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.to ronto.edu with SMTP id <2793>; Tue, 27 Oct 1992 22:16:31 -0500 Received: by mail-relay-1.mv.us.adobe.com; id AA01745; Tue, 27 Oct 92 19:15:56 -0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA12298; Tue, 27 Oct 92 19:14:33 PST Date: Tue, 27 Oct 1992 22:14:33 -0500 From: Paul Haahr Message-Id: <9210280314.AA12298@utopia.mv.us.adobe.com> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Interesting things from the Plan 9 rc manpage > It's too slow and too big. testimony i've heard from a friend at the labs is that the startup time is painful. we speculated at the time that it was due to the way the environment is treated on plan9 combined with the use of rcmain. as i remember, on the gnots, startup time was >1sec, reliably. (this is all hearsay, folks, so take it with a grain of salt.) From rc-owner Tue Oct 27 22:42:52 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2795>; Tue, 27 Oct 1992 22:40:04 -0500 To: rc Subject: Re: Interesting things from the Plan 9 rc manpage In-reply-to: haahr's message of Tue, 27 Oct 92 22:14:33 -0500. <9210280314.AA12298@utopia.mv.us.adobe.com> Date: Tue, 27 Oct 1992 22:39:51 -0500 From: Chris Siebenmann Message-Id: <92Oct27.224004est.2795@hawkwind.utcs.toronto.edu> Since Plan 9 implements the environment as a filesystem (a single directory) it wouldn't surprise me if it takes a while to fire up an rc if you have lots of functions or environment variables. When I saw Pike demonstrating 8 1/2 (and when I saw it running on a 386 portable), I don't think window creation took that long, although 8 1/2 can hide shell startup delay if it wants to be clever. The Labs style seems to tend towards a certain sparseness of environment, so it may have been considered OK by most people. - cks From rc-owner Tue Oct 27 23:02:47 1992 Received: from munnari.oz.au ([128.250.1.21]) by hawkwind.utcs.toronto.edu with SMTP id <2798>; Tue, 27 Oct 1992 22:59:24 -0500 Received: from sw.oz (via basser) by munnari.oz.au with SunIII (5.83--+1.3.1+0. 50) id AA15520; Wed, 28 Oct 1992 14:58:33 +1100 (from jeremy@sw.oz.au) Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP id AA27137; Wed, 28 Oct 92 15:00:18 AES (5.59) (from jeremy@sw.oz.au for cks%hawkwind.utcs.toronto.edu@munnari.cs.mu.o z.au) Received: by chao.sw.oz.au (4.1/SMI-4.1) id AA01939; Wed, 28 Oct 92 15:00:08 EST From: jeremy@sw.oz.au (Jeremy Fitzhardinge) Message-Id: <9210280400.AA01939@chao.sw.oz.au> Subject: Re: Interesting things from the Plan 9 rc manpage To: cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) Date: Tue, 27 Oct 1992 23:00:07 -0500 Cc: rc@hawkwind.utcs.toronto.edu In-Reply-To: <92Oct27.224004est.2795@hawkwind.utcs.toronto.edu> from "Chris Sie benmann" at Oct 27, 92 10:39:51 pm Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@ G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k} yqshddFb l[EC}c=;uc%x'}uh3E91p&oE Since Plan 9 implements the environment as a filesystem (a single > directory) it wouldn't surprise me if it takes a while to fire up an > rc if you have lots of functions or environment variables. I can't see why that would be a problem. A new process would share the namespace of its parent, including /env, so there's no work that needs to be done by any party. If a new environment needs to be set up, then perhaps there is more work. I suppose an 'rc' would tend to be started with rfork(RFENVG) (meaning "use a copy of the parent's env, but don't share changes), so that may take more time. > When I saw Pike demonstrating 8 1/2 (and when I saw it running on a > 386 portable), I don't think window creation took that long, although > 8 1/2 can hide shell startup delay if it wants to be clever. Pike's claim has always been that a window started in 8 1/2 perceptually instantaneously. I always assumed that means that your shell puts a prompt up pretty quickly after that. Type-ahead helps if your shell is slowish to start up. > The Labs style seems to tend towards a certain sparseness of > environment, so it may have been considered OK by most people. Sparse, but quick. J From rc-owner Tue Oct 27 23:11:21 1992 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.to ronto.edu with SMTP id <2799>; Tue, 27 Oct 1992 23:09:26 -0500 Received: by mail-relay-1.mv.us.adobe.com; id AA01902; Tue, 27 Oct 92 20:09:08 -0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA15404; Tue, 27 Oct 92 20:07:46 PST Date: Tue, 27 Oct 1992 23:07:46 -0500 From: Paul Haahr Message-Id: <9210280407.AA15404@utopia.mv.us.adobe.com> To: jeremy@sw.oz.au Subject: Re: Interesting things from the Plan 9 rc manpage Cc: rc@hawkwind.utcs.toronto.edu > A new process would share the > namespace of its parent, including /env, so there's no work that needs > to be done by any party. yes, but a shell typically reads its entire environment on startup, and all those readdir(), open(), read(), and close() operations can't be free. on the other hand, if they don't cache the environment in the shell, every reference to an environment variable has to do 3 system calls (open, read, close), which is painful in my mind, but maybe rob's right when he says you shouldn't worry about system call overhead. thinking about it, they probably have to use the latter approach, because otherwise you can't take advantage of the sharing of environments between processes that plan 9 offers. anyway, this is all idle speculation. From rc-owner Tue Oct 27 23:23:14 1992 Received: from munnari.oz.au ([128.250.1.21]) by hawkwind.utcs.toronto.edu with SMTP id <2801>; Tue, 27 Oct 1992 23:20:57 -0500 Received: from sw.oz (via basser) by munnari.oz.au with SunIII (5.83--+1.3.1+0. 50) id AA16363; Wed, 28 Oct 1992 15:20:01 +1100 (from jeremy@sw.oz.au) Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP id AA27408; Wed, 28 Oct 92 15:20:56 AES (5.59) (from jeremy@sw.oz.au for haahr%mv.us.adobe.com@munnari.cs.mu.oz.au) Received: by chao.sw.oz.au (4.1/SMI-4.1) id AA02032; Wed, 28 Oct 92 15:20:48 EST From: jeremy@sw.oz.au (Jeremy Fitzhardinge) Message-Id: <9210280420.AA02032@chao.sw.oz.au> Subject: Re: Interesting things from the Plan 9 rc manpage To: haahr@mv.us.adobe.com (Paul Haahr) Date: Tue, 27 Oct 1992 23:20:47 -0500 Cc: jeremy@sw.oz.au, rc@hawkwind.utcs.toronto.edu In-Reply-To: <9210280407.AA15404@utopia.mv.us.adobe.com> from "Paul Haahr" at O ct 27, 92 08:07:46 pm Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@ G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k} yqshddFb l[EC}c=;uc%x'}uh3E91p&oE > A new process would share the namespace of its parent, including /env, > > so there's no work that needs to be done by any party. > > yes, but a shell typically reads its entire environment on startup, and > all those readdir(), open(), read(), and close() operations can't be free. > on the other hand, if they don't cache the environment in the shell, > every reference to an environment variable has to do 3 system calls > (open, read, close), which is painful in my mind, but maybe rob's right > when he says you shouldn't worry about system call overhead. > > thinking about it, they probably have to use the latter approach, because > otherwise you can't take advantage of the sharing of environments between > processes that plan 9 offers. Despite Pike's well known resistance to memory mapped files, this looks like at least one pretty good application for them. Really, that's what segattach() is, but it has its own special name-space (the class), rather than going through the filesystem namespace. True, that's not the intent, but it loses generality to be otherwise. Are we off topic yet? > anyway, this is all idle speculation. Fun, isn't it? Need something to fill a mailbox while people stop arguing abou t job control in es. J -- jeremy@sw.oz.au ph:+61 2 698 2322-x122 fax:+61 2 699 9174 While the earth dies dreaming, I lie screaming. From rc-owner Tue Oct 27 23:29:59 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2805>; Tue, 27 Oct 1992 23:28:10 -0500 To: rc Subject: Re: Interesting things from the Plan 9 rc manpage In-reply-to: haahr's message of Tue, 27 Oct 92 23:07:46 -0500. <9210280407.AA15404@utopia.mv.us.adobe.com> Date: Tue, 27 Oct 1992 23:27:53 -0500 From: Chris Siebenmann Message-Id: <92Oct27.232810est.2805@hawkwind.utcs.toronto.edu> The Plan 9 rc appears to keep plain environment variables in the environment, and not parse them out; however, it does scan the environment on startup to detect and parse function defenitions. - cks From rc-owner Tue Oct 27 23:50:28 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2806>; Tue, 27 Oct 1992 23:48:27 -0500 To: rc Subject: a difference between Duff's rc and Byron's Date: Tue, 27 Oct 1992 23:48:25 -0500 From: Chris Siebenmann Message-Id: <92Oct27.234827est.2806@hawkwind.utcs.toronto.edu> (I stumbled across this trying to do timing trials on both) "rc -lc 'command'" runs your .rcrc in Duff's rc, but does not in Byron's. - cks From rc-owner Wed Oct 28 00:13:14 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2809>; Wed, 28 Oct 1992 00:10:53 -0500 To: rc Subject: Re: Interesting things from the Plan 9 rc manpage Date: Wed, 28 Oct 1992 00:10:49 -0500 From: Chris Siebenmann Message-Id: <92Oct28.001053est.2809@hawkwind.utcs.toronto.edu> Scott Schwartz asks about a performance comparison between Duff's rc and Byron's. Unfortunately, I can't really give one; I've only looked at Duff's rc for comparison purposes, never for actual use (especially as it lacks a number of amenities I use heavily, such as a prompt function). Duff's rc compiles to a somewhat bigger binary on this machine, and seems to start up new shells a bit slower. Contributions of benchmarks will produce more extensive measurements for the curious; I can't think of any good ones. The -I option is mentioned in the mk manpage, which says that it runs recipies by supplying them as standard input to 'rc -e -I' (-e is omitted if errors are being ignored). I suspect that the claim that Plan 9 rc prompts only when reading from a terminal is inaccurate, and that if given no arguments it always prompts (unless given -I); that would explain the need for it and the mention in mk's manpage. Anyone know Tom Duff well enough to send him email asking about it? - cks From rc-owner Wed Oct 28 01:27:25 1992 Received: from joyce.cs.su.OZ.AU ([129.78.8.208]) by hawkwind.utcs.toronto.edu with SMTP id <2810>; Wed, 28 Oct 1992 01:23:59 -0500 To: byron@netapp.com, rc@hawkwind.utcs.toronto.edu Message-ID: <19921028155943.1634.frobozz@orthanc.cs.su.OZ.AU> In-Reply-To: <9210280117.AA25914@netapp.netapp.com> From: matty@cs.su.oz.au (James Matthew Farrow) Date: Wed, 28 Oct 1992 00:59:43 -0500 Organisation: Basser Dept of Computer Science, Sydney University, Australia X-Name: Boggo the Wonder Cat X-Face: (U?GH?osc&;NtYo%_FS>9<5bs*|E$grN|sun}Rqt'daJ6(yXXs4dr}`_@gc:q1Y_ xA%VF^,4h=}},mu?*~pcrAk2,{4D")109dr=+JCp&BDS(*]5RnZQ+Fehl;hI!t-( z{JHWYQ6CzsEBllWb,(ojs'2X!Iw?R22RtA|6Qc.gIie=,=NCp`?0^F^tF=>HWTv!h#WCDgGp.WVc& X-Mailer: Frobozz Magic Mailer [1.5] Subject: Re: Interesting things from the Plan 9 rc manpage > Date: Tue, 27 Oct 1992 20:17:47 -0500 > From: byron@netapp.com (Byron Rakitzis) > Message-Id: <9210280117.AA25914@netapp.netapp.com> > To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu > Subject: Re: Interesting things from the Plan 9 rc manpage > > -s: Print out exit status after any command where the > status is non-null (false). > > This can be done with an appropriate fn prompt in my rc. Surely this won't work for non-interactive files. On Plan 9's, rc does print the status when invoked non-interactively, I just checked. Matty. -- James Matthew Farrow | "For in that moment I beheld the ruin matty@cs.su.OZ.AU | of my existence. My world fell dark Basser Department of Computer Science | and my life became a shallow dream. Sydney University - FAX: +61 2 692 3838 | `Odi et amo. Excrucior.'" - Tlindah From rc-owner Wed Oct 28 02:02:55 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2813>; Wed, 28 Oct 1992 02:00:53 -0500 To: rc Subject: Re: a difference between Duff's rc and Byron's In-reply-to: cks's message of Tue, 27 Oct 92 23:48:25 -0500. <92Oct27.234827est.2806@hawkwind.utcs.toronto.edu> Date: Wed, 28 Oct 1992 02:00:39 -0500 From: Chris Siebenmann Message-Id: <92Oct28.020053est.2813@hawkwind.utcs.toronto.edu> It appears I must have slipped up somewhere; 'rc -lc 'command'' properly runs your .rcrc before executing the command. - cks From rc-owner Wed Oct 28 05:44:49 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2771>; Wed, 28 Oct 1992 05:44:00 -0500 To: rc Subject: why I though 'rc -lc 'command'' didn't source .rcrc Date: Wed, 28 Oct 1992 05:43:57 -0500 From: Chris Siebenmann Message-Id: <92Oct28.054400est.2771@hawkwind.utcs.toronto.edu> I was testing rc in a 'clean' environment in order to get consistent timings, via 'env - time ...'. When I tested Duff's rc, I listed an explicit value for $HOME, since I was using startup files that would work with it. When I tested Byron's rc, I forgot to specify a 'HOME=...' entry (under the mental fog of thinking this would use the one in my environment); of course, rc had no $HOME, had no idea of where to look for .rcrc, and so couldn't run it. I'm not certain if it's worth printing out an error message if things don't seem to make sense, and in any case this is not (by any means!) a common occurrence. Might be something to think about, though. - cks From rc-owner Wed Oct 28 10:42:31 1992 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.to ronto.edu with SMTP id <2771>; Wed, 28 Oct 1992 10:28:53 -0500 Received: by mail-relay-1.mv.us.adobe.com; id AA02922; Wed, 28 Oct 92 07:28:23 -0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA17758; Wed, 28 Oct 92 07:27:00 PST Date: Wed, 28 Oct 1992 10:27:00 -0500 From: Paul Haahr Message-Id: <9210281527.AA17758@utopia.mv.us.adobe.com> To: cks@hawkwind.utcs.toronto.edu Subject: Re: Interesting things from the Plan 9 rc manpage Cc: rc@hawkwind.utcs.toronto.edu > I > suspect that the claim that Plan 9 rc prompts only when reading > from a terminal is inaccurate, and that if given no arguments > it always prompts (unless given -I) this makes sense, since the plan9 version of isatty() is likely not to be correct, according to the documentation. From rc-owner Thu Oct 29 11:01:15 1992 Received: from gatech.edu ([128.61.1.1]) by hawkwind.utcs.toronto.edu with SMTP id <2756>; Thu, 29 Oct 1992 10:57:13 -0500 Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA09258 for rc@hawkwind.utcs.toronto.edu; Thu, 29 Oct 92 10:57:05 ES T Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA09905; for rc@hawkwind.utcs.toronto.edu; Thu, 29 Oct 92 10:57:02 E ST Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA09110; Thu, 29 Oct 92 10:56:34 EST From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9210291556.AA09110@penfold.cc.gatech.edu> Date: Thu, 29 Oct 1992 10:56:34 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: rc@hawkwind.utcs.toronto.edu Subject: minimalism > From: byron@netapp.com (Byron Rakitzis) > Message-Id: <9210280117.AA25914@netapp.netapp.com> > > It's too slow and too big. > > I think that's just a Bell Labs pissing contest. Over there your macho- > ness as a programmer is measured in inverse proportion to the number > of lines of code you produce for a given task. Yes, Minimalism is an absolute there. Unfortunately, sometimes minimalism makes it hard to get Real Work (tm) done. Compare Perl to Awk sometime. Perl is a Gosh-awful mess to read, but people with real work to do love it. I think there are things that could be added to awk to make it more useful in the ways Perl is, but you have to be careful. "What's his point?" you're all muttering... Minimalism is good as a goal, but you shouldn't let it get in the way; if you really need a feature, add it. A good example is the -u flag on sort. It was added because so many people were just calling uniq anyway, and it made things go more efficiently. Just another point of view from the awk guy over in the corner. Arnold Robbins --- College of Computing | Ping is the screw- Georgia Tech, Atlanta, GA 30332-0280 | driver of network Domain: arnold@cc.gatech.edu Phone: +1 404 894 9214 | debugging tools. UUCP: uunet!cc.gatech.edu!arnold FAX: +1 404 853 9378 | -- me From rc-owner Mon Nov 2 17:16:56 1992 Received: from relay1.UU.NET ([137.39.1.5]) by hawkwind.utcs.toronto.edu with S MTP id <2776>; Mon, 2 Nov 1992 17:13:37 -0500 Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27713; Mon, 2 Nov 92 17:13:29 -0500 Received: from lisa.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA25701; Mon, 2 Nov 92 14:13:28 PST Received: by lisa.cygnus.com (5.0/SMI-SVR4) id AA02884; Mon, 2 Nov 92 14:20:47 PST Date: Mon, 2 Nov 1992 17:20:47 -0500 From: brendan@cygnus.com Message-Id: <9211022220.AA02884@lisa.cygnus.com> To: rc mailing list Subject: using ~ for $home Reply-To: brendan@cygnus.com Content-Length: 310 I've tried to get by without it, but I always find myself getting annoyed at rc when I have to type $home all the time, instead of `~'. So I've just decided I want it in there. Before I go in and hack on it, has anyone else already done it? (Replace ~ at the beginning of an argument with $home.) Brendan From rc-owner Mon Nov 2 17:28:06 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2779>; Mon, 2 Nov 1992 17:27:35 -0500 To: rc Subject: a feature I wish rc had Date: Mon, 2 Nov 1992 17:27:29 -0500 From: Chris Siebenmann Message-Id: <92Nov2.172735est.2779@hawkwind.utcs.toronto.edu> rc has convenient ways of adding things to a list, but it has no particularly easy way of doing the converse, taking something out of one. It would be especially powerful if one could take things out of implicit lists, ie say 'all filenames of this pattern, except filenames of that pattern' conveniently. Just today's gratuitious feature idea (well, not too gratuitious). - cks From rc-owner Mon Nov 2 17:38:53 1992 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.to ronto.edu with SMTP id <2780>; Mon, 2 Nov 1992 17:38:14 -0500 Received: by mail-relay-1.mv.us.adobe.com; id AA19254; Mon, 2 Nov 92 14:38:00 - 0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA09994; Mon, 2 Nov 92 14:36:31 PST Date: Mon, 2 Nov 1992 17:36:31 -0500 From: Paul Haahr Message-Id: <9211022236.AA09994@utopia.mv.us.adobe.com> Received: by NeXT Mailer (1.63) To: Chris Siebenmann Subject: Re: a feature I wish rc had Cc: es mailing list , rc mailing list > rc has convenient ways of adding things to a list, but it has > no particularly easy way of doing the converse, taking something > out of one. It would be especially powerful if one could take things > out of implicit lists, ie say 'all filenames of this pattern, except > filenames of that pattern' conveniently. i've always wanted this in a shell, but never found a convenient notation for it. if someone can suggest one, it's certainly a potential es feature. i just use ``ls|grep -v'' usually. From rc-owner Mon Nov 2 22:55:45 1992 Received: from gatech.edu ([128.61.1.1]) by hawkwind.utcs.toronto.edu with SMTP id <2776>; Mon, 2 Nov 1992 22:55:01 -0500 Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA16860 for rc@hawkwind.utcs.toronto.edu; Mon, 2 Nov 92 22:54:45 EST Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA06978; for rc@hawkwind.utcs.toronto.edu; Mon, 2 Nov 92 22:54:40 ES T Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA11141; Mon, 2 Nov 92 22:54:12 EST Date: Mon, 2 Nov 1992 22:54:12 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9211030354.AA11141@penfold.cc.gatech.edu> To: rc@hawkwind.utcs.toronto.edu Subject: file globbing > rc has convenient ways of adding things to a list, but it has > no particularly easy way of doing the converse, taking something > out of one. It would be especially powerful if one could take things > out of implicit lists, ie say 'all filenames of this pattern, except > filenames of that pattern' conveniently. The, ahem, Korn shell, has an extended pattern matching notation: *(pat1|pat2|..) zero or more of pat1, pat2, ... ?(pat1|pat2|..) one or zero of pat1, pat2, ... +(pat1|pat2|..) one or more of pat1, pat2, ... @(pat1|pat2|..) exactly one of pat1, pat2, ... !(pat1|pat2|..) anything that does not match pat1, pat2... I find the most useful to be stuff like $ ls !(*.o|core) I don't use it a lot, mostly I suspect because it's a fairly new feature. Arnold From rc-owner Tue Nov 3 13:07:36 1992 Received: from relay1.UU.NET ([137.39.1.5]) by hawkwind.utcs.toronto.edu with S MTP id <2779>; Tue, 3 Nov 1992 13:07:01 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26305; Tue, 3 Nov 92 13:06:55 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 130512.5604; Tue, 3 Nov 1992 13:05:12 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa05646; Tue, 3 Nov 92 11:10:01 EST From: culliton@srg.srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: cks@hawkwind.utcs.toronto.edu, haahr@mv.us.adobe.com Subject: Re: a feature I wish rc had Cc: es@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Date: Tue, 3 Nov 1992 11:10:54 -0500 Message-Id: <9211031110.aa20698@ceres.srg.af.mil> >> It would be especially powerful if one could take things >> out of implicit lists, ie say 'all filenames of this pattern, except >> filenames of that pattern' conveniently. >i've always wanted this in a shell, but never found a convenient notation >for it. if someone can suggest one, it's certainly a potential es feature. > >i just use ``ls|grep -v'' usually. I usually use sed to do this kind of list manipulation, for example when we have net problems one of the following works quite well to pull the NFS mounted partions out of my path. path=`{echo $path | sed 's:/usr/share/bin::'} eval `{whatis path | sed 's:/usr/share/bin::'} The second could easily be turned into a general function to do the job, but being able to fetch it out of my history makes that more bother (and clutter in the environment) than it's worth. Anybody feel like producing an all builtin function for this? Something like "remove pattern list" or "remove index list". It shouldn't be too hard. From rc-owner Tue Nov 3 14:54:18 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2779>; Tue, 3 Nov 1992 14:53:24 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA06108; Tue, 3 Nov 92 14:53:17 -0500 Received: by earth.osf.org (5.65/4.7) id AA09196; Tue, 3 Nov 92 14:53:16 -0500 Date: Tue, 3 Nov 1992 14:53:16 -0500 From: rsalz@osf.org Message-Id: <9211031953.AA09196@earth.osf.org> To: cks@hawkwind.utcs.toronto.edu, culliton@srg.srg.af.mil, haahr@mv.us.adobe.com Subject: Re: a feature I wish rc had Cc: es@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu >Anybody feel like producing an all builtin function for this? >Something like "remove pattern list" or "remove index list". It >shouldn't be too hard. Trivial: fn remove { pat=() i=() list=() { pat=$1 shift || { echo 'Usage erorr' >[1=2] ; return 1; } for (i) eval ~ $i $pat || list=($list $i) echo $list } } remove '*.c' foo.c bar baz.c path=`{remove /usr/share/bin $path} From rc-owner Tue Nov 3 17:33:09 1992 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.to ronto.edu with SMTP id <2776>; Tue, 3 Nov 1992 17:32:43 -0500 Received: by mail-relay-1.mv.us.adobe.com; id AA23345; Tue, 3 Nov 92 14:32:07 - 0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA02604; Tue, 3 Nov 92 14:32:34 PST Date: Tue, 3 Nov 1992 17:32:34 -0500 From: Paul Haahr Message-Id: <9211032232.AA02604@utopia.mv.us.adobe.com> To: rsalz@osf.org Subject: Re: a feature I wish rc had Cc: es@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu yes, these are all good suggestions, but they don't feel right to me. what i want is some notation for saying save (*.[ch] - y.tab.c xxx.*) while, of course, would generate all .c and .h files other than y.tab.c and anything that matched xxx.*. note that, in this hypothetical, the things after the - are not glob expaned but just used to filter the list. and while i could probably come up with a remove operation that had the same semantics, it's missing the notational convenience. on the other hand, i'm not sure i'd want to use a shell that had such syntax in it. (by the way: i tend to dislike using eval to get around the meta-character rules, but that's just my hangup.) From rc-owner Tue Nov 3 17:44:07 1992 Received: from linc.cis.upenn.edu ([130.91.6.8]) by hawkwind.utcs.toronto.edu w ith SMTP id <2779>; Tue, 3 Nov 1992 17:43:41 -0500 Received: from SAUL.CIS.UPENN.EDU by linc.cis.upenn.edu id AA22175; Tue, 3 Nov 92 17:43:30 -0500 Return-Path: Received: from LOCALHOST.upenn.edu by saul.cis.upenn.edu id AA22431; Tue, 3 Nov 92 17:43:29 EST Posted-Date: Tue, 03 Nov 92 17:43:28 EST Message-Id: <9211032243.AA22431@saul.cis.upenn.edu> To: Paul Haahr Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: a feature I wish rc had In-Reply-To: Your message of "Tue, 03 Nov 92 17:32:34 EST." <9211032232.AA02604@utopia.mv.us.adobe.com> Date: Tue, 3 Nov 1992 17:43:28 -0500 From: Mark-Jason Dominus > save (*.[ch] - y.tab.c xxx.*) > > note that, in this hypothetical, the things after the - are not glob > expanded Why not? Consider a `set-subtract' command, which is a little like `echo'. set-subtract [foo]... - [bar]... echoes all the words that are on the left of the `-' but not on the right. Then instead of > save ( *.[ch] - y.tab.c xxx.* ) use save `{ set-subtract *.[ch] - y.tab.c xxx.* } The globbing is just what you want. From rc-owner Tue Nov 3 19:06:43 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2776>; Tue, 3 Nov 1992 19:06:27 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA11756; Tue, 3 Nov 92 17:03:16 PPE Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA00168; Tue, 3 Nov 92 15:44:01 PST Date: Tue, 3 Nov 1992 18:44:01 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9211032344.AA00168@netapp.netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: set subtract Given two lists a and b, it is possible to do set subtract in rc with the ~ operator: for (i in $a) if (!~ $i $b) echo $i So all that you need to do is write a function to build these two lists based on the [a] - [b] syntax suggested. Something like this: fn set-subtract { a=() while () { switch ($1) { case () echo usage: $0 'foo - bar' >[1=2] return 1 case - shift break case * a=($a $1) shift } } for (i in $a) if (!~ $i $*) echo $i } (Btw, I would choose a shorter name than set-subtract. Sort of reminds me of the regexp syntax that Nicklaus Wirth uses in his Oberon system. I think it's straight BNF. To say .* you have to write it as {~c}. Or even worse, foo*bar becomes "fo"{"o"}"bar". Does he really use this tool, or expect anyone else to? But I digress..) From rc-owner Tue Nov 3 19:42:49 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2776>; Tue, 3 Nov 1992 19:42:34 -0500 To: rc Subject: Re: set subtract In-reply-to: byron's message of Tue, 03 Nov 92 18:44:01 -0500. <9211032344.AA00168@netapp.netapp.com> Date: Tue, 3 Nov 1992 19:42:18 -0500 From: Chris Siebenmann Message-Id: <92Nov3.194234est.2776@hawkwind.utcs.toronto.edu> The problem with a set-subtract function is that it will loose quoting information if it's used as 'foo `{set-sub ....}', and you thus need to have it passed variable names to work on. But then you can't just use this on a command line; you have to build lists beforehand. About half the time I'd like to use this is on command lines, so I keep wishing for a better solution. - cks From rc-owner Tue Nov 3 20:28:34 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2776>; Tue, 3 Nov 1992 20:28:07 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2625>; Tue, 3 Nov 1992 20:27:17 -0500 To: Paul Haahr cc: Chris Siebenmann , es mailing list , rc mailing list Subject: Re: a feature I wish rc had In-reply-to: Your message of "Mon, 02 Nov 92 17:36:31 EST." <9211022236.AA09994@utopia.mv.us.adobe.com> Date: Tue, 3 Nov 1992 20:26:52 -0500 From: Scott Schwartz Message-Id: <92Nov3.202717est.2625@groucho.cs.psu.edu> | i've always wanted this in a shell, but never found a convenient notation | for it. if someone can suggest one, it's certainly a potential es feature. One idea is to add list comprehensions to your language. List comprehensions are the list version of set builder notation. They have the same power as nested for loops, but with a more compact syntax. From rc-owner Wed Nov 4 07:46:33 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2776>; Wed, 4 Nov 1992 07:45:30 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA07623; Wed, 4 Nov 92 13:45:01 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA17936; Wed, 4 Nov 92 13:45:00 +0100 Date: Wed, 4 Nov 1992 07:45:00 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9211041245.AA17936@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: set subtract In-Reply-To: Mail from 'Chris Siebenmann ' dated: Tue, 3 Nov 1992 19:42:18 -0500 The problem with a set-subtract function is that it will loose quoting information if it's used as 'foo `{set-sub ....}', and you thus need to have it passed variable names to work on. But then you can't just use this on a command line; you have to build lists beforehand. About half the time I'd like to use this is on command lines, so I keep wishing for a better solution. - cks Applause, applause! I'd vote for making such a function built into rc to avoid meta character trouble, the way the ~ operator does it. A related builtin I always wanted to have: idx = `{ index list_of_patterns list_to_search_in } This should return a list of indices of the search patterns in the second list. ; echo `{ index a ( a b c a ) } 1 4 ; Malte From rc-owner Wed Nov 4 09:13:42 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2776>; Wed, 4 Nov 1992 09:13:06 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA29032; Wed, 4 Nov 92 09:12:37 -0500 Received: by earth.osf.org (5.65/4.7) id AA11509; Wed, 4 Nov 92 09:12:36 -0500 Date: Wed, 4 Nov 1992 09:12:36 -0500 From: rsalz@osf.org Message-Id: <9211041412.AA11509@earth.osf.org> To: malte@techfak.uni-bielefeld.de, rc@hawkwind.utcs.toronto.edu Subject: Re: set subtract >A related builtin I always wanted to have: > idx = `{ index list_of_patterns list_to_search_in } >This should return a list of indices of the search patterns in the second list . > ; echo `{ index a ( a b c a ) } > 1 4 Easy; the following just uses built-ins. Note that it implements the example (first arg is a pattern, not a list of patterns); I don't believe the synopsis can be done. fn index { pat=() i=() result=() count=() { pat=$1 shift || { echo 'Usage error' >[1=2] ; return 1 } for (i) { count=(a $count) eval ~ $i $pat && result=($result $#count) } echo $result } } From rc-owner Wed Nov 4 09:26:52 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2779>; Wed, 4 Nov 1992 09:25:55 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA10553; Wed, 4 Nov 92 15:25:34 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA18713; Wed, 4 Nov 92 15:25:33 +0100 Date: Wed, 4 Nov 1992 09:25:33 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9211041425.AA18713@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: set subtract In-Reply-To: Mail from 'rsalz@osf.org' dated: Wed, 4 Nov 1992 09:12:36 -0500 Easy; the following just uses built-ins. Note that it implements the example (first arg is a pattern, not a list of patterns); I don't believe the synopsis can be done. fn index { pat=() i=() result=() count=() { pat=$1 shift || { echo 'Usage error' >[1=2] ; return 1 } for (i) { count=(a $count) eval ~ $i $pat && result=($result $#count) } echo $result } } Fine, this is similar to what I do now. Why a built in command ? Imagine $pat has a value of '$something'. This will break it. Malte From rc-owner Thu Nov 5 14:41:38 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2776>; Thu, 5 Nov 1992 14:38:55 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA26946; Thu, 5 Nov 92 20:38:40 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA00902; Thu, 5 Nov 92 20:38:39 +0100 Date: Thu, 5 Nov 1992 14:38:39 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9211051938.AA00902@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: rc echos newlines when killed Does anybody know why rc-1.4 echos a newline on stderr when killed by sigint ? #!/vol/local/bin/rcscript -p fn alarm { { sleep $1; kill -INT $pid }& } alarm 3 while( ); echo not reached When invoking this script as alarm, alarm >[2=1] | od -c the output is 0000000 \n 0000001 Malte From rc-owner Thu Nov 5 15:46:24 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2776>; Thu, 5 Nov 1992 15:45:52 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA27097; Thu, 5 Nov 92 21:45:34 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA01130; Thu, 5 Nov 92 21:45:32 +0100 Date: Thu, 5 Nov 1992 15:45:32 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9211052045.AA01130@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: rc and signal handlers I just came across a situation were I want to temporarily change the sematics of a signal handler, say during the execution of a function. fn doit { sighdlr = `` $nl { whatis -s | fgrep 'fn sigint' } ... eval $sighdlr } doesn't work, of course. What is needed is a kind of local signal handler, or a way to put a signal handler definition into a variable like fn doit { whatis fn sigint var ... eval $var } I suggest local signal handlers and local functions. Also, the man-page is not too clear about signals: "Only signals that are being ignored are passed on to programs run by r c" The should read "signals that are being caught", I guess. Signal handler definitions look like functions but are *not*; it should be stated that one cannot "return" from a signal handler. Malte From rc-owner Thu Nov 5 17:06:41 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2776>; Thu, 5 Nov 1992 17:06:28 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA10953; Thu, 5 Nov 92 15:00:13 PPE Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA21626; Thu, 5 Nov 92 14:00:28 PST Date: Thu, 5 Nov 1992 17:00:28 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9211052200.AA21626@netapp.netapp.com> To: malte@techfak.uni-bielefeld.de, rc@hawkwind.utcs.toronto.edu Subject: Re: rc and signal handlers signal handlers ARE function definitions. They just have the added feature that they get run at "interrupt level". If it's not obvious that you can't "return" from a signal handler, then you need to think a little more carefully about what signals are. btw, ; fn sigint { echo hi } ; sigint hi ; From rc-owner Thu Nov 5 18:16:38 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2776>; Thu, 5 Nov 1992 18:16:09 -0500 To: rc Subject: Re: rc and signal handlers In-reply-to: malte's message of Thu, 05 Nov 92 15:45:32 -0500. <9211052045.AA01130@dahlie.techfak.uni-bielefeld.de> Date: Thu, 5 Nov 1992 18:16:05 -0500 From: Chris Siebenmann Message-Id: <92Nov5.181609est.2776@hawkwind.utcs.toronto.edu> | Also, the man-page is not too clear about signals: | "Only signals that are being ignored are passed on to programs run by rc" | The should read "signals that are being caught", I guess. The manpage is correct as written; caught signals are not passed on to children, and revert to default behavior. Only ignored signals are passed on to children. If one thinks about how catching signals works, it becomes obvious that this has to be that way. - cks From rc-owner Thu Nov 5 19:29:52 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2780>; Thu, 5 Nov 1992 19:29:33 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA26499; Thu, 5 Nov 92 17:26:20 PPE Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA12616; Thu, 5 Nov 92 16:28:29 PST Date: Thu, 5 Nov 1992 19:28:29 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9211060028.AA12616@netapp.netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: aha I understand now the complaint about "signal handlers not being functions" The problem is that the rc signal handler does not invoke signal-functions the same way that functions are normally invoked. So far the only difference I noticed is that "return" is not handled. I am inclined to make the two the same, if only because it simplifies the interface. It also means that you will be able to set $status from within a signal handler by using "return", for whatever that's worth. From rc-owner Thu Nov 5 20:43:29 1992 Received: from relay2.UU.NET ([137.39.1.7]) by hawkwind.utcs.toronto.edu with S MTP id <2776>; Thu, 5 Nov 1992 20:43:08 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA15084; Thu, 5 Nov 92 20:43:05 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 203829.28455; Thu, 5 Nov 1992 20:38:29 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa29894; Thu, 5 Nov 92 20:22:07 EST From: culliton@srg.srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: byron@netapp.com, rc@hawkwind.utcs.toronto.edu Subject: Re: aha Date: Thu, 5 Nov 1992 20:22:28 -0500 Message-Id: <9211052022.aa01582@ceres.srg.af.mil> br> I am inclined to make the two the same, if only because br> it simplifies the interface. It also means that you br> will be able to set $status from within a signal handler br> by using "return", for whatever that's worth. EEK! Asynchronously? Like between "if ( ! command )" and "echo command failed with status $status"? Sounds iffy to me. OBNiggle - The man page says the following about wait: "If no pid is specified, rc waits for >>ANY<< child process to exit." Which would be OK because you can always say "while (! ~ $#apids 0) wait", but it is not the way things really work. The man page should say: "If no pid is specified, rc waits for all child processes to exit." From rc-owner Thu Nov 5 21:28:14 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2776>; Thu, 5 Nov 1992 21:27:51 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA09138; Thu, 5 Nov 92 19:24:44 PPE Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA08482; Thu, 5 Nov 92 18:25:59 PST Date: Thu, 5 Nov 1992 21:25:59 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9211060225.AA08482@netapp.netapp.com> To: netcom!uunet.uu.net!srg!culliton@netcom.com, rc@hawkwind.utcs.toronto.edu Subject: Re: aha Wait! $status already gets set asynchronously with signal handlers every time they run a command. So perhaps the signal handler code should stash away the old $status and restore it after the signal handler is done running. (I didn't mean to open a can of worms, I think setting $status asynchronously is a really stupid idea, and I am merely suggesting that this aspect of rc be cleaned up for 1.5.) From rc-owner Fri Nov 6 03:06:42 1992 Received: from mail.swip.net ([192.71.220.11]) by hawkwind.utcs.toronto.edu wit h SMTP id <2776>; Fri, 6 Nov 1992 03:05:56 -0500 Received: by mail.swip.net (5.65c8/1.2) id AA27853; Fri, 6 Nov 1992 09:05:35 +0100 Received: from lynx.analytikerna by analytikerna.se (4.1/SMI-4.1) id AA04710; Fri, 6 Nov 92 09:07:00 +0100 Date: Fri, 6 Nov 1992 03:07:00 -0500 From: bk@analytikerna.se (Bengt KLEBERG) Message-Id: <9211060807.AA04710@analytikerna.se> To: rc@hawkwind.utcs.toronto.edu Subject: signal handlers and functions If this is a question that needs input from users I would say that it is much easier to have one kind of functions, and that these functions handle signals, too. Bengt From rc-owner Fri Nov 6 07:05:15 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2776>; Fri, 6 Nov 1992 07:03:55 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA04434; Fri, 6 Nov 92 13:03:36 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA01626; Fri, 6 Nov 92 13:03:35 +0100 Date: Fri, 6 Nov 1992 07:03:35 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9211061203.AA01626@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: rc and signal handlers In-Reply-To: Mail from 'Chris Siebenmann ' dated: Thu, 5 Nov 1992 18:16:05 -0500 | Also, the man-page is not too clear about signals: | "Only signals that are being ignored are passed on to programs run b y rc" | The should read "signals that are being caught", I guess. The manpage is correct as written; caught signals are not passed on to children, and revert to default behavior. Only ignored signals are pass ed on to children. If one thinks about how catching signals works, it becomes obvious tha t this has to be that way. - cks This is perfectly true! But also ugly ! This way, one has to redefine signal handlers for each backquote substitution. On BSD and System V children inherit signal handlers when forking and one has to change them explicitly. Could someone explain to me why rc does it automatically ? I'd rather prefer a simple way to reset signal handlers, something like fn sigreset { for( sig in `{ whatis -s | cut -f2 '-d ' } ) eval fn $sig } About "return"ing from a signal handler: One really doesn't want to do that. I just mentioned it to make it clear to beginners. What bothers me most is that rc doesn't complain about a return when defining the function and that everything is fine when invoking the function interactively. But, when the signal is caught, you'll get "return outside of function". Malte From rc-owner Fri Nov 6 07:16:29 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2780>; Fri, 6 Nov 1992 07:15:12 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA04472; Fri, 6 Nov 92 13:15:00 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA01731; Fri, 6 Nov 92 13:14:58 +0100 Date: Fri, 6 Nov 1992 07:14:58 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9211061214.AA01731@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: aha In-Reply-To: Mail from 'byron@netapp.com (Byron Rakitzis)' dated: Thu, 5 Nov 1992 21:25:59 -0500 Wait! $status already gets set asynchronously with signal handlers every time they run a command. Works great! Instead of fn sigint { return 1 } while( ~ $status(0) 0 ) { ... } I use fn false { return 1 } fn sigint { false } while( ~ $status(0) 0 ) { ... } So perh aps the signal handler code should stash away the old $status and restore it after the signal handler is done running. This make it impossible (I think) to program something as "do this as long as it works but not longer than 10 seconds". Malte From rc-owner Fri Nov 6 08:30:25 1992 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.to ronto.edu with SMTP id <2782>; Fri, 6 Nov 1992 08:29:14 -0500 Received: by mail-relay-1.mv.us.adobe.com; id AA03655; Fri, 6 Nov 92 05:29:08 - 0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA07295; Fri, 6 Nov 92 05:29:21 PST Date: Fri, 6 Nov 1992 08:29:21 -0500 From: Paul Haahr Message-Id: <9211061329.AA07295@utopia.mv.us.adobe.com> To: malte@techfak.uni-bielefeld.de Subject: Re: aha Cc: rc@hawkwind.utcs.toronto.edu [ Byron's suggestion to save the status before and restore it after doing signal processing, which i agree with 100%.] > This make it impossible (I think) to program something as "do this as long > as it works but not longer than 10 seconds". not at all. instead of writing fn false { return 1 } fn sigint { false } while( ~ $status(0) 0 ) { ... } just do interrupted = false fn sigint { interrupted = true } while (!~ $interrupted true) { ... } From rc-owner Fri Nov 6 08:37:36 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2785>; Fri, 6 Nov 1992 08:36:20 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA04957; Fri, 6 Nov 92 14:36:11 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA01855; Fri, 6 Nov 92 14:36:09 +0100 Date: Fri, 6 Nov 1992 08:36:09 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9211061336.AA01855@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: aha In-Reply-To: Mail from 'Paul Haahr ' dated: Fri, 6 Nov 92 05:29:21 PST interrupted = false fn sigint { interrupted = true } while (!~ $interrupted true) { ... } To be precise: while (!~ $interrupted true) {{ ... } || break } Malte From rc-owner Fri Nov 6 12:17:57 1992 Received: from gatech.edu ([128.61.1.1]) by hawkwind.utcs.toronto.edu with SMTP id <2776>; Fri, 6 Nov 1992 12:17:33 -0500 Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA02988 for rc@hawkwind.utcs.toronto.edu; Fri, 6 Nov 92 12:17:22 EST Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA07416; for don.deal@oit.gatech.edu; Fri, 6 Nov 92 12:17:20 EST Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA12502; Fri, 6 Nov 92 12:16:54 EST Date: Fri, 6 Nov 1992 12:16:54 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9211061716.AA12502@penfold.cc.gatech.edu> To: rc@hawkwind.utcs.toronto.edu Subject: printing the plan 9 manuals Has anybody successfully printed the plan 9 doc on a printer using QMS's Ultrascript posctscrpt interpreter. Our central computing organization has a Kodak high speed duplexing postscript printer that uses this and it choked on several of the docs. The ``support'' person send me the errors and that was it. No response as to whether they could take the problem up with Kodak. So, before I go asking Rob Pike what kind of printers they use & how they generated the postscript, I thought I'd ask others what their experience was. (I know this isn't rc related, but I didn't want to do a general net broadcast yet.) Thanks, Arnold Robbins --- College of Computing | Ping is the screw- Georgia Tech, Atlanta, GA 30332-0280 | driver of network Domain: arnold@cc.gatech.edu Phone: +1 404 894 9214 | debugging tools. UUCP: uunet!cc.gatech.edu!arnold FAX: +1 404 853 9378 | -- me From rc-owner Sat Nov 7 00:02:15 1992 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu w ith SMTP id <2776>; Sat, 7 Nov 1992 00:00:59 -0500 Received: by quux.es.su.oz.au id <14650>; Sat, 7 Nov 1992 15:00:28 +1000 From: noel@es.su.oz.au Date: Fri, 6 Nov 1992 23:59:49 -0500 to: arnold@cc.gatech.edu (Arnold Robbins), rc@hawkwind.utcs.toronto.edu Subject: Re: printing the plan 9 manuals In-Reply-To: <9211061716.AA12502@penfold.cc.gatech.edu> Message-ID: <199211070459.13307.out.bafel@es.su.oz.au> From: arnold@cc.gatech.edu (Arnold Robbins) Date: Sat, 7 Nov 1992 03:16:54 +1000 To: rc@hawkwind.utcs.toronto.edu Subject: printing the plan 9 manuals on an apple laserwriter, no problem at all. From rc-owner Tue Nov 10 03:15:42 1992 Received: from relay1.UU.NET ([137.39.1.5]) by hawkwind.utcs.toronto.edu with S MTP id <2776>; Tue, 10 Nov 1992 03:13:38 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29137; Tue, 10 Nov 92 03:13:16 -0500 Received: from crowfix.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 031210.24750; Tue, 10 Nov 1992 03:12:10 EST Received: by crowfix.uucp (/\==/\ Smail3.1.22.1 #22.6) id ; Mon, 9 Nov 92 23:21 PST Message-Id: Date: Tue, 10 Nov 1992 02:21:00 -0500 From: crowfix!felix@uunet.UU.NET (Felix Finch) To: rc@hawkwind.utcs.toronto.edu Subject: I want to unsubscribe but I don't know how Sorry for broadcasting this, but I've tried several variations on the address, and I've lost whatever notes I had written down. If the list maintainer sees this, could you please unsubscribe me? Thanks. ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch, scarecrow repairer / felix@crowfix.com / uunet!crowfix!felix From rc-owner Tue Nov 10 05:14:50 1992 Received: from relay1.UU.NET ([137.39.1.5]) by hawkwind.utcs.toronto.edu with S MTP id <2776>; Tue, 10 Nov 1992 05:14:16 -0500 Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA16405; Tue, 10 Nov 92 05:13:57 -0500 Received: by cygnus.com (4.1/SMI-4.1) id AA01337; Tue, 10 Nov 92 02:13:56 PST Date: Tue, 10 Nov 1992 05:13:56 -0500 From: brendan@cygnus.com (Brendan Kehoe) Message-Id: <9211101013.AA01337@cygnus.com> To: rc mailing list Cc: brendan@cygnus.com Subject: ~ == $home Reply-To: brendan@cygnus.com Here's my first crack at making a tilde be used as an alternative to $home (or $h). (Well, it's actually my second--the first was an addition to the grammar, doing `foo~bar' convinced me to forget continuing to use that.) This doesn't support ~user, but can with a little more hacking (I'm too tired right now). A ~ by itself at the beginning of the line still works as the twiddle operator. Just to make life complete, gcc 2.3.1 miscompiles footobar.c (list2array) when optimization isn't being used. (I'll be looking at that before I do ~user.) Brendan *** glob.c.~1~ Mon Feb 17 14:45:24 1992 --- glob.c Tue Nov 10 02:08:26 1992 *************** static List *doglob(char *w, char *m) { *** 194,198 **** zero) since doglob gets called iff there's a metacharacter to be mat ched */ ! if (*s == '\0') { matched = dmatch(".", dir, metadir); goto end; --- 195,199 ---- zero) since doglob gets called iff there's a metacharacter to be mat ched */ ! if (*s == '\0' && *w != '~') { matched = dmatch(".", dir, metadir); goto end; *************** static List *doglob(char *w, char *m) { *** 203,206 **** --- 204,216 ---- firstdir.n = NULL; matched = &firstdir; + } else if (*w == '~') { + firstdir.w = varlookup("home")->w; + firstdir.n = NULL; + matched = &firstdir; + if (*s == '\0') { + firstdir.m = NULL; + goto end; + } + firstdir.m = metadir; } else { /* *** lex.c.~1~ Tue Mar 31 08:40:20 1992 --- lex.c Tue Nov 10 02:04:25 1992 *************** *** 38,42 **** 1, 1, 0, 1, 1, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, ! 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, --- 38,42 ---- 1, 1, 0, 1, 1, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, ! 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, /* ~ */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, *************** top: while ((c = gchar()) == ' ' || c == *** 98,104 **** w = RW; i = 0; read: do { buf[i++] = c; ! if (c == '?' || c == '[' || c == '*') saw_meta = TRUE; if (i >= bufsize) --- 98,111 ---- w = RW; i = 0; + if (c == '~') { + c = gchar(); + ugchar(c); + if (c == ' ' || c == '\t') + return TWIDDLE; + c = '~'; + } read: do { buf[i++] = c; ! if (c == '?' || c == '[' || c == '*' || c == '~') saw_meta = TRUE; if (i >= bufsize) -- Brendan Kehoe brendan@cygnus.com Cygnus Support, Palo Alto, CA +1 415 322 3811 His name's Avery! From rc-owner Thu Nov 12 18:29:48 1992 Received: from dtek.chalmers.se ([129.16.30.8]) by hawkwind.utcs.toronto.edu wi th SMTP id <2784>; Thu, 12 Nov 1992 18:26:33 -0500 From: Stefan Axelsson Message-Id: <9211122326.AA06156@dtek.chalmers.se> Received: from hacke10.dtek.chalmers.se by dtek.chalmers.se id AA06156; Fri, 13 Nov 92 00:26:12 +0100 Received: by hacke10.dtek.chalmers.se id AA10019; Fri, 13 Nov 92 00:25:24 +0100 Subject: ~ == $home To: rc@hawkwind.utcs.utoronto.ca (The rc mailing list) Date: Thu, 12 Nov 1992 18:25:23 -0500 X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1413 Hmm, I missed the beginning of this thread, but I've avoided missing ~ == home by using cdpath, and the variable expansion feature of editline. 1) Our usernames are very regular (d7stfax, aso) and thus are well suited for inclusion in the cdpath variable. e.g: cdpath=(. /users/dtek /users/dtek/d82 /users/dtek/d83 /users/dtek/d84 \ /users/dtek/d85 /users/dtek/d86 /users/dtek/d87 /users/dtek/d88 \ /users/dtek/d89 /users/dtek/d90 /users/dtek/d91 /users/dtek/d92) Thus I can say cd d7stfax, and end up in: /users/dtek/d87/d7stfax. Of course this solution doesn't cover all contingencies like ~d7stfax would, but in practice I have had no problem with it. 2) Now there`s the annoying fact that you cannot use filename completion to complete say; $h/bin/whateve. If you have editline compiled in you can set '_H_' for instance to; /users/dtek/d87/d7stfax/, and improve the situation. Since I have a keyboard with a 'meta' shift key, I press M-Shift-h and can use filename completion from there on. OK, that's three simultanous keys, but I have no problem with that. Your command line can get quite long though. As in 1) above this isn't perfect, but it works like a charm for me. These solutions may not, for various reasons, be right for you, but then again everybodys mileage may vary. Regards, -- Stefan Axelsson, Chalmers University of Technology, d7stfax@dtek.chalmers.se Sweden From rc-owner Wed Nov 18 11:34:32 1992 Received: from gatech.edu ([128.61.1.1]) by hawkwind.utcs.toronto.edu with SMTP id <2664>; Wed, 18 Nov 1992 11:32:41 -0500 Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA00455 for rc@hawkwind.utcs.toronto.edu; Wed, 18 Nov 92 11:32:28 ES T Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA03103; for rc@hawkwind.utcs.toronto.edu; Wed, 18 Nov 92 11:32:13 E ST Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA16629; Wed, 18 Nov 92 11:31:49 EST From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9211181631.AA16629@penfold.cc.gatech.edu> Date: Wed, 18 Nov 1992 11:31:49 -0500 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: rc@hawkwind.utcs.toronto.edu Subject: 'sam' available from research.att.com! I saw an off hand reference in comp.unix.bsd, and sure enough, Rob Pike's 'sam' editor is now up for ftp on research.att.com, in /dist/sam. All you really need is bundle.Z, a compress shell archive; the README is also in it. I had to make some minor changes to sam.tut.ms to get it to gnu troff; change all the \f(I to \fI. There's about 4 places. This is an X11 version ported from Plan 9 back to Unix. This will probably motivate me to switch from MGR to X. So, I thought I'd let all you minimalist junkies on the rc list know about it. Arnold From rc-owner Wed Nov 18 12:18:28 1992 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2664>; Wed, 18 Nov 1992 12:17:52 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA00806; Wed, 18 Nov 92 12:17:34 -0500 Received: by earth.osf.org (5.65/4.7) id AA02104; Wed, 18 Nov 92 12:17:33 -0500 Date: Wed, 18 Nov 1992 12:17:33 -0500 From: rsalz@osf.org Message-Id: <9211181717.AA02104@earth.osf.org> To: arnold@cc.gatech.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: 'sam' available from research.att.com! >change all the \f(I to \fI and all \f(B to \fB, too. From rc-owner Wed Nov 18 12:22:04 1992 Received: from gatech.edu ([128.61.1.1]) by hawkwind.utcs.toronto.edu with SMTP id <2729>; Wed, 18 Nov 1992 12:21:36 -0500 Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1) id AA01760 for rc@hawkwind.utcs.toronto.edu; Wed, 18 Nov 92 12:21:15 ES T Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1) id AA04608; for rsalz@osf.org; Wed, 18 Nov 92 12:21:09 EST Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA16722; Wed, 18 Nov 92 12:20:41 EST From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9211181720.AA16722@penfold.cc.gatech.edu> Date: Wed, 18 Nov 1992 12:20:40 -0500 In-Reply-To: rsalz@osf.org's 18-line message on Nov 18, 12:17pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: rsalz@osf.org Subject: Re: 'sam' available from research.att.com! Cc: rc@hawkwind.utcs.toronto.edu me: >> change all the \f(I to \fI rsalz: > and all \f(B to \fB, too. I didn't stumble on this; I got rid of the CW macro at the front which may be the only place that uses \f(B, but I left the WC macro alone, since I don't think groff has the CS font. (Courier Slanted?) The joys of troff. Arnold From rc-owner Wed Nov 18 12:36:11 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2798>; Wed, 18 Nov 1992 12:35:40 -0500 To: rc Subject: Re: 'sam' available from research.att.com! In-reply-to: arnold's message of Wed, 18 Nov 92 11:31:49 -0500. <9211181631.AA16629@penfold.cc.gatech.edu> Date: Wed, 18 Nov 1992 12:35:32 -0500 From: Chris Siebenmann Message-Id: <92Nov18.123540est.2798@hawkwind.utcs.toronto.edu> For the interested, I have a small set of modifications to the X portion of sam that create what I feel are some improvements in the interface and make it more Blit-like. Send me email if you want context diffs. - cks From rc-owner Wed Nov 18 13:22:07 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2802>; Wed, 18 Nov 1992 13:21:01 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA05047; Wed, 18 Nov 92 10:17:21 PST Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA10576; Wed, 18 Nov 92 10:16:09 PST Date: Wed, 18 Nov 1992 13:16:09 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9211181816.AA10576@netapp.netapp.com> To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: 'sam' available from research.att.com! >For the interested, I have a small set of modifications[...] I have also hacked sam in a couple of ways: 1) I make command window appear on the left by default. i.e., the window is tall&thin, not short&fat. Since most commands are only a couple of letters long (/foo, x/foo/c/bar, etc.) it means that you can have a lot more history visible in the editor than with the short&fat command window. The occasional long line doesn't bother me. 2) I hacked the selection-positioning code so that that when the current selection is skipped to, that selection is in the middle of the screen rather than right at the top. This makes it a lot easier to take in the context of the thing you just skipped to. (I dunno, maybe I'm used to it because vi does it that way.) 3) I fixed an array indexing error in main which causes sam to dump core when you give it a bad option. (sigh) In general, I have found that sam likes to dump core all too frequently under SunOS. Some of the dumps seem to be related to synchronization problems between sam & samterm: as soon as one goes out of whack it panics & dumps core. All these fixes are 1 line fixes, btw, which is nice. Modifying sam to use, for example, ctags, might be more of a challenge. From rc-owner Wed Nov 18 13:27:34 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2664>; Wed, 18 Nov 1992 13:27:08 -0500 To: rc Subject: Re: 'sam' available from research.att.com! In-reply-to: byron's message of Wed, 18 Nov 92 13:16:09 -0500. <9211181816.AA10576@netapp.netapp.com> Date: Wed, 18 Nov 1992 13:27:03 -0500 From: Chris Siebenmann Message-Id: <92Nov18.132708est.2664@hawkwind.utcs.toronto.edu> Note that the people at Bell Labs who are doing have been silently updating the sam distribution; unless you've sent them bug reports, you may not have heard about the new versions. The bug in options processing that Byron found has been fixed, for example (along with a bunch of others). - cks From rc-owner Wed Nov 18 16:21:06 1992 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2798>; Wed, 18 Nov 1992 16:20:39 -0500 Received: by mod.civil.su.oz.au id <28685>; Thu, 19 Nov 1992 08:04:30 +1100 From: John (For the colours are many, but the light is one.) Mackin Date: Wed, 18 Nov 1992 15:36:14 -0500 To: The sam Mailing List (snicker) Subject: Byron's comments In-Reply-To: <9211181816.AA10576@netapp.netapp.com> Message-ID: <199211190736.579.rc.bador@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ 1) I make command window appear on the left by default. i.e., the window is tall&thin, not short&fat. Use the Scrollbar, Luke!! :) 2) I hacked the selection-positioning code so that that when the current selection is skipped to, that selection is in the middle of the screen rather than right at the top. This is a damn fine plan. I don't know why I didn't ever do this. Does this have a good side-effect on what happens when you type at the bottom of the window? That is, does it make it scroll only half instead of the whole window, leaving you with only a line or so of context? I find that annoying, and so over the years have developed the habit of never typing across the bottom, but just scrolling with the scrollbar when that time gets near. ... hmm. I have just realised a possible reason for not doing this. If you are doing repeated searches for something that's reasonably frequent (and that's a common idiom of mine: "look" "look" "look" clicking on Button Two) this could cause twice as many scrolls. Hmm. In general, I have found that sam likes to dump core all too frequently under SunOS. Yes. That's the other reason I haven't changed to that version of sam from the one I am using: it doesn't seem to be solid at all yet. I have had a couple of "panic: Bflush"es out of it just in testing. This is not a UNIX-version problem; people I know who use Plan 9 say that the sam on there does this too. It's not repeatable (read: we don't know how to repeat it). The sam I use _never_ panics. Another reason I haven't switched (as mentioned in mail to Chris earlier) is that the interface has moved a bit far for my taste from the precisely Blit-like interface I am now using. By far the worst aspect is the fact that the Button Three menu doesn't scroll, but just grows taller without bound as you add files. Another reason I haven't switched is because my window manager (gwm 1.7i) has a bug that prevents clients that use the WM_TAKE_FOCUS protocol, which the new sam does, from ever getting the focus. I think David Hogan has a fix for this -- I haven't gotten it from him yet. Note that the current version of gwm (1.7n, I think) exhibits the same symptom for what seems to be a different reason, and we don't have a fix for that version. To contrast with the bashing, I was pleased by the performance of the new sam under test (speed-wise, I mean). I was concerned since the libXg they distribute is built on Xt. The jerq-tools emulation in the sam I use is built on raw Xlib and is a speed demon. I was very happy to see that the new version didn't seem to be noticeably slower. Modifying sam to use, for example, ctags, might be more of a challenge. Before anyone tries this, let me say that it would be far, far better to see if we can get the Labs to give us "samuel" instead. samuel is sam with built-in C browser knowledge; much more powerful than ctags. Caveat: I've never used samuel. I have, however, spent a bit of time watching someone who was skilled with it and used to it use it, and it looked very smooth indeed. Unfortunately the manual entry isn't in the printed V10 manual -- they relegated it to section A, the `unprinted appendix' -- but you get the idea. Just like sam -- if you don't use the browser features, you don't notice them -- and the menus remain uncluttered. But if you want to, you can do all the good things: show me the declaration of the selected identifier, or all uses of it, etc. etc. The database handling is particularly nice since it is updated lazily -- and you can go on editing while that's happening. OK, John. From rc-owner Wed Nov 18 19:44:09 1992 Received: from cserve.cs.adfa.oz.au ([131.236.20.1]) by hawkwind.utcs.toronto.e du with SMTP id <2795>; Wed, 18 Nov 1992 19:43:35 -0500 Received: by cserve.cs.adfa.oz.au (4.1/1.34) id AA21852; Thu, 19 Nov 92 11:43:05 EST Newsgroups: adfa.rc Path: cjsv_sun.cs.adfa.oz.au!sserve!ccadfa.cc.adfa.oz.au!cjsv From: Christopher.Vance@adfa.oz.au (Christopher JS Vance) To: Subject: Re: 'sam' available from research.att.com! Message-Id: <1992Nov18.232942.8241@sserve.cc.adfa.oz.au> Originator: cjsv@ccadfa.cc.adfa.oz.au Sender: news@sserve.cc.adfa.oz.au Organization: Computer Science, University College, UNSW/ADFA, Canberra, Austra lia References: <9211181720.AA16722@penfold.cc.gatech.edu> Distribution: adfa Date: Wed, 18 Nov 1992 18:29:42 -0500 Apparently-To: rc@hawkwind.utcs.toronto.edu Apparently-To: cjsv In article <9211181720.AA16722@penfold.cc.gatech.edu> arnold@cc.gatech.edu (Arn old Robbins) writes: | me: | >> change all the \f(I to \fI | | rsalz: | > and all \f(B to \fB, too. | | I didn't stumble on this; I got rid of the CW macro at the front which | may be the only place that uses \f(B, but I left the WC macro alone, since | I don't think groff has the CS font. (Courier Slanted?) | | The joys of troff. Or you can print the Postcript version in dist/plan9man/*sam*. (The plan9man directory was available before sam was.) -- Christopher From rc-owner Fri Nov 27 12:02:56 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2825>; Fri, 27 Nov 1992 12:00:01 -0500 Received: from faui33.informatik.uni-erlangen.de ([131.188.43.2]) by archone.ta mu.edu with SMTP id <45316>; Fri, 27 Nov 1992 10:59:46 -0600 Received: from faui30t.informatik.uni-erlangen.de by immd3.informatik.uni-erlan gen.de with SMTP (5.64+/7.2b-FAU) id AA18197; Fri, 27 Nov 92 17:59:23 +0100 From: Stefan Dalibor Message-Id: <9211271659.AA18197@faui33.informatik.uni-erlangen.de> Date: Fri, 27 Nov 1992 12:01:52 -0500 To: rc@archone.tamu.edu Subject: gcc-2.3.1 -O2 corrupts rc? Hello, interested in finding The Ultimate Shell I felt that I should have a look at rc; I copied the sources for version 1.4 from archone.tamu.edu, compiled it with gcc-2.3.1. Compilation made no problems (except warnings: proto.h:49: warning: conflicting types for built-in function `memcpy' proto.h:49: warning: type mismatch with previous external decl :0: warning: previous external decl of `memcpy' which disappeared after removing the forward declaration of memcpy from proto.h). But: make trip failed if compiled with option -O2 (all available optimizations turned on): % make trip ./rc -p < trip.rc tripping ./rc . . . . (output from successful tests deleted) . . . . trip took a wrong turn: match trip complete % On the other hand, trip.rc completed successfully when rc was compiled with: - gcc-2.2.2 -O2 - gcc-2.3.1 -O - cc -Qpath /local/lib/unproto -O[234] -I/local/lib/unproto -Dconst= -Dvolatile= where unproto is a package converting ANSI-C to K&R-C by Wietse Venema (got it from ftp.win.tue.nl). Has anybody of you experienced the same? Is this a known bug of gcc-2.3.1 (and if, has it been reported to GNU)? Or is it possible that I did something wrong during the installation? Please e-mail to me, as I'm unsubscribed to this list (I still don't know whether I'll like rc, who likes shells at all... :-) P.S. Browsing through the rc-list-file that came with the distribution I have to suppose that the author of rc gave up working on it; archone.tamu.edu seems to have ceased ftp-service. Is there a place where fixes to rc are archived or who (if anybody) maintains rc now? Thanks in advance, Stefan ---------------------------------------------------- Stefan Dalibor Lehrstuhl fuer Rechnerstrukturen (IMMD III) Friedrich-Alexander-Universitaet Erlangen-Nuernberg Erlangen, Germany e-mail: dalibor@immd3.informatik.uni-erlangen.de From rc-owner Tue Dec 1 01:55:15 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2845>; Tue, 1 Dec 1992 01:49:21 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA09022; Mon, 30 Nov 92 22:45:01 PST Received: by netapp.netapp.com (4.1/SMI-4.1) id AA18635; Mon, 30 Nov 92 22:41:15 PST Date: Tue, 1 Dec 1992 01:41:15 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9212010641.AA18635@netapp.netapp.com> To: dalibor@immd3.informatik.uni-erlangen.de, rc@hawkwind.utcs.toronto.edu Subject: Re: gcc-2.3.1 -O2 corrupts rc? re: gcc. I don't have gcc-2.3 here, you are on your own. Given how flaky new GNU code is I wouldn't be surprised if it's an optimizer bug. BTW, you don't mention the architecture you are using. >P.S. Browsing through the rc-list-file that came with the distribution I have > to suppose that the author of rc gave up working on it; archone.tamu.edu > seems to have ceased ftp-service. > Is there a place where fixes to rc are archived or who (if anybody) > maintains rc now? re: me. I'm still here, as byron@netapp.com. Mail to the old address *should* be forwarded here. If it isn't, please let me know! re: fixes. rc-1.5 should be out eventually. Let me get es out of my hair first. The fact that 1.4 is so stable is a disincentive for me to work hard on 1.5, btw. However, I am keeping a track of all the (so far minor) changes that need to be made. Unless I have an unexpected amount of spare time on my hands, I'm hoping to have something by mid-winter. re: archives. Chris Siebenmann is of course taking care of this at Toronto. Thanks Chris! I'm wondering whether a note to this effect should be posted to the net? i.e., something that will get propagated to comp.archives. re: archone.tamu.edu. Apparently Texas A&M University has seen it fit to ignore all ftp and telnet from off-site. Nice move. I guess it fits in well with their academic mission, something like that. (Pardon my cynicism, but this is worse than Stanford turning off fingerd on their general-access machines (like leyland)) Byron. From rc-owner Tue Dec 1 02:31:58 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2853>; Tue, 1 Dec 1992 02:26:29 -0500 To: rc Subject: anonymous ftp from archone.tamu.edu Date: Tue, 1 Dec 1992 02:26:23 -0500 From: Chris Siebenmann Message-Id: <92Dec1.022629est.2853@hawkwind.utcs.toronto.edu> I asked the system administrator of archone.tamu.edu about this, and here's his reply. - cks ------- Forwarded Message From: Steve Rikli To: cks@hawkwind.utcs.toronto.edu Subject: Re: what happened to anonymous ftp to archone.tamu.edu? archone.tamu.edu is still in the anonymous ftp business, but tamu.edu is being unfriendly. The Computing Services Center (i.e. main campus computing beaurocracy) at Texas A&M was attacked by crackers near the end of August. According to their reports, the crackers were able to get into computers all over campus (interestingly enough, they did not get into archone or any of my other systems). The response to this attack was to set up a packet filter at the main campus routers--all incoming ftp, rsh, rlogin, telnet is being filtered and turned away from non-tamu.edu sites, except for a select few campus computers. At the beginning of November, the CSC made available a series of scripts and routines (basically Cops, but more paranoid and tailored to look for signs of this recent attack) which any site admin on campus can run on his/her computers, and if they pass, these computers will be allowed free access to/from the outside world again. archone.tamu.edu has passed most of these tests (all save one, actually) but the last is somthing of a matter of opinion. I don't particularly care for it, but I suppose I will end up doing it, just because my net access depends on it. This has been more than a little bit of an inconvenience for me--I provide several things anonymously via ftp, not the least of which is Byron's rc, and my "customers" are unhappy. I don't blame them. Once I "fix" the last of the CSC's criteria, I assume it will take a couple weeks for archone to be unhindered again, so I am hoping for sometime before the end of December. Sorry for the inconvenience, but please bear with me--things won't always be like this. cheers, sr. - ------- || Steve Rikli ||| Visualization Lab || || steve@archone.tamu.edu ||| Texas A&M University || || 409-845-3465 ||| College Station, TX 77843-3137 || ------- End of Forwarded Message From rc-owner Wed Dec 2 22:44:02 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2230>; Wed, 2 Dec 1992 22:41:26 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA09702; Wed, 2 Dec 1992 21:41:14 -0600 Message-Id: <9212030341.AA09702@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: All I want for Christmas ... Date: Wed, 2 Dec 1992 22:41:13 -0500 From: Alan Watson X-Mts: smtp Well, rc v1.5 was mentioned, so I figure it's time to get out my wish list and see what Santa brings for Christmas. 1. Error handling after exec If I do: ; exec foo foo not found then rc dies (as do all other shells, I believe). Would it be difficult to continue after such an error, so that the user could decide on the appropriate action to take? This would more closely parallel the behaviour of the system call, but is it the behaviour we want from a shell? 2. -s flag Other shells have a -s flag, meaning "read commands from stdin unless told otherwise." It seems pretty useless to me, but my X server executes my .X11Startup by the equivalent of "$SHELL -s <.X11Startup". I'm not sure if this is standard (what's wrong with execlp?), but it would not surprise me if this feature was specific to Ultrix servers. Ultrix rather frowns of the MIT way of configuring X. (Oh, the drama and joy of Ultrix.) I get around this by using a five line C program as my "shell"; it eliminates any "-s" at argv[1] and then execs rc. Is there any support for adding an (essentially dummy) -s flag to rc for the sake of compatibility with other shells? From rc-owner Wed Dec 2 22:58:30 1992 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2408>; Wed, 2 Dec 1992 22:57:40 -0500 Received: by mod.civil.su.oz.au id <28685>; Thu, 3 Dec 1992 14:56:54 +1100 From: John (Deceased persons have no earning capacity) Mackin Date: Wed, 2 Dec 1992 22:48:47 -0500 To: The rc Mailing List Subject: Re: All I want for Christmas ... In-Reply-To: <9212030341.AA09702@oldp.astro.wisc.edu> Message-ID: <199212031448.1918.rc.badug@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ If I do: ; exec foo foo not found then rc dies (as do all other shells, I believe). Not _all_ other shells, just most of 'em. The Pike (V8+) version of sh continues after a failed exec. I don't think this is too big an issue, but I lean to the side of continuing, on the basis that if the user typed the exec interactively and made a typo or was confused, they probably didn't want their shell to go away. 2. -s flag This has been talked about on the list before. Boyd did this 'cos he felt he had to. I sent Boyd's code to Rich Salz. Personally, as I have said before, I see nothing at all wrong with adopting command line usage that brings rc more into line with the defacto standard set by sh, and therefore I am behind -s, if not heavily. On the other hand, I find it disappointing that -s proponents cannot muster anything better than the tired old `I seem to need this on Ultrix, for reasons I can't explain' argument. Hell, people! I have many Ultrix boxes here. They are good boxes! The _first_ thing you do on an Ultrix box is build X11R5. The _second_ thing you do is rm -rf DEATHwindows, and set up xdm and R5. Come on up to Freely Distributable X Windows, Your International Passport To Bitmapped Graphics Pleasure! You'll Be So Glad You Did! (Well hell, X is terrible, but it's a gazillion times better than DEATHwindows. Of course you might have special graphics hardware, watch that one. Luckily, we don't.) OK, John. From rc-owner Wed Dec 2 23:37:54 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2664>; Wed, 2 Dec 1992 23:35:08 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA08892; Wed, 2 Dec 92 20:34:33 PST Received: by netapp.netapp.com (4.1/SMI-4.1) id AA03379; Wed, 2 Dec 92 20:28:57 PST Date: Wed, 2 Dec 1992 23:28:57 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9212030428.AA03379@netapp.netapp.com> To: alan@oldp.astro.wisc.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: All I want for Christmas ... re: -s. I think I agreed on the list that I will incorporate this into 1.5. re: exec. I would rather not change the behavior of exec. For example, what if some script uses exec for flow control; an exec which continued on failure would change the behavior of the script. From rc-owner Wed Dec 2 23:44:40 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2688>; Wed, 2 Dec 1992 23:43:43 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2581>; Wed, 2 Dec 1992 23:42:59 -0500 To: byron@netapp.com (Byron Rakitzis) cc: alan@oldp.astro.wisc.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: All I want for Christmas ... In-reply-to: Your message of "Wed, 02 Dec 92 23:28:57 EST." <9212030428.AA03379@netapp.netapp.com> Date: Wed, 2 Dec 1992 23:42:50 -0500 From: Scott Schwartz Message-Id: <92Dec2.234259est.2581@groucho.cs.psu.edu> | re: exec. I would rather not change the behavior of exec. For example, | what if some script uses exec for flow control; an exec which continued | on failure would change the behavior of the script. I'd rather have the shell do the right thing and fix the scripts. From rc-owner Thu Dec 3 00:02:48 1992 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu w ith SMTP id <2699>; Thu, 3 Dec 1992 00:01:55 -0500 Received: by quux.es.su.oz.au id <14651>; Thu, 3 Dec 1992 16:01:00 +1100 From: Noel Hunt To: byron@netapp.com, schwartz@groucho.cs.psu.edu Subject: Re: All I want for Christmas ... Cc: alan@oldp.astro.wisc.edu, rc@hawkwind.utcs.toronto.edu Message-Id: <92Dec3.160100+1100.14651@quux.es.su.oz.au> Date: Thu, 3 Dec 1992 00:00:46 -0500 From hawkwind.utcs.toronto.edu!rc-owner Thu Dec 3 15:45:16 1992 From: Scott Schwartz I'd rather have the shell do the right thing and fix the scripts. i agree. From rc-owner Thu Dec 3 00:06:37 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2704>; Thu, 3 Dec 1992 00:04:59 -0500 To: rc Subject: Re: All I want for Christmas ... In-reply-to: noel's message of Thu, 03 Dec 92 00:00:46 -0500. <92Dec3.160100+1100.14651@quux.es.su.oz.au> Date: Thu, 3 Dec 1992 00:04:58 -0500 From: Chris Siebenmann Message-Id: <92Dec3.000459est.2704@hawkwind.utcs.toronto.edu> | I'd rather have the shell do the right thing and fix the scripts. I'd rather have us do what Tom Duff's rc shell does; the version I have prints an error message and exits. - cks From rc-owner Thu Dec 3 00:30:51 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2712>; Thu, 3 Dec 1992 00:30:19 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA12219; Wed, 2 Dec 92 21:27:09 PST Received: by netapp.netapp.com (4.1/SMI-4.1) id AA03981; Wed, 2 Dec 92 21:23:00 PST Date: Thu, 3 Dec 1992 00:23:00 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9212030523.AA03981@netapp.netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: Re: All I want for Christmas ... We have >Well, it could recover after the exec iff the shell is interactive. and >I'd rather have the shell do the right thing and fix the scripts. The lady doth protest too much, methinks. I honestly can't see how this could be a big deal one way or another, and given the choice, I prefer to resist any change to the program so late in the game. From rc-owner Thu Dec 3 01:19:37 1992 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2720>; Thu, 3 Dec 1992 01:19:15 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2516>; Thu, 3 Dec 1992 01:18:32 -0500 To: byron@netapp.com (Byron Rakitzis) cc: rc@hawkwind.utcs.toronto.edu Subject: Re: All I want for Christmas ... In-reply-to: Your message of "Thu, 03 Dec 92 00:23:00 EST." <9212030523.AA03981@netapp.netapp.com> Date: Thu, 3 Dec 1992 01:18:15 -0500 From: Scott Schwartz Message-Id: <92Dec3.011832est.2516@groucho.cs.psu.edu> | I honestly can't see how this could be a big deal one way or another, It depends on how sophisticated your shell scripts are. One could reasonably argue that if it makes a difference you should use a more capable language. | and given the choice, I prefer to resist any change to the program so | late in the game. So what does es do? :-) From rc-owner Thu Dec 3 01:23:21 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2724>; Thu, 3 Dec 1992 01:22:51 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA10599; Thu, 3 Dec 1992 00:22:42 -0600 Message-Id: <9212030622.AA10599@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: All I want for Christmas ... Date: Thu, 3 Dec 1992 01:22:41 -0500 From: Alan Watson X-Mts: smtp 1. exec The only time I use exec interactively is when I install a new version of rc. I think it would be a poor choice to differentiate the behaviour of exec based on the interactiveness of the shell. Part of the reason that I would like the change is that I often use exec in scripts ... but I also often make mistakes in scripts. Dumping the environment to stderr after a failed exec would be a useful debugging aid. It also just seems "the right thing to do." However, Byron's reservations are valid. 2. -s Hey, yeah, now you mention it I remember that coming round. My apologies for bringing it up again. 3. Let me make one more comment, which arises from a recent discussion in comp.unix.shell: ; rc <; Thu, 3 Dec 1992 02:24:36 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA19848; Wed, 2 Dec 92 23:24:21 PST Received: by netapp.netapp.com (4.1/SMI-4.1) id AA04993; Wed, 2 Dec 92 23:16:48 PST Date: Thu, 3 Dec 1992 02:16:48 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9212030716.AA04993@netapp.netapp.com> To: schwartz@groucho.cs.psu.edu Subject: Re: All I want for Christmas ... Cc: rc@hawkwind.utcs.toronto.edu >So what does es do? :-) The sky's the limit. Paul even added ~-expansion. ; prompt='es> ' es es> exec asdf asdf not found es> From rc-owner Thu Dec 3 02:25:13 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2408>; Thu, 3 Dec 1992 02:24:53 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA19852; Wed, 2 Dec 92 23:24:23 PST Received: by netapp.netapp.com (4.1/SMI-4.1) id AA05059; Wed, 2 Dec 92 23:23:19 PST Date: Thu, 3 Dec 1992 02:23:19 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9212030723.AA05059@netapp.netapp.com> To: alan@oldp.astro.wisc.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: All I want for Christmas ... Aha, more trivia. . /dev/tty does not start an interactive context. you need to explicitly say . -i /dev/tty Hence your two examples rc<; Thu, 3 Dec 1992 09:37:08 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA11280; Thu, 3 Dec 1992 08:36:54 -0600 Message-Id: <9212031436.AA11280@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: All I want for Christmas ... Date: Thu, 3 Dec 1992 09:36:54 -0500 From: Alan Watson X-Mts: smtp I could have sworn that ". /dev/tty" worked like that yesterday ... someone must have hacked my system and patched the binaries over night. I guess you don't want to call isatty() every time one uses ".", but I'm still not sure if this is "right." What is so special about start-up, that one doesn't need an explicit "-i" flag? Why not check stdin every time it gets redirected? While I agree this last suggestion is of very limited use, and may well be trivial, it is hardly "more" trivia -- unless you think the error handling and the sh compatibility of your shell are trivial issues. Alan. From rc-owner Thu Dec 3 12:41:58 1992 Received: from relay1.UU.NET ([137.39.1.5]) by hawkwind.utcs.toronto.edu with S MTP id <2237>; Thu, 3 Dec 1992 12:41:25 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA28316; Thu, 3 Dec 92 12:40:59 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 123938.26450; Thu, 3 Dec 1992 12:39:38 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa06993; Thu, 3 Dec 92 11:36:08 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: More stuff related to exec... Date: Thu, 3 Dec 1992 11:37:31 -0500 Message-Id: <9212031137.aa29960@ceres.srg.af.mil> Here, presented for your amusement, is a cute little stunt that sh, ksh, and csh do and that rc, and bash do not. If you have occasion to use the "newgrp" command or read the man page it says that when you run newgrp it replaces the current shell (effectively an exec) this obviously entails magic within the shells (try "strings /bin/sh | grep newgrp") Not only that, but newgrp seems to revert to the shell named in the login file, ignoring the current setting of SHELL. If you care about the exec behaviour you can obviously create a newgrp function ("fn newgrp { exec /bin/newgrp $* }"). As for the other, it looks like that's just the way the ball bounces. Isn't unix fun? ;-) Tom From rc-owner Thu Dec 3 13:16:00 1992 Received: from venus.sunquest.com ([149.138.1.68]) by hawkwind.utcs.toronto.edu with SMTP id <2237>; Thu, 3 Dec 1992 13:15:32 -0500 Received: by venus.sunquest.com (5.57/Ultrix3.0-C) id AA14317; Thu, 3 Dec 92 11:15:14 -0700 Received: by rt.sunquest.com (AIX 2.1 2/4.03) id AA16018; Thu, 3 Dec 92 11:14:06 MST Message-Id: <9212031814.AA16018@rt.sunquest.com> From: To: <@venus:rc@hawkwind.utcs.toronto.edu> Subject: Please unsubscribe me Date: Thu, 3 Dec 1992 13:14:06 -0500 Illegal-Object: Syntax error in From: address found on hawkwind.utcs.toronto.ed u: From: Ward...JamesWard jew@sunquest.com ^^ ^-missing end of mailbox | \-illegal word in localpart \-expected word From rc-owner Thu Dec 3 13:40:52 1992 Received: from venus.sunquest.com ([149.138.1.68]) by hawkwind.utcs.toronto.edu with SMTP id <2237>; Thu, 3 Dec 1992 13:40:25 -0500 Received: by venus.sunquest.com (5.57/Ultrix3.0-C) id AA14414; Thu, 3 Dec 92 11:40:20 -0700 Received: by rt.sunquest.com (AIX 2.1 2/4.03) id AA16118; Thu, 3 Dec 92 11:39:12 MST Message-Id: <9212031839.AA16118@rt.sunquest.com> Illegal-Object: Syntax error in To: address found on hawkwind.utcs.toronto.edu: To: <@venus:rc%hawkwind.utcs.toronto.edu> ^-illegal end of route addr ess From: To: Subject: Please unsubscribe me Date: Thu, 3 Dec 1992 13:39:11 -0500 Illegal-Object: Syntax error in From: address found on hawkwind.utcs.toronto.ed u: From: Ward...JamesWard jew@sunquest.com ^^ ^-missing end of mailbox | \-illegal word in localpart \-expected word ------- Forwarded Message Received: by rt.sunquest.com (AIX 2.1 2/4.03) id AA16048; Thu, 3 Dec 92 11:19:18 MST Received: from ALPHA.SUNQUEST.COM by sunquest.sunquest.com (4.1/SMI-4.1) id AA03789; Thu, 3 Dec 92 11:20:25 MST Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by ALPHA.SUNQUEST.C OM with SMTP; Thu, 3 Dec 1992 11:20:22 -0700 (MST) Received: from venus.sunquest.com ([149.138.1.68]) by hawkwind.utcs.toronto.edu with SMTP id <2237>; Thu, 3 Dec 1992 13:15:32 -0500 Received: by venus.sunquest.com (5.57/Ultrix3.0-C) id AA14317; Thu, 3 Dec 92 11:15:14 -0700 Received: by rt.sunquest.com (AIX 2.1 2/4.03) id AA16018; Thu, 3 Dec 92 11:14:06 MST Message-Id: <9212031814.AA16018@rt.sunquest.com> From: To: <@venus:rc@hawkwind.utcs.toronto.edu@sunquest.com> Subject: Please unsubscribe me Date: Thu, 3 Dec 1992 13:14:06 -0500 Illegal-Object: Syntax error in From: address found on hawkwind.utcs.toronto.ed u: From: Ward...JamesWard jew@sunquest.com ^^ ^-missing end of mailbox | \-illegal word in localpart \-expected word M ------- End of Forwarded Message From rc-owner Thu Dec 3 16:16:10 1992 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu w ith SMTP id <2237>; Thu, 3 Dec 1992 16:15:33 -0500 Received: by quux.es.su.oz.au id <14653>; Fri, 4 Dec 1992 08:12:51 +1100 From: noel@es.su.oz.au Date: Thu, 3 Dec 1992 16:11:42 -0500 to: culliton@srg.srg.af.mil (Tom Culliton x2278), rc@hawkwind.utcs.toronto.edu Subject: Re: More stuff related to exec... In-Reply-To: <9212031137.aa29960@ceres.srg.af.mil> Message-ID: <199212032111.19030.out.babon@es.su.oz.au> From: culliton@srg.af.mil (Tom Culliton x2278) Subject: More stuff related to exec... If you have occasion to use the "newgrp" command or read the man page che? what happened to berkeley multi-groups? From rc-owner Thu Dec 3 18:39:20 1992 Received: from relay.cs.toronto.edu ([128.100.1.105]) by hawkwind.utcs.toronto. edu with SMTP id <2237>; Thu, 3 Dec 1992 18:38:33 -0500 Received: from xenitec.on.ca ([142.77.5.3]) by relay.cs.toronto.edu with SMTP i d <150145>; Thu, 3 Dec 1992 18:38:23 -0500 Received: from golem by xenitec.xenitec.on.ca id aa09422; 3 Dec 92 18:37 EST To: noel@es.su.oz.au cc: Tom Culliton x2278 , rc@hawkwind.utcs.toronto.edu Subject: Re: More stuff related to exec... In-reply-to: Your message of "Thu, 03 Dec 92 16:11:42 EST." <199212032111.19030.out.babon@es.su.oz.au> Date: Thu, 3 Dec 1992 18:22:41 -0500 From: "David J. Fiander" Message-ID: <9212031822.aa14299@golem.waterloo.on.ca> > If you have occasion to use the "newgrp" command or read the man page > >che? what happened to berkeley multi-groups? Last time I checked, my xenix box isn't running BSD Unix. - David From rc-owner Thu Dec 3 21:46:25 1992 Received: from relay1.UU.NET ([137.39.1.5]) by hawkwind.utcs.toronto.edu with S MTP id <2237>; Thu, 3 Dec 1992 21:45:23 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA06406; Thu, 3 Dec 92 21:45:13 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 214444.4698; Thu, 3 Dec 1992 21:44:44 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa17592; Thu, 3 Dec 92 21:38:57 EST From: culliton@srg.srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: noel@es.su.oz.au Subject: Re: More stuff related to exec... Cc: rc@hawkwind.utcs.toronto.edu Date: Thu, 3 Dec 1992 21:38:51 -0500 Message-Id: <9212032138.aa01864@ceres.srg.af.mil> > che? what happened to berkeley multi-groups? Can you say SysVr3? I knew you could! From rc-owner Fri Dec 4 07:55:30 1992 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2645>; Fri, 4 Dec 1992 07:54:41 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld .de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA05840; Fri, 4 Dec 92 13:53:54 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA01867; Fri, 4 Dec 92 13:53:53 +0100 Date: Fri, 4 Dec 1992 07:53:53 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9212041253.AA01867@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: more wishes for chrismas I'd like to add two things to the christmas wishlist: 1) back slash to escape a single character or alternatively 2) make '#' introduce a comment only at the beginning of a line or if preceeded by white space only. Our new students find it difficult to quote emacs backup file names when they want to move or delete them. Malte From rc-owner Fri Dec 4 09:03:47 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2645>; Fri, 4 Dec 1992 09:03:10 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA03650; Fri, 4 Dec 1992 08:02:52 -0600 Message-Id: <9212041402.AA03650@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Cc: malte@techfak.uni-bielefeld.de Subject: Re: more wishes for chrismas Date: Fri, 4 Dec 1992 09:02:51 -0500 From: Alan Watson X-Mts: smtp The backslash is used by so many Unix utilities (in particular sed) that it would be a pain to have it as an escape character is the shell. I have got so used to typing: ; sed 'some-guff-including-\' bar that I use quotes whenever I type: ; sed 'some-guff-not-using-shell-meta-characters' bar I very rarely make quoting errors in rc, but I used to make them all of the time in sh. Quoting is one less think I have to think about, and that allows me to devote more attention to getting other stuff done. Tom Duff got this one not just right, but perfect. There are a few characters which only make sense at certain places -- like "=" which has to be quoted in dd commands -- but at least the current rules have a simplicity about them. No "foo does bar except for on the third Wednesday in the month if the month starts on a weekend." Alan. From rc-owner Fri Dec 4 09:04:12 1992 Received: from cheviot.ncl.ac.uk ([128.240.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2664>; Fri, 4 Dec 1992 09:03:59 -0500 Received: from ncl.bygate (bygate.ncl.ac.uk) by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Fri, 4 Dec 1992 14:03:32 GMT From: Gerry.Tomlinson@newcastle.ac.uk Message-Id: Subject: Re: more wishes for chrismas To: rc@hawkwind.utcs.toronto.edu Date: Fri, 4 Dec 1992 09:03:26 -0500 In-Reply-To: <9212041253.AA01867@dahlie.techfak.uni-bielefeld.de>; from "malte@ de.uni-bielefeld.techfak" at Dec 4, 92 12:57 pm X-Mailer: ELM [version 2.3 PL11] > > I'd like to add two things to the christmas wishlist: > 1) back slash to escape a single character or alternatively > 2) make '#' introduce a comment only at the beginning of a line or > if preceeded by white space only. > > Our new students find it difficult to quote emacs backup file names when they > want to move or delete them. and how about lpr -#2 filename .... ? Gerry. -- Gerry.Tomlinson@newcastle.ac.uk Computing Laboratory, The University, Newcastle upon Tyne, UK, NE1 7RU Tel: +44 091 222 8139 From rc-owner Fri Dec 4 09:50:48 1992 Received: from endgame.gsfc.nasa.gov ([128.183.44.24]) by hawkwind.utcs.toronto .edu with SMTP id <2645>; Fri, 4 Dec 1992 09:50:25 -0500 Received: by endgame.gsfc.nasa.gov with SMTP id AA16613 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 09:48:3 3 -0500 Message-Id: <199212041448.AA16613@endgame.gsfc.nasa.gov> To: rc@hawkwind.utcs.toronto.edu Subject: Re: more wishes for chrismas From: Steve Rezsutek In-Reply-To: Alan Watson's message of "Fri, 04 Dec 92 09:02:51 EST." <9212041402.AA03650@oldp.astro.wisc.edu> Date: Fri, 4 Dec 1992 09:48:30 -0500 Sender: steve@endgame.gsfc.nasa.gov Alan Watson sez... > I very rarely make quoting errors in rc, but I used to make them all > of the time in sh. Quoting is one less think I have to think about, > and that allows me to devote more attention to getting other stuff > done. Sounds like my experience, too. And further... > There are a few characters which only make sense at certain places -- > like "=" which has to be quoted in dd commands -- but at least the > current rules have a simplicity about them. No "foo does bar except > for on the third Wednesday in the month if the month starts on a > weekend." I couldn't agree more. One of the things I like most about rc is the simple rule: 'it''s either quoted, or it isn''t'. For things like arguments to dd, the biological CPU overhead of typing two extra characters is a small price to pay in exchange for not having to constantly think about which type of quoting to apply where. If y'all want my $0.02, I'd say 'nay' to backslash quoting... Steve From rc-owner Fri Dec 4 09:59:53 1992 Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by hawkwind.utcs.toronto .edu with SMTP id <2645>; Fri, 4 Dec 1992 09:59:22 -0500 Via: uk.ac.oxford.prg; Fri, 4 Dec 1992 14:58:35 +0000 Received: from uk.ac.oxford.robots.lucrece.robots (lucrece-gate.robots) by prg.oxford.ac.uk id AA19496; Fri, 4 Dec 92 14:58:28 GMT Received: from robots.ox.ac.uk (casca.robots) by uk.ac.oxford.robots.lucrece.robots (4.1/robots.1) id AA17217; Fri, 4 Dec 92 14:58:25 GMT Received: by robots.ox.ac.uk (4.1/robots.remoteV2.0) id AA01599; Fri, 4 Dec 92 14:58:25 GMT Date: Fri, 4 Dec 1992 09:58:25 -0500 From: peter@robots.oxford.ac.uk Message-Id: <9212041458.AA01599@casca.robots.ox.ac.uk> To: rc@hawkwind.utcs.toronto.edu Subject: Re: more wishes for chrismas > 1) back slash to escape a single character or alternatively > 2) make '#' introduce a comment only at the beginning of a line or > if preceeded by white space only. No thanks! I think it would be better to keep the rules simple and consistent as they are now, that's why Tom Duff wrote ``rc'' wasn't it? It would be better in the long run to teach the students from day one, that ``#'' is a comment, and "'" is for quoting. Otherwise they might as well use ``sh'' and it's derivatives :-). Pete. From rc-owner Fri Dec 4 10:01:16 1992 Received: from odin.INS.CWRU.Edu ([129.22.8.102]) by hawkwind.utcs.toronto.edu with SMTP id <2689>; Fri, 4 Dec 1992 10:00:59 -0500 Received: by odin.INS.CWRU.Edu (5.65b+ida+/CWRU-1.5-ins) id AA04385; Fri, 4 Dec 92 09:58:58 -0500 (from chet for rc@hawkwind.utc s.toronto.edu) Date: Fri, 4 Dec 1992 09:52:42 -0500 From: Chet Ramey To: culliton@srg.af.mil Subject: Re: More stuff related to exec... Cc: rc@hawkwind.utcs.toronto.edu, chet@odin.INS.CWRU.Edu Reply-To: chet@po.CWRU.Edu In-Reply-To: Message from culliton@srg.af.mil of Thu, 3 Dec 1992 11:37:31 -0500 Message-Id: <9212041452.AA04276.SM@odin.INS.CWRU.Edu> Read-Receipt-To: chet@po.CWRU.Edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii > Here, presented for your amusement, is a cute little stunt that sh, > ksh, and csh do and that rc, and bash do not. > > If you have occasion to use the "newgrp" command or read the man page > it says that when you run newgrp it replaces the current shell > (effectively an exec) this obviously entails magic within the shells > (try "strings /bin/sh | grep newgrp") Not only that, but newgrp seems > to revert to the shell named in the login file, ignoring the current > setting of SHELL. With the advent of BSD-like multiple groups in Posix and most Unix versions, it's not worth the space it takes to have a `newgrp' shell builtin. > If you care about the exec behaviour you can obviously create a newgrp > function ("fn newgrp { exec /bin/newgrp $* }"). As for the other, it > looks like that's just the way the ball bounces. Isn't unix fun? ;-) Shells that have a newgrp builtin just do the exec internally, so a shell function suffices. (Look at the tcsh source, for instance.) That is, if you care enough about newgrp to want one. Chet -- ``The use of history as therapy means the corruption of history as history.'' -- Arthur Schlesinger Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu From rc-owner Fri Dec 4 12:53:57 1992 Received: from relay1.UU.NET ([137.39.1.5]) by hawkwind.utcs.toronto.edu with S MTP id <2645>; Fri, 4 Dec 1992 12:53:36 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19154; Fri, 4 Dec 92 12:53:27 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 125029.1076; Fri, 4 Dec 1992 12:50:29 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa02283; Fri, 4 Dec 92 11:53:57 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: malte@techfak.uni-bielefeld.de, rc@hawkwind.utcs.toronto.edu Subject: Re: more wishes for chrismas Date: Fri, 4 Dec 1992 11:53:55 -0500 Message-Id: <9212041153.aa03906@ceres.srg.af.mil> >I'd like to add two things to the christmas wishlist: > >1) back slash to escape a single character or alternatively NO NO NO NO! God protect us from creeping featurism! One of the most beautiful things about rc as it stands is the purity and simplicity of it's quoting. I remember battling with the quoting in sh and ksh and can't stand the thought of going back. >2) make '#' introduce a comment only at the beginning of a line or > if preceeded by white space only. > >Our new students find it difficult to quote emacs backup file names when they >want to move or delete them. > >Malte This is how I currently use the comment character, but rc's existing simplicity still seems perferable to me. Tom From rc-owner Fri Dec 4 17:06:07 1992 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2645>; Fri, 4 Dec 1992 17:05:32 -0500 To: rc Subject: Re: more wishes for chrismas Date: Fri, 4 Dec 1992 17:05:28 -0500 From: Chris Siebenmann Message-Id: <92Dec4.170532est.2645@hawkwind.utcs.toronto.edu> | 1) back slash to escape a single character or alternatively | 2) make '#' introduce a comment only at the beginning of a line or | if preceeded by white space only. Ugh and ugh. These go against the whole philosophy of quoting in rc (not to mention breaking existing scripts, especially 2). If you want to make this modification, please don't call the result 'rc'. You might be better off hacking up one of the shells designed to be user-cuddly at all costs, even; zsh, say. No one cares about consistency in them. - cks From rc-owner Sat Dec 5 11:25:21 1992 Received: from plg.uwaterloo.ca ([129.97.140.10]) by hawkwind.utcs.toronto.edu with SMTP id <2689>; Sat, 5 Dec 1992 11:22:12 -0500 Received: by plg.uwaterloo.ca id <28994>; Sat, 5 Dec 1992 11:21:21 -0500 From: Dave Mason To: rc@hawkwind.utcs.toronto.edu In-reply-to: <9212041402.AA03650@oldp.astro.wisc.edu> (message from Alan Watson on Fri, 4 Dec 1992 09:02:51 -0500) Subject: Re: more wishes for chrismas X-Face: %Q_F^9R-:'3MM7eZ6@E.x@f\*bgatzGv-8d%I~L[p^.F)3QF{kq\UTsu|e#?)3FPwJNvPPB !s*He|-*M^p*~bh"Nywm5NLL\\Rl3r(hWHY*F:$/RdKV*bS";n&#\Ov@*=]mu\}6tP Date: Sat, 5 Dec 1992 11:21:13 -0500 > Date: Fri, 4 Dec 1992 09:02:51 -0500 > From: Alan Watson > > There are a few characters which only make sense at certain places -- > like "=" which has to be quoted in dd commands -- but at least the > current rules have a simplicity about them. No "foo does bar except > for on the third Wednesday in the month if the month starts on a > weekend." This is the only spot where I get bitten occasionally and wouldn't mind a change. If local assignments were only allowed at the beginning of lines, then: dd count=1 bs=512 wouldn't cause a problem. In fact, looking at the grammar in the rc manual, assignments *are* only allowed at the beginning of lines, and I don't see the rule that causes the problem. ../Dave From rc-owner Sat Dec 5 15:53:19 1992 Received: from Princeton.EDU ([128.112.128.1]) by hawkwind.utcs.toronto.edu wit h SMTP id <2706>; Sat, 5 Dec 1992 15:52:46 -0500 Received: from phoenix.Princeton.EDU by Princeton.EDU (5.65b/2.95/princeton) id AA16809; Sat, 5 Dec 92 15:52:07 -0500 Received: from tan.Princeton.EDU by phoenix (5.65b/1.113) id AA11075; Sat, 5 Dec 92 15:52:04 -0500 From: Emin Gun Sirer Received: by tan.Princeton.EDU (4.1/CS_101_Cluster_Client) id AA08118; Sat, 5 Dec 92 15:52:02 EST Date: Sat, 5 Dec 1992 15:52:02 -0500 Message-Id: <9212052052.AA08118@tan.Princeton.EDU> To: dmason@plg.uwaterloo.ca, rc@hawkwind.utcs.toronto.edu Subject: Re: more wishes for chrismas >From: Dave Mason >Date: Sat, 5 Dec 1992 11:21:13 -0500 > >> Date: Fri, 4 Dec 1992 09:02:51 -0500 >> From: Alan Watson >> >> There are a few characters which only make sense at certain places -- >> like "=" which has to be quoted in dd commands -- but at least the >> current rules have a simplicity about them. > >This is the only spot where I get bitten occasionally and wouldn't >mind a change. If local assignments were only allowed at the >beginning of lines, then: > dd count=1 bs=512 >wouldn't cause a problem. In fact, looking at the grammar in the rc >manual, assignments *are* only allowed at the beginning of lines, and >I don't see the rule that causes the problem. Yes, promotion is inconsistent. For example: ;~ a sdfdsfg [status 1] ;ls file1 ~ file3 ;ls file1 = file3 [syntax error] ;in arg1 syntax error ;cmnd in asfd ;(elem1 in elem3) So the rule in the latter part is that the keyword gets promoted to a string unless it is the first word on a line. But the same thing is not true of "=", which does not get promoted anywhere. However, "~" gets promoted around *in the lexer*, which is not a good thing. The solutions I see, in order of desirability as far as I'm concerned: 1. Fix dd and awk (I was at Bell Labs when someone changed the plan9 dd to take "-infile fname" and "-outfile" as opposed to "infile=fname". People were furious that a lot of their scripts had to be fixed. But it only happens once and saves a lot of headache later on). 1. Promote '=' as if it was a keyword. Put '~' promotion in the grammer along with '='. 1. Promote all syntax error causing keyword constructs to strings (this'll require following multiple paths through the parser but is doable) and retry. Duff's rc paper praises sh for using recursive descent, but criticizes it because a lot of the routines change their behaviour according to some flags. The counterpart to this in a yacc-based program is the special treatment of certain tokens in the lexer. Yes, it's nice that rc has a yacc grammer that anyone can understand, but does everyone know when a given character represents token TWIDDLE or CHAR and is this treatment uniform for all characters that are more or less the same ?? Gun. From rc-owner Sun Dec 6 03:23:36 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2723>; Sun, 6 Dec 1992 03:22:40 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA26087; Sun, 6 Dec 92 00:22:04 PST Received: by netapp.netapp.com (4.1/SMI-4.1) id AA19252; Sun, 6 Dec 92 00:21:32 PST Date: Sun, 6 Dec 1992 03:21:32 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9212060821.AA19252@netapp.netapp.com> To: egsirer@phoenix.Princeton.EDU, rc@hawkwind.utcs.toronto.edu Subject: Re: more wishes for chrismas >However, "~" gets promoted around >*in the lexer*, which is not a good thing. Maybe this is true in Duff's rc (I don't see how or why, actually) but it certainly isn't true about my lexer. The only serious lexical hacks are free carets and the treatment of '('. I guess you can also include the scanning of variable names (which are presumed to be in the character class [a-zA-Z0-9_*]). > 1. Promote '=' as if it was a keyword. Would anyone like to submit a working yacc grammar for this? After playing with the grammar for a little bit, I didn't find a way to do this for '='. It's my suspicion that a working grammar that promoted '=' would be very ugly, but I'd love to be disproved. From rc-owner Tue Dec 8 10:39:07 1992 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2731>; Tue, 8 Dec 1992 10:22:14 -0500 Received: from linc.cis.upenn.edu ([130.91.6.8]) by archone.tamu.edu with SMTP id <45316>; Tue, 8 Dec 1992 09:21:43 -0600 Received: from SAUL.CIS.UPENN.EDU by linc.cis.upenn.edu id AA01498; Tue, 8 Dec 92 10:21:25 -0500 Return-Path: Received: from LOCALHOST.upenn.edu by saul.cis.upenn.edu id AA27087; Tue, 8 Dec 92 10:21:24 EST Posted-Date: Tue, 08 Dec 92 10:21:23 EST Message-Id: <9212081521.AA27087@saul.cis.upenn.edu> To: rc@archone.tamu.edu Cc: mjd@saul.cis.upenn.edu Subject: Re: more wishes for chrismas In-Reply-To: Your message of "Fri, 04 Dec 92 07:53:53 EST." <9212041253.AA01867@dahlie.techfak.uni-bielefeld.de> Date: Tue, 8 Dec 1992 10:21:23 -0500 From: Mark-Jason Dominus > make '#' introduce a comment only at the beginning of a line or > if preceeded by white space only. > > Our new students find it difficult to quote emacs backup file names when they > want to move or delete them. Just for the information of people using GNU `readline': If there is a file named #foo# in the current directory, then if you do filename completion on '# you get '#foo#' From rc-owner Sun Dec 13 21:06:41 1992 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2689>; Sun, 13 Dec 1992 21:05:31 -0500 Received: by mod.civil.su.oz.au id <28680>; Mon, 14 Dec 1992 13:04:48 +1100 From: John (I don't want no teenage queen / I just want my M-fourteen) Mackin Date: Sun, 13 Dec 1992 20:58:29 -0500 To: The rc Mailing List Subject: An interesting (maybe) point Message-ID: <199212141258.4391.rc.bafeg@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ After the discussions of some months back regarding "what is a function", and "what is a return value", I pricked up my ears (as it were) when I saw the following arrive on the ZMailer mailing list. For those who aren't familiar with it, ZMailer is a mail delivery system. Part of it is a shell, called "zsh", which is not to be confused with the PD interactive shell of the same name. ZMailer's zsh is intended to be Bourne-with-extensions, and is used for writing ZMailer's configuration scripts. It has lists, and its lists nest, unlike rc. That (IMHO) makes it much harder to program in -- rc's flat lists are a much more natural model for a shell. Anyway, here is a cautionary tale that demonstrates what happens when you don't keep the overall guiding principle of what you are doing carefully in mind. OK, John. --- begin message from ZMailer list From: Felix Lee Date: Tue, 8 Dec 1992 03:13:30 +1100 To: zmailer@cs.toronto.edu Subject: zmailer, zsh makes numbers disappear. Message-Id: <92Dec7.110320est.87558@guardian.cs.psu.edu> If you send mail to "123456", zmailer bounces it back correctly, but the error says "no such user -" instead of "no such user 123456". The number disappears because crossbar calls (uucproute "123456"), and uucproute does a (return "$address"), where address=123456. The problem is 'return' behaves entirely differently when it's given a number. This is a strange problem with zsh. It looks like this will also cause other subtle router problems that rarely occur in normal operation, but will get exposed by the right combination of errors. Workaround: replace all occurrences of (return $string) with (echo $string; return), which a little less efficient, but does the correct thing. - -- --- end message from ZMailer list From rc-owner Thu Dec 17 04:02:07 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2701>; Thu, 17 Dec 1992 04:00:33 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA17826; Thu, 17 Dec 1992 03:00:18 -0600 Message-Id: <9212170900.AA17826@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Here documents Date: Thu, 17 Dec 1992 04:00:18 -0500 From: Alan Watson X-Mts: smtp I was playing around with here documents, trying to get environment variable substitution within a file, when I noticed the following: [1] ; foo=bar ; cat <; Thu, 17 Dec 1992 09:11:09 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA18196; Thu, 17 Dec 1992 08:10:55 -0600 Message-Id: <9212171410.AA18196@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Here documents Date: Thu, 17 Dec 1992 09:10:55 -0500 From: Alan Watson X-Mts: smtp Obviously, my question 3 should be prefaced by `When a command has both a here document and a redirection of stdin, should the here document be read from the command's stdin?' This prevents the current behaviour of here documents in scripts from changing. Alan. From rc-owner Thu Dec 17 12:16:06 1992 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.to ronto.edu with SMTP id <2749>; Thu, 17 Dec 1992 12:15:40 -0500 Received: by mail-relay-1.mv.us.adobe.com; id AA02667; Thu, 17 Dec 92 09:15:25 -0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA04914; Thu, 17 Dec 92 09:12:51 PST Date: Thu, 17 Dec 1992 12:12:51 -0500 From: Paul Haahr Message-Id: <9212171712.AA04914@utopia.mv.us.adobe.com> Received: by NeXT Mailer (1.63) To: Alan Watson Subject: Re: Here documents Cc: rc mailing list > 1. Can someone provide a more definitive definition of the > source of here documents. here documents are always read from the same place as where commands are read. they are also read at parse time, not execution time. this is done to support here docs in functions and loops, which i believe are not supported by td's rc. (use rc -nx to explore what's going on: heredocs get turned into here strings.) ;; rc -nx ; cat << EOF hello, $USER EOF cat <<<'hello, '^$^USER^' ' ; > 2. Should a here document be read from rc's stdin, rather than the > source of its commands? Would this break any existing scripts? > This would allow example [3] to work. no, that's what redirection, pipes, and normal standard input processing do. it would break just about every script. > 3. Should a here document be read from a command's stdin, > rather than the shell input? Would this break any existing scripts? > This would allow example [2] to work. no, for the same reasons. ---- as to your examples, i don't see why you're using here docs: > [2] ; { echo '$foo' ; echo EOF } | cat < [3] ; { echo '$foo' ; echo EOF } | rc -c 'cat < [4] ; { echo 'cat < I am intrigued that such subtleties exist in an apparently > straightforward feature of the language. heredocs don't fit naturally into the model of the rest of the shell, but are so useful as to warrant an exception. i think byron's solution (here strings and conversion at parse time) is elegant and clever, and, when understood, makes the answers to ``what if?'' questions obvious. From rc-owner Thu Dec 17 13:29:23 1992 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2701>; Thu, 17 Dec 1992 13:29:06 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA21554; Thu, 17 Dec 1992 12:29:04 -0600 Message-Id: <9212171829.AA21554@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Here documents Date: Thu, 17 Dec 1992 13:29:03 -0500 From: Alan Watson X-Mts: smtp Paul writes: > heredocs get turned into here strings Ah, finally a justification for here strings (my number three candidate for elimination from rc after ` without {} and ``{}). >> 2. Should a here document be read from rc's stdin, rather than the >> source of its commands? Would this break any existing scripts? > >no, that's what redirection, pipes, and normal standard input processing do. >it would break just about every script. I was thinking more of interactive invocations of rc (or, perhaps more accurately, I was emphatically not thinking about scripts). A better suggestion would be that if we are at EOF on the source of command input, a here document should be read from stdin; this would allow my example [3] to work. Byron writes: > As to your question about whether input should be read from stdin > "if there's a redirection of stdin". What does this mean? I mean that when I specify both a redirection of stdin (by putting a pipe in front of a command or using an explicit `<') and a here document, that the here document should be read from the source of stdin. In concrete terms, this would take a hypothetical: ; foo | bar < In general, > it's not possible to tell if there's a redirection of stdin. Really? Yes, rc cannot tell if its stdin has been redirected, but surely it can tell if it is asked to redirect the stdin of a command. Perhaps not, as rc does not fault any of: ; cat foo | cat foo | cat ; cat foo >bar for having multiple redirections of stdin and stdout. To be honest, I would be happiest if rc had issued error messages for my examples [2] and [3], but from Byron's statement this would appear to be impossible. I have to say I am somewhat surprised. Perhaps Byron's description of the source of here documents should be added to the man page, just for completeness. Alan. From rc-owner Thu Dec 17 14:34:19 1992 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2747>; Thu, 17 Dec 1992 14:33:54 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA03224; Thu, 17 Dec 92 11:31:55 PST Received: by netapp.netapp.com (4.1/SMI-4.1) id AA04653; Thu, 17 Dec 92 11:19:17 PST Date: Thu, 17 Dec 1992 14:19:17 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9212171919.AA04653@netapp.netapp.com> To: alan@oldp.astro.wisc.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Here documents >Ah, finally a justification for here strings. Sorry, but it's in TFM: (This feature enables rc to export functions using here documents into the environment; the author does not expect users to find this feature useful.) From rc-owner Thu Dec 17 14:46:29 1992 Received: from netmail.microsoft.com ([131.107.1.3]) by hawkwind.utcs.toronto.e du with SMTP id <2748>; Thu, 17 Dec 1992 14:46:07 -0500 Received: from ingate.microsoft.com by netmail.microsoft.com with SMTP (5.65/25 -eef) id AA11301; Thu, 17 Dec 92 11:36:32 -0800 Received: from microsoft by ingate.microsoft.COM id aa29990; Thu, 17 Dec 92 11:35:56 PST X-Msmail-Message-Id: B0B1F477 X-Msmail-Conversation-Id: B0B1F477 X-Msmail-Wiseremark: Snail version -8.50 To: rc@hawkwind.utcs.toronto.edu Date: Tue, 8 Dec 1992 12:17:55 -0500 Subject: Here documents From: raymondc@microsoft.COM Message-Id: <9212171135.aa29990@ingate.microsoft.COM> : { echo 'cat <; Thu, 17 Dec 1992 22:09:09 -0500 Received: from cerberus.bhpese.oz.au by merlin.resmel.bhp.com.au with SMTP id A A19365 (5.65c/IDA-1.4.4 for ); Fri, 18 Dec 1992 14:08: 15 +1100 Received: from localhost by cerberus.bhpese.oz.au with SMTP id AA29892; Fri, 18 Dec 1992 14:08:25 +1100; sendmail 5.67a/Sm3.5RMSU (from Sm@cerberus.bhpese.oz.au for rc@hawkwind.utcs.toronto.edu) Message-Id: <199212180308.AA29892@cerberus.bhpese.oz.au> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Here documents In-Reply-To: Your message of "Thu, 17 Dec 92 13:29:03 EST." <9212171829.AA21554@oldp.astro.wisc.edu> X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" I expect here documents to be part of the shell syntax stream, rather than part of the shell data stream. Thus it did not occur to me that something like the following would be even conceivable: { echo ...; echo ...; echo EOF } | cat << EOF as for multiple redirection in the same command, this doesn't bother me as long as it is done left->right. So I should be able to do cmd >file1 >[9=1] >[1=2] Sm From rc-owner Tue Jan 12 02:14:00 1993 Received: from merlin.resmel.bhp.com.au ([134.18.1.6]) by hawkwind.utcs.toronto .edu with SMTP id <2408>; Tue, 12 Jan 1993 02:12:42 -0500 Received: from cerberus.bhpese.oz.au by merlin.resmel.bhp.com.au with SMTP id A A04227 (5.65c/IDA-1.4.4 for ); Tue, 12 Jan 1993 18:11: 55 +1100 Received: from localhost by cerberus.bhpese.oz.au with SMTP id AA24909; Tue, 12 Jan 1993 18:12:11 +1100; sendmail 5.67a/Sm3.5RMSU (from Sm@cerberus.bhpese.oz.au for rc@hawkwind.utcs.toronto.edu) Message-Id: <199301120712.AA24909@cerberus.bhpese.oz.au> To: rc@hawkwind.utcs.toronto.edu Subject: rc under hp-ux X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" We have aquired a hp 9000/817 running hp-ux A.09.00, and I started my usual porting sequence, compile rc. Unfortunately, it doesn't work. More specifically stdargs/varargs seems to be playing up. Compiling -O causes the compiler to barf on print.c, compiling -g completes, but then execution results in core dumps. I thought I'd ask if anyone has already solved these problems before spending the time to make it work, so I'd appreciate it if you could drop me a line if you have already hacked rc to work under hp-ux. Sm -- Scott Merrilees, BHP Information Technology, Newcastle, Australia Internet: Sm@bhpese.oz.au Phone: +61 49 40 2132 Fax: ... 2165 From rc-owner Tue Jan 12 02:23:21 1993 Received: from albert.gnu.ai.mit.edu ([128.52.46.31]) by hawkwind.utcs.toronto. edu with SMTP id <2664>; Tue, 12 Jan 1993 02:23:01 -0500 Received: from hal.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP id ; Tue, 12 Jan 93 02:22:56 -0500 Received: by hal.gnu.ai.mit.edu (AIX 3.2/UCB 5.64/4.0) id ; Tue, 12 Jan 1993 02:22:55 -0500 From: mycroft@gnu.ai.mit.edu Message-Id: <9301120722.AA33910@hal.gnu.ai.mit.edu> Subject: Latest version? To: rc@hawkwind.utcs.toronto.edu Date: Tue, 12 Jan 1993 02:22:54 -0500 X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 177 I haven't been paying much attention lately, and I know there was some talk about a version 1.5. As far as I know, 1.4 is still the latest version, though. Is this correct? From rc-owner Tue Jan 12 11:50:11 1993 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2712>; Tue, 12 Jan 1993 11:49:44 -0500 Received: from archone by archone.tamu.edu id <45316>; Tue, 12 Jan 1993 10:49:3 0 -0600 From: Steve Rikli To: rc@archone.tamu.edu Subject: anon. ftp to archone.tamu.edu is up Message-Id: <93Jan12.104930cst.45316@archone.tamu.edu> Date: Tue, 12 Jan 1993 11:49:23 -0500 Anonymous ftp to archone.tamu.edu (128.194.53.42) should now be enabled. For those of you new to rc, this was the original home of the rc distribution via ftp, and it is still available there. I don't know offhand where else it has propogated, but the more the better. Hi Byron! cheers, sr. ------------- || Steve Rikli ||| Visualization Lab || || steve@archone.tamu.edu ||| Texas A&M University || || 409-845-3465 ||| College Station, TX 77843-3137 || From rc-owner Tue Jan 12 17:06:14 1993 Received: from relay.cs.toronto.edu ([128.100.1.105]) by hawkwind.utcs.toronto. edu with SMTP id <2723>; Tue, 12 Jan 1993 17:05:42 -0500 Received: from xenitec.on.ca ([142.77.5.3]) by relay.cs.toronto.edu with SMTP i d <150179>; Tue, 12 Jan 1993 17:05:19 -0500 Received: from golem by xenitec.xenitec.on.ca id aa20392; 12 Jan 93 17:00 EST To: Scott Merrilees cc: rc@hawkwind.utcs.toronto.edu Subject: Re: rc under hp-ux In-reply-to: Your message of "Tue, 12 Jan 93 02:12:06 EST." <199301120712.AA24909@cerberus.bhpese.oz.au> Date: Tue, 12 Jan 1993 16:57:37 -0500 From: "David J. Fiander" Message-ID: <9301121657.aa22344@golem.waterloo.on.ca> >From: Scott Merrilees >We have aquired a hp 9000/817 running hp-ux A.09.00, and I started >my usual porting sequence, compile rc. Unfortunately, it doesn't >work. More specifically stdargs/varargs seems to be playing up. >Compiling -O causes the compiler to barf on print.c, compiling -g >completes, but then execution results in core dumps. If I had to guess I would say that this is the fact that rc tries to save a va_list in a struct and pass it around. I had the same problem on another system. I don't know if what rc is doing is legit. according to ANSI, but I also don't quite know how to change it so that it doesn't do that. - David From rc-owner Tue Jan 12 19:30:04 1993 Received: from merlin.resmel.bhp.com.au ([134.18.1.6]) by hawkwind.utcs.toronto .edu with SMTP id <2408>; Tue, 12 Jan 1993 19:29:34 -0500 Received: from cerberus.bhpese.oz.au by merlin.resmel.bhp.com.au with SMTP id A A01619 (5.65c/IDA-1.4.4 for ); Wed, 13 Jan 1993 11:28: 24 +1100 Received: from localhost by cerberus.bhpese.oz.au with SMTP id AA05376; Wed, 13 Jan 1993 11:27:53 +1100; sendmail 5.67a/Sm3.5RMSU (from Sm@cerberus.bhpese.oz.au for rc@hawkwind.utcs.toronto.edu) Message-Id: <199301130027.AA05376@cerberus.bhpese.oz.au> To: rc@hawkwind.utcs.toronto.edu Subject: Re: rc under hp-ux In-Reply-To: Your message of "Tue, 12 Jan 93 16:57:37 EST." <9301121657.aa22344@golem.waterloo.on.ca> X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" >>From: Scott Merrilees >>We have aquired a hp 9000/817 running hp-ux A.09.00, and I started >>my usual porting sequence, compile rc. Unfortunately, it doesn't >>work. More specifically stdargs/varargs seems to be playing up. >>Compiling -O causes the compiler to barf on print.c, compiling -g >>completes, but then execution results in core dumps. > >If I had to guess I would say that this is the fact that rc >tries to save a va_list in a struct and pass it around. I had >the same problem on another system. I don't know if what rc is >doing is legit. according to ANSI, but I also don't quite know >how to change it so that it doesn't do that. This is what I have found, rc core dumps because format->args is zero. Sm From rc-owner Wed Jan 13 01:08:27 1993 Received: from merlin.resmel.bhp.com.au ([134.18.1.6]) by hawkwind.utcs.toronto .edu with SMTP id <2645>; Wed, 13 Jan 1993 01:08:00 -0500 Received: from cerberus.bhpese.oz.au by merlin.resmel.bhp.com.au with SMTP id A A09189 (5.65c/IDA-1.4.4 for ); Wed, 13 Jan 1993 17:07: 12 +1100 Received: from localhost by cerberus.bhpese.oz.au with SMTP id AA17370; Wed, 13 Jan 1993 17:06:41 +1100; sendmail 5.67a/Sm3.5RMSU (from Sm@cerberus.bhpese.oz.au for rc@hawkwind.utcs.toronto.edu) Message-Id: <199301130606.AA17370@cerberus.bhpese.oz.au> To: rc@hawkwind.utcs.toronto.edu Subject: Re: rc under hp-ux X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" >From: Scott Merrilees >We have aquired a hp 9000/817 running hp-ux A.09.00, and I started >my usual porting sequence, compile rc. Unfortunately, it doesn't >work. More specifically stdargs/varargs seems to be playing up. >Compiling -O causes the compiler to barf on print.c, compiling -g >completes, but then execution results in core dumps. It looks like there is a bug in how the hp compiler handles stdarg/varargs stuff. va_start() results in a call to __builtin_va_start(), which I assume is intercepted by the compiler as a special function, & it tries to do some magic. This doesn't seem to work if the first argument is a structure element reference using . or ->. The work around was to replace the structure element references with simple variables. I have raised this matter with hp support, so hopefully the compiler will get fixed. In the interim, if anyone has this problem with a hp, they might like to try the following patch to print.c. Sm -- *** print.c.orig Mon Apr 6 14:22:28 1992 --- print.c Wed Jan 13 16:44:05 1993 *************** *** 272,278 **** int n = -format->flushed; va_list saveargs = format->args; ! va_start(format->args, fmt); n += printfmt(format, fmt); va_end(format->args); format->args = saveargs; --- 272,278 ---- int n = -format->flushed; va_list saveargs = format->args; ! { va_list ap; va_start(ap, fmt); format->args = ap; } n += printfmt(format, fmt); va_end(format->args); format->args = saveargs; *************** *** 300,306 **** format.flushed = 0; format.u.n = fd; ! va_start(format.args, fmt); printfmt(&format, fmt); va_end(format.args); --- 300,306 ---- format.flushed = 0; format.u.n = fd; ! { va_list ap; va_start(ap, fmt); format.args = ap; } printfmt(&format, fmt); va_end(format.args); *************** *** 341,347 **** Format format; char *result; format.u.n = 1; ! va_start(format.args, fmt); result = memprint(&format, fmt, ealloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); return result; --- 341,347 ---- Format format; char *result; format.u.n = 1; ! { va_list ap; va_start(ap, fmt); format.args = ap; } result = memprint(&format, fmt, ealloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); return result; *************** *** 351,357 **** Format format; char *result; format.u.n = 0; ! va_start(format.args, fmt); result = memprint(&format, fmt, nalloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); return result; --- 351,357 ---- Format format; char *result; format.u.n = 0; ! { va_list ap; va_start(ap, fmt); format.args = ap; } result = memprint(&format, fmt, nalloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); return result; From rc-owner Fri Jan 15 12:28:05 1993 Received: from bcars520 ([192.58.194.73]) by hawkwind.utcs.toronto.edu with SMT P id <2664>; Fri, 15 Jan 1993 12:21:27 -0500 X400-Received: by mta bcars520 in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 15 Jan 1993 12:21:05 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 15 Jan 1993 12:19:19 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 15 Jan 1993 07:20:00 -0500 Date: Fri, 15 Jan 1993 07:20:00 -0500 X400-Originator: /DD.ID=1619692/G=Hamish/I=HI/S=Macdonald/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.840:15.00. 93.17.19.19] X400-Content-Type: P2-1984 (2) Content-Identifier: what does ~! ... From: "Hamish (H.I.) Macdonald" Message-ID: <"18857 Fri Jan 15 12:19:31 1993"@bnr.ca> To: rc@hawkwind.utcs.toronto.edu Subject: what does ~! mean? I've noticed the use of ~! in trip.rc in a few places: if (~! `` '' {echo --} $nl) fail echo -- I don't understand what this is supposed to do. According to the grammar, TWIDDLE should be followed by an optional caret and words. I don't see anything in the grammer allowing ~ to be followed by a BANG (unless the ! is a word, in which case there should be white space after the TWIDDLE, no?). Is the sense of this backwards? Should it be '! ~' (or !~) ? Thanks, Hamish. From rc-owner Fri Jan 15 16:29:01 1993 Received: from netcomsv.netcom.com ([163.179.1.9]) by hawkwind.utcs.toronto.edu with SMTP id <2701>; Fri, 15 Jan 1993 16:27:03 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA02415; Fri, 15 Jan 93 13:25:59 PST Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA11374; Fri, 15 Jan 93 13:26:30 PST Date: Fri, 15 Jan 1993 16:26:30 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9301152126.AA11374@netapp.netapp.com> To: hamish@bnr.ca, rc@hawkwind.utcs.toronto.edu Subject: Re: what does ~! mean? It is a typo. Thanks. (Wow, there are 4 of them, that's pretty embarrassing.) From rc-owner Mon Jan 18 01:49:47 1993 Received: from merlin.resmel.bhp.com.au ([134.18.1.6]) by hawkwind.utcs.toronto .edu with SMTP id <2685>; Mon, 18 Jan 1993 01:48:13 -0500 Received: from cerberus.bhpese.oz.au by merlin.resmel.bhp.com.au with SMTP id A A15848 (5.65c/IDA-1.4.4 for ); Mon, 18 Jan 1993 17:47: 46 +1100 Received: from localhost by cerberus.bhpese.oz.au with SMTP id AA26417; Mon, 18 Jan 1993 17:47:41 +1100; sendmail 5.67a/Sm3.5RMSU (from Sm@cerberus.bhpese.oz.au for rc@hawkwind.utcs.toronto.edu) Message-Id: <199301180647.AA26417@cerberus.bhpese.oz.au> To: rc@hawkwind.utcs.toronto.edu Subject: varaiable expansion and here documents X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" I ran into an inconsistancy recently that may be of interest: ; a=(aa bb cc) ; b=2 ; echo $a($b) bb ; cat << EOF $a($b) EOF aa bb cc(2) ; I expected the output from echo & cat to be identical. Comments ? Byron ? Sm -- Scott Merrilees, BHP Information Technology, Newcastle, Australia Internet: Sm@bhpese.oz.au Phone: +61 49 40 2132 Fax: ... 2165 From rc-owner Mon Jan 18 02:24:18 1993 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.to ronto.edu with SMTP id <2712>; Mon, 18 Jan 1993 02:23:58 -0500 Received: by mail-relay-1.mv.us.adobe.com; id AA16972; Sun, 17 Jan 93 23:23:51 -0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA13510; Sun, 17 Jan 93 23:23:10 PST Date: Mon, 18 Jan 1993 02:23:10 -0500 From: Paul Haahr Message-Id: <9301180723.AA13510@utopia.mv.us.adobe.com> To: Sm@cerberus.bhpese.oz.au Subject: Re: varaiable expansion and here documents Cc: rc@hawkwind.utcs.toronto.edu the behavior of Byron's rc agrees with Tom Duff's paper, which refers to variable names but not expressions. these rules are simple. let's not confuse matters by allowing arbitrary expression syntax to heredocs. my $.02. From rc-owner Mon Jan 18 11:36:57 1993 Received: from netcomsv.netcom.com ([163.179.1.9]) by hawkwind.utcs.toronto.edu with SMTP id <2685>; Mon, 18 Jan 1993 11:34:06 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA23047; Mon, 18 Jan 93 08:33:04 PST Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA01007; Mon, 18 Jan 93 08:33:04 PST Date: Mon, 18 Jan 1993 11:33:04 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9301181633.AA01007@netapp.netapp.com> To: Sm@cerberus.bhpese.oz.au, rc@hawkwind.utcs.toronto.edu Subject: Re: varaiable expansion and here documents I don't know if it's obvious in the documentation, but variable expansion inside here documents is of a very restricted form. e.g., look at the discusson of how the '^' character is treated, or how to enter a literal '$'. If you need list concatenation, backquote expansion, etc., then you should use the regular rc parser. From rc-owner Mon Jan 18 22:00:54 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2726>; Mon, 18 Jan 1993 22:00:04 -0500 Received: by mod.civil.su.oz.au id <28688>; Tue, 19 Jan 1993 13:59:34 +1100 From: John (Most modern computers would break if you stood on them) Mackin Date: Mon, 18 Jan 1993 21:57:45 -0500 To: The rc Mailing List Subject: Re: varaiable expansion and here documents In-Reply-To: <9301180723.AA13510@utopia.mv.us.adobe.com> Message-ID: <199301191357.1902.rc.bafok@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ these rules are simple. let's not confuse matters by allowing arbitrary expression syntax to heredocs. I agree 100% with Paul. It's not necessary and would just be a feeping creature. OK, John. From rc-owner Mon Jan 18 22:36:10 1993 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2741>; Mon, 18 Jan 1993 22:35:37 -0500 Received: by archone.tamu.edu id <45316>; Mon, 18 Jan 1993 21:35:10 -0600 From: Steve Rikli To: rc@archone.tamu.edu Subject: ~ expansion Message-Id: <93Jan18.213510cst.45316@archone.tamu.edu> Date: Mon, 18 Jan 1993 22:35:07 -0500 Would some kind soul who archived the ~username expansion discussion be so kind as to forward it to me? Failing that, would someone who has hacked a workable ~username definition/function be willing to share? thnx, sr. From rc-owner Tue Jan 19 00:08:41 1993 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.to ronto.edu with SMTP id <2701>; Tue, 19 Jan 1993 00:08:02 -0500 Received: by mail-relay-1.mv.us.adobe.com; id AA19946; Mon, 18 Jan 93 21:07:55 -0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA14286; Mon, 18 Jan 93 21:07:13 PST Date: Tue, 19 Jan 1993 00:07:13 -0500 From: Paul Haahr Message-Id: <9301190507.AA14286@utopia.mv.us.adobe.com> To: steve@archone.tamu.edu Subject: Re: ~ expansion Cc: rc@hawkwind.utcs.toronto.edu well, the one from es could be lifted quite easily and retrofitted. it's ftp'able from ftp.white.toronto.edu. From rc-owner Tue Jan 19 02:15:32 1993 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2714>; Tue, 19 Jan 1993 02:15:06 -0500 Received: from relay1.UU.NET ([192.48.96.5]) by archone.tamu.edu with SMTP id < 45316>; Tue, 19 Jan 1993 01:14:49 -0600 Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA02138; Tue, 19 Jan 93 02:14:46 -0500 Received: from localhost.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA21881; Mon, 18 Jan 93 23:14:46 PST Message-Id: <9301190714.AA21881@cygnus.com> To: Steve Rikli Cc: rc@archone.tamu.edu Subject: Re: ~ expansion In-Reply-To: Your message of "Mon, 18 Jan 93 22:35:07 EST." <93Jan18.213510cst.45316@archone.tamu.edu> Date: Tue, 19 Jan 1993 02:14:46 -0500 From: brendan@cygnus.com Here's my hack for it: *** glob.c.~1~ Mon Feb 17 14:45:24 1992 --- glob.c Tue Nov 10 02:08:26 1992 *************** static List *doglob(char *w, char *m) { *** 194,198 **** zero) since doglob gets called iff there's a metacharacter to be mat ched */ ! if (*s == '\0') { matched = dmatch(".", dir, metadir); goto end; --- 195,199 ---- zero) since doglob gets called iff there's a metacharacter to be mat ched */ ! if (*s == '\0' && *w != '~') { matched = dmatch(".", dir, metadir); goto end; *************** static List *doglob(char *w, char *m) { *** 203,206 **** --- 204,216 ---- firstdir.n = NULL; matched = &firstdir; + } else if (*w == '~') { + firstdir.w = varlookup("home")->w; + firstdir.n = NULL; + matched = &firstdir; + if (*s == '\0') { + firstdir.m = NULL; + goto end; + } + firstdir.m = metadir; } else { /* *** lex.c.~1~ Tue Mar 31 08:40:20 1992 --- lex.c Tue Nov 10 02:04:25 1992 *************** *** 38,42 **** 1, 1, 0, 1, 1, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, ! 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, --- 38,42 ---- 1, 1, 0, 1, 1, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, ! 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, /* ~ */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, *************** top: while ((c = gchar()) == ' ' || c == *** 98,104 **** w = RW; i = 0; read: do { buf[i++] = c; ! if (c == '?' || c == '[' || c == '*') saw_meta = TRUE; if (i >= bufsize) --- 98,111 ---- w = RW; i = 0; + if (c == '~') { + c = gchar(); + ugchar(c); + if (c == ' ' || c == '\t') + return TWIDDLE; + c = '~'; + } read: do { buf[i++] = c; ! if (c == '?' || c == '[' || c == '*' || c == '~') saw_meta = TRUE; if (i >= bufsize) From rc-owner Tue Jan 19 16:53:49 1993 Received: from mail-relay-1.mv.us.adobe.com ([130.248.1.1]) by hawkwind.utcs.to ronto.edu with SMTP id <2699>; Tue, 19 Jan 1993 16:52:11 -0500 Received: by mail-relay-1.mv.us.adobe.com; id AA22808; Tue, 19 Jan 93 13:52:02 -0800 Received: by utopia.mv.us.adobe.com (NeXT-1.0 (From Sendmail 5.52)/NX3.0S) id AA00335; Tue, 19 Jan 93 13:50:59 PST Date: Tue, 19 Jan 1993 16:50:59 -0500 From: Paul Haahr Message-Id: <9301192150.AA00335@utopia.mv.us.adobe.com> Received: by NeXT Mailer (1.63) To: es mailing list , rc mailing list Subject: informal BOF at usenix? do we have enough rc and es users going to usenix in san diego to be worth putting together a very informal birds of a feather session? byron & i will both be there. if you're interested, reply to me. paul From rc-owner Thu Jan 21 22:46:54 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2699>; Thu, 21 Jan 1993 22:45:49 -0500 Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09581; Thu, 21 Jan 93 22:45:36 -0500 Received: from localhost.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA01794; Thu, 21 Jan 93 19:45:35 PST Message-Id: <9301220345.AA01794@cygnus.com> To: rc mailing list Subject: rc on the Alpha Date: Thu, 21 Jan 1993 22:45:35 -0500 From: brendan@cygnus.com FYI, rc works fine on the alpha with none of the special defines turned on. Brendan From rc-owner Tue Feb 2 16:56:47 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2726>; Tue, 2 Feb 1993 16:55:03 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA24335; Tue, 2 Feb 93 16:54:49 -0500 Received: by earth.osf.org (5.65/4.7) id AA02326; Tue, 2 Feb 93 16:54:47 -0500 Date: Tue, 2 Feb 1993 16:54:47 -0500 From: rsalz@osf.org Message-Id: <9302022154.AA02326@earth.osf.org> To: rc@hawkwind.utcs.toronto.edu Subject: for your amusement In alt.sources From: jfriedl@TUBBY.MACH.CS.CMU.EDU (Jeffrey Friedl) Message-ID: This is an implementation of the (big, bloated, featureful) FSF readline library in the (big, bloated, featureful) Perl language. Awe-inspiring. /r$ From rc-owner Mon Feb 22 10:43:48 1993 Received: from mailbox.osf.org ([130.105.1.8]) by hawkwind.utcs.toronto.edu wit h SMTP id <2749>; Mon, 22 Feb 1993 10:38:04 -0500 Received: from earth.osf.org by mailbox.osf.org (5.64+/OSF 1.0) id AA04404; Mon, 22 Feb 93 10:37:58 -0500 Received: by earth.osf.org (5.65/4.7) id AA11536; Mon, 22 Feb 93 10:37:57 -0500 Date: Mon, 22 Feb 1993 10:37:57 -0500 From: rsalz@osf.org Message-Id: <9302221537.AA11536@earth.osf.org> To: rc@hawkwind.utcs.toronto.edu Subject: Why featureful shells can be bad Here's a fun story. The machine rodan.uu.net is the central server for internal stuff at UUNET; it's where staff gets their email, has their homedirs, etc. Well for some reason there was a file /usr/spool/mqueue/=sendmail file, but no /usr/lib/sendmail. Someone cp'd the latter, and tried to remove the former rm =sendmail Well, in zsh "=foo" means "expand to the full path of the exectuable of foo. Zap, away went /usr/lib/sendmail AGAIN and nobody at uunet got email for an hour or two. Two iterations of this. /r$ From rc-owner Mon Mar 1 15:45:51 1993 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2766>; Mon, 1 Mar 1993 15:44:04 -0500 Received: from odin.INS.CWRU.Edu ([129.22.8.102]) by archone.tamu.edu with SMTP id <45316>; Mon, 1 Mar 1993 14:43:14 -0600 Received: by odin.INS.CWRU.Edu (5.65b+ida+/CWRU-1.5.4-ins) id AA05364; Mon, 1 Mar 93 15:43:23 -0500 (from chet for rc@archone.tamu .edu) Resent-Message-Id: <9303012043.AA05364@odin.INS.CWRU.Edu> Resent-Date: Tue, 6 Aug 1991 12:10:43 -0400 Resent-From: Chet Ramey Date: Tue, 6 Aug 1991 12:10:43 -0400 From: Donn Cave Sender: Chet Ramey Subject: Re: login shells Reply-To: chet@po.CWRU.Edu Resent-To: rc@archone.tamu.edu Message-Id: <9108061610.AA02130@milton.u.washington.edu> Read-Receipt-To: chet@po.CWRU.Edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Return-Path: Apparently-To: rc@archone.tamu.edu > I think rshd is broken. How should it work? Would it be OK with you, if rshd exec'd commands with "-" prefixed to the shell name in argv[0], thus causing them to be "logins"? That will force people who exec stty etc. in .rcrc to bracket that stuff with an interactivity test, but it's fairly straightforward. Donn Cave, University Computing Services, University of Washington donn@cac.washington.edu -- ``The use of history as therapy means the corruption of history as history.'' -- Arthur Schlesinger Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu From rc-owner Mon Mar 1 15:46:11 1993 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2770>; Mon, 1 Mar 1993 15:45:57 -0500 Received: from odin.INS.CWRU.Edu ([129.22.8.102]) by archone.tamu.edu with SMTP id <45312>; Mon, 1 Mar 1993 14:43:59 -0600 Received: by odin.INS.CWRU.Edu (5.65b+ida+/CWRU-1.5.4-ins) id AA05405; Mon, 1 Mar 93 15:44:08 -0500 (from chet for rc@archone.tamu .edu) Date: Mon, 1 Mar 1993 15:43:48 -0500 From: Chet Ramey To: rc@archone.tamu.edu Subject: whoops Reply-To: chet@po.CWRU.Edu Message-Id: <9303012043.AA05395.SM@odin.INS.CWRU.Edu> Read-Receipt-To: chet@po.CWRU.Edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sorry about that. -- ``The use of history as therapy means the corruption of history as history.'' -- Arthur Schlesinger Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu From rc-owner Tue Mar 9 06:39:34 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2784>; Tue, 9 Mar 1993 06:37:45 -0500 Received: by mod.civil.su.oz.au id <28686>; Tue, 9 Mar 1993 21:37:18 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Tue, 9 Mar 1993 06:32:13 -0500 To: The rc Mailing List Subject: backquote poser Message-ID: <199303092132.8960.rc.baful@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ I was just writing an rc script where I wanted to assign a variable the value of the output of the "domainname" command. This command might not be present on the system the script is being run on; if not, I wanted the variable assigned the null list, and for no error message about domainname not being found to be echoed onto the script's standard error. The best thing I could come up with was: domain = ` { exec >[2] /dev/null; domainname } Anyone got a cleaner idea? For some reason it seems to me it should be able to be done more neatly. I guess I mainly don't like needing a semicolon. OK, John. From rc-owner Tue Mar 9 07:14:04 1993 Received: from albert.gnu.ai.mit.edu ([128.52.46.31]) by hawkwind.utcs.toronto. edu with SMTP id <2784>; Tue, 9 Mar 1993 07:13:47 -0500 Received: from hal.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP id ; Tue, 9 Mar 93 07:13:31 -0500 Received: by hal.gnu.ai.mit.edu (AIX 3.2/UCB 5.64/4.0) id ; Tue, 9 Mar 1993 07:13:29 -0500 From: mycroft@gnu.ai.mit.edu Message-Id: <9303091213.AA42953@hal.gnu.ai.mit.edu> Subject: Re: backquote poser To: rc@hawkwind.utcs.toronto.edu Date: Tue, 9 Mar 1993 07:13:29 -0500 In-Reply-To: <199303092132.8960.rc.baful@civil.su.oz.au> from "John" at Mar 9, 93 06:32:13 am X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 410 > domain = ` { exec >[2] /dev/null; domainname } > > Anyone got a cleaner idea? For some reason it seems to me it should > be able to be done more neatly. I guess I mainly don't like needing > a semicolon. Snippets from my .rcrc: EDITOR=`{which vi >[2] /dev/null || echo /usr/ucb/vi} PAGER=`{which less >[2] /dev/null || which more >[2] /dev/null} UNSHAR=`{which unshar >[2] /dev/null || echo /bin/sh} From rc-owner Tue Mar 9 07:29:17 1993 Received: from tamarin.bath.ac.uk ([138.38.32.3]) by hawkwind.utcs.toronto.edu with SMTP id <2784>; Tue, 9 Mar 1993 07:28:59 -0500 Received: from gdr.bath.ac.uk by tamarin.bath.ac.uk with SMTP (PP) id <21662-0@tamarin.bath.ac.uk>; Tue, 9 Mar 1993 12:28:16 +0000 Date: Tue, 9 Mar 1993 07:28:11 -0500 From: Icarus Sparry To: John cc: The rc Mailing List Subject: Re: backquote poser Reply-to: I.Sparry@bath.ac.uk Message-Id: <93Mar9.072859est.2784@hawkwind.utcs.toronto.edu> domain = `{ {domainname} >[2] /dev/null } ^ Actually I think an '@' should be needed here, but it appears that one is optional. From rc-owner Wed Mar 10 16:25:41 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2789>; Wed, 10 Mar 1993 16:22:43 -0500 To: rc Subject: Things I'd like whatis to have: Date: Wed, 10 Mar 1993 16:22:28 -0500 From: Chris Siebenmann Message-Id: <93Mar10.162243est.2789@hawkwind.utcs.toronto.edu> Arguments -e, -f, and -p to restrict the search to environment variables, functions, and programs. The default case would continue to be '-efp'. (I suggest -e and -f for symmetry; I'm really only interested in -p) - cks From rc-owner Wed Mar 10 16:30:01 1993 Received: from albert.gnu.ai.mit.edu ([128.52.46.31]) by hawkwind.utcs.toronto. edu with SMTP id <2791>; Wed, 10 Mar 1993 16:29:46 -0500 Received: from hal.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP id ; Wed, 10 Mar 93 16:29:19 -0500 Received: by hal.gnu.ai.mit.edu (AIX 3.2/UCB 5.64/4.0) id ; Wed, 10 Mar 1993 16:29:18 -0500 From: mycroft@gnu.ai.mit.edu Message-Id: <9303102129.AA32186@hal.gnu.ai.mit.edu> Subject: Re: Things I'd like whatis to have: To: cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) Date: Wed, 10 Mar 1993 16:29:18 -0500 Cc: rc@hawkwind.utcs.toronto.edu In-Reply-To: <93Mar10.162243est.2789@hawkwind.utcs.toronto.edu> from "Chris Sie benmann" at Mar 10, 93 04:22:28 pm X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 97 I was thinking of `whatis -b', where the `b' means `builtin'. You can guess what it would do. From rc-owner Wed Mar 10 16:37:51 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2793>; Wed, 10 Mar 1993 16:37:29 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA07728; Wed, 10 Mar 93 16:36:49 -0500 Received: by earth.osf.org (5.65/4.7) id AA16597; Wed, 10 Mar 93 16:36:49 -0500 Date: Wed, 10 Mar 1993 16:36:49 -0500 From: rsalz@osf.org Message-Id: <9303102136.AA16597@earth.osf.org> To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Things I'd like whatis to have: here's "whatis -p", called "wh" from a standard old BBN program. fn wh { i=() { for (i in $path) { test -x $i^/^$1 && echo $i^/^$1 && return 0 } echo $1 not found >[1=2] return 1 } } From rc-owner Wed Mar 10 18:32:50 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2789>; Wed, 10 Mar 1993 18:32:21 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18112; Wed, 10 Mar 93 17:54:14 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 175344.4740; Wed, 10 Mar 1993 17:53:44 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa11947; Wed, 10 Mar 93 17:16:19 EST From: culliton@srg.srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Things I'd like whatis to have: Date: Wed, 10 Mar 1993 17:16:16 -0500 Message-Id: <9303101716.aa10551@ceres.srg.af.mil> To me this seems like an idea worth at least considering, it would also be nice to have an option to see the whole chain of candidates. (the function and possibly the builtin or executable(s)) I once had a function, that called a script, that called the binary, all with the same name, and it stopped working when another version appeared in my path. (Memory falters on whether this was from changing the $path or an executable in a new place.) I ended up writing the following rc function to tell me where an executable was (or could be) coming from. It should probably also check if there is a function by the name given, before listing the executable files, but I tend to know what functions are in my .rcrc file. fn whereis { i=() p=() { for (i) for (p in $path) if (test -f $p/$i -a -x $p/$i) echo $p/$i }} From rc-owner Wed Mar 10 18:41:49 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2792>; Wed, 10 Mar 1993 18:41:18 -0500 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA08478; Wed, 10 Mar 93 18:41:16 -0500 Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 184012.12209; Wed, 10 Mar 1993 18:40:12 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa12944; Wed, 10 Mar 93 18:21:52 EST From: culliton@srg.srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu, rsalz@osf.org Subject: Re: Things I'd like whatis to have: Date: Wed, 10 Mar 1993 18:21:45 -0500 Message-Id: <9303101821.aa10970@ceres.srg.af.mil> > From: rsalz@osf.org > > here's "whatis -p", called "wh" from a standard old BBN program. > fn wh { i=() { > for (i in $path) { > test -x $i^/^$1 && echo $i^/^$1 && return 0 > } > echo $1 not found >[1=2] > return 1 > } } This has a slight bug, to avoid getting caught by directories the test should be: test -f $i^/^$1 -a -x $i^/^$1 Tom From rc-owner Thu Mar 11 10:51:07 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2789>; Thu, 11 Mar 1993 10:50:22 -0500 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA20408; Thu, 11 Mar 93 10:49:54 -0500 Received: by earth.osf.org (5.65/4.7) id AA17928; Thu, 11 Mar 93 10:49:53 -0500 Date: Thu, 11 Mar 1993 10:49:53 -0500 From: rsalz@osf.org Message-Id: <9303111549.AA17928@earth.osf.org> To: cks@hawkwind.utcs.toronto.edu, culliton@srg.srg.af.mil, rc@hawkwind.utcs.toronto.edu, rsalz@osf.org Subject: Re: Things I'd like whatis to have: >This has a slight bug, to avoid getting caught by directories the test Pedantically, yes. I like seeing directory name/executable clobbers. It is normally not an issue for me since I just threw the "&& return 0" on to what I posted; normally I don't have that -- I want to see all versions. Chris was concerned about the cost of exec'ing all those test(1)'s. This version cuts it down to one: fn mywhat { @ for (i) { fn $i whatis $i } } From rc-owner Thu Mar 18 11:45:59 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2688>; Thu, 18 Mar 1993 11:39:30 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA23968; Thu, 18 Mar 1993 10:39:18 -0600 Message-Id: <9303181639.AA23968@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: exec-ing a function Date: Thu, 18 Mar 1993 11:39:17 -0500 From: Alan Watson X-Mts: smtp This may be old hat to some, but after some confusion I have just discovered that one can `exec' a function. Perhaps a sentence in the manual page would save others confusion. Incidentally, I had an observing run at the Kitt Peak National Observatory a couple of weeks ago. Modern observing is not especially fun -- you basically sit at a computer for 16h each night. After a few minutes with csh, I went looking in /etc/shells for the alternatives, and to my pleasant surprise found rc (but, interestingly, neither ksh, tcsh, zsh, or bash). The Good News is spreading! Alan. From rc-owner Sun Mar 21 22:21:53 1993 Received: from netcomsv.netcom.com ([163.179.1.9]) by hawkwind.utcs.toronto.edu with SMTP id <2688>; Sun, 21 Mar 1993 22:21:03 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA03742; Sun, 21 Mar 93 19:21:11 PST Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA12650; Sun, 21 Mar 93 19:12:26 PST Date: Sun, 21 Mar 1993 22:12:26 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9303220312.AA12650@netapp.netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: informal survey regarding <{} I was wondering if anyone in rc-land is using the <{} feature with fifos. Specifically, I've been thinking about ditching fifos in favor of synchronous operation with tmp files. Advantages: o You can seek on a tmp file, so diff will work. o tmp files are much closer in semantics to real pipes, so I expect fewer bugs. o fifos aren't present everywhere, files are. o fifos don't work everywhere (e.g., the notorious tmpfs bug), files do. Disadvantages: o Existing users might depend on fifos. o Advantage of pipe in the kernel is lost; command must wait on all the tmp files being written first. I could even argue, based on the first item in "Advantages", that one might want to use tmp files even over /dev/fd, but I don't want to risk starting a flame war. Anyway, reply to me and I can summarize to the list. From rc-owner Sun Mar 21 22:33:40 1993 Received: from merlin.resmel.bhp.com.au ([134.18.1.6]) by hawkwind.utcs.toronto .edu with SMTP id <2688>; Sun, 21 Mar 1993 22:33:21 -0500 Received: from cerberus.bhpese.oz.au by merlin.resmel.bhp.com.au with SMTP id A A20197 (5.65c/IDA-1.4.4 for ); Mon, 22 Mar 1993 13:32: 40 +1000 Received: from localhost by cerberus.bhpese.oz.au with SMTP id AA10340; Mon, 22 Mar 1993 13:32:23 +1000; sendmail 5.67a/Sm3.6RMPSU (from Sm@cerberus.bhpese.oz.au for rc@hawkwind.utcs.toronto.edu) Message-Id: <199303220332.AA10340@cerberus.bhpese.oz.au> To: byron@netapp.com (Byron Rakitzis) Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: informal survey regarding <{} In-Reply-To: Your message of "Sun, 21 Mar 93 22:12:26 EST." <9303220312.AA12650@netapp.netapp.com> X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" >I was wondering if anyone in rc-land is using the <{} feature >with fifos. > >Specifically, I've been thinking about ditching fifos in favor >of synchronous operation with tmp files. > >Advantages: > > o You can seek on a tmp file, so diff will work. > o tmp files are much closer in semantics to real pipes, > so I expect fewer bugs. > o fifos aren't present everywhere, files are. > o fifos don't work everywhere (e.g., the notorious > tmpfs bug), files do. > >Disadvantages: > > o Existing users might depend on fifos. > o Advantage of pipe in the kernel is lost; command must > wait on all the tmp files being written first. > >I could even argue, based on the first item in "Advantages", >that one might want to use tmp files even over /dev/fd, but >I don't want to risk starting a flame war. > >Anyway, reply to me and I can summarize to the list. I'd be interested in the tmp file approach. Fifos don't work under risc/os 4.52. I tried to write a /dev/fd file system for the kernel, but am getting some kernel crashes because of undocumented interfaces. Is there anything wrong with having tmp files as the default, and fifos & /dev/fd as options ? Sm From rc-owner Sun Mar 21 22:58:49 1993 Received: from munnari.oz.au ([128.250.1.21]) by hawkwind.utcs.toronto.edu with SMTP id <2688>; Sun, 21 Mar 1993 22:58:32 -0500 Received: from sw.oz.au (via basser.cs.su.oz.au) by munnari.oz.au with MHSnet ( 5.83--+1.3.1+0.50) id AA15220; Mon, 22 Mar 1993 13:58:11 +1000 (from jeremy@sw.oz.au) Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP id AA09092; Mon, 22 Mar 93 13:43:30 AES (5.59) (from jeremy@sw.oz.au for rc%hawkwind.utcs.toronto.edu@munnari.oz.au) Received: by chao.sw.oz.au (4.1/SMI-4.1) id AA11618; Mon, 22 Mar 93 13:43:19 EST From: jeremy@sw.oz.au (Jeremy Fitzhardinge) Message-Id: <9303220343.AA11618@chao.sw.oz.au> Subject: Porting rc to Linux To: rc@hawkwind.utcs.toronto.edu Date: Sun, 21 Mar 1993 22:43:18 -0500 Organization: Softway Pty Ltd X-Face: '6U=%Tv\k1l-:?\$C[D@ G 7(vl~w8&y}!f\bh#wL#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k} yqshddFb l[EC}c=;uc%x'}uh3E91p&oE (in the kernel source tree). linux/signal.h doesn't have comments after each #define describing the signal. I just made mksignal look at a fake signal.h when running under Linux. A better solution might be to use the sys_siglist array which has the name to number mapping of the signal names, if not a text description. They were the easy problems, that prevented compilation. The subtle one was in which.c. Under linux gid_t is defined as an unsigned short, and getgroups() takes a pointer to gid_t as its second argument. rc uses an array of ints for the group list, so it got a list of bad groups. This meant that rc wouldn't exec a file that was group executable only and the group was in the user's supplimentary list. When searching the path, why does rc try to double guess the kernel by testing the permissions itself rather than just trying to exec it? And if it has to (whatis), why doesn't it just use the access system call rather than doing it for itself in rc_access? The comment says "does the right thing for group-executable files" - does access() not work correctly on other Unicies in this case? J From rc-owner Sun Mar 21 23:16:34 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2701>; Sun, 21 Mar 1993 23:16:20 -0500 Received: by mail-relay-2.mv.us.adobe.com; id AA14961; Sun, 21 Mar 93 20:16:04 -0800 Received: by astro.mv.us.adobe.com; id AA18919; Sun, 21 Mar 93 20:16:37 -0800 Date: Sun, 21 Mar 1993 23:16:37 -0500 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9303220416.AA18919@astro.mv.us.adobe.com> To: jeremy@sw.oz.au, rc@hawkwind.utcs.toronto.edu Subject: Re: Porting rc to Linux > When searching the path, why does rc try to double guess the kernel > by testing the permissions itself rather than just trying to exec it? because you want to be able to do the path search before you fork. > And if it has to (whatis), why doesn't it just use the access system > call rather than doing it for itself in rc_access? because access lies if you run setuid or setgid, among other things. From rc-owner Thu Mar 25 12:31:19 1993 Received: from netcomsv.netcom.com ([163.179.1.9]) by hawkwind.utcs.toronto.edu with SMTP id <2704>; Thu, 25 Mar 1993 12:28:19 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA19484; Thu, 25 Mar 93 09:28:16 PST Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA01022; Wed, 24 Mar 93 19:50:31 PST Date: Wed, 24 Mar 1993 22:50:31 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9303250350.AA01022@netapp.netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: informal results I received 5-6 replies to my question; some people don't use <{} at all, some people think FIFOs are indespensible, and some would like to see a tmp file implementation. If I do anything about this, it will probably be to add tmp files in addition to the two current options, though it makes me unhappy to have 3 implementations of the same feature. Thanks for your input, Byron. From rc-owner Thu Mar 25 19:47:17 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2704>; Thu, 25 Mar 1993 19:46:48 -0500 Received: by mod.civil.su.oz.au id <28678>; Fri, 26 Mar 1993 10:45:57 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Thu, 25 Mar 1993 19:38:16 -0500 To: The rc Mailing List Subject: /dev/fd driver for Ultrix DECstations Message-ID: <199303261038.9018.rc.bagav@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ I thought this was posted to comp.sources.unix. In any case it was certainly ok'd for public release; I would have given a reference to comp.sources.unix for it but when I looked I couldn't work out what was going on there -- maybe the archive site I looked at was busted. Anyway. Since rc can use /dev/fd to advantage, maybe this will interest people on this list. As the Subject: says, this is a device driver implementing /dev/fd for DECstations running Ultrix, version 4.2 (or later, it says; I have only tried 4.2 myself). This is by Boyd Roberts. You need the kernel objects that come with your Ultrix distribution to re-build the kernel to include this driver. Follow the build instructions in the README; they work :). OK, John. # To unbundle, sh this file echo README 1>&2 sed 's/.//' >README <<'//GO.SYSIN DD README' -Installation instructions for a Ninth Edition style /dev/fd driver for -4.2 (and later) ULTRIX systems. - - 1. cp devfd.c /usr/sys/fs/gfs - - 2. Edit /usr/sys/machine/common/conf.c and before `cdevsw' add : - -#if DEVFD > 0 -int devfdopen(); -#else -#define devfdopen nodev -#endif - - 3. Choose a free slot in the `cdevsw' (I used 90) and put: - - {devfdopen, nodev, nodev, nodev, /*90*/ - nodev, nodev, nodev, 0, - nodev, nodev, 0, 0}, - - 4. Edit /usr/sys/conf/mips/files.mips and add: - -fs/gfs/devfd.c optional devfd device-driver Notbinary - - 5. To enable this driver for your kernel, the following two lines - must be added to /usr/sys/conf/mips/ - -options DEVFD -pseudo-device devfd - - - 6. Re-configure your kernel and make it: - - cd /usr/sys/conf/mips/ - config - cd /usr/sys/MIPS/ - make depend - make - - 7. Boot the new `vmunix'. - - 8. Create the necessary special files with /usr/bin/sh5: - - cd /dev - mkdir fd - cd fd - umask 0111 - i=0 - while test $i -lt 64 - do - mknod $i c 90 $i # use major device (ie. 90) that - i=`expr $i + 1` # concurs with your cdevsw entry - done - ln /dev/fd/0 /dev/stdin - ln /dev/fd/1 /dev/stdout - ln /dev/fd/2 /dev/stderr - - 9. You now have a /dev/fd driver, test it with: - - echo '/dev/fd ok?' | cat /dev/stdin - -Thanks to Norman Wilson for an essential piece of insight which allows /dev/fd -to be implemented as a driver, rather than a foul hack in the kernel [c]open() . - - -Boyd Roberts -Member of Technical Staff -Paris Research Laboratory -Digital Equipment Corporation //GO.SYSIN DD README echo devfd.c 1>&2 sed 's/.//' >devfd.c <<'//GO.SYSIN DD devfd.c' -/* Copyright 1991 Digital Equipment Corporation - * All Rights Reserved - * - * Permission to use, copy, and modify this software and its documentation is - * hereby granted only under the following terms and conditions. Both the - * above copyright notice and this permission notice must appear in all copies - * of the software, derivative works or modified versions, and any portions - * thereof, and both notices must appear in supporting documentation. - * - * Users of this software agree to the terms and conditions set forth herein, - * and hereby grant back to Digital a non-exclusive, unrestricted, royalty-fre e - * right and license under any changes, enhancements or extensions made to the - * core functions of the software, including but not limited to those affordin g - * compatibility with other hardware or software environments, but excluding - * applications which incorporate this software. Users further agree to use - * their best efforts to return to Digital any such changes, enhancements or - * extensions that they make and inform Digital of noteworthy uses of this - * software. Correspondence should be provided to Digital at: - * - * Director of Licensing - * Paris Research Laboratory - * Digital Equipment Corporation - * 85 Avenue Victor Hugo - * 92500 Rueil Malmaison - * France - * - * This software may be distributed (but not offered for sale or transferred - * for compensation) to third parties, provided such third parties agree to - * abide by the terms and conditions of this notice. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL - * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES O F - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT - * CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL - * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR - * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS - * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS - * SOFTWARE. - */ - -/* - * Ninth Edition style /dev/fd/... driver. - * - * Boyd Roberts - * Digital PRL - * September '91 - */ - -#include "../h/param.h" -#include "../h/systm.h" -#include "../h/dir.h" -#include "../h/user.h" -#include "../h/kernel.h" -#include "../h/gnode.h" -#include "../h/proc.h" -#include "../h/conf.h" -#include "../h/file.h" -#include "../h/socket.h" -#include "../h/socketvar.h" -#include "../h/mount.h" -#include "../h/stat.h" -#include "../h/ioctl.h" -#include "../h/flock.h" -#include "../h/exec.h" - -#undef GETF -#define GETF(fp, fd) if ((fp = getf(fd)) == NULL) return u.u_error - -int -devfdopen(dev, flag) -dev_t dev; -int flag; -{ - struct file *fp; /* file table entry for this open */ - struct file *dfp; /* file table entry for /dev/fd/`minor(dev)' */ - int fd; /* fd allocated for this open */ - int dfd; /* fd allocated for /dev/fd/`minor(dev)' */ - - dfd = minor(dev); - fd = u.u_r.r_val1; /* courtesy of ufalloc() */ - -#ifdef DEBUG - mprintf("/dev/fd/%d will be %d\n", dfd, fd); -#endif DEBUG - - GETF(dfp, dfd); - GETF(fp, fd); - - /* If both are the same then it's opening a closed /dev/fd/... */ - if (fp == dfp) - return EBADF; - - /* fake dup() */ - smp_lock(&lk_file, LK_RETRY); - U_OFILE_SET(fd, dfp); - dfp->f_count++; - U_POFILE_SET(fd, U_POFILE(dfd)); - smp_unlock(&lk_file); - - /* free my file table entry and return */ - return closef(fp); -} - //GO.SYSIN DD devfd.c From rc-owner Mon Mar 29 14:25:24 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2720>; Mon, 29 Mar 1993 14:23:23 -0500 Received: from localhost by groucho.cs.psu.edu with SMTP id <2539>; Mon, 29 Mar 1993 14:21:58 -0500 To: The rc Mailing List Subject: Re: /dev/fd driver for Ultrix DECstations In-reply-to: Your message of "Thu, 25 Mar 1993 19:38:16 EST." <199303261038.9018.rc.bagav@civil.su.oz.au> Date: Mon, 29 Mar 1993 14:21:23 -0500 From: Scott Schwartz Message-Id: <93Mar29.142158est.2539@groucho.cs.psu.edu> Does anyone have one for SunOS, by any chance? From rc-owner Mon Mar 29 14:55:37 1993 Received: from optima.cs.arizona.edu ([192.12.69.5]) by hawkwind.utcs.toronto.e du with SMTP id <2725>; Mon, 29 Mar 1993 14:54:32 -0500 Received: from wolf.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA20551; Mon, 29 Mar 1993 12:53:23 MST Received: by wolf.cs.arizona.edu; Mon, 29 Mar 1993 12:53:22 MST Date: Mon, 29 Mar 1993 14:47:36 -0500 From: Jim Davis Subject: Re: /dev/fd driver for Ultrix DECstations To: Scott Schwartz Cc: The rc Mailing List In-Reply-To: <93Mar29.142158est.2539@groucho.cs.psu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 29 Mar 1993, Scott Schwartz wrote: > Does anyone have one for SunOS, by any chance? Yes, for 4.1.1. Never tried it on 4.1.2 or 4.1.3, but I think it should work. Anonymous ftp to gemini.tuc.noao.edu:/pub/devfd.shar. (For all its warts, Solaris 2.1 has /dev/fd built in and it works well with rc.) -- Jim Davis | "So here I am, not being entertained." jdavis@cs.arizona.edu | -- Calvin From rc-owner Thu Apr 1 03:44:25 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2724>; Thu, 1 Apr 1993 03:41:39 -0500 Received: by mail-relay-2.mv.us.adobe.com; id AA21839; Thu, 1 Apr 93 00:41:29 - 0800 Received: by astro.mv.us.adobe.com; id AA06451; Thu, 1 Apr 93 00:42:06 -0800 Date: Thu, 1 Apr 1993 03:42:06 -0500 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9304010842.AA06451@astro.mv.us.adobe.com> To: es@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: an even newer shell we'd like to bring y'all up to some work we've been doing on the successor shell to es. Article 9438 of comp.unix.shell: Xref: adobe comp.unix.shell:9438 comp.unix.wizards:20772 Newsgroups: comp.unix.shell,comp.unix.wizards Path: adobe!haahr From: haahr@adobe.com (Paul Haahr) Subject: tzsh, a new shell Message-ID: <1993Apr1.083812.18334@adobe.com> Summary: several kitchen sinks Sender: usenet@adobe.com (USENET NEWS) Reply-To: haahr@adobe.com (Paul Haahr) Organization: Adobe Systems Incorporated Date: Thu, 1 Apr 1993 08:38:12 GMT We'd like to announce the availability of a beta version of tzsh, a new shell for Unix, Plan 9, MS-DOS, and OS/360. For the past several months, since the time we presented a Usenix paper on our previous shell, es, we've been wondering how we could build a shell that people would actually use. We decided that a few simple, clean concepts, borrowed from the most popular shells as well as traditional programming languages would provide a solid basis for a shell that would meet the requirements of most USENET readers. A while ago, we realized that Scheme and functional languages made little sense as the basis for shells, because hierarchical lists did not match well the semantics of the Unix(TM) execve(2) argv vector. We found, however, the semantics very well matched the concept of the ``array'' from the FORTRAN family of languages. (For those unfamiliar with the array concept, there are probably some books that still teach FORTRAN.) When we started looking further at what we could steal from FORTRAN, we realized that one of the ideas which had lead us astray in rc and es was the use of whitespace as a separator. In tzsh (when using tzsh syntax, see below) the comma is used to separate words. By using comma as the separator, whitespace characters do not have to be quoted. Further, the use of a continuation character in column 6 of input can continue lines, so backslashes do not have to be quoted. Quoting rules in tzsh are rather simple. By preceding a string with a number (n) and the letter H, all the following n characters are quoted, except if they are one of $ ` ! which must be quoted by doubling them inside the quoted string. To get around the infamous quoted backquotes inside backquotes problem from /bin/sh, without using the confusing rc or es syntax, all backquote substitutions start from the ` character and go up to the end of the line (or column 72, which ever comes first). Tzsh also borrows implicit typing of variables from FORTRAN. Any shell variable whose name begins with a P or Q is taken to be a colon-separated path. Variables that start with I-N are integers. Variables that start with the letters A-E and L-N are not exported into the environment, by default, though the ``export'' and `dontexport'' commands can override the defaults. For convenience, all shell variables must be all-uppercase, with up to six significant characters. And, another feature borrowed from FORTRAN that will certainly please novice shell users: All shell variables are global. Changes to a shell variable performed in a subshell automatically change the value in the parent shell. This feature alone should reduce volume in comp.unix.questions by 50%. Tzsh borrows many interactive features from bash, zsh, and tcsh. We think, in fact, that tzsh offers the most comprehensive set of command editing and completion features. Based on the user settable variable, COMMAND_LINE_EDITOR_EMULATION you can control what editor the command line editor emulates. The default is TECO, but tzsh also supports emacs, vi, sam -d, ed, and WYLBUR modes. We hope to support sam (not -d), sun textedit and MS-DOS EDLIN style editing in the final release. (In addition, tzsh accepts !-style history, but the colon suffixes are perl programs rather than sed-style expressions.) Tzsh will complete commands, file names, directory names, sentences, user names, host names, phone numbers, mail aliases, variable names from C and FORTRAN programs, shell variables, dates, and inode numbers. By redefining the COMPLETION_METHOD variable, the programmer can add specific types of completion and the programs which use them. Of course, tzsh has job control. On initialization, tzsh runs all of the .-named files in your home directory, except that it doesn't run .profile, .rcrc, and .esrc unless it was invoked as a login shell or it thinks you haven't logged in yet. If given the -N flag, tzsh also doesn't run .newsrc and .Xdefaults; the authors swear by this option. Tzsh optionally accepts all valid sh, ksh, bash, csh, tcsh, zsh, rc, and es commands. If a command would be interpreted differently by some of the shells, the user can set the environment variable PSHELL_EMULATION_PATH to a list of colon-separated shell names giving the order in which to resolve conflicts between different possible interpretations. For example, PSHELL_EMULATION_PATH=tzsh:zsh:rc:sh:es says that tzsh should first try to interpret commands with tzsh syntax, and if they are illegal that way, then try zsh syntax, etc. As a special case, a component of PSHELL_EMULATION_PATH may be two (or more) shell names separated by ampersands. If the interpretation of the command differs between the shells, both versions are run. For example PSHELL_EMULATION_PATH=rc&csh:es:zsh:bash date | mail research!rob both mails the date to Rob Pike and prints ``rob: Event not found.'' Note that using 'rc&rc' as a component is a convenient way to guarantee that all commands are executed twice. When using tzsh over a noisy phone line, the form ``rc&rc&rc'' is very useful; a majority vote of the interpretations of the commands is used. A beta copy of the shell may be obtained from ftp.kremvax.su:/pub/tzsh/tzsh-0.999.tar.Z There is no man page yet, but reading the source along with every other line from the zsh, tcsh, and perl man pages should be a good enough guide to the shell for most FORTRAN 8x programmers. We would like to thank Raymond Chen and Dave Hitz for their help in the design and implementation of tzsh. -- Paul Haahr & Byron Rakitzis -- paul haahr adobe systems incorporated haahr@adobe.com ...!decwrl!adobe!haahr +1 415 962 6056 From rc-owner Wed Apr 7 23:21:36 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2738>; Wed, 7 Apr 1993 23:17:11 -0400 Received: by mod.civil.su.oz.au id <28689>; Thu, 8 Apr 1993 13:16:53 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Wed, 7 Apr 1993 23:12:41 -0400 To: The rc Mailing List Subject: minor but annoying rc-1.4 bug Message-ID: <199304081312.14307.rc.bagez@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ In certain circumstances, rc 1.4 reports an error with the incorrect line number, and I don't mean off by one. The simplest case I have at the moment is this one: --- begin try #!/usr/local/bin/rc fn runtimeerror { $1 = fred } echo before while (true) { runtimeerror echo loop end } echo after --- end try A run gives me: : mod;; try before line 15: null variable name Line 15 is the close curly on the while loop. If you don't have the while loop, it correctly reports the error as being on the line where the call to the "runtimeerror" function was. This can be (and was) a real hassle if the loop was bigger (mine was) and if you don't know what's going on (I didn't at first :). OK, John. From rc-owner Thu Apr 8 00:21:54 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2740>; Thu, 8 Apr 1993 00:21:27 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA03489; Wed, 7 Apr 93 21:21:15 - 0700 Received: by astro.mv.us.adobe.com; id AA16665; Wed, 7 Apr 93 21:21:54 -0700 Date: Thu, 8 Apr 1993 00:21:54 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9304080421.AA16665@astro.mv.us.adobe.com> To: john@civil.su.oz.au Subject: Re: minor but annoying rc-1.4 bug Cc: rc@hawkwind.utcs.toronto.edu most interpreters suffer from this problem. that's not saying it's not a problem, but it's a hard one to fix. where does the error for fn runtimeerror { $1 = fred } rc -c 'runtimeerror' get reported. it really should be tagged to be in at least the function that caused the problem, as well as the source line that the was used to create the particular tree node in question. none of this is impossible, but a solution isn't pretty. es suffers from at least as much of the problem, as do other shells in which you you can write something equivalent. how would you fix it? which line would be associated with the error message? 4, inside the definition of runtimeerror? 9, at the call to runtimeerror? paul From rc-owner Thu Apr 8 09:06:29 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2740>; Thu, 8 Apr 1993 08:52:28 -0400 Received: from spool.uu.net (via localhost.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11651; Thu, 8 Apr 93 08:51:59 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 172901.28362; Wed, 7 Apr 1993 17:29:01 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa22332; Wed, 7 Apr 93 15:50:45 EDT From: culliton@srg.srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Speed of rc Date: Wed, 7 Apr 1993 15:50:47 -0400 Message-Id: <9304071550.aa10315@ceres.srg.af.mil> When running commands or scripts it seems that rc often takes longer than it should, especially compared to sh or ksh. I also seem to remember seeing something in comp.unix.shell within the last couple of months, about the relative speed of various shells, which showed rc as being substantially slower. What this leads me to wonder is, if anyone has ever bothered to do any serious timing tests or profile rc and find out where it's spending its time? I raised this issue with Byron once, but he had bigger fish to fry at the time. (and rightly so) However the shell has been stable for quite a while, and it might be well worth exploring, especially now that a version 1.5 is being considered. Tom From rc-owner Thu Apr 8 11:45:29 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2738>; Thu, 8 Apr 1993 11:44:56 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA04512; Thu, 8 Apr 93 08:44:33 - 0700 Received: by astro.mv.us.adobe.com; id AA27842; Thu, 8 Apr 93 08:45:07 -0700 Date: Thu, 8 Apr 1993 11:45:07 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9304081545.AA27842@astro.mv.us.adobe.com> To: culliton@srg.srg.af.mil Subject: Re: Speed of rc Cc: rc@hawkwind.utcs.toronto.edu > When running commands or scripts it seems that rc often takes longer > than it should, especially compared to sh or ksh. i don't find this true at all. i haven't ever used ksh seriously, but rc feels (that's not is, but feels) much faster than sh on all machines i've tried it on. > I also seem to > remember seeing something in comp.unix.shell within the last couple of > months, about the relative speed of various shells, which showed rc as > being substantially slower. i don't remember it that way. as i recall, the numbers from rc looked about the same as all other shells, which was not surprising, given that the benchmark seemed to be testing just how fast the machine forked. > What this leads me to wonder is, if anyone > has ever bothered to do any serious timing tests or profile rc and find > out where it's spending its time? i know that Byron had done this on at least several times during his work on rc, but i don't think he's done it recently. the last major performance tweak that i recall was that there were some list operations being done in O(n^2) time when they didn't have to be, and that fixed, but i'm not sure if that was a pre- or post-1.4 change. profiling code & looking for hot spots is always a good thing to do. i think you'll find that rc is pretty much flat and not spending an inordinate amount of time in any particular kind of operation. paul From rc-owner Thu Apr 8 12:52:14 1993 Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto. edu with SMTP id <2738>; Thu, 8 Apr 1993 12:51:49 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA00236; Thu, 8 Apr 93 09:51:47 PDT Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA11092; Thu, 8 Apr 93 01:28:14 PDT Date: Thu, 8 Apr 1993 04:28:14 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9304080828.AA11092@netapp.netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: re. a minor but annoying bug Well, the reason for the bug is that rc does not annotate the parse-tree with line numbers the way a C compiler might. The error printer makes a stab at what the line number is, by printing the number of newlines read so far. (This trick works ok for syntax errors.) Therefore, an error raised anywhere inside a while loop will print the line number of the close-brace of the while loop. I realize this is ugly, but a fix for this problem is more effort than I can or want to put into rc right now. From rc-owner Thu Apr 8 13:07:00 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2744>; Thu, 8 Apr 1993 13:06:40 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA00346; Thu, 8 Apr 1993 12:06:33 -0500 Message-Id: <9304081706.AA00346@oldp.astro.wisc.edu> To: byron@netapp.com (Byron Rakitzis) Subject: Re: re. a minor but annoying bug Cc: rc@hawkwind.utcs.toronto.edu Date: Thu, 8 Apr 1993 13:06:32 -0400 From: Alan Watson X-Mts: smtp I think this is the kind of `yes, it's ugly, but I've got better things to do' problem for which the BUGS section of the manual page was designed. Alternatively, only print a line number for syntax errors, on the grounds that no information is better than false information. rc does better than another scripting language I use regularly (cl in IRAF -- an astronomical data mangling package), which always reports an error as occuring on the line AFTER the last line in a file. Alan. From rc-owner Thu Apr 8 18:50:52 1993 Received: from spool.UU.NET ([153.39.3.34]) by hawkwind.utcs.toronto.edu with S MTP id <2744>; Thu, 8 Apr 1993 18:50:04 -0400 Received: from srg.UUCP by spool.UU.NET with UUCP (5.61/UUNET-uucp-primary) id AA16533; Thu, 8 Apr 93 18:49:40 -0400 Received: from ceres.srg.af.mil by srg.srg.af.mil id aa08120; Thu, 8 Apr 93 18:31:27 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: haahr@mv.us.adobe.com Subject: Re: Speed of rc Cc: rc@hawkwind.utcs.toronto.edu Date: Thu, 8 Apr 1993 18:31:31 -0400 Message-Id: <9304081831.aa24256@ceres.srg.af.mil> me> When running commands or scripts it seems that rc often takes longer me> than it should, especially compared to sh or ksh. paul> i don't find this true at all. i haven't ever used ksh seriously, but paul> rc feels (that's not is, but feels) much faster than sh on all machines paul> i've tried it on. I've actually rewritten rc scripts for sh so that they would be used by more of our users, and seen notable speed differences. (I'm talking about jobs that take minutes (in either shell) rather than seconds here, can run up to a couple hundred lines of script and chew up whole directory hierarchies and many megabytes of data.) Except in cases where rc made it easy to use a better algorithm, which created fewer processes or invoked fewer external commands, sh wins. There seem to be a couple of components to this. First sh has test builtin, and on our machines, for rc to use test means firing up sh to do it. Second when I use pattern matching to any significant extent, or do lots of fiddling with lists, rc seems to bog down. Heavy `{} usage also seems to chew lots of time. Don't get me wrong, this is not meant to be a criticism of rc, I love it and wouldn't want to give it up. It was about 10 times easier to write the scripts in rc than it would be in sh, and they're often much smaller and cleaner. Using rc encourages me to write things when it wouldn't seem worth the effort in sh or (shudder!) perl. (I think that Perl is exactly the wrong solution for the same reasons that PL/1 was.) paul> the last major performance paul> tweak that i recall was that there were some list operations being done paul> in O(n^2) time when they didn't have to be, and that fixed, but i'm not paul> sure if that was a pre- or post-1.4 change. I remember this as a pre-1.4 change, but operations on big lists still seem to take a fair amount of time. paul> profiling code & looking for hot spots is always a good thing to do. paul> i think you'll find that rc is pretty much flat and not spending an paul> inordinate amount of time in any particular kind of operation. The difference may well be simply one of usage styles, and the answer may be as simple as some hints about how to improve the efficiency of rc scripts. For example using find where appropriate is usually a BIG win especially since test isn't builtin. Tom PS - I actually spent a fair amount of time once trying to figure out a stunt to run co-processes under rc so I can fire up sh (for test), and something else to do math, exactly once and then have functions that talk to them. In the end I decided it either couldn't be done or wasn't worth the effort. From rc-owner Thu Apr 8 19:26:53 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2746>; Thu, 8 Apr 1993 19:26:35 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA06529; Thu, 8 Apr 93 16:13:28 - 0700 Received: by astro.mv.us.adobe.com; id AA16094; Thu, 8 Apr 93 16:09:58 -0700 Date: Thu, 8 Apr 1993 19:09:58 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9304082309.AA16094@astro.mv.us.adobe.com> To: culliton@srg.af.mil Subject: Re: Speed of rc Cc: rc@hawkwind.utcs.toronto.edu ok, now i understand what's going on. yes, if you use test a lot in rc, it will go slowly. if your /bin/sh has a test builtin, that will run faster. there's no surprises here, you're just comparing apples and oranges. i think that there are two very good reasons that test is not built into rc: (1) with one glaring exception (echo), rc really has no extraneous builtins, and (2) the semantics of test are, at best, awful. in addition, i know that Byron hesitated before deviating seriously from the bell labs version of rc. personally, if test had nice semantics, i would prefer to see it built in to rc. it doesn't. paul ps: as many of you know, Byron and i have been doing a new shell, es, in which we felt no obligation to be compatible with rc. es needed to have a builtin for doing some test-like things because path-searching is done by functions written in es rather than c. because of this, we exposed an access function, which does many things that test does, albeit cleaner. From rc-owner Thu Apr 8 20:44:23 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2746>; Thu, 8 Apr 1993 20:44:00 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2538>; Thu, 8 Apr 1993 20:39:42 -0400 To: culliton@srg.af.mil (Tom Culliton x2278) cc: haahr@mv.us.adobe.com, rc@hawkwind.utcs.toronto.edu Subject: Re: Speed of rc In-reply-to: Your message of "Thu, 08 Apr 1993 18:31:31 EDT." <9304081831.aa24256@ceres.srg.af.mil> Date: Thu, 8 Apr 1993 20:38:11 -0400 From: Scott Schwartz Message-Id: <93Apr8.203942edt.2538@groucho.cs.psu.edu> Just some random thoughts... Tom writes: | I actually spent a fair amount of time once trying to figure out a | stunt to run co-processes under rc so I can fire up sh (for test), and | something else to do math, exactly once and then have functions that | talk to them. In the end I decided it either couldn't be done or | wasn't worth the effort. Yet another defect in Unix, where IPC is so limited that even simple and obvious things are so painful that no one does them. Similarly, if dynamic loading were fundamental and pervasive one could envision taking any a.out file, mapping it once, and then calling its entry points. For example, make the system (OS, language runtime, etc) understand /bin/sh/glob. Then the normal execve means calling /bin/sh/main. The problem with being spartan is that you end up being stoic. From rc-owner Fri Apr 9 11:46:41 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Fri, 9 Apr 1993 11:45:31 -0400 Received: by mod.civil.su.oz.au id <28689>; Sat, 10 Apr 1993 01:45:09 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Fri, 9 Apr 1993 11:23:00 -0400 To: The rc Mailing List Subject: Re: Speed of rc In-Reply-To: <93Apr8.203942edt.2538@groucho.cs.psu.edu> Message-ID: <199304100123.13535.rc.bagir@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Here are a few comments on the speed of rc. I hope they're not too incoherent, but it's now or never. Someone said that they had a problem in that their test command was built into sh, and that therefore every time they wanted to do a test inside an rc script they ended up having to fire up an sh to do it. I'm sure you can do much better than that. I have encountered that situation on various different Unix machines (sorry, in my current state of mind the details escape me). There _are_ machines where the _only_ test command is built into some flavour of sh; I think some versions of RS/6000 AIX may be like that. There are also machines where, yes, test is built into sh, but a test binary is also supplied (looking for a binary named "[" can often win). On these latter machines, clearly the problem is solved, just use the supplied test binary. On machines where there really and definitely isn't a binary for test, just compile one. I am sure there are sources floating around on the net. If all else fails there is certainly a gnu version. That way you will end up with a much lighter-weight operation than having to start up a copy of sh just to do "test". Hell if it came to that, anyone around here could code up test.c in short order. Now for my personal experiences and some numbers. I have always found rc to be acceptably fast with one exception. When I am coding shell scripts I am not looking for blazing performance. It always seems to deliver the goods, sometimes even faster than I expected. The exception is this. I use a mail system called "mace" written by Boyd Roberts. It is a little bit like MH in that you incorporate your mail into an inbound mail folder. He has a facility where as the mail is incorporated, each item's headers can optionally be matched against some REs and if they match, a command is queued up to be executed on that mail item after the incorporation is complete. I am on a fairly high-volume mailing list where it is not uncommon for thirty or forty items to arrive while I am away from my terminal (should I not come in for a whole weekend, I usually see hundreds). I have it set up to automatically move these items to the correct box, so one command gets executed per item at the end of the incorporation. This takes an excruciatingly long time if there are a lot to move. There are, of course, many variables and it is hard to measure. What Boyd does is fire up a single copy of $SHELL (rc in my case) and send all the commands down a pipe to its standard input; clearly a better idea than one shell per command. So I just did some simple measurements on that. In /tmp, I created an executable called "xx" which was just the null C program. I created "pus" which had 1000 lines, each saying "xx". I got some interesting numbers. (This is on a DECstation 5000/120 running Ultrix 4.2, so sh is a very old version.) : mod;; /bin/time sh -c 'cat pus | sh' 27.8 real 5.2 user 21.1 sys : mod;; /bin/time sh -c 'cat pus | sh' 27.2 real 5.3 user 20.8 sys : mod;; /bin/time sh -c 'cat pus | sh' 27.5 real 5.3 user 21.0 sys : mod;; /bin/time sh -c 'cat pus | sh' 27.3 real 5.4 user 20.7 sys : mod;; /bin/time sh -c 'cat pus | rc' 34.7 real 1.8 user 31.3 sys : mod;; /bin/time sh -c 'cat pus | rc' 34.8 real 1.8 user 31.1 sys : mod;; /bin/time sh -c 'cat pus | rc' 34.5 real 1.7 user 31.1 sys : mod;; /bin/time sh -c 'cat pus | rc' 34.8 real 1.8 user 31.3 sys I wish I had time to find out why rc used a whole third more system time. I suspect this might be at the root of my mace performance problem. I thought initally that it might be something to do with path searching, so I tried cutting that out of the picture, to no obvious effect: "pus2" contained lines with "./xx", and "pus3" lines with "/tmp/xx". : mod;; /bin/time sh -c 'cat pus2 | sh' 27.1 real 5.2 user 20.5 sys : mod;; /bin/time sh -c 'cat pus2 | sh' 27.0 real 5.2 user 20.5 sys : mod;; /bin/time sh -c 'cat pus2 | sh' 27.5 real 5.3 user 20.8 sys : mod;; /bin/time sh -c 'cat pus2 | rc' 33.7 real 1.6 user 30.5 sys : mod;; /bin/time sh -c 'cat pus2 | rc' 37.3 real 1.6 user 31.7 sys : mod;; /bin/time sh -c 'cat pus2 | rc' 35.5 real 1.5 user 31.5 sys : mod;; /bin/time sh -c 'cat pus3 | sh' 27.7 real 5.3 user 21.2 sys : mod;; /bin/time sh -c 'cat pus3 | sh' 27.5 real 5.3 user 20.8 sys : mod;; /bin/time sh -c 'cat pus3 | sh' 27.9 real 5.4 user 21.1 sys : mod;; /bin/time sh -c 'cat pus3 | rc' 34.6 real 1.7 user 31.3 sys : mod;; /bin/time sh -c 'cat pus3 | rc' 34.8 real 1.8 user 31.2 sys : mod;; /bin/time sh -c 'cat pus3 | rc' 34.3 real 1.6 user 31.0 sys As you can see, the results are substantially the same. Note that rc wins on user time, which is why it isn't drastically slower overall. Maybe someone will be inspired to look at this further. I would, and I still might, but certainly not now and I don't know if I will get a chance. OK, John. From rc-owner Fri Apr 9 12:33:06 1993 Received: from plg.uwaterloo.ca ([129.97.140.10]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Fri, 9 Apr 1993 12:32:53 -0400 Received: by plg.uwaterloo.ca id <28706>; Fri, 9 Apr 1993 12:32:25 -0400 From: Dave Mason To: rc@hawkwind.utcs.toronto.edu In-reply-to: <93Apr8.203942edt.2538@groucho.cs.psu.edu> (message from Scott Sch wartz on Thu, 8 Apr 1993 20:38:11 -0400) Subject: Speed of rc X-Face: %Q_F^9R-:'3MM7eZ6@E.x@f\*bgatzGv-8d%I~L[p^.F)3QF{kq\UTsu|e#?)3FPwJNvPPB !s*He|-*M^p*~bh"Nywm5NLL\\Rl3r(hWHY*F:$/RdKV*bS";n&#\Ov@*=]mu\}6tP Date: Fri, 9 Apr 1993 12:32:16 -0400 Of course it was 10 seconds after I finished reading (and deleting) John Mackin(sp?)'s note that I realized the problem: environment rc will have a significantly larger environment (rc functions) than sh, and many systems have *abysmal* exec performance because of the time spent copying the environment. I did some benchmarks on a MIPS M/120 (13 Specmarks) running RiscOS and a National Semiconductor 32016 (.75 Specmarks) running Sys5r2, and I don't remember the exact results, but execing with a 0K environment was about the expected factor of 20 faster on the MIPS, and with a 5K environment it was *much* slower - maybe a factor of only 4, and I calculated that in a research O/S we were working on (although it never ran so I couldn't verify this) the exec (with 5K environment) would run *faster* on the NS32016 than the existing one on the M/120. So, John: try a version of rc with an empty environment. I suspect the system times will be as fast as those for sh. ../Dave From rc-owner Fri Apr 9 12:48:17 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Fri, 9 Apr 1993 12:48:05 -0400 Received: by mod.civil.su.oz.au id <28689>; Sat, 10 Apr 1993 02:47:41 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Fri, 9 Apr 1993 12:39:38 -0400 To: The rc Mailing List Subject: Re: Speed of rc In-Reply-To: <93Apr9.123225edt.28706@plg.uwaterloo.ca> Message-ID: <199304100239.22248.rc.bagiy@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Summary: Dave Mason shows us, once again, that shots from the hip usually miss. rc will have a significantly larger environment (rc functions) than sh, and many systems have *abysmal* exec performance because of the time spent copying the environment. I don't know if you just didn't bother to read my mail, Dave, or what. rc and sh were both being executed with precisely the same environment. So whatever contribution exec makes in copying the environment will have been the same for both. For the record, I just did a wc of my environment and it is around 2100 characters. As to `rc functions,' never forget than an important factor in the _startup_ time of Byron's rc is that it imports functions lazily. Of course, startup time is specifically not at issue here. So, John: try a version of rc with an empty environment. I suspect the system times will be as fast as those for sh. BZZZZZT! Sorry, Player One, you lose this time, but thanks for trying... : mod;; env - sh $ /bin/time /bin/sh -c '/bin/cat pus2 | /usr/local/bin/rc' 27.5 real 1.3 user 24.7 sys $ /bin/time /bin/sh -c '/bin/cat pus2 | /usr/local/bin/rc' 27.7 real 1.2 user 25.1 sys $ /bin/time /bin/sh -c '/bin/cat pus2 | /usr/local/bin/rc' 27.5 real 1.1 user 25.0 sys $ /bin/time /bin/sh -c '/bin/cat pus2 | /usr/local/bin/rc' 27.4 real 1.1 user 24.7 sys $ /bin/time /bin/sh -c '/bin/cat pus2 | /bin/sh' 17.2 real 1.3 user 14.9 sys $ /bin/time /bin/sh -c '/bin/cat pus2 | /bin/sh' 16.8 real 1.4 user 14.4 sys $ /bin/time /bin/sh -c '/bin/cat pus2 | /bin/sh' 16.8 real 1.5 user 14.2 sys $ /bin/time /bin/sh -c '/bin/cat pus2 | /bin/sh' 16.9 real 1.4 user 14.8 sys Clearly, with an empty environment, we can't do any path searching, so I tried only pus2 this time, with the "./xx"s in it. We still see rc using a much higher system time than sh. Interestingly, sh's user-time has come down to on a par with rc's. I won't offer any speculation on that one. OK, John. From rc-owner Fri Apr 9 14:18:14 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Fri, 9 Apr 1993 14:17:56 -0400 Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11221; Fri, 9 Apr 93 13:17:03 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 131638.8007; Fri, 9 Apr 1993 13:16:38 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa08501; Fri, 9 Apr 93 11:58:48 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: haahr@mv.us.adobe.com Subject: Re: Speed of rc Cc: rc@hawkwind.utcs.toronto.edu Date: Fri, 9 Apr 1993 11:58:55 -0400 Message-Id: <9304091158.aa11610@ceres.srg.af.mil> Paul writes: > ok, now i understand what's going on. yes, if you use test a lot in rc, > it will go slowly. if your /bin/sh has a test builtin, that will run faster. > there's no surprises here, you're just comparing apples and oranges. The issue can't be dismissed that easily. I've seen relatively pokey behaviour even in scripts that have been written using exclusively builtin functions. I'm not espousing the idea of building test into rc, just asking if some tuning could be done, particularly in the areas that I mentioned before. Tom From rc-owner Fri Apr 9 15:24:44 1993 Received: from plg.uwaterloo.ca ([129.97.140.10]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Fri, 9 Apr 1993 15:23:31 -0400 Received: by plg.uwaterloo.ca id <28723>; Fri, 9 Apr 1993 15:22:27 -0400 From: Dave Mason To: rc@hawkwind.utcs.toronto.edu In-reply-to: <199304100239.22248.rc.bagiy@civil.su.oz.au> (john@civil.su.oz.au) Subject: Speed of rc X-Face: %Q_F^9R-:'3MM7eZ6@E.x@f\*bgatzGv-8d%I~L[p^.F)3QF{kq\UTsu|e#?)3FPwJNvPPB !s*He|-*M^p*~bh"Nywm5NLL\\Rl3r(hWHY*F:$/RdKV*bS";n&#\Ov@*=]mu\}6tP Date: Fri, 9 Apr 1993 15:22:14 -0400 Ignoring rude comments about my conjectures... John is of course right, that in his tests both sh and rc had the same environments, so the environment copy time will be the same (although from his numbers it's clear this is a significant cost and it may be worth looking for a different way to handle environments on Unix) and we have to look for other differences... Well, the obvious one (for me) is that /bin/sh is built to be static, and when I built rc and es, I took the sun defaults which build to use dynamic libraries. So I tried John's test looking at the system calls for static and dynamic cases... essentially no difference... But the execution time is very different. At least on this Sun 4/590, dynamic libraries cost a lot of system time, and when I run static versions my rc has virtually identical system times as sh and es only uses about 7% more system time (which may well be because of the 3 times larger binary and demand-load paging). (And es' *total* time is within a couple percent of sh.) John's mileage may vary. (e.g. if he's not running dynamic libraries.) Paul & Byron: any idea why the es executable is so large? ../Dave ; /bin/time /bin/sh -c '/bin/cat pus2 | /bin/sh' ; /bin/cat pus2|trace -c /bin/sh rc-stat rc es-stat es sh 90K 82K 286K 163K 106K text+data size 1.4 2.3 1.1 2.0 4.6 user time 32.5 44.2 36.0 49.3 32.4 system time 37.5 49.4 40.9 58.9 40.1 real time 1059 1068 1007 1064 1076 wait4 1076 1076 1062 1062 1071 sigblock 1034 1034 1023 1023 1063 sigstack 1000 1000 1000 1000 1000 SIGCHLD (20) 1000 1000 1000 1000 999 fork 78 78 72 72 14 sigvec 41 41 38 38 7 sigsetmask 1 1 1 1 1 exit 8 8 9 9 brk 1 1 1 1 getpid 1 1 1 1 ioctl 1 1 1 1 getpagesize (Some or all of the following calls are attributable to Dynamic libraries): 33 36 9 12 63 read 7 14 7 14 4 close 3 10 7 open 1 2 1 getuid 1 2 1 getgid 10 10 mmap 4 4 getdents 2 2 fstat 1 1 getrlimit Only rc: 1000 1000 stat 1 1 getgroups Only es: 3 3 dup 1 1 sigcleanup (As an aside, I find it interesting that there is little correlation between the number of wait4, sigblock and sigstack calls among the shells, and I don't see how sh gets 1000 SIGCHLD's with only 999 forks! But this is repeatable: sh definitely elides the last fork. Whether that optimization is worthwhile is unclear.) From rc-owner Fri Apr 9 17:13:57 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2751>; Fri, 9 Apr 1993 17:12:43 -0400 To: rc Subject: Re: Speed of rc In-reply-to: dmason's message of Fri, 09 Apr 93 15:22:14 -0400. <93Apr9.152227edt.28723@plg.uwaterloo.ca> Date: Fri, 9 Apr 1993 17:12:41 -0400 From: Chris Siebenmann Message-Id: <93Apr9.171243edt.2751@hawkwind.utcs.toronto.edu> Dynamically linking programs that fork() looses big on SunOS and Solaris; I always static-link rc on those machines. It's a quite dramatic difference. I really wish Sun could get their act together about it, too; I was appalled to see it continue in Solaris. - cks From rc-owner Fri Apr 9 20:16:41 1993 Received: from netcomsv.netcom.com ([163.179.1.9]) by hawkwind.utcs.toronto.edu with SMTP id <2748>; Fri, 9 Apr 1993 20:15:56 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA20303; Thu, 8 Apr 93 13:14:22 PDT Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA16814; Thu, 8 Apr 93 13:14:44 PDT Date: Thu, 8 Apr 1993 16:14:44 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9304082014.AA16814@netapp.netapp.com> To: culliton@srg.srg.af.mil, haahr@mv.us.adobe.com Subject: Re: Speed of rc Cc: rc@hawkwind.utcs.toronto.edu I seem to remember the "benchmark" posted on c.u.s as being quite artificial. That said, I'll tell you what I know about rc's speed: I don't think you will make rc ever go faster by examining prof output. The fat just isn't there. The slowest routine is probably yacc, but it's not even close to the time you spend in Unix system calls. The problem can be viewed in one of two ways: either (1) rc is not perl, or (2) Unix is too slow. Take your pick. rc has to go do fork/exec for a lot of tasks which a featureful shell or perl might cram in as a builtin. I agree that the speed at which scripts run is a valid concern, and all I can say is that I don't have a good answer at this time. I can't bring myself to buy into the perl philosophy. From rc-owner Mon Apr 12 01:52:42 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2765>; Mon, 12 Apr 1993 01:51:24 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA11953; Sun, 11 Apr 93 22:51:07 -0700 Received: by astro.mv.us.adobe.com; id AA12093; Sun, 11 Apr 93 22:51:46 -0700 Date: Mon, 12 Apr 1993 01:51:46 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9304120551.AA12093@astro.mv.us.adobe.com> To: dmason@plg.uwaterloo.ca, rc@hawkwind.utcs.toronto.edu Subject: Re: Speed of rc i haven't read most of this note, (still catching up on my mail), but > any idea why the es executable is so large? it shrinks in size dramatically if you turn off assertions. some of the things that have to be done for the garbage collector generate a lot of assertions which should really just be compile-time checks. the other thing is that es has lots of functionality (taken generally out of the shared libraries, with only a little bit of glue code) that rc does not have, even if it is minor: ~-expansion, builtin time(), etc. a lot of this can be thought of as code bloat. nevertheless, es w/o assertions should be roughly the size of a csh linked in the same way. thanks for your analysis. paul From rc-owner Mon Apr 12 14:06:29 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2750>; Mon, 12 Apr 1993 14:05:51 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2579>; Mon, 12 Apr 1993 14:04:23 -0400 To: rc@hawkwind.utcs.toronto.edu Subject: plan9-fans Date: Mon, 12 Apr 1993 14:03:53 -0400 From: Scott Schwartz Message-Id: <93Apr12.140423edt.2579@groucho.cs.psu.edu> rc-fans: you may be interested to hear that there is now a plan9-fans mailing list, plan9-fans@cs.psu.edu. Send a note to plan9-fans-request to be added. From rc-owner Tue Apr 13 15:27:24 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2752>; Tue, 13 Apr 1993 15:26:25 -0400 To: The rc Mailing List Subject: Re: Speed of rc In-reply-to: john's message of Fri, 09 Apr 93 11:23:00 -0400. <199304100123.13535.rc.bagir@civil.su.oz.au> Date: Tue, 13 Apr 1993 15:26:18 -0400 From: Chris Siebenmann Message-Id: <93Apr13.152625edt.2752@hawkwind.utcs.toronto.edu> Interestingly, I ran similar tests to John Mackin's, and got more or less the reverse of his results; on a DECstation 5000/133 with everything on a fairly pokey and slow local disk, the sh './xx' case was noticably slower than the rc case. I've seen these numbers replicated across some other machines (including a SunOS box in my testing, although it was hard to get a consistent load average on that machine). Here are the numbers themselves: ! : whirlwind.sys ; l=(1 2 3 4 5) ! : whirlwind.sys ; for (i in $l) {/bin/time sh -c 'cat pus2 | ./rc.gcc'} ! 25.0 real 1.0 user 22.2 sys ! 24.3 real 1.1 user 21.8 sys ! 25.1 real 1.1 user 22.4 sys ! 24.2 real 1.0 user 21.7 sys ! 23.1 real 1.0 user 21.4 sys ! : whirlwind.sys ; for (i in $l) {/bin/time sh -c 'cat pus2 | ./rc.c89'} ! 25.5 real 0.9 user 22.2 sys ! 24.0 real 1.1 user 21.8 sys ! 26.6 real 1.0 user 23.1 sys ! 23.8 real 1.1 user 21.7 sys ! 25.3 real 0.9 user 22.9 sys ! : whirlwind.sys ; for (i in $l) {/bin/time sh -c 'cat pus2 | /bin/sh'} ! 30.4 real 9.0 user 20.1 sys ! 31.0 real 9.1 user 20.3 sys ! 30.7 real 9.2 user 20.2 sys ! 29.4 real 8.9 user 19.7 sys ! 29.4 real 8.9 user 19.8 sys [rc.gcc and rc.c89 are rc binaries compiled with gcc 2.2.2 and DEC's c89 ANSI compiler, respectively.] - cks From rc-owner Tue Apr 13 16:31:58 1993 Received: from netcomsv.netcom.com ([163.179.1.9]) by hawkwind.utcs.toronto.edu with SMTP id <2766>; Tue, 13 Apr 1993 16:31:35 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA20364; Tue, 13 Apr 93 13:31:41 PDT Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA15743; Tue, 13 Apr 93 13:26:04 PDT Date: Tue, 13 Apr 1993 16:26:04 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9304132026.AA15743@netapp.netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: speed of rc John pointed out to me that the rc path search does a stat() before an exec(), even for an absolute path name. Optimizing out that stat should take care of the "pus" problem, if indeed that file is full of lines which say "/tmp/xx". Disclaimer: I haven't tried to reproduce any of this stuff here yet. Further disclaimer: I want to offer my apologies for not spending more time on rc, but things have really never been busier for me as a programmer. From rc-owner Tue Apr 13 17:23:29 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Tue, 13 Apr 1993 17:23:06 -0400 Received: by mod.civil.su.oz.au id <28713>; Wed, 14 Apr 1993 07:22:53 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Tue, 13 Apr 1993 17:13:47 -0400 To: Chris Siebenmann cc: The rc Mailing List Subject: Re: Speed of rc In-Reply-To: <93Apr13.152625edt.2752@hawkwind.utcs.toronto.edu> Message-ID: <199304140713.7817.rc.bagop@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Chris, Fascinating! I want to work out what is going on here. The first question, and I am really in little doubt as to the answer, is: was that rc-1.4? You didn't say, and I know some earlier versions didn't do the redundant stat() call that appears to be at the bottom of the extra system time I am seeing. Note that you, like me, see substantially larger user times with sh than with rc; the difference was that I saw larger system times with rc than with sh, whereas in your tests they are on a par. Given that you were using 1.4, I'd say the next logical step (and this is just a suggestion, feel free to make your own if you don't like this one) is I'll give you my rc-1.4 binary one way or another (I can put it up for anon ftp here, probably best) and you can test that binary under the same conditions as the others. Let me know what you think. Puzzled, but OK, John. From rc-owner Tue Apr 13 17:32:29 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2766>; Tue, 13 Apr 1993 17:32:05 -0400 Received: by mod.civil.su.oz.au id <28713>; Wed, 14 Apr 1993 07:31:40 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Tue, 13 Apr 1993 17:23:47 -0400 To: Byron Rakitzis cc: The rc Mailing List Subject: Re: speed of rc In-Reply-To: <9304132026.AA15743@netapp.netapp.com> Message-ID: <199304140723.7906.rc.bagos@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Further disclaimer: I want to offer my apologies for not spending more time on rc, but things have really never been busier for me as a programmer. Byron, As far as I am concerned, no apologies are needed. You have done a tremendous job. I can't speak for anyone but myself, but for my part I appreciate your work every moment I am sitting at my terminal, and more times besides. I think the evidence is clear: there's a large user community on the rc list, and what we talk about is polishing off tiny blemishes from something that's already close to perfect. The dearth of patches/releases also speaks for the quality of what you've done. I've said all this before, and if I am still around will doubtless in time say it again. Thank you so much. OK, John. From rc-owner Tue Apr 13 18:43:59 1993 Received: from albert.gnu.ai.mit.edu ([128.52.46.31]) by hawkwind.utcs.toronto. edu with SMTP id <2764>; Tue, 13 Apr 1993 18:43:39 -0400 Received: from hal.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP id ; Tue, 13 Apr 93 18:43:13 -0400 Received: by hal.gnu.ai.mit.edu (AIX 3.2/UCB 5.64/4.0) id ; Tue, 13 Apr 1993 18:42:53 -0400 From: mycroft@gnu.ai.mit.edu Message-Id: <9304132242.AA52145@hal.gnu.ai.mit.edu> Subject: Re: speed of rc To: john@civil.su.oz.au (John) Date: Tue, 13 Apr 1993 19:42:53 -0400 Cc: byron@netapp.com, rc@hawkwind.utcs.toronto.edu In-Reply-To: <199304140723.7906.rc.bagos@civil.su.oz.au> from "John" at Apr 13, 93 05:23:47 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 212 > As far as I am concerned, no apologies are needed. You have done a > tremendous job. I concur. I've found this implementation to be very reliable. The first thing I do on a new machine now is compile rc. From rc-owner Wed Apr 14 11:11:48 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2764>; Wed, 14 Apr 1993 11:10:57 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA22505; Wed, 14 Apr 93 11:10:47 -0400 Received: by earth.osf.org (5.65/4.7) id AA07466; Wed, 14 Apr 93 11:10:46 -0400 Date: Wed, 14 Apr 1993 11:10:46 -0400 From: rsalz@osf.org Message-Id: <9304141510.AA07466@earth.osf.org> To: rc@hawkwind.utcs.toronto.edu Subject: useful one-liner fn allbut { i=() { for (i in *) ~ $i $* || echo $i } } I use it for things like this: shar `{allbut RCS} | Mail joe From rc-owner Thu Apr 15 00:34:39 1993 Received: from ccadfa.cc.adfa.oz.au ([131.236.1.2]) by hawkwind.utcs.toronto.ed u with SMTP id <2764>; Thu, 15 Apr 1993 00:34:13 -0400 Received: by ccadfa.cc.adfa.oz.au (5.65c/1.34) id AA11980; Thu, 15 Apr 1993 14:33:53 +1000 Message-Id: <199304150433.AA11980@ccadfa.cc.adfa.oz.au> To: rc@hawkwind.utcs.toronto.edu Subject: Re: difference between and ? From: Christopher.Vance@adfa.oz.au (Christopher JS Vance) Organization: Computer Science, University College, UNSW/ADFA, Canberra, Austra lia References: <1993Apr09.023608.22375@rat.csc.calpoly.edu> <1993Apr14.163211.4342 @thunder.mcrcim.mcgill.edu> <1993Apr15.042726.22102@sserve.cc.adfa.oz.au> Date: Thu, 15 Apr 1993 00:33:53 -0400 Sender: cjsv@ccadfa.cc.adfa.oz.au In article <1993Apr14.163211.4342@thunder.mcrcim.mcgill.edu> in newsgroup comp.lang.c talking about and mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: | On systems where both exist, they are normally compatible, in that you | can use an ANSI prototype to call a function written to use | , and you can write a function using and then | call it as a varargs function from traditional code. No guarantees, of | course, but when both headers exist this will usually work. I found, when porting Byron Rakitzis' implementation of rc to a Pyramid 9810 running OSx 5.1, that I had a purported ANSI-compatible compiler (grokking prototypes and const), but no . (Pyramid have shipped for years, and it's a bit strange...) This rc uses prototyped functions throughout, using new-style for both declarations and definitions. What worked for me was to remove the argument prototypes (just from the variadic functions) leaving the return type and empty parentheses. For the definition, the Pyramid allows it to include the va_alist *after* some fixed arguments (if there were fixed arguments, they had to be declared old-style with only the argument names inside the parentheses). And I had to change the invocations of va_start in the routine bodies to omit the second parameter. I guess I could have hacked the definitions even more to put the va_alist in as the only argument, but this was the only architecture I had which didn't do properly, and my way meant minimal change to the bodies of these routines. I also toyed with trying to make a that did the right thing, but I knew that worked, so it was easier to do this workaround. (And when I looked at gcc's way I felt sick. I still haven't the time or heart to try to get gcc doing things the right way on the Pyramid.) -- Christopher From rc-owner Thu Apr 15 10:05:52 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2770>; Thu, 15 Apr 1993 10:05:28 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA14082; Thu, 15 Apr 93 10:05:17 -0400 Received: by earth.osf.org (5.65/4.7) id AA09675; Thu, 15 Apr 93 10:05:15 -0400 Date: Thu, 15 Apr 1993 10:05:15 -0400 From: rsalz@osf.org Message-Id: <9304151405.AA09675@earth.osf.org> To: rc@hawkwind.utcs.toronto.edu Subject: RC on HP9000/710? Anyone got rc running on a Snake, HP9000/710? rc.trip fails, and I haven't started looking yet. Built with gcc, so it may be suspect. Tnx. /r$ From rc-owner Thu Apr 15 17:07:41 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Thu, 15 Apr 1993 17:07:03 -0400 Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10808; Thu, 15 Apr 93 17:06:50 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 163721.18631; Thu, 15 Apr 1993 16:37:21 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa10553; Thu, 15 Apr 93 16:25:51 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: byron@netapp.com, john@civil.su.oz.au Subject: Re: speed of rc Cc: rc@hawkwind.utcs.toronto.edu Date: Thu, 15 Apr 1993 16:26:45 -0400 Message-Id: <9304151626.aa12954@ceres.srg.af.mil> Since I started this thread I wanted stop for a moment to agree whole heartedly with John in praise of rc. My experience is that Byron's rc is completely stable, bug free, solid as a rock, easily ported, clean, polished, a pleasure to use, etc. My comments definitely fall into the category of nitpicking. I've pushed it in all sorts of strange and intresting ways, and (aside from a porting bug caused by SCO's flakey signal.h) never had it fail. Byron has nothing to apologize for and a great deal to be very proud of. To Byron in particular: The design philosophy behind rc has my strongest endorsement, perl is a monster, and like one of those "all in one" kitchen gadgets I find it completely useless. It is unstable and buggy, takes forever to port, and otherwise generally makes my head ache. My concerns about the speed of rc come from trying to do big production type jobs with it and trying to evangelize to the unwashed sh/csh types around here. (Our sysadmins can't even be bothered to support bash, and do ksh only grudgingly. Since rc is simple enough for anyone to understand and bug free, it would be a perfect solution, if I could only overcome peoples inertia.) Byron's point about analyzing rc with prof is well taken, there are a couple of gotchas to beware of though. People often make to much of flattening out the usage peaks. A high peak doesn't necessarily mean that means that a certain section of code is a bottle neck, it could mean the code is optimal and efficiently doing it's work in a tight loop. (e.g. A document format to format translator that spends 95% of it's time in 5 lines of code that handle normal text.) Nor does a flat profile means that the code is optimal, it could very well mean that lots of code extra code is getting executed. (e.g. In the translator mentioned above doing character by character i/o rather than buffered.) And when a program is system call bound, as Byron indicates is the case with rc, there is still the possibility of extraneous calls. (such as the stat call that Dave Mason and Byron mention) Dave Mason also makes an excellent point about the size of the environment under rc and the effect on the cost of execs. Writing in rc it is often natural to stick things into lists in the enviroment, which would be in a file or pipe under sh. Especially when trying to avoid external programs for the sake of speed. The fact that all variables and functions are exported adds to this. It wouldn't suprise me if this was were part of my time was going under SCO ODT. A good thing to remember when writing scripts. Remember, I'm not throwing stones here, just asking a question: What can we do (if anything, and short of polluting rc with extra builtins) to speed rc up? Tom PS - sorry this was so long... From rc-owner Thu Apr 15 19:32:57 1993 Received: from merlin.resmel.bhp.com.au ([134.18.1.6]) by hawkwind.utcs.toronto .edu with SMTP id <2764>; Thu, 15 Apr 1993 19:32:33 -0400 Received: from cerberus.bhpese.oz.au by merlin.resmel.bhp.com.au with SMTP id A A04531 (5.65c/IDA-1.4.4 for ); Fri, 16 Apr 1993 09:31: 45 +1000 Received: from localhost by cerberus.bhpese.oz.au with SMTP id AA05912; Fri, 16 Apr 1993 09:33:07 +1000; sendmail 5.67a/Sm3.6RMPSU (from Sm@cerberus.bhpese.oz.au for rc@hawkwind.utcs.toronto.edu) Message-Id: <199304152333.AA05912@cerberus.bhpese.oz.au> To: rsalz@osf.org Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: RC on HP9000/710? In-Reply-To: Your message of "Thu, 15 Apr 93 10:05:15 -0400." <9304151405.AA09675@earth.osf.org> X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" >Anyone got rc running on a Snake, HP9000/710? rc.trip fails, and I haven't >started looking yet. Built with gcc, so it may be suspect. Tnx. I built it on a 9000/817, then just used the binary on the 9000/715s we eventually got. I didn't try rc.trip. I've been using it for months. Sm From rc-owner Fri Apr 16 07:50:30 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2764>; Fri, 16 Apr 1993 07:49:46 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA23546; Fri, 16 Apr 93 07:49:32 -0400 Received: by earth.osf.org (5.65/4.7) id AA11631; Fri, 16 Apr 93 07:49:31 -0400 Date: Fri, 16 Apr 1993 07:49:31 -0400 From: rsalz@osf.org Message-Id: <9304161149.AA11631@earth.osf.org> To: rc@hawkwind.utcs.toronto.edu Subject: Re: RC on HP9000/710? In-Reply-To: Mail from 'Scott Merrilees ' dated: Fri, 16 Apr 93 09:33:04 +1000 Cc: rc@hawkwind.utcs.toronto.edu I got rc built and passing the trip test yesterday. I had to build sigmsgs by hand. This was on an HP9000/710, running HP-UX 9.01. The header file just cannot be parsed by mksignal. I think because it gets confused by multiple NSIG and _NSIG #define's. The more I think about it, the more I don't like the way rc uses signals as indicies. I would rather see it extend sigmsgs to contain rows like {SIGTERM, "sigterm", "terminated"} Then, rather then using a signal as an index, it looped through the table to find the matching SIGxxx, and then used the table subscript as the index. It might be possible to generate this table automatically. A quick look seems to show that es works the same way. While I wouldn't call it a show-stopper, I think it, too, should be fixed. /r$ From rc-owner Fri Apr 16 11:01:22 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2770>; Fri, 16 Apr 1993 11:00:48 -0400 Received: from spool.uu.net (via localhost.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA20532; Fri, 16 Apr 93 11:00:36 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 105758.9596; Fri, 16 Apr 1993 10:57:58 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa15899; Fri, 16 Apr 93 10:48:06 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rsalz@osf.org Subject: Re: RC on HP9000/710? Cc: rc@hawkwind.utcs.toronto.edu Date: Fri, 16 Apr 1993 10:48:02 -0400 Message-Id: <9304161048.aa00934@ceres.srg.af.mil> I encountered exactly the same thing with SCO Unix for about the same reason. The smaller NSIG was being used top size the array and then signals that were off the end of the array where stomping memory. At the time Byron said that others folks had the same problem with HP/UX. Here's the message: > From srg.srg.af.mil!archone.tamu.edu!byron Fri May 22 04:30:33 1992 > From: Byron Rakitzis > To: culliton@srg.srg.af.mil > Subject: sigmsgs.c > Date: Fri, 22 May 1992 02:33:32 -0500 > Status: RO > > Here's the problem: SCO has different NSIG's and mksignal simply > goes for the last NSIG it sees in /usr/include/sys/signal.h. > > I don't know an easy answer to this conundrum, except to advise > SCO users to build this thing by hand; there is already another > OS out there with a braindead signal.h: HP/UX, and I think people > there get the idea also. > > I dunno, any ideas? > > BTW, I assume that rc with a healthy sigmsgs.c runs ok, right? I don't think that using the signal numbers as indices is a problem but at the time, I did suggest a range check be done. The right way to do this is probably at compile time using #if and #error so that you get an error when you try to build the code and don't add any run time overhead. For example in walk.c there is a #if that looks like this: (this is the one that screwed up SCO) #if !defined(NOJOB) && defined(SIGTTOU) && defined(SIGTTIN) && defined(SIGTSTP) If we added: #if (SIGTTOU >= NUMOFSIGNALS) || (SIGTTIN >= NUMOFSIGNALS) || (SIGTSTP >= NUMOF SIGNALS) #error mksignal failed, you may have to build sigmsg.c by hand #endif This wouldn't be so hard to track down. The other thing that would help is a note in config.h or the README to the effect that SCO-ODT and HP/UX have this problem. Tom From rc-owner Fri Apr 16 11:01:30 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto .edu with SMTP id <2771>; Fri, 16 Apr 1993 11:01:17 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA07 854 (5.65c/IDA-1.4.4 for ); Fri, 16 Apr 1993 11:00: 38 -0400 Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA02363; Fri, 16 Apr 93 11:00:32 EDT From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9304161500.AA02363@penfold.cc.gatech.edu> Date: Fri, 16 Apr 1993 11:00:32 -0400 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: rc@hawkwind.utcs.toronto.edu Subject: rc and signals > The more I think about it, the more I don't like the way rc uses signals > as indicies. I would rather see it extend sigmsgs to contain rows like > {SIGTERM, "sigterm", "terminated"} > Then, rather then using a signal as an index, it looped through the table > to find the matching SIGxxx, and then used the table subscript as the > index. It might be possible to generate this table automatically. Another way to do it would be to generate the table #ifdef SIGFOO { SIGFOO, "sigfoo", "murphy came to town"}, #endif /* SIGFOO */ Then, at startup, sort the table, eliminate duplicates, and voila, the signal can be used an index again. The "standard" signals don't need the ifdefs, but there are lots of other signals that are not universal, and also signals that are often aliased to each other (e.g. SIGPOLL <-> SIGIO, SIGCLD <-> SIGCHLD. Aren't merged Unixes wondeful?) I believe ksh does something along these lines. For all that ksh may be bloated as a language, DGK is one smart guy and there's no reason not to borrow implementation tricks. Arnold From rc-owner Fri Apr 16 11:31:00 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2778>; Fri, 16 Apr 1993 11:30:44 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA06118; Fri, 16 Apr 93 11:30:41 -0400 Received: by earth.osf.org (5.65/4.7) id AA13016; Fri, 16 Apr 93 11:30:40 -0400 Date: Fri, 16 Apr 1993 11:30:40 -0400 From: rsalz@osf.org Message-Id: <9304161530.AA13016@earth.osf.org> To: arnold@cc.gatech.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: rc and signals > #ifdef SIGFOO > { SIGFOO, "sigfoo", "murphy came to town"}, > #endif /* SIGFOO */ Yes, of course, this is the right way to do it. >Then, at startup, sort the table, eliminate duplicates, and voila, the >signal can be used an index again. No it can't; suppose I have a machine that leaves some signal numbers unused? > DGK is one smart guy I remain mildly convinced that this is not true. /r$ From rc-owner Fri Apr 16 11:36:05 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2780>; Fri, 16 Apr 1993 11:35:47 -0400 Received: from spool.uu.net (via localhost.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA03919; Fri, 16 Apr 93 11:35:40 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 113321.14834; Fri, 16 Apr 1993 11:33:21 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa16825; Fri, 16 Apr 93 11:16:03 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rsalz@osf.org Subject: Re: RC on HP9000/710? Cc: rc@hawkwind.utcs.toronto.edu Date: Fri, 16 Apr 1993 11:16:01 -0400 Message-Id: <9304161116.aa01178@ceres.srg.af.mil> Rich says: > Tnx for the note. I think run-time lookup isn't going to cost a lot... It would be more robust at a minor run time cost, but that just masks the problem. At the base of it is the fact that the mksignal script gets confused if sys/signal.h is not relatively simple. We need a way to detect this at compile time. Tom From rc-owner Fri Apr 16 12:03:48 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto .edu with SMTP id <2764>; Fri, 16 Apr 1993 12:03:07 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA09 551 (5.65c/IDA-1.4.4 for ); Fri, 16 Apr 1993 12:02: 57 -0400 Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA02488; Fri, 16 Apr 93 12:02:50 EDT From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9304161602.AA02488@penfold.cc.gatech.edu> Date: Fri, 16 Apr 1993 12:02:50 -0400 In-Reply-To: rsalz@osf.org's 31-line message on Apr 16, 11:30am X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: rsalz@osf.org, arnold@cc.gatech.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: rc and signals > >Then, at startup, sort the table, eliminate duplicates, and voila, the > >signal can be used an index again. > > No it can't; suppose I have a machine that leaves some signal numbers unused? It's a Simple Matter Of Programming to fill in the blank spots with an entry that says "invalid signal" or "signal 17 (noname)". I don't *think* there are too many systems where the signal numbers are non-contiguous. > > DGK is one smart guy > > I remain mildly convinced that this is not true. Let me rephrase this then. He's a pretty good programmer. I also think he's too quick to add features, but that's a different issue from "is ksh well written code or not". In my experience, ksh comes up and runs > 95% of the time on almost any kind of Unix system out there. Ksh is generally the first thing I bring up on a new system that doesn't have it (long habit, sorry :-). Probably soon that will no longer be true for me, it'll be es (+ or - readline) . Arnold From rc-owner Fri Apr 16 15:01:20 1993 Received: from trout.nosc.mil ([128.49.16.7]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Fri, 16 Apr 1993 15:00:43 -0400 Received: from schroeder.nosc.mil by trout.nosc.mil (5.59/1.27) id AA26560; Fri, 16 Apr 93 12:00:26 PDT Message-Id: <9304161900.AA26560@trout.nosc.mil> Received: by peanuts.nosc.mil; Fri, 16 Apr 93 12:00:22 PDT Date: Fri, 16 Apr 1993 15:00:22 -0400 From: broman@peanuts.nosc.mil (Vincent Broman) To: rc@hawkwind.utcs.toronto.edu Subject: Memory leaking Reply-To: broman@trout.nosc.mil I run rc 1.4 on 386-Minix (and other machines) with the editline add-on. I have a recurring problem that looks like a memory leak in rc. After some time interacting with rc, I eventually type something like "ls | more" and get one or two messages "Arg list too long", which is perror output for the E2BIG error, happening in exec(). The problem is always fixable by doing "exec rc -l" and going on. Since Minix fixes the memory allocated to a program at exec time to a user-chosen, but modest, value, it appears that the program is running out of memory. I checked my yacc and it doesn't seem to malloc(). It is not impossible that the Minix exec() call itself is buggy, but can anyone suggest any other avenues of investigation? Anyone else see memory leaks not caused by yacc? Vincent Broman, code 572 Bayside Naval Command Control and Ocean Surveillance Center, RDT&E Div. San Diego, CA 92152-6147, USA Email: broman@nosc.mil From rc-owner Fri Apr 16 15:14:37 1993 Received: from netcomsv.netcom.com ([163.179.1.9]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Fri, 16 Apr 1993 15:14:18 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA25032; Fri, 16 Apr 93 12:14:20 PDT Received: by netapp.netapp.com (4.1/SMI-4.1) id AA18202; Fri, 16 Apr 93 12:14:30 PDT Date: Fri, 16 Apr 1993 15:14:30 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9304161914.AA18202@netapp.netapp.com> To: broman@trout.nosc.mil, rc@hawkwind.utcs.toronto.edu Subject: Re: Memory leaking I don't know if editline leaks memory, but bare-1.4 has been tested with purify and doesn't show any significant leaks. The insignificant ones will be fixed in 1.5. Note that regardless of leaks rc uses more memory than sh. From rc-owner Fri Apr 16 18:08:41 1993 Received: from relay.cs.toronto.edu ([128.100.1.105]) by hawkwind.utcs.toronto. edu with SMTP id <2764>; Fri, 16 Apr 1993 18:08:16 -0400 Received: from xenitec.on.ca ([142.77.5.3]) by relay.cs.toronto.edu with SMTP i d <150186>; Fri, 16 Apr 1993 18:08:09 -0400 Received: from golem by xenitec.xenitec.on.ca id aa02806; 16 Apr 93 18:05 EDT To: Byron Rakitzis cc: rc@hawkwind.utcs.toronto.edu Subject: Re: rc 1.5 In-reply-to: Your message of "Fri, 16 Apr 93 15:14:30 EDT." <9304161914.AA18202@netapp.netapp.com> Date: Fri, 16 Apr 1993 18:04:03 -0400 From: "David J. Fiander" Message-ID: <9304161804.aa02967@golem.waterloo.on.ca> >From: Byron Rakitzis >The insignificant [memory leaks] will be fixed in 1.5. Will 1.5 be brought into line with the Plan 9 man page? Things like the flag command and having the "." command search the path? - David From rc-owner Fri Apr 16 18:22:17 1993 Received: from netcomsv.netcom.com ([163.179.1.9]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Fri, 16 Apr 1993 18:21:50 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA19312; Fri, 16 Apr 93 15:21:45 PDT Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA25866; Fri, 16 Apr 93 15:21:39 PDT Date: Fri, 16 Apr 1993 18:21:39 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9304162221.AA25866@netapp.netapp.com> To: davidf@golem.waterloo.on.ca Subject: Re: rc 1.5 Cc: rc@hawkwind.utcs.toronto.edu >Will 1.5 be brought into line with the Plan 9 man page? That's a good question. I'm hoping to freeze rc. I also don't feel the need to bring rc "into line" with anything else. So offhand I would say no. The flag command is present in plan9 rc for a very specific reason (/lib/rcmain). And I don't want dot to search my path. What if I do: ; cat >test <; Fri, 16 Apr 1993 18:29:23 -0400 Received: from canaan.eecs.nwu.edu by epsilon.eecs.nwu.edu (4.1/SMI-4.0-proxy) id AA29126; Fri, 16 Apr 93 17:29:06 CDT From: quanstro@epsilon.eecs.nwu.edu (Erik Quanstrom) Received: by canaan.eecs.nwu.edu (4.1/client-1.5) id AA26631; Fri, 16 Apr 93 17:27:50 CDT Date: Fri, 16 Apr 1993 18:27:50 -0400 Message-Id: <9304162227.AA26631@canaan.eecs.nwu.edu> To: Subject: bug in rc? Apparently-To: rc@hawkwind.utcs.toronto.edu ; if^if syntax error ; if^bar syntax error ; bar^if barif not found So why are the first two syntax errors? From rc-owner Fri Apr 16 18:45:37 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2764>; Fri, 16 Apr 1993 18:45:15 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA02779; Fri, 16 Apr 93 15:45:06 -0700 Received: by astro.mv.us.adobe.com; id AA20615; Fri, 16 Apr 93 15:45:47 -0700 Date: Fri, 16 Apr 1993 18:45:47 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9304162245.AA20615@astro.mv.us.adobe.com> To: quanstro@epsilon.eecs.nwu.edu Subject: Re: bug in rc? Cc: rc@hawkwind.utcs.toronto.edu because otherwise yacc gives conflicts. if you really want to do that, use 'if'^if this has to do with the way the first, word, and comword productions are used. it's sensible and hasn't caused anyone problems until now. it also dates back to Tom Duff's plan 9 rc, so Byron can just say he did it for purposes of compatibility. :-) From rc-owner Fri Apr 16 19:12:09 1993 Received: from netcomsv.netcom.com ([163.179.1.9]) by hawkwind.utcs.toronto.edu with SMTP id <2764>; Fri, 16 Apr 1993 19:11:46 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA21659; Fri, 16 Apr 93 15:43:19 PDT Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1) id AA26231; Fri, 16 Apr 93 15:43:45 PDT Date: Fri, 16 Apr 1993 18:43:45 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9304162243.AA26231@netapp.netapp.com> To: quanstro@epsilon.eecs.nwu.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: bug in rc? "if" in the first position denotes the if keyword. In any other position it is passed on as an argument. this is true in sh as well: $ echo fi fi $ fi echo syntax error: `fi' unexpected $ although the rules for sh parsing are probably harder to deduce.. From rc-owner Sat Apr 17 08:39:18 1993 Received: from relay.cs.toronto.edu ([128.100.1.105]) by hawkwind.utcs.toronto. edu with SMTP id <2751>; Sat, 17 Apr 1993 08:38:01 -0400 Received: from xenitec.on.ca ([142.77.5.3]) by relay.cs.toronto.edu with SMTP i d <150176>; Sat, 17 Apr 1993 08:37:48 -0400 Received: from golem by xenitec.xenitec.on.ca id aa13850; 17 Apr 93 8:35 EDT To: Byron Rakitzis cc: rc@hawkwind.utcs.toronto.edu Subject: Re: rc 1.5 In-reply-to: Your message of "Fri, 16 Apr 93 18:21:39 EDT." <9304162221.AA25866@netapp.netapp.com> Date: Sat, 17 Apr 1993 07:51:55 -0400 From: "David J. Fiander" Message-ID: <9304170751.aa04405@golem.waterloo.on.ca> >That's a good question. I'm hoping to freeze rc. I also don't feel >the need to bring rc "into line" with anything else. So offhand I >would say no. The flag command is present in plan9 rc for a very >specific reason (/lib/rcmain). It's also there so scripts can change flags. I would like to be able to write scripts that turn on the -x flag internally, when their debug flag is specified on the command line. >And I don't want dot to search >my path. [deletion] >and "." is at the end of my path? Does this mean I run /bin/test >as rc input? (THIS IS WHAT /bin/sh ACTUALLY DOES!!) Actually, /bin/sh, /bin/ksh, and the POSIX.2 shell all check the current directory for a file named "test", and _then_ search the path for a file named "test" which is also executable. The reason I would like "." to search the path is that then I can create the directory /usr/bin/rclib, and store scripts in there. Then my scripts can just say . rclib/read to load the read function that I have stored there. - David From rc-owner Sat Apr 17 12:48:32 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2751>; Sat, 17 Apr 1993 12:47:58 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA28250; Sat, 17 Apr 1993 11:47:19 -0500 Message-Id: <9304171647.AA28250@oldp.astro.wisc.edu> To: "David J. Fiander" Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: rc 1.5 Date: Sat, 17 Apr 1993 12:47:18 -0400 From: Alan Watson X-Mts: smtp [Re flags:] > It's also there so scripts can change flags. I would like to > be able to write scripts that turn on the -x flag internally, > when their debug flag is specified on the command line. I would also find this useful, especially for debugging functions. > Actually, /bin/sh, /bin/ksh, and the POSIX.2 shell all check > the current directory for a file named "test", and _then_ > search the path for a file named "test" which is also > executable. None of the Bourne derivatives (sh, sh5, ksh, and bash) behave that way on this machine (Decstation running Ultrix 4.3); the only ones which get it `right' are the csh derivatives (csh and tcsh). > The reason I would like "." to search the path is that then I > can create the directory /usr/bin/rclib, and store > scripts in there. Then my scripts can just say > > . rclib/read > > to load the read function that I have stored there. Try: rclib = /usr/bin/rclib . $rclib/read From rc-owner Sat Apr 17 12:55:59 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2751>; Sat, 17 Apr 1993 12:55:47 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA04367; Sat, 17 Apr 93 09:55:37 -0700 Received: by astro.mv.us.adobe.com; id AA11180; Sat, 17 Apr 93 09:56:19 -0700 Date: Sat, 17 Apr 1993 12:56:19 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9304171656.AA11180@astro.mv.us.adobe.com> To: alan@oldp.astro.wisc.edu Subject: Re: rc 1.5 Cc: rc@hawkwind.utcs.toronto.edu > > The reason I would like "." to search the path is that then I > > can create the directory /usr/bin/rclib, and store > > scripts in there. Then my scripts can just say > > . rclib/read > > to load the read function that I have stored there. > Try: > rclib = /usr/bin/rclib > . $rclib/read other alternatives: fn load { for (i in $*) . /usr/bin/rclib/^$i } load read es and autoloading of shell functions :-) paul From rc-owner Mon Apr 19 08:04:45 1993 Received: from odin.INS.CWRU.Edu ([129.22.8.102]) by hawkwind.utcs.toronto.edu with SMTP id <2753>; Mon, 19 Apr 1993 08:03:21 -0400 Received: by odin.INS.CWRU.Edu (5.65b+ida+/CWRU-1.5.4-ins) id AA08814; Mon, 19 Apr 93 08:02:50 -0400 (from chet for rc@hawkwind.ut cs.toronto.edu) Date: Mon, 19 Apr 1993 07:59:00 -0400 From: Chet Ramey To: davidf@golem.waterloo.on.ca Subject: Re: rc 1.5 Cc: rc@hawkwind.utcs.toronto.edu Reply-To: chet@po.CWRU.Edu In-Reply-To: Message from davidf@golem.waterloo.on.ca of Sat, 17 Apr 1993 07:51 :55 -0400 (id <9304170751.aa04405@golem.waterloo.on.ca>) Message-Id: <9304191159.AA08714.SM@odin.INS.CWRU.Edu> Read-Receipt-To: chet@po.CWRU.Edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii > Actually, /bin/sh, /bin/ksh, and the POSIX.2 shell all check > the current directory for a file named "test", and _then_ > search the path for a file named "test" which is also > executable. This is not true, except in some older versions of sh. Current versions of sh do not do it; I don't think ksh ever did. Posix.2 specifies that only a path search is performed. The current directory is not searched unless it is in $PATH ``to avoid introducing suceptibility to trojan horses that a user might be trying to avoid by leaving `.' out of $PATH.'' Chet -- ``The ballpark is quiet now, save for the sound of droplets landing. That is as it should be. For today there are two fewer boys of summer.'' Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu From rc-owner Mon Apr 19 21:35:35 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2753>; Mon, 19 Apr 1993 21:35:17 -0400 Received: by mod.civil.su.oz.au id <28689>; Tue, 20 Apr 1993 11:34:25 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Mon, 19 Apr 1993 21:29:42 -0400 To: The rc Mailing List Subject: Re: rc and signals In-Reply-To: <9304161530.AA13016@earth.osf.org> Message-ID: <199304201129.11095.rc.baguy@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ > DGK is one smart guy I remain mildly convinced that this is not true. I'm with Rich. Read some of his code and then see if you still believe that. OK, John. From rc-owner Wed Apr 21 20:20:03 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2773>; Wed, 21 Apr 1993 20:19:08 -0400 Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA08746; Wed, 21 Apr 93 20:19:04 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 201821.7807; Wed, 21 Apr 1993 20:18:21 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa16439; Wed, 21 Apr 93 19:25:34 EDT From: culliton@srg.srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: trip took a wrong turn: dot -i Date: Wed, 21 Apr 1993 19:26:12 -0400 Message-Id: <9304211926.aa18149@ceres.srg.af.mil> I was reading back through old messsages to the mailing list and came across a comment about trip.rc having "~!" in four places where it should have "!~". Being a damned fool, I went and fixed it, which of course made me very unhappy because it revealed a problem with '. -i' not printing a prompt like it should. AAARGH! (Why couldn't I leave well enough alone?) For example on my system feeding the following script to rc makes it stop and wait for user commands but doesn't ever print the prompt! ------------------------------------------------------------------------------ #! /bin/rc echo 'This is test of ". -i"' echo 'First we set the prompt to something we''ll recognize' prompt=(PROMPT1 PROMPT2) echo 'we now try to go interactive' . -i /dev/tty echo 'end of interaction' ------------------------------------------------------------------------------ Anybody got a clue? Tom From rc-owner Wed Apr 21 20:20:12 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2774>; Wed, 21 Apr 1993 20:19:58 -0400 Received: from spool.uu.net (via localhost.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09306; Wed, 21 Apr 93 20:19:03 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 201823.7812; Wed, 21 Apr 1993 20:18:23 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa16831; Wed, 21 Apr 93 19:55:13 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: culliton@uunet.UU.NET, rc@hawkwind.utcs.toronto.edu Subject: Re: trip took a wrong turn: dot -i Date: Wed, 21 Apr 1993 19:55:29 -0400 Message-Id: <9304211955.aa18331@ceres.srg.af.mil> My earlier message didn't mention that I'm using GNU readline with rc. >From looking at the code it seems like a bug in the section of input.c around line 118 which is conditionally included for READLINE. If my brain was working better (or when it is) I might have a go at fixing it. Tom From rc-owner Wed Apr 21 22:00:46 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2773>; Wed, 21 Apr 1993 22:00:29 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA20178; Wed, 21 Apr 93 19:00:18 -0700 Received: by astro.mv.us.adobe.com; id AA07626; Wed, 21 Apr 93 19:01:01 -0700 Date: Wed, 21 Apr 1993 22:01:01 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9304220201.AA07626@astro.mv.us.adobe.com> To: culliton@srg.af.mil Subject: Re: trip took a wrong turn: dot -i Cc: rc@hawkwind.utcs.toronto.edu just to confirm Tom's previous note, rc-1.4 w/o readline does the right thing here. From rc-owner Thu Apr 29 04:12:45 1993 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <2785>; Thu, 29 Apr 1993 04:10:41 -0400 Received: from holly.harlequin.co.uk ([193.128.4.58]) by archone.tamu.edu with SMTP id <45322>; Thu, 29 Apr 1993 03:10:14 -0500 Received: from piaget.harlqn.co.uk ([192.88.238.4]) by holly.harlequin.co.uk; T hu, 29 Apr 1993 09:16:26 +0100 Received: from rocannon.harlqn.co.uk by piaget.harlqn.co.uk; Thu, 29 Apr 93 09: 16:20 BST From: Richard Brooksby Date: Thu, 29 Apr 1993 04:16:19 -0400 Message-Id: <648.9304290816@rocannon.harlqn.co.uk> To: rc@archone.tamu.edu Subject: WANTED: Information about rc Newsgroups: comp.unix.shell Summary: Some questions about the shell named `rc' and its background. Keywords: rc information wanted I heard about rc a while back on comp.unix.shell when someone wrote about its `minimalist approach'. Being a minimalist myself I was instantly attracted and sought it out. I now use it as my main shell and am very pleased. When I ftp'd the source I also received some documents about Plan-9, and something explaining the rc rationale. However, in general I find the background of rc mysterious. If someone who knows is willing to write to me and tell me about Plan-9, rc, etc. I'd be grateful. I'd also be pleased to hear from other rc users. By the way, there is an rc mailing list which can be subscribed to by mailing rc-request@archone.tamu.edu. I'll post a summary of responses by mail in comp.unix.shell and on the rc mailing list. Thanks. --- Richard Brooksby ML Project / Symbolic Processing Division / Harlequin +44 223 872522 From rc-owner Thu Apr 29 23:33:16 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2783>; Thu, 29 Apr 1993 23:32:22 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA20746; Thu, 29 Apr 93 20:32:15 -0700 Received: by astro.mv.us.adobe.com; id AA02753; Thu, 29 Apr 93 20:33:01 -0700 Date: Thu, 29 Apr 1993 23:33:01 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9304300333.AA02753@astro.mv.us.adobe.com> To: es@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: for better or for worse, es has been announced to the rest of the world. version 0.84 is now available for ftp from the usual place. (thanks Chris!) i think this release should work straight out of the box on most machines. very little has changed since 0.83; see the CHANGES file for details. the usenet posting follows. paul Article 9818 of comp.unix.shell: Xref: adobe comp.unix.shell:9818 comp.unix.wizards:21071 comp.lang.misc:10810 c omp.lang.tcl:4036 comp.lang.scheme:6086 Newsgroups: comp.unix.shell,comp.unix.wizards,comp.lang.misc,comp.lang.tcl,comp .lang.scheme Path: adobe!haahr From: haahr@adobe.com (Paul Haahr) Subject: es, a new shell Message-ID: <1993Apr30.032118.27003@adobe.com> Followup-To: comp.unix.shell Keywords: es rc shell Sender: usenet@adobe.com (USENET NEWS) Organization: Adobe Systems Incorporated Date: Fri, 30 Apr 1993 03:21:18 GMT We'd like to announce the availability of es, a new Unix shell. Es evolved out of Byron's public reimplementation of rc, the Plan 9 shell. When he was writing rc, the two of us started speculating what a shell would be like if it were designed as a programming language rather than as an ad hoc collection of syntax and builtins that happen to trigger certain system calls. We stole a lot from other programming languages---notably rc, Scheme, and Tcl---and ended up with a system that is very extensible and programmable. The version we are releasing is 0.84; that is, a little more than four-fifths of a product. It's been used by a few dozen people while the big design issues were worked out, but we're freezing development of major new features until we've got a stable 1.0 version. We don't think there are very many serious bugs, but we can't claim that it's been extensively tested. (At least one of us has been using it as a login shell for over six months.) Es is availble by anonymous ftp from ftp.sys.utoronto.ca:/pub/es/es-0.84.tar.Z It is written in ANSI C, and effectively requires a compiler that knows about prototypes, and the like. You may need to add a few compile-time options to the CFLAGS line in the Makefile, and, of course, header files always move around, but other than that it should just compile and run. For details on es, please see the man page in the distribution. For some background on the design of es, see our Winter 1993 Usenix paper, ``Es: a shell with higher-order functions,'' available by ftp as ftp.sys.utoronto.ca:/pub/es/usenix-w93.ps.Z Please report any bugs in es (or other problems with it) to us at haahr@adobe.com byron@netapp.com There is a mailing list for discussing es. Send mail to es-request@hawkwind.utcs.toronto.edu to join the list. The list itself is es@hawkwind.utcs.toronto.edu Es is in the public domain. We hold no copyrights or patents on the source code, and do not place any restrictions on its distribution. We would appreciate it if any distributions credit the authors. The following are answers to a few questions people might have about es. Q: What machines does it run on? A: So far, we've run it successfully on Sparc machines under SunOS 4.x and Solaris 2, Sun3s, Silicon Graphics and MIPS machines, DEC Alpha OSF/1 and MIPS Ultrix machines, NeXTs, and IBM RS6000s. Others have run it under SCO Open Desktop, Interactive's Unix for Intel processors, and HP/UX 9.0.1. Somebody sent us a note about getting it running on a Cray. Where the native compilers support ANSI C we've used them, otherwise we've used gcc. Q: What's performance like? A: Pretty good, not that it matters much, since most shells spend very little time doing anything interesting other than making system calls. Roughly, performance is slightly worse than that of rc. Interactive performance is pretty good, and startup time is pretty small. Q: What's going to change between now and the 1.0 release? A: As little as possible. We want to get the remaining bugs out and address portability issues. We'd also like to document the internals better. Q: Does es support history? A: Yes, in two forms. First, es can be used with GNU readline or a compatible library, such as editline. Second, es will optionally write all interactive input to a file, which an auxiliary program can manipulate. It does not have csh-style ! history. Q: You say es is extensible. Can I add csh-style history? A: No, or, at least, not yet. We'd like to come up with a way for an es user to extend the syntax. Right now extensibility in es is similar to C++ operators: you can give new semantics to existing syntax, but you can't invent wholly new syntax. Future versions of es probably will support user-defined syntax. We think definition-by-example systems such as extend-syntax in Scheme are a good model, but we don't know how to apply that approach to a language that doesn't have lispish syntax. Q: Does es have job control? A: No. While neither of us likes job control, we did not leave it out for ideological reasons. Rather, we wanted to avoid the complexity it would add to the shell. If someone can tell us how to add job control portably without requiring pervasive changes to the shell's semantics or implementation, we would probably do it. Q: Isn't es just another of those minimalist, spartan shells that people like to read about but not use? A: As two of rc's earliest adopters outside of Bell Labs, we'd disagree with the premise that a small shell is worse to use than a big one. Nonetheless, we're ashamed to admit that es is not as minimalist as it could be. In fact, compiled with assertion checking on (the default), es is larger than csh on most systems. Rc is in many ways the perfect shell. It's small, fast, and predictable. There's not much to confuse a user in it. Es is different; it's larger, slower, and has many nooks and crannies. The central difference between the two shells is that rc is hard-coded to the right thing, where you can customize es to do what you want it to do. That ability to extend es required a more sophisticated language and more builtin operations than are found in rc. Q: What does es mean for Byron's rc implementation? A: Rc is a mature, stable piece of code. New development on rc has mostly stopped, reflecting the maturity of the code. The last release of Byron's rc was last May, although another one is coming soon. Es, on the other hand, is still rather immature, and makes a wonderful testbed for new ideas on how to construct shells. We expect that some rc users will switch to es and some will not. Enjoy! -- Paul Haahr & Byron Rakitzis -- paul haahr adobe systems incorporated haahr@adobe.com ...!decwrl!adobe!haahr +1 415 962 6056 From rc-owner Sat May 1 17:05:47 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2802>; Sat, 1 May 1993 17:05:02 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA27623; Sat, 1 May 1993 16:04:52 -0500 Message-Id: <9305012104.AA27623@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: pushd/popd/dirs for es Date: Sat, 1 May 1993 17:04:51 -0400 From: Alan Watson X-Mts: smtp If I want /bin/pwd, I know where to find it. From rc-owner Mon May 10 21:31:40 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2810>; Mon, 10 May 1993 21:30:30 -0400 Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA24846; Mon, 10 May 93 21:29:45 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 211403.11226; Mon, 10 May 1993 21:14:03 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa02106; Mon, 10 May 93 20:56:54 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Re: trip took a wrong turn: dot -i Date: Mon, 10 May 1993 18:56:14 -0400 Message-Id: <9305101856.aa14389@ceres.srg.af.mil> First I encountered this problem with -i when I fixed trip.rc. > For example on my system feeding the following script to rc makes it > stop and wait for user commands but doesn't ever print the prompt! > > ----------------------------------------------------------------------------- - > #! /bin/rc > echo 'This is test of ". -i"' > echo 'First we set the prompt to something we''ll recognize' > prompt=(PROMPT1 PROMPT2) > echo 'we now try to go interactive' > . -i /dev/tty > echo 'end of interaction' > ----------------------------------------------------------------------------- - Then I narrowed it down to being readline related. > My earlier message didn't mention that I'm using GNU readline with rc. > From looking at the code it seems like a bug in the section of input.c > around line 118 which is conditionally included for READLINE. If my > brain was working better (or when it is) I might have a go at fixing > it. Now I understand exactly what is happening but can't decide what the "right way" to fix it is. Maybe Byron or Chet can make a suggestion. Without READLINE defined there is some code in input.c and lex.c that print the appropriate prompts if the global variable interactive is TRUE. With READLINE defined, they simply set the variable prompt which gets passed to the readline function. So far, so good. However, if the fd beig read is not stdin, readline is not called, and as a result no prompt gets printed. Blech! I see two possible solutions. 1) If we're not going to call readline, print the prompts, either where they would be printed "normally" or in the code surrounding the readline call. This is simple but inconsistent. 2) Tell readline to use the appropriate fd by setting rl_instream or some other means. Unfortunately readline seems to want to deal in FILE *'s rather than fd's, so a fdopen() might be required to get one, which seems pretty silly because readline always does a fileno() on them! Chet: Is there a better way to twist readline's tail? Byron: Care to state a preference? I'll post a patch as soon as the choice becomes clear. Tom From rc-owner Tue May 11 08:17:55 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2818>; Tue, 11 May 1993 08:15:22 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA27490; Tue, 11 May 93 08:15:05 -0400 Received: by earth.osf.org (5.65/4.7) id AA07128; Tue, 11 May 93 08:15:03 -0400 Date: Tue, 11 May 1993 08:15:03 -0400 From: rsalz@osf.org Message-Id: <9305111215.AA07128@earth.osf.org> To: culliton@srg.af.mil, rc@hawkwind.utcs.toronto.edu Subject: Re: trip took a wrong turn: dot -i >2) Tell readline to use the appropriate fd by setting rl_instream or ... >Chet: Is there a better way to twist readline's tail? Please don't do anything that affects the readline use. If you do, then I will have to muck up my editline drop-in replacement and I'd rather not do that. :-) /r$ From rc-owner Tue May 11 19:49:39 1993 Received: from netcomsv.netcom.com ([163.179.1.13]) by hawkwind.utcs.toronto.ed u with SMTP id <2811>; Tue, 11 May 1993 19:48:42 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA14125; Tue, 11 May 93 16:48:45 PDT Received: from ghoti.netapp.com by netapp.netapp.com (4.1/SMI-4.1) id AA06236; Tue, 11 May 93 16:48:45 PDT Received: by ghoti.netapp.com (4.1/SMI-4.1) id AA07423; Tue, 11 May 93 16:48:38 PDT Date: Tue, 11 May 1993 19:48:38 -0400 From: netapp!byron@netcom.com (Byron Rakitzis) Message-Id: <9305112348.AA07423@ghoti.netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: a small diversion Hi, I am just posting a small piece of code for your amusement. I've always been sick of /bin/find's syntax, so about a year ago I wrote a little toy program to explore an alternative user interface. I have a small yacc program which takes a C-like expression syntax on stdin and produces find-compatible syntax on stdout. Doubtless it is incomplete, which is why I call it a toy. I also have an rc script which interfaces my preprocessor to /bin/find itself. Here are some examples of find pre-processor input and output: (type(d)||type(f))&&print becomes ( -type d -o -type f ) -a -print and name(*.o)&&exec(rm {}) becomes -name *.o -a -exec rm {} As I see it, the main advantages of my approach are: 1) You don't need to split up the find expression so that one token == one argv[] element. e.g., I find '(foo||bar)&&print' much easier to type than '(' foo -o bar ')' -a -print 2) I find that /bin/find syntax is write-only, whereas it's easier for me to parse visually what's going on, even with the above two simple expressions. Well, that's enough for now. I mostly just want to amuse, as well as provoke thought. This is not a "production" solution. Here's the script I use as a replacement to find, which I call "f": # to unbundle, sh this file # bundled by byron on ghoti at Tue May 11 16:43:31 PDT 1993 # contents of bundle: # f echo f sed 's/^-//' > f <<'end of f' -#!/bin/rc -if (~ $#* 0 1) { - echo 'usage: f ' >[1=2] - exit 1 -} -files=() -while (! ~ $#* 1) { - files = ($1 $files) - shift -} -find $files `{echo $1 | prefind} end of f It is used as: f where expr is a *single* argument, usually surrounded in quotes. For example: f . 'type(d)&&print' The yacc source follows. Run through yacc, and compile it into "prefind". Byron. # to unbundle, sh this file # bundled by byron on ghoti at Tue May 11 16:44:00 PDT 1993 # contents of bundle: # find.y echo find.y sed 's/^-//' > find.y <<'end of find.y' -%term ORELSE ANDALSO CMD - -%{ -static int yylex(void); -static char *sprint(const char *fmt,...); -static void *ealloc(unsigned n); -static void *erealloc(void *p, unsigned n); -#define WORDSIZE 8 -#define CHECKSIZE() if (i >= size) buf = erealloc(buf, size *= 2) -%} - -%union { - char *s; -} - -%type find expr or and not un clist -%type CMD - -%% - -find : expr { printf("%s\n", $1); } - -expr : or - -or : and - | or ORELSE and { $$ = sprint("% -o %", $1, $3); } - -and : not - | and ANDALSO not { $$ = sprint("% -a %", $1, $3); } - -not : '!' un { $$ = sprint("! %", $2); } - | un - -un : '(' expr ')' { $$ = sprint("( % )", $2); } - | CMD { $$ = sprint("-%", $1); } - | CMD '(' clist ')' { $$ = sprint("-% %", $1, $3); } - -clist : CMD - | clist CMD { $$ = sprint("% %", $1, $2); } - -%% - -#include -#include -#include - -static int yylex() { - char *buf; - int c; - unsigned i, size; - -top: switch (c = getchar()) { - case ' ': case '\t': case '\n': - goto top; - case EOF: case '\0': - case '!': case ',': - case '(': case ')': - return c; - case '&': - if ((c = getchar()) == '&') - return ANDALSO; - return '?'; - case '|': - if ((c = getchar()) == '|') - return ORELSE; - return '?'; - default: - buf = ealloc(size = WORDSIZE); - i = 0; - while (1) { - buf[i++] = c; - CHECKSIZE(); - switch (c = getchar()) { - default: - break; - case EOF: case '\0': - case ' ': case '\t': case '\n': - case '(': case ')': case ',': - case '!': case '&': case '|': - ungetc(c, stdin); - buf[i] = '\0'; - yylval.s = buf; - return CMD; - } - } - } -} - -static char *sprint(const char *fmt,...) { - va_list ap; - unsigned size, i = 0; - char *buf = ealloc(size = WORDSIZE); - - va_start(ap, fmt); - - while (*fmt != '\0') { - if (*fmt != '%') { - buf[i++] = *fmt++; - CHECKSIZE(); - } else { - char *word = va_arg(ap, char *); - while (*word != '\0') { - buf[i++] = *word++; - CHECKSIZE(); - } - fmt++; - } - } - - va_end(ap); - - buf[i] = '\0'; - return buf; -} - -static void *ealloc(unsigned n) { - void *p = malloc(n); - if (p == NULL) { - perror("malloc"); - exit(1); - } - return p; -} - -static void *erealloc(void *p, unsigned n) { - p = realloc(p, n); - if (p == NULL) { - perror("realloc"); - exit(1); - } - return p; -} - -static void yyerror(char *s) { - fprintf(stderr, "%s\n", s); - exit(1); -} - -extern int main() { - yyparse(); - return 0; -} end of find.y From rc-owner Wed May 12 01:40:52 1993 Received: from netcomsv.netcom.com ([163.179.1.13]) by hawkwind.utcs.toronto.ed u with SMTP id <2811>; Wed, 12 May 1993 01:40:05 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA24380; Tue, 11 May 93 22:39:57 PDT Received: by netapp.netapp.com (4.1/SMI-4.1) id AA08807; Tue, 11 May 93 22:37:58 PDT Date: Wed, 12 May 1993 01:37:58 -0400 From: netapp!byron@netcom.com (Byron Rakitzis) Message-Id: <9305120537.AA08807@netapp.netapp.com> To: culliton@srg.af.mil, rc@hawkwind.utcs.toronto.edu Subject: Re: trip took a wrong turn: dot -i I've thought about it for a little while and I can't make up my mind. Here is my preference: readline should take a file descriptor as an argument. Ok, given that that is "impossible", I think the best way out may be to make the rest of the prompt2 stuff in rc readline- and file- descriptor-cognisant, i.e., by printing prompt2 if "!readline || fd != 0". It's ugly, but I can rationalize it by saying that it's hiding behind this grotesque #ifdef READLINE to begin with. Byron. From rc-owner Thu May 13 14:14:35 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2221>; Thu, 13 May 1993 14:13:17 -0400 Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25818; Thu, 13 May 93 14:13:06 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 141148.23305; Thu, 13 May 1993 14:11:48 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa25030; Thu, 13 May 93 14:06:58 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: An extra patch for trip.rc Date: Thu, 13 May 1993 14:07:23 -0400 Message-Id: <9305131407.aa20335@ceres.srg.af.mil> Just to make life a bit easier here is the patch to trip.rc which fixes the "~! should be !~" bug. Tom ----------8<--------------------CUT HERE--------------------8<---------- *** trip.rc Wed Apr 21 19:10:23 1993 --- trip.rc2 Wed Apr 21 18:29:53 1993 *************** *** 237,243 **** if (~ `{echo -n} ?) fail echo -n ! if (~! `` '' {echo --} $nl) fail echo -- pwd=`/bin/pwd cdpath=/ { # some local assignments --- 237,243 ---- if (~ `{echo -n} ?) fail echo -n ! if (!~ `` '' {echo --} $nl) fail echo -- pwd=`/bin/pwd cdpath=/ { # some local assignments *************** *** 409,415 **** echo hi eof ! prompt=';' if (~! `` '' {. -i /tmp/dot.$pid>[2=1]} ';hi'^$nl';') fail dot -i submatch .' '/tmp/dot.$pid hi dot --- 409,415 ---- echo hi eof ! prompt=';' if (!~ `` '' {. -i /tmp/dot.$pid>[2=1]} ';hi'^$nl';') fail dot -i submatch .' '/tmp/dot.$pid hi dot *************** *** 457,463 **** ~ $* bar || fail restore of '$*' after local group ~ `{exec>[2=1];$rc -xc 'foo=()'} 'foo=()' || fail -x echo of variable deletio n ! fn_ff='{' prompt='' if (~! `` $nl {$rc -cff>[2=1]} 'line 1: '*' error near eo f') fail 'bogus function in environment' # --- 457,463 ---- ~ $* bar || fail restore of '$*' after local group ~ `{exec>[2=1];$rc -xc 'foo=()'} 'foo=()' || fail -x echo of variable deletio n ! fn_ff='{' prompt='' if (!~ `` $nl {$rc -cff>[2=1]} 'line 1: '*' error near eo f') fail 'bogus function in environment' # *************** *** 517,523 **** # fn prompt {echo hi} ! prompt=() if (~! `{$rc -i /dev/null>[2]/dev/null} hi) fail fn prompt fn prompt # --- 517,523 ---- # fn prompt {echo hi} ! prompt=() if (!~ `{$rc -i /dev/null>[2]/dev/null} hi) fail fn prompt fn prompt # From rc-owner Thu May 13 14:14:55 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2223>; Thu, 13 May 1993 14:14:41 -0400 Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25941; Thu, 13 May 93 14:13:18 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 141147.23295; Thu, 13 May 1993 14:11:47 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa24773; Thu, 13 May 93 13:59:13 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: A patch for prompting (was Re: trip took a wrong turn: dot -i) Date: Thu, 13 May 1993 13:59:40 -0400 Message-Id: <9305131359.aa20263@ceres.srg.af.mil> Here is my patch for the problem in input.c and lex.c. Note that I moved the function print_prompt2 from lex.c to input.c to keep the variable istack static to input.c. This patch is against version 1.4 "as released" and includes the one line patch I sent shortly after the release. With the patch applied the corrected (~! fixed to !~) trip.rc completes successfully. Tom ----------8<--------------------CUT HERE--------------------8<---------- *** lex.c.old Mon May 25 14:11:51 1992 --- lex.c Thu May 13 11:44:24 1993 *************** *** 339,354 **** realbuf = ealloc(bufsize); } - extern void print_prompt2() { - lineno++; - #ifdef READLINE - prompt = prompt2; - #else - if (interactive) - fprint(2, "%s", prompt2); - #endif - } - /* Scan in a pair of integers for redirections like >[2=1]. CLOSED represents a closed file descriptor (i.e., >[2=]) and UNSET represents an undesignated file descrip tor (e.g., --- 339,344 ---- *** input.c.old Mon May 25 15:31:28 1992 --- input.c Thu May 13 12:08:17 1993 *************** *** 117,123 **** while (1) { #ifdef READLINE if (interactive && istack->fd == 0) { ! rlinebuf = readline(prompt); if (rlinebuf == NULL) { chars_in = 0; } else { --- 117,123 ---- while (1) { #ifdef READLINE if (interactive && istack->fd == 0) { ! rlinebuf = rc_readline(prompt); if (rlinebuf == NULL) { chars_in = 0; } else { *************** *** 275,284 **** } if ((s = varlookup("prompt")) != NULL) { #ifdef READLINE ! prompt = s->w; ! #else ! fprint(2, "%s", s->w); #endif prompt2 = (s->n == NULL ? "" : s->n->w); } } --- 275,285 ---- } if ((s = varlookup("prompt")) != NULL) { #ifdef READLINE ! if (istack->fd == 0) ! prompt = s->w; ! else #endif + fprint(2, "%s", s->w); prompt2 = (s->n == NULL ? "" : s->n->w); } } *************** *** 298,303 **** --- 299,317 ---- unexcept(); /* eError */ return parsetree; } + + extern void print_prompt2() { + lineno++; + if (interactive) + { + #ifdef READLINE + if (istack->fd == 0) + prompt = prompt2; + else + #endif + fprint(2, "%s", prompt2); + } + } /* parse a function imported from the environment */ From rc-owner Sat May 15 00:33:20 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2223>; Sat, 15 May 1993 00:14:51 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA01457; Fri, 14 May 1993 23:14:17 -0500 Message-Id: <9305150414.AA01457@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: read Date: Sat, 15 May 1993 00:14:16 -0400 From: Alan Watson X-Mts: smtp I know we've spent some time on this topic before, but I would like to suggest that a read primitive should be added to rc. The promise of one over in the es list has thrown me into an evangelical mood. (a) Boyd Roberts wrote in response to a suggestion to implement test functionality in rc `The shell is there to run programs, not to have programs built into it,' and I agree. However, the shell should also possess an appropriate set of primitives for linking programs together in an efficient manner, and it is my opinion that the likes of echo and read are essential for this capability. (b) There have been many implementations of read posted to the list, and most of them have been contained bugs. Even the one in the EXAMPLES file does not behave like a true sh read upon encountering EOF (it sets the variable to '1', rather than unsetting it). (c) There are reads and there are reads: some take only one argument, others take multiple arguments; some split the input line according to ifs, others don't; behaviour on EOF is almost entirely unpredictable. A builtin read, documented in the man page, would be completely portable. (This alone justifies the builtin echo independently of performance issues -- there's no uncertainty as to whether one is following SYSV or BSD semantics when one uses echo in an rc script. I might even go as far as to say that the NOECHO option should be removed, and those people with religeous objections can use a function to override the builtin and get at /bin/echo, so that builtin echo will always be predicable.) (d) External implementations of read are slow as hell, and this really limits their usefulness. (C'mon, Byron, you added echo just for this reason!) To me, the most important points are (c) and (d) (after all, it is a simple matter to fix the read in the EXAMPLES file). If we had an agreed on definition of the semantics of read, I could implement it as an addon and the rest of you could implement it as a function and we'd all be happy. For better or for worse, rc does not have a mechanism for implementing `standard' functions, unlike es, so there is no method available to universally instantiate such a definition other than as a builtin. Code bload is not an issue -- this builtin adds about 80 very simple and straightforward lines. The only issues are whether read should take multiple arguments, and whether it should perform ifs separation on the line to make a list. I know you're busy, Byron, so I'll append my implementation of a builtin read at the end of this message, together with a trip.read. This read takes only one argument, does not perform ifs separation, does strip the trailing newline, and unsets the variable when no input is read. (Basically, it is a single-argument analogue of the v7 sh read.) Alan. ; diff -e ORIG/addon.h addon.h 23a #ifndef NOREAD #undef ADDONS #define ADDONS { b_read, "read" }, extern void b_read (char **av); #endif . ; diff -e ORIG/addon.c addon.c 5a #include "rc.h" #include "addon.h" #ifndef NOREAD /* b_reads -- read a single line, terminated by \n or EOF, from the standard input, and assign the line without the terminator to av[1]. */ static int readchar (int fd) { unsigned char c; if (read (fd, &c, 1) == 1) return c; else return EOF; } void b_read (char **av) { char *name; int c; char *line; SIZE_T len; SIZE_T max_len; SIZE_T max_len_quantum; /* check usage is "read name" */ if (av[1] == NULL) rc_error ("missing variable name"); if (av[2] != NULL) rc_error ("too many arguments to read"); name = av[1]; /* read a single line from stdin */ line = NULL; len = 0; max_len = 0; max_len_quantum = 256; do { c = readchar (0); if (len == 0 && c == EOF) break; if (c == '\n' || c == EOF) c = 0; if (len == max_len) { max_len += max_len_quantum; line = erealloc (line, max_len); } line[len] = c; len++; } while (c); /* if we successfully read a line assign it to name and return TRUE, * otherwise unset name and return FALSE */ if (line != NULL) { assign (word (name, NULL), word (line, NULL), FALSE); efree (line); set (TRUE); } else { assign (word (name, NULL), NULL, FALSE); set (FALSE); } return; } #endif . ; cat trip.read # trip.read -- check a read implementation performs like a true v7 sh read fn check { ./rc -c $2 >[2=] if ( ~ $1 0 ) { ~ $status 0 || echo failed: $2 } else { ! ~ $status 0 || echo failed: $2 } } check 0 true check 1 false nl = ' ' ifs = $nl file = /etc/passwd first = `{ cat $file } first = $first(1) echo 'start of trip.read' # check read X and read '*' return 0 check 0 'exec <$file ; read X' check 0 'exec <$file ; read ''*''' # check read, read 1, read '' return !0 check 1 'exec <$file ; read' check 1 'exec <$file ; read 1' check 1 'exec <$file ; read ''''' # check read X correctly reads first line check 0 'exec <$file ; read X ; ~ $X $first' # check read '*' correctly reads first line, preserves $0 check 0 'exec <$file ; old0 = $0 ; read ''*'' ; ~ $0 $old0 && ~ $1 $first && ~ $#* 1' # check read returns !0 on EOF and I/O error check 1 'exec ; Sun, 16 May 1993 02:49:29 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA09549; Sun, 16 May 1993 01:49:14 -0500 Message-Id: <9305160649.AA09549@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: read Date: Sun, 16 May 1993 02:49:13 -0400 From: Alan Watson X-Mts: smtp I have just realized that my implementation of read returns the wrong status if you type: ; read x foo More seriously, and strengthening my suggestion that read should be a builtin, I cannot find a way to get `awk' to simulate `line'. In response to the above input, line would print "foo\n" and set status to 1. The obvious awk replacement, i.e., ; fn line { awk '{print $0; exit 0}END{print $0; exit 1}' } does not work in this way, rather I have to press twice, and then it prints "foo\n0\nfoo\n1\n". Your mission, should you choose to accept it, is to come up with a portable (i.e., you can't use line) read which implements v7 semantics on EOF (i.e., if anything was typed before EOF then set the variable to this, otherwise unset it, and return 1 if an EOF is seen). Actually, a working implementation of line will be sufficient (although, obviously, the C code for line will not do). I'd also very much appreciate it if someone could restore my faith in awk by explaining its output! Alan. From rc-owner Sun May 16 03:25:36 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2699>; Sun, 16 May 1993 03:12:28 -0400 To: rc Subject: Re: read In-reply-to: alan's message of Sun, 16 May 93 02:49:13 -0400. <9305160649.AA09549@oldp.astro.wisc.edu> Date: Sun, 16 May 1993 03:12:05 -0400 From: Chris Siebenmann Message-Id: <93May16.031228edt.2699@hawkwind.utcs.toronto.edu> You can't do a read that works unless you have a program that reads input without any buffering (note that anything using stdio doesn't qualify; stdio will happily suck in a buffer's worth when stdin isn't a terminal). If you assume line, you can do a clumsy read; $bgstatus makes it much cleaner (thank you, Byron!). - cks From rc-owner Sun May 16 04:05:17 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2714>; Sun, 16 May 1993 03:51:35 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA09920; Sun, 16 May 1993 02:51:01 -0500 Message-Id: <9305160751.AA09920@oldp.astro.wisc.edu> To: Chris Siebenmann Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: read Date: Sun, 16 May 1993 03:51:00 -0400 From: Alan Watson X-Mts: smtp Yes, I know. I don't actually think it is that clumsy. Since awk appeared in read in the examples file, I assumed awk performed unbuffered reads (I was rather surprised, I must admit); direct experiment reveals this not to be the case. I suggest that the read in the EXAMPLES file be replaced with fn read { if ( ! ~ $#* 1 ) { echo >[1=2] Usage: read variable return 1 } var = $1 { ifs = $nl { * = `{ line ; echo $status } } $var = $1 return $2 } } From rc-owner Mon May 17 22:14:40 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2223>; Mon, 17 May 1993 22:13:46 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA18944; Mon, 17 May 1993 21:13:31 -0500 Message-Id: <9305180213.AA18944@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: read Date: Mon, 17 May 1993 22:13:30 -0400 From: Alan Watson X-Mts: smtp Gosh, this stuff is tricky, isn't it? Here are both external and built-in implementations of read, following v7 semantics on EOF (i.e., set the variable to '' and return 1), and a corrected trip.read. None of the other reads in the list or the examples get this right (including my previous offerings). Of course, all of this will be made redundant by bqstatus. I take it by the silence that no one objects to a built-in read by default ("yeah, right"). Alan. ; cat addon/read.c /* b_reads -- read a single line, terminated by \n or EOF, from the standard input, and assign the line without the terminator to av[1]. */ static int readchar (int fd) { unsigned char c; if (read (fd, &c, 1) == 1) return c; else return EOF; } void b_read (char **av) { char *name; int c; char *line; SIZE_T len; SIZE_T max_len; SIZE_T max_len_quantum; /* check usage is "read name" */ if (av[1] == NULL) rc_error ("missing variable name"); if (av[2] != NULL) rc_error ("too many arguments to read"); name = av[1]; /* read a single line from stdin */ line = NULL; len = 0; max_len = 0; max_len_quantum = 256; do { c = readchar (0); if (len == max_len) line = erealloc (line, max_len += max_len_quantum); if (c == '\n' || c == EOF) line[len] = 0; else line[len] = c; len++; } while (c != '\n' && c != EOF); /* assign whatever we read to the variable */ assign (word (name, NULL), word (line, NULL), FALSE); efree (line); /* return TRUE if we terminated with a \n, otherwise FALSE */ set (c == '\n'); return; } ; cat read.fn fn read { switch ( $#* ) { case 0 echo >[1=2] missing variable return 1 case 1 case * echo >[1=2] too many arguments to read return 1 } lines = () { ifs = $nl { lines = `{ line ; echo $status } } if ( ~ $#lines 1 ) { $1 = '' return $lines } else { $1 = $lines(1) return $lines(2) } } } ; cat trip.read # trip.read -- check a read implementation performs like a true v7 sh read fn check { echo $1 $2 ./rc -c $2 if ( ! ~ $status $1 ) { echo failed: $2 } } check 0 true check 1 false nl = ' ' ifs = $nl file = /etc/passwd first = `{ cat $file } first = $first(1) echo 'start of trip.read' # check read X and read '*' return 0 check 0 'exec <$file ; read X' check 0 'exec <$file ; read ''*''' # check read, read 1, read '=', and read '' return 1 check 1 'exec <$file ; read' check 1 'exec <$file ; read 1' check 1 'exec <$file ; read ''=''' check 1 'exec <$file ; read ''''' # check read X correctly reads first line check 0 'exec <$file; read X ; ~ $X $first' check 0 'echo -n $first | { read X ; ~ $X $first }' # check read '*' correctly reads first line, preserves $0 check 0 'exec <$file ; old0 = $0 ; read ''*'' ; ~ $0 $old0 && ~ $1 $first && ~ $#* 1' # check read returns 1 on EOF and I/O error check 1 'exec ; Tue, 18 May 1993 13:01:19 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA22461; Tue, 18 May 1993 12:01:05 -0500 Message-Id: <9305181701.AA22461@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: A delicious thought Date: Tue, 18 May 1993 13:01:04 -0400 From: Alan Watson X-Mts: smtp rc keeps everything in the environment (other than its flags and at least until noexport arrives), so there is almost no need for any built-in commands whatsoever: simply, exec a command which performs the `built-in' and then have that command exec another rc, e.g.: ; fn cd { exec not-built-in-cd $* } ; cat `{ whatis not-built-in-cd } #! /bin/sh cd ${1+$"$@"} exec rc ; Flags like `-x' don't get carried over, but otherwise this seems like a complete functional replacement of cd (and, likewise, limit, wait, and umask). Of course, if you really wanted to do this, you'd probably code up the not-built-ins in C. All of this is somewhat academic, but if someone DID want to add a new built-in (or, rather, something which had to function in the same process as rc), this would be an obvious solution. To me, this is a strong argument in favour of placing the flags in the environment (or, at least, what they can be read into the environment) and against noexport (or, at least, against a no export which cannot be easily and temporarily over-ridden). Once again, rc's clean design and the original philosophy of putting everything into the environment seems to be paying off dividends. Alan. P.S. A free email message to the first person to publicly claim that they really do want to exec twice just to change directory (limit is a more obvious candidate to go to a not-built-in implementation -- wouldn't you like to get one more piece of #ifdef-ed code out of the source?). From rc-owner Tue May 18 13:09:23 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto .edu with SMTP id <2230>; Tue, 18 May 1993 13:08:56 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA27 279 (5.65c/IDA-1.4.4 for ); Tue, 18 May 1993 13:08: 43 -0400 Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA05746; Tue, 18 May 93 13:08:40 EDT From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9305181708.AA05746@penfold.cc.gatech.edu> Date: Tue, 18 May 1993 13:08:40 -0400 In-Reply-To: Alan Watson's 52-line message on May 18, 1:01pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: rc@hawkwind.utcs.toronto.edu Subject: Re: A delicious thought Everything old is new again..... I read in an early history of unix paper that on the very early unix systems (pdp-7 vintage!) everything in fact worked this way. You typed a command. The shell exec'ed it, and then the code in exit() would re-exec the shell. When they added fork to the system, they noticed that 'cd' didn't take them anywhere.... At that point it became built-in to the shell. I could almost see doing this with limit. cd is a bit expensive, methinks (just think about the TWO call through nami. One to find cd, the next to do the chdir. ugh) Arnold From rc-owner Tue May 18 13:17:38 1993 Received: from netcomsv.netcom.com ([163.179.1.13]) by hawkwind.utcs.toronto.ed u with SMTP id <2685>; Tue, 18 May 1993 13:17:15 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA29328; Tue, 18 May 93 10:17:21 PDT Received: by netapp.netapp.com (4.1/SMI-4.1) id AA05128; Tue, 18 May 93 10:10:39 PDT Date: Tue, 18 May 1993 13:10:39 -0400 From: netapp!byron@netcom.com (Byron Rakitzis) Message-Id: <9305181710.AA05128@netapp.netapp.com> To: alan@oldp.astro.wisc.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: A delicious thought Actually, before I used rc I ran "limit" in the following way: :; exec csh % limit frob-me 0 % exec sh :; and I am not completely sure I want to go back. Thanks to Paul Haahr for this trick, btw. From rc-owner Tue May 18 14:21:44 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2701>; Tue, 18 May 1993 14:19:26 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA22839; Tue, 18 May 1993 13:19:13 -0500 Message-Id: <9305181819.AA22839@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: A delicious thought Date: Tue, 18 May 1993 14:19:12 -0400 From: Alan Watson X-Mts: smtp I should never post before lunch: my hunger even affected the title. You can't do cd et al. properly in the way I suggested, as rc does not keep all of its state in the environment (specifically, it doesn't keep where it is an a flow control construct, the input stack, $*, and $status). So, you couldn't use a not-built-in command in an if () statement, couldn't use it in a script, and couldn't find out if it worked or not. I thought that we might at least salvage a non-builtin-in limit, but then I realized that probably the most common use of limit is to set coredumpsize to 0 in .rcrc. Of course, we could have rc realize its entire state in the environment, but I hear the wolves baying over in the es list, so I won't even suggest this. Alan. From rc-owner Tue May 18 15:40:35 1993 Received: from albert.gnu.ai.mit.edu ([128.52.46.31]) by hawkwind.utcs.toronto. edu with SMTP id <2223>; Tue, 18 May 1993 15:40:04 -0400 Received: from trinity.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP id ; Tue, 18 May 93 15:39:39 -0400 Received: by trinity.gnu.ai.mit.edu (5.67/4.0) id ; Tue, 18 May 93 15:39:19 -0400 From: root@gnu.ai.mit.edu Message-Id: <9305181939.AA03874@trinity.gnu.ai.mit.edu> Subject: Re: A delicious thought To: alan@oldp.astro.wisc.edu (Alan Watson) Date: Tue, 18 May 1993 15:39:14 -0400 Cc: rc@hawkwind.utcs.toronto.edu In-Reply-To: <9305181701.AA22461@oldp.astro.wisc.edu> from "Alan Watson" at May 18, 93 01:00:50 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 169 > ; fn cd { exec not-built-in-cd $* } > ; cat `{ whatis not-built-in-cd } > #! /bin/sh > cd ${1+$"$@"} > exec rc > ; This does the Wrong Thing within a script. From rc-owner Wed May 19 00:41:32 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2223>; Wed, 19 May 1993 00:40:54 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA03713; Tue, 18 May 1993 23:40:47 -0500 Message-Id: <9305190440.AA03713@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: lazy auto-loading of functions Date: Wed, 19 May 1993 00:40:46 -0400 From: Alan Watson X-Mts: smtp Jealous of Paul Haahr's beautiful implementation of lazy auto-loading of functions in es, I tried to do something similar in rc (which I'm still using as my everyday shell). Obviously, one cannot use his approach directly, but one can go some of the way to reducing the size of the environment as follows: fnlib = $home/fn fn load { builtin . $fnlib/$1 } builtin cd $fnlib name = () for ( name in * ) fn $name { load $0 && $0 $* } builtin cd This is just what you need for those rarely used but sometimes essential functions. Alan. From rc-owner Wed May 19 05:25:38 1993 Received: from holly.harlequin.co.uk ([193.128.4.58]) by hawkwind.utcs.toronto. edu with SMTP id <2237>; Wed, 19 May 1993 05:24:40 -0400 Received: from piaget.harlqn.co.uk (piaget.harlequin.co.uk) by holly.harlequin. co.uk; Wed, 19 May 1993 10:24:45 +0100 Received: from morris.harlqn.co.uk by piaget.harlqn.co.uk; Wed, 19 May 93 10:24 :39 BST From: Richard Brooksby Date: Wed, 19 May 1993 05:21:29 -0400 Message-Id: <20399.9305190921@morris.harlqn.co.uk> To: rc@hawkwind.utcs.toronto.edu, es@hawkwind.utcs.toronto.edu Subject: May I suggest we digestify the rc and es lists? Much as I enjoy corresponding about rc and es I am finding that my mailbox, which is already overloaded, is becoming even more so. I am even considering unsubscribing (to es at least) simply because I do not have the time. May I suggest that the rc and es lists are made into digests at the distribution site? I would much prefer to receive a daily message containing correspondence, even though it would slow down the reaction time somewhat. (Actually, in my experience, slowing down the reaction time often improves the content of a list.) Is this technically feasible? Do others agree that this would be a good thing? Please consider this carefully. I beleive I have something to contribute; it would be a shame if I didn't have the chance. --- Richard Brooksby ML Project / Symbolic Processing Division / Harlequin +44 223 872522 From rc-owner Wed May 19 06:04:07 1993 Received: from holly.harlequin.co.uk ([193.128.4.58]) by hawkwind.utcs.toronto. edu with SMTP id <2685>; Wed, 19 May 1993 06:03:32 -0400 Received: from piaget.harlqn.co.uk (piaget.harlequin.co.uk) by holly.harlequin. co.uk; Wed, 19 May 1993 11:03:38 +0100 Received: from morris.harlqn.co.uk by piaget.harlqn.co.uk; Wed, 19 May 93 11:03 :30 BST From: Richard Brooksby Date: Wed, 19 May 1993 06:00:21 -0400 Message-Id: <21463.9305191000@morris.harlqn.co.uk> To: alan@oldp.astro.wisc.edu Cc: rc@hawkwind.utcs.toronto.edu, es@hawkwind.utcs.toronto.edu In-Reply-To: Alan Watson's message of Tue, 18 May 1993 14:19:12 -0400 <93051818 19.AA22839@oldp.astro.wisc.edu> Subject: Re: A delicious thought Alan Watson wrote: > You can't do cd et al. properly in the way I suggested, as rc does > not keep all of its state in the environment... : > Of course, we could have rc realize its entire state in the > environment, but I hear the wolves baying over in the es list, so I > won't even suggest this. What you are suggesting is just that rc should be continuation rather than stack based. I doubt that even the es designers contemplated this option, although it would make a very interesting shell. However, since the Unix process model is stack based (process parent/child relationships are just like a stack) it wouldn't mesh very well. A nicer thing, in my humble opinion, would be to include a foreign function interface and allow dynamic linking to libraries. One could then import Clib and make system calls directly. --- Richard Brooksby ML Project / Symbolic Processing Division / Harlequin +44 223 872522 From rc-owner Wed May 19 10:05:47 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2689>; Wed, 19 May 1993 10:05:22 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA05715; Wed, 19 May 1993 09:04:32 -0500 Message-Id: <9305191404.AA05715@oldp.astro.wisc.edu> To: Richard Brooksby Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: A delicious thought Date: Wed, 19 May 1993 10:04:31 -0400 From: Alan Watson X-Mts: smtp [Hi, Richard, remember me from GROGGS way back?] Richard Brooksby wrote: > > You can't do cd et al. properly in the way I suggested, as rc does > > not keep all of its state in the environment... > : > > Of course, we could have rc realize its entire state in the > > environment, but I hear the wolves baying over in the es list, so I > > won't even suggest this. > > What you are suggesting is just that rc should be continuation rather > than stack based. I doubt that even the es designers contemplated > this option, although it would make a very interesting shell. Like I said, I didn't even suggest this. > A nicer thing, in my humble opinion, would be to include a foreign > function interface and allow dynamic linking to libraries. One could > then import Clib and make system calls directly. Not in rc; perhaps in es. rc is the clean(er) and simple(r) one, remember. The difference between rc and es is that rc makes the choices for you, so you don't have the opportunity to get them wrong :-). From rc-owner Wed May 19 12:48:11 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2223>; Wed, 19 May 1993 12:21:00 -0400 To: rc, es Subject: Re: May I suggest we digestify the rc and es lists? In-reply-to: richard's message of Wed, 19 May 93 05:21:29 -0400. <20399.9305190921@morris.harlqn.co.uk> Date: Wed, 19 May 1993 12:20:42 -0400 From: Chris Siebenmann Message-Id: <93May19.122100edt.2223@hawkwind.utcs.toronto.edu> I have no digestification software in this mailer and, really, not any time to find, test, install, and babysit it; not to mention that digests are harder to deal with than plain mail for most people. I also don't really find the volume on either list to be particularly high. - cks From rc-owner Wed May 19 13:05:09 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2230>; Wed, 19 May 1993 12:48:18 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA01049; Wed, 19 May 93 09:21:17 -0700 Received: by astro.mv.us.adobe.com; id AA22903; Wed, 19 May 93 09:22:10 -0700 Date: Wed, 19 May 1993 12:22:10 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9305191622.AA22903@astro.mv.us.adobe.com> To: richard@harlequin.co.uk Subject: Re: May I suggest we digestify the rc and es lists? Cc: es@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu as an implementor of one of the two languages (the one that is evolving more these days) having several rounds of correspondence a day is very useful to me. i would hate to see the latency increased that much. perhaps, if someone volunteered to do it, there could be digestified versions of the lists and people could decide to subscribe either the digestified or normal (undigestified) version. i'd also like, by the way, to thank Chris for maintaining the lists as well as the es distribution. they are the only things about es that haven't given me trouble. paul From rc-owner Wed May 19 13:22:28 1993 Received: from uu4.psi.com ([38.146.21.2]) by hawkwind.utcs.toronto.edu with SM TP id <2237>; Wed, 19 May 1993 13:22:02 -0400 Received: from tahiti.UUCP by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUC P; id AA06757 for ; Wed, 19 May 93 12:56:47 -0400 Received: from lilith.eti by evtech.com (4.1/SMI-4.1) id AA17680; Wed, 19 May 93 11:54:23 CDT Date: Wed, 19 May 1993 12:54:23 -0400 From: jbone@evtech.com (Jeff Bone x223) Message-Id: <9305191654.AA17680@evtech.com> To: rc@hawkwind.utcs.toronto.edu, es@hawkwind.utcs.toronto.edu, cks@hawkwind.utcs.toronto.edu Subject: Re: May I suggest we digestify the rc and es lists? IMHO, digests are a pain. Just my $0.02, jb From rc-owner Wed May 19 13:43:44 1993 Received: from epsilon.eecs.nwu.edu ([129.105.5.104]) by hawkwind.utcs.toronto. edu with SMTP id <2230>; Wed, 19 May 1993 13:43:24 -0400 Received: from canaan.eecs.nwu.edu by epsilon.eecs.nwu.edu (4.1/SMI-4.0-proxy) id AA22974; Wed, 19 May 93 12:43:11 CDT From: quanstro@epsilon.eecs.nwu.edu (Erik Quanstrom) Received: by canaan.eecs.nwu.edu (4.1/client-1.5) id AA24302; Wed, 19 May 93 12:39:28 CDT Date: Wed, 19 May 1993 13:39:28 -0400 Message-Id: <9305191739.AA24302@canaan.eecs.nwu.edu> To: Subject: re: lazy auto-loading of functions Apparently-To: rc@hawkwind.utcs.toronto.edu Alan Watson writes: Jealous of Paul Haahr's beautiful implementation of lazy auto-loading of functions in es, I tried to do something similar in rc . . . This is just what you need for those rarely used but sometimes essential functions. I'm just curious. If it's seldom used, then speed shouldn't matter that much. Why not just use a shell script if you are concerned about env bloat? From rc-owner Wed May 19 14:05:47 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2223>; Wed, 19 May 1993 14:05:27 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA08447; Wed, 19 May 1993 13:05:11 -0500 Message-Id: <9305191805.AA08447@oldp.astro.wisc.edu> To: quanstro@epsilon.eecs.nwu.edu (Erik Quanstrom) Subject: Re: lazy auto-loading of functions Cc: rc@hawkwind.utcs.toronto.edu Date: Wed, 19 May 1993 14:05:10 -0400 From: Alan Watson X-Mts: smtp Functions are where it's at. They have two advantages from a programmers point of view over shell scripts: you can use them as front-ends to executables and then use `builtin' to get at the original (John Macklin posted a `pathos' script to the mailing list way back, but using builtin in a function is more elegant) and you can also rid of them with -p, and not have to play tricks with path in sensitive scripts. It's also one fewer fork and exec. I have enough functions that I don't want to keep them all in .rcrc, One of the reasons I hadn't converted more of my scripts to functions was that I was worried things sourcing them all individually would be slow -- now there is no impediment. Alan. From rc-owner Fri May 21 00:39:14 1993 Received: from uwast.astro.wisc.edu ([128.104.39.203]) by hawkwind.utcs.toronto .edu with SMTP id <2223>; Fri, 21 May 1993 00:38:40 -0400 Received: by uwast.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA04004; Thu, 20 May 1993 23:38:24 -0500 Message-Id: <9305210438.AA04004@uwast.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: man Date: Fri, 21 May 1993 00:38:24 -0400 From: Alan Watson X-Mts: smtp The system supplied mans on Ultrix are awful: /usr/ucb/man is very slow, especially across NFS, /usr/bin/man doesn't know about cat files, and neither of them do the right thing with MANPATH. I had been using a hacked version of one of the later Berkeley mans, but it always left a bad taste in my mouth -- finding, formatting, and printing a man page is a perfect job for a shell script, so why was I using a binary? This came to a head when our system manager installed the perl man as the system default. It's about twice as fast as /usr/ucb/man (more so over NFS), and understands MANPATH, but it still isn't exactly a snappy -- it takes about a second to get going on a 5000/200, which is a noticeable delay. So, I set to work with rc, and managed to come up with a function that is between three and four times faster than the perl version -- it gets a man page up in a couple of tenths of a second. The fact that my code is less than a tenth of the size of the perl code gives me a warm feeling inside -- small is beautiful, remember. The single most important contributor to this responsiveness is the fact that, unless we have to format the pages for the first time, there are no execs in the function before you hit the `more' that outputs the man page. (I assume that echo is a built-in.) None of the tricks I used were new -- they've all appeared in the EXAMPLES file, although I'm sure there will have been many independent discoveries of the two most important techniques -- but I don't think I've come across a previous example where avoiding external commands has had such a dramatic and beneficial effect. The fact that built-ins work so efficiently is a testament to the superb quality of Byron's implementation, but none of it would have been possible without Tom Duff's design, that is, do not rescan! Anyway, here's the code. It understands `man -k', $PAGER, $manpath, and sections like `1yp'; it doesn't understand any of the formatting options. Enjoy. Alan. fn apropos { if ( ~ $#* 0 ) { echo >[1=2] 'usage: apropos subject ...' return 1 } manpath = $manpath pager = $PAGER { if ( ~ $#manpath 0 ) manpath = /usr/man if ( ~ $#pager 0 ) pager = ( page -s -u ) subject = () for ( subject in $* ) { { whatis = () for ( whatis in $manpath^'/whatis' ) if ( ~ $whatis `{ echo $whatis^* } ) fgrep $subject $whatis } | sed 's/^\.[A-Z][A-Z]//;s/^[ ]*//' | sort -udf | $pager } } return } fn man { if ( ~ $#* 0 ) { echo >[2=1] 'usage: man [section] subject ...' return 1 } if ( ~ $1 -k ) { shift apropos $* return } @ { # mansearch: look for man pages along $manpath. fn mansearch { name = $1 section = $2 manpages = () dir = () for ( dir in $manpath ) { if ( ~ $#section 0 ) { manpages = $dir^'/man'^[1-8lnop]^'/'^$name^'.'^* } else { manpages = $dir^'/man'^[1-8lnop]^'/'^$name^'.'^$section } if ( ! ~ $manpages *^'[1-8lnop]'^* ) { echo $manpages return 0 } } return 1 } # mantocat: convert /some/dirs/man1/foo.1 to /some/dirs/cat1/foo.1. fn mantocat { manpage = $1 catpage = () sectionnumber = () { ifs = ( / $nl ) { * = `{ echo $manpage } } if ( ~ $manpage /* ) catpage = / catpage = $catpage^$1 shift while ( ! ~ $#* 2 ) { catpage = $catpage^'/'^$1 shift } for ( sectionnumber in 1 2 3 4 5 6 7 8 l n o p ) { if ( ~ $1 'man'^$sectionnumber ) { catpage = $catpage^'/cat'^$sectionnumber break } } shift catpage = $catpage^'/'^$1 echo $catpage } } # manformat: check cat pages exists, and if not then create it. fn manformat { manpage = $1 catpage = $2 catpages = () { catpages = $catpage^* if ( ! ~ $catpage $catpages ) { cd `{ dirname `{ dirname $manpage } } tbl $manpage | nroff -man | col >$catpage } } } # manoutput: output the cat page using $PAGER. fn manoutput { pager = $PAGER { if ( ~ $#pager 0 ) pager = ( page -s -u ) $pager $1 } } _status = 0 manpages = () manpath = $manpath { if ( ~ $#manpath 0 ) manpath = '/usr/man' while ( ! ~ $#* 0 ) { if ( ~ $1 [1-8]* [lnop] ) { if ( ~ $#* 1 ) { echo >[2=1] 'usage: man [section] subject ...' exit 1 } else { manpages = `{ mansearch $2 $1 } shift } } else { manpages = `{ mansearch $1 } } if ( ~ $#manpages 0 ) { echo >[1=2] 'man: cannot find man pages for '^$1 _status = 1 } else { manpage = () catpage = () for ( manpage in $manpages ) { catpage = `{ mantocat $manpage } manformat $manpage $catpage manoutput $catpage } } shift } exit $_status } } } From rc-owner Fri May 21 15:06:12 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2223>; Fri, 21 May 1993 15:05:04 -0400 Return-Path: techfak.uni-bielefeld.de!malte Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2685>; Fri, 21 May 1993 09:24:17 -0400 Received: from idefix.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA27685; Fri, 21 May 1993 15:23: 52 +0200 Received: by idefix.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA27027; Fri, 21 May 93 15:23:50 +0200 Date: Fri, 21 May 1993 09:23:50 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9305211323.AA27027@idefix.techfak.uni-bielefeld.de> To: rc-owner Subject: builtin time Content-Length: 606 Resent-To: rc Resent-Date: Fri, 21 May 1993 15:04:50 -0400 Resent-From: Chris Siebenmann Resent-Message-Id: <93May21.150504edt.2223@hawkwind.utcs.toronto.edu> I hardly dare to ask for it, but what about a "time" builtin ? I'm well aware of the existance of /usr/bin/time or whereever it may reside, but that doesn't allow to measure the time it took a builtin or a function to complete. I came across this when I tried to measure the time it takes for several commands running in parallel, like for( i in *.c ){ cc $i & } ; time wait $apids which, of course, gives only an approximization. The correct way is { for( i in *.c ){ time cc $i & }} | sed -f filter.script measure each cc run independently and sum up the outputs. Any opinions about it ? Malte From rc-owner Fri May 21 15:14:53 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2685>; Fri, 21 May 1993 15:13:08 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA11633; Fri, 21 May 93 12:12:57 -0700 Received: by astro.mv.us.adobe.com; id AA12057; Fri, 21 May 93 12:13:52 -0700 Date: Fri, 21 May 1993 15:13:52 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9305211913.AA12057@astro.mv.us.adobe.com> To: malte@techfak.uni-bielefeld.de Subject: Re: builtin time Cc: rc@hawkwind.utcs.toronto.edu for just this reason (inability to time builtins, in a shell where more things look like builtins), we added time to es. paul From rc-owner Fri May 21 15:19:52 1993 Received: from epsilon.eecs.nwu.edu ([129.105.5.104]) by hawkwind.utcs.toronto. edu with SMTP id <2688>; Fri, 21 May 1993 15:19:35 -0400 Received: from eden.eecs.nwu.edu by epsilon.eecs.nwu.edu (4.1/SMI-4.0-proxy) id AA19527; Fri, 21 May 93 14:19:21 CDT From: quanstro@epsilon.eecs.nwu.edu (Erik Quanstrom) To: Received: by eden.eecs.nwu.edu (4.1/client-1.5) id AA04787; Fri, 21 May 93 14:16:54 CDT Date: Fri, 21 May 1993 15:16:54 -0400 Message-Id: <9305211916.AA04787@eden.eecs.nwu.edu> Apparently-To: From rc-owner Fri May 21 17:15:28 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2689>; Fri, 21 May 1993 17:14:28 -0400 Received: from spool.uu.net (via localhost) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA20508; Fri, 21 May 93 17:14:09 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 171233.25928; Fri, 21 May 1993 17:12:33 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa27257; Fri, 21 May 93 17:04:32 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: builtin time and read and ... Date: Fri, 21 May 1993 17:04:35 -0400 Message-Id: <9305211704.aa19691@ceres.srg.af.mil> The last few months has seen the following "wish-list" items discussed: builtin time (Malte) builtin read (Alan Watson) flag command (David J. Fiander) . searching the path (David J. Fiander) new options to whatis (Chris Siebenmann and me) \ quoting (Malte) comment changes (Malte) ~ expansion (Brendan Kehoe, et al.) list exclusion syntax (Chris Siebenmann and Paul Haahr) This list isn't even close to complete, and some reasonable ideas have been offered, BUT we need to resist the temptation to add "just one more feature" to rc, lest creeping featurism destroy us all. Note that I'm not innocent, having agreed when Chris Siebenmann suggested adding options to builtin whatis. (Maybe we all should join "Creeping Features Anonymous".) There are lots of things that rc doesn't have, job control, cd spell checking, mailbox checking, command hashing, zillions of builtins, ... We need to remember that this was a conscious design decision, and it was exactly that elegant minimalism which attracted many of us to it. Tom From rc-owner Fri May 21 20:44:01 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2223>; Fri, 21 May 1993 20:43:42 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2537>; Fri, 21 May 1993 20:42:04 -0400 To: rc@hawkwind.utcs.toronto.edu Subject: wishlist Date: Fri, 21 May 1993 20:43:06 -0400 From: Scott Schwartz Message-Id: <93May21.204204edt.2537@groucho.cs.psu.edu> My biggest wish: I'd like fn / { echo do stuff } to work. From rc-owner Sat May 22 13:14:43 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2223>; Sat, 22 May 1993 13:13:55 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA03079; Sat, 22 May 1993 12:13:49 -0500 Message-Id: <9305221713.AA03079@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: bug in globber? Date: Sat, 22 May 1993 13:13:49 -0400 From: Alan Watson X-Mts: smtp rc doesn't seem to be able to glob through a directory without having read permission; sh can. ; mkdir foo ; echo foo/../foo* foo/../foo ; chmod u-r foo ; echo foo/../foo* foo/../foo* ; sh $ echo foo/../foo* foo/../foo $ sh5 $ echo foo/../foo* foo/../foo $ This is under Ultrix 4.3, so /bin/sh is a creaky old v7 sh and /bin/sh5 is the SVR2 sh. And, no, the shs aren't running setuid root! Alan. From rc-owner Sat May 22 19:49:37 1993 Received: from Princeton.EDU ([128.112.128.1]) by hawkwind.utcs.toronto.edu wit h SMTP id <2230>; Sat, 22 May 1993 19:48:56 -0400 Received: from phoenix.Princeton.EDU by Princeton.EDU (5.65b/2.96/princeton) id AA11546; Sat, 22 May 93 19:48:42 -0400 Received: by phoenix.princeton.edu (5.65c/1.113) id AA29247; Sat, 22 May 1993 19:46:36 -0400 Date: Sat, 22 May 1993 19:46:36 -0400 From: Emin Gun Sirer Message-Id: <199305222346.AA29247@phoenix.princeton.edu> To: alan@oldp.astro.wisc.edu Subject: Re: bug in globber? Cc: rc@hawkwind.utcs.toronto.edu >rc doesn't seem to be able to glob through a directory without having >read permission; sh can. I think (and Byron can correct me if I'm wrong) this is because rc globs all the elements of a path if there is globbing anywhere within it. That is, given "foo/../foo*" rc will first match "foo" against everything in ".", ".." against everything in foo (for which it needs read permission) and "foo*" against stuff in "foo/..". This was done to keep the implementation simple and rc's globber works correctly, which is a lot more than what one could say about some other shells. If this is not changed, perhaps it should be documented. I believe the comment regarding globbing disappeared some time between 1.2 and 1.4. If someone spends the time to fix this AND NOT BREAK anything else, so much the better. Judging by the comments in 1.4beta (which I am running), there seems to be code to check for metacharacters in each path element and glob only occasionally; however, trace still shows that every directory on the path is read. Gun. P.S. Someone forgot to add the controversy about hash not introducing a comment if it is not preceded by white space (e.g. lpr -#2), my personal pet peeve, to the wish list. From rc-owner Sun May 23 00:31:37 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2230>; Sun, 23 May 1993 00:31:03 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA15343; Sat, 22 May 93 21:30:54 -0700 Received: by astro.mv.us.adobe.com; id AA21172; Sat, 22 May 93 21:31:50 -0700 Date: Sun, 23 May 1993 00:31:50 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9305230431.AA21172@astro.mv.us.adobe.com> To: egsirer@phoenix.Princeton.EDU Subject: Re: bug in globber? Cc: rc@hawkwind.utcs.toronto.edu Gun writes > I think (and Byron can correct me if I'm wrong) this is because rc globs > all the elements of a path if there is globbing anywhere within it. That > is, given "foo/../foo*" rc will first match "foo" against everything in ".", > ".." against everything in foo (for which it needs read permission) and > "foo*" against stuff in "foo/..". and he's right. it's actually a trivial change to make; we changed it when we ported rc's globber to es. i believe that Byron had put it on his list of changes for 1.5, and it's probably a change that should be made for both correctness and performance reasons. paul From rc-owner Sun May 23 16:23:21 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2230>; Sun, 23 May 1993 16:22:29 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA06575; Sun, 23 May 1993 15:22:17 -0500 Message-Id: <9305232022.AA06575@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: FAQ Date: Sun, 23 May 1993 16:22:16 -0400 From: Alan Watson X-Mts: smtp People have mentioned a FAQ list in the past, but nothing came of it. Over the last couple of weeks, I've gone through the mailing list archive and patched together a rough first draft. Coverage is fairly idiosyncratic, and I'm sure I've missed out things that others would consider essential for newcomers to rc. Some of the questions aren't really FAQs, but are IMHO sufficiently useful to a newcomer to rc that they are worthy of inclusion. The list is available by anonymous FTP as pub/rc/FAQ on oldp.astro.wisc.edu. There are five things you can do for me: (a) Tell me what's wrong; (b) Tell me what's missing; (c) Tell me what could be better explained or organized; (d) Tell me what shouldn't be included; (e) Tell me which combinations of machines, OSes, and compilers you have used to successfully compiled rc (and whether any tricks were necessary). We have Decstations, Vaxes, Suns, and Alphas here, but I have only ever bother to compile rc up on my Decstation. If this shapes up, perhaps it would be worth distributing with the sources and to new subscribers to the mailing list. Thanks, Alan. From rc-owner Sun May 23 17:59:14 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2688>; Sun, 23 May 1993 17:58:57 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA06974; Sun, 23 May 1993 16:58:46 -0500 Message-Id: <9305232158.AA06974@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: FAQ Date: Sun, 23 May 1993 17:58:45 -0400 From: Alan Watson X-Mts: smtp I will maintain a file called FAQ.errata in the same directory as the FAQ list. This should save people from reporting the same bugs and typos. To my chagrin, FAQ.errata already contains one typo and one bug. Alan. From rc-owner Mon May 24 11:25:53 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2230>; Mon, 24 May 1993 11:25:26 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27012; Mon, 24 May 93 11:25:13 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 112319.12823; Mon, 24 May 1993 11:23:19 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa17907; Mon, 24 May 93 11:16:03 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu, schwartz@groucho.cs.psu.edu Subject: Re: wishlist Date: Mon, 24 May 1993 11:17:03 -0400 Message-Id: <9305241117.aa09898@ceres.srg.af.mil> WHOA! My earlier message seems to have been misinterpreted. > From: Scott Schwartz ---------------------- > My biggest wish: > > I'd like > fn / { echo do stuff } > to work. > From: Emin Gun Sirer ---------------------- > P.S. Someone forgot to add the controversy about hash not introducing a > comment if it is not preceded by white space (e.g. lpr -#2), my personal > pet peeve, to the wish list. My intent WAS NOT to publish a wish list of things which should be changed in or added to rc. Instead it was to show some of the things that people had asked for and hopefully point out that if we did all these things we would end up with a ugly bloated mess. I was urging restraint rather than soliciting more crazed featurism. In case I'm still not making myself clear, some reasonable ideas have been discussed along with some REALLY bad ones, I don't think most of them belong in rc. It is supposed to be small and simple, IT IS small and simple, LETS KEEP IT THAT WAY! Tom From rc-owner Mon May 24 12:15:43 1993 Received: from epsilon.eecs.nwu.edu ([129.105.5.104]) by hawkwind.utcs.toronto. edu with SMTP id <2688>; Mon, 24 May 1993 12:15:24 -0400 Received: from eden.eecs.nwu.edu by epsilon.eecs.nwu.edu (4.1/SMI-4.0-proxy) id AA16619; Mon, 24 May 93 11:15:14 CDT From: quanstro@epsilon.eecs.nwu.edu (Erik Quanstrom) Received: by eden.eecs.nwu.edu (4.1/client-1.5) id AA28928; Mon, 24 May 93 11:13:56 CDT Date: Mon, 24 May 1993 12:13:56 -0400 Message-Id: <9305241613.AA28928@eden.eecs.nwu.edu> To: Subject: Re: wishlist Apparently-To: rc@hawkwind.utcs.toronto.edu Suppose we considered changes to rc which might promote small & simple. From rc-owner Mon May 24 21:47:39 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2755>; Mon, 24 May 1993 21:47:08 -0400 Return-Path: oldp.astro.wisc.edu!alan Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2755>; Mon, 24 May 1993 21:44:07 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA20975; Mon, 24 May 1993 20:43:44 -0500 Message-Id: <9305250143.AA20975@oldp.astro.wisc.edu> To: rc-owner Subject: Re: wishlist Date: Mon, 24 May 1993 21:43:43 -0400 From: Alan Watson X-Mts: smtp Resent-To: rc Resent-Date: Mon, 24 May 1993 21:46:55 -0400 Resent-From: Chris Siebenmann Resent-Message-Id: <93May24.214708edt.2755@hawkwind.utcs.toronto.edu> So what should go? (a) Here strings: use "echo 'foo' | bar" instead of "bar <<< 'foo'". For more complex cases, like "bar <<<[0]'foo0' <<<[1]'foo1'" use "echo 'foo0' |[1=0] { echo 'foo1' |[1=1] bar }" (b) The flattening operator: use a function instead fn flatten { if ( ~ $#* 0 ) { echo >[2=1] 'usage: flatten list ...' return 1 } list = $1 { shift $list = $1 while ( ! ~ $#* 0 1 ) { shift $list = $list^' '^$1 } } } (c) `` backquote substitution: use ifs = ( foo ) { bar = `{ baz } } (d) newpgrp: use a wrapper around rc. (e) cdpath: do it with a function. From rc-owner Tue May 25 02:55:42 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2230>; Tue, 25 May 1993 02:55:21 -0400 Received: from idefix.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA22229; Tue, 25 May 1993 08:55: 13 +0200 Received: by idefix.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA28604; Tue, 25 May 93 08:55:12 +0200 Date: Tue, 25 May 1993 02:55:12 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9305250655.AA28604@idefix.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: wishlist In-Reply-To: Mail from 'Alan Watson ' dated: Mon, 24 May 1993 21:43:43 -0400 Content-Length: 1679 In response to Alan Watson : (a) Here strings: use "echo 'foo' | bar" instead of "bar <<< 'foo'" For more complex cases, like "bar <<<[0]'foo0' <<<[1]'foo1'" us e "echo 'foo0' |[1=0] { echo 'foo1' |[1=1] bar }" Well, I made this mistake too: echo 'foo' != 'foo' but echo -n 'foo' == 'foo' I think it's too much typing ( see answer to backqoutes ). But I wouldn't bother if here string were removed because I don't use them anyway. (b) The flattening operator: use a function instead rc lists are always flat, so reading your function definition, I assume you mean joining a lists elements into a single element. If this is the case use fn flatten {$1=``(){echo -n $$1}} because your flattening function uses the flattening operator it tries to replace. (c) `` backquote substitution: use Yes, this will surely simplify the parser, but in my experience simplicity is not the ultimate goal. In a real worlds shell you have to watch for conveniencies, too. Whenever I try to persuade people to use rc, after a while they'll complain about too much typing because of oversimplified quoting rules. That's why I asked for backslash escapes. I like the "``" mechanism very much. And besides, what should be The Right Thing to do ; ifs = () { echo $#ifs $ifs } 0 or 1 I mean, should ifs be unset or set to an empty list ? What does it mean if ifs not set ? If set to an empty list, this would be different from every other variable. (d) newpgrp: use a wrapper around rc You'll loose the history list when using readline or editline. And another thing that hasn't been discussed here: What about compatibility with plan 9 rc ? Malte From rc-owner Tue May 25 05:51:51 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2408>; Tue, 25 May 1993 05:51:26 -0400 Received: by mod.civil.su.oz.au id <28714>; Tue, 25 May 1993 19:51:08 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Tue, 25 May 1993 05:16:58 -0400 To: The rc Mailing List Subject: Re: wishlist In-Reply-To: <9305250655.AA28604@idefix.techfak.uni-bielefeld.de> Message-ID: <199305251916.16762.rc.bajob@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ I'm quoting Malte. [...] I wouldn't bother if here string were removed because I don't use them anyway. [He basically supports here strings, though.] The point all the here-string bashers are missing is that here strings are ESSENTIAL. Quite apart from arguments from NCARGS, which will doubtless be shot down on the grounds that ``echo is a builtin'' (not in _my_ rc it isn't!!), the point is that here _documents_ are convenient (I don't hear anyone arguing that here documents should be ditched), and rc needs here strings in order to export functions containing here documents! Yes? Try exporting a function using a here document sometime using a Pike sh. Make sure you have something to vomit into handy. And for the curious, the very last sentence of the Plan 9 rc manual entry is: Functions that use here documents don't work. Is that what you'd rather have? Here strings stay. [Referring to a proposal to ditch ``:] Yes, this will surely simplify the parser, but in my experience simplicity is not the ultimate goal. In a real worlds shell you have to watch for conveniencies, too. This is precisely, 100%, absolutely on-target! We don't want a shell we can prove theorems about. We want a shell that is _nice to use._ Everything should be made as simple as possible, _and no simpler._ Oversimplifying leads to, as Byron once put it very well, a ``Bell Labs pissing contest.'' We don't pursue minimalism for its own sake. We pursue it for _our_ sakes. There are still some of us -- probably everyone on this list -- who believe that software bloat is bad, and that smaller, faster code is better. That doesn't mean that we want to edit text files using "cat >" (I'm typing this in sam :). Whenever I try to persuade people to use rc, after a while they'll complain about too much typing because of oversimplified quoting rules. I don't know who these people are, or what kind of people they are, but if that's how they think I am inclined to think that their opinions are valueless, since they have no taste in software. rc's quoting rules are just about the best thing about the whole damn design, along with the `this is not a macro language, there is no rescanning' paradigm. I have heard many complaints directed at rc since mid-1991 when I first started proselytising about it, but this one (that the quoting rules are too simple) has _never_ been among them. I think you have just shown the shell to some very, very weird people. Let me guess -- they edit with emacs, yes? That's why I asked for backslash escapes. Happily, you didn't and won't get them. With luck, Paul will throw them out of es in the current pruning drive (plug plug :). I like the "``" mechanism very much. So do I. Its convenience certainly justifies its redundancy many times over. It must stay. Why are people looking for features to throw out of rc, anyway? It isn't too big. This whole discussion started with Tom pointing out features that _should not be added_, changes that _shouldn't_ be made. IMNSHO, design-wise, Byron's rc is very, very close to perfect right now. There's no need to look for things to take out. (d) newpgrp: use a wrapper around rc You'll loose the history list when using readline or editline. newpgrp is just an essential builtin in a non-job-control shell that lives in a job-control world. Really. And another thing that hasn't been discussed here: What about compatibility with plan 9 rc ? This is a big, big issue (in my mind, anyway, I don't know how others feel). The way I see it, Byron has improved on Duff's design very substantially. I can't speak to quality of implementation, since I have never read Duff's sources (although I now have legal access to them), but Byron's sources are roughly twice as many characters as Duff's. I don't think that is in any way indicative that Byron's version is twice as complicated, since Byron's rc is a rock-solid, production-quality _portable Unix program_. Duff's rc is a Plan 9 program. Like most Plan 9 native programs, you might even be lucky if you can compile it with a non-Plan 9 compiler, and when it comes to true portability, forget it. Plan 9 programs are not designed or implemented to port to other than Plan 9. Yes, I know the title of Duff's paper. I still claim his rc will definitely NOT compile and work in anything like the variety of environments that Byron's will. Gratuitous back-porting of Plan 9 features into Unix programs _must be avoided_. I don't have time to speak to this in detail now, but the point is, just because something is The Right Thing to do in the Plan 9 environment does NOT make it The Right Thing to do in a Unix/X environment. Plan 9 is nice, but it's Plan 9. Unix is Unix. rc scripts for Unix won't port to Plan 9 anyway, unless they're trivial -- and do you REALLY want to see "if not" instead of "else"? Come off it. Byron has _done the job_. Let him fix these last few tiny rough spots and then _that's it_, OK? Really. Byron's rc is better than Duff's and certainly isn't broken. And we _all_ know what not being broken means when it comes time to think about fixing... OK, John. From rc-owner Tue May 25 09:34:12 1993 Received: from mail.swip.net ([192.71.220.11]) by hawkwind.utcs.toronto.edu wit h SMTP id <2688>; Tue, 25 May 1993 09:33:48 -0400 Received: from analytikerna.se (analytik.analytikerna.se) by mail.swip.net (5.6 5c8-/1.2) id AA11250; Tue, 25 May 1993 15:33:25 +0200 Received: from lynx.analytikerna by analytikerna.se (4.1/SMI-4.1) id AA06322; Tue, 25 May 93 15:33:34 +0200 Date: Tue, 25 May 1993 09:33:34 -0400 From: bk@analytikerna.se (Bengt KLEBERG) Message-Id: <9305251333.AA06322@analytikerna.se> To: rc@hawkwind.utcs.toronto.edu Subject: Simple ' question Greetings, I would like to get this behaviour: sed '1 r filename' otherfile but with a $lineNumber instead of 1. This doesn't work: sed ''''$lineNumber r filename'''' otherfile Suggestions anyone? Bengt From rc-owner Tue May 25 09:46:57 1993 Received: from relay.pipex.net ([158.43.128.1]) by hawkwind.utcs.toronto.edu wi th SMTP id <2704>; Tue, 25 May 1993 09:46:38 -0400 Received: from pipex.net by relay.pipex.net with SMTP (PP) id <06065-0@relay.pipex.net>; Tue, 25 May 1993 14:45:29 +0100 To: bk@analytikerna.se Cc: rc@hawkwind.utcs.toronto.edu From: Tim.Goodwin@pipex.net Subject: Re: Simple ' question Date: Tue, 25 May 1993 09:41:00 -0400 Message-ID: <"relay.pipe.070:25.04.93.13.45.42"@pipex.net> > I would like to get this behaviour: > > sed '1 r filename' otherfile > > but with a $lineNumber instead of 1. How about this? sed $lineNumber^' r filename' otherfile (The caret operator is one of my favourite things about rc, especially when used with lists. There can't be many days go by that I don't say something like cat /tmp/^(foo bar qux) | whatever ) Tim. From rc-owner Tue May 25 09:48:34 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2714>; Tue, 25 May 1993 09:48:18 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA08867; Tue, 25 May 93 09:48:08 -0400 Received: by earth.osf.org (5.65/4.7) id AA13171; Tue, 25 May 93 09:48:07 -0400 Date: Tue, 25 May 1993 09:48:07 -0400 From: rsalz@osf.org Message-Id: <9305251348.AA13171@earth.osf.org> To: bk@analytikerna.se, rc@hawkwind.utcs.toronto.edu Subject: Re: Simple ' question Two quick ways: eval 'sed $linenumber r filename' sed $linenumber ^ ' r filename' From rc-owner Tue May 25 11:00:30 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2729>; Tue, 25 May 1993 11:00:05 -0400 Return-Path: oldp.astro.wisc.edu!alan Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2724>; Tue, 25 May 1993 09:51:43 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA24734; Tue, 25 May 1993 08:51:24 -0500 Message-Id: <9305251351.AA24734@oldp.astro.wisc.edu> To: rc-owner Subject: Re: Simple ' question Date: Tue, 25 May 1993 09:51:24 -0400 From: Alan Watson X-Mts: smtp Resent-To: rc Resent-Date: Tue, 25 May 1993 10:59:58 -0400 Resent-From: Chris Siebenmann Resent-Message-Id: <93May25.110005edt.2729@hawkwind.utcs.toronto.edu> sed $linenumber^' r filename' otherfile You should find this explained in the sections of the manual and Duff's paper where variables and `careting' are discussed. (For non-English speakers, `to caret' is not a real English verb, rather it is one that Duff made up and comes from the name for the `^' character.) From rc-owner Tue May 25 11:22:33 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2724>; Tue, 25 May 1993 11:22:14 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA25152; Tue, 25 May 1993 10:22:07 -0500 Message-Id: <9305251522.AA25152@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Simple ' question Date: Tue, 25 May 1993 11:22:06 -0400 From: Alan Watson X-Mts: smtp > Two quick ways: > eval 'sed $linenumber r filename' I don't think so. > sed $linenumber ^ ' r filename' This works. From rc-owner Tue May 25 12:06:28 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2740>; Tue, 25 May 1993 12:06:07 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA23128; Tue, 25 May 93 09:05:57 -0700 Received: by astro.mv.us.adobe.com; id AA16574; Tue, 25 May 93 09:06:53 -0700 Date: Tue, 25 May 1993 12:06:53 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9305251606.AA16574@astro.mv.us.adobe.com> To: rc@hawkwind.utcs.toronto.edu Subject: Re: login shells ... re SHELL containing 'r' and broken (restricted) Bourne shells: that's funny, /bin/sh on my next machine looks for '\377' rather than 'r'. i wonder how that got there. :-) after all, emacs is useful for some things. From rc-owner Tue May 25 12:07:05 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2733>; Tue, 25 May 1993 12:06:51 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA23132; Tue, 25 May 93 09:06:43 -0700 Received: by astro.mv.us.adobe.com; id AA16589; Tue, 25 May 93 09:07:40 -0700 Date: Tue, 25 May 1993 12:07:40 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9305251607.AA16589@astro.mv.us.adobe.com> To: rc@hawkwind.utcs.toronto.edu Subject: Re: login shells ... but seriously, some mention of the restricted shell brain-damage should probably be in the rc faq. From rc-owner Tue May 25 12:08:14 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2742>; Tue, 25 May 1993 12:08:00 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA23140; Tue, 25 May 93 09:07:48 -0700 Received: by astro.mv.us.adobe.com; id AA16597; Tue, 25 May 93 09:08:44 -0700 Date: Tue, 25 May 1993 12:08:44 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9305251608.AA16597@astro.mv.us.adobe.com> To: rc@hawkwind.utcs.toronto.edu Subject: Re: login shells ... > but seriously, some mention of the restricted shell brain-damage > should probably be in the rc faq. and before anyone yells at me, i just noticed that it's already there. good show, Alan. paul From rc-owner Tue May 25 17:30:28 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2230>; Tue, 25 May 1993 17:29:17 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA29703; Tue, 25 May 1993 16:29:11 -0500 Message-Id: <9305252129.AA29703@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: wishlist Date: Tue, 25 May 1993 17:29:10 -0400 From: Alan Watson X-Mts: smtp John writes: > Why are people looking for features to throw out of rc, anyway? I'm English, so I like whining; an Australian should understand that. > There are still some of us -- probably everyone on this list -- who believe > that software bloat is bad, and that smaller, faster code is better. Yes, but man page bloat is worse. So, let me defend some of my statements: (a) Here strings. If echo is a built-in, here strings are redundant with echo and pipes (more on why I think echo should be a built-in later). Will anyone argue with me that a redundant feature WHICH USERS NEVER USE DIRECTLY should leave the language? The only caveat is if the code to re-write functions in terms of echo and pipes is more likely to be a problem to maintain than the current code, and if Byron feels he has better things to do with his time (and he almost certainly does). (b) `` > Its convenience certainly justifies its redundancy many times > over. It must stay. I will accept an argument of convenience if you calculate the factional occurance of `` in your history file, and if that faction is larger than, say, 0.5%. Typing convenience just doesn't wash in scripts. Two ways to do one thing is bad, bad, bad. Really sinful. We should either junk `` or ifs, and since the later comes handed down from the heavens, the former must go. (c) newpgrp Perhaps I'm speaking from ignorance here, but what about a stand-alone binary along the lines of nice, nohup, et al? If people really want it built-in, then they can hack addon.h. (d) $^foo Oops, Malte shows me up. Same arguments as (b). As I've mentioned in private email to Byron, I'm not going to stop using rc just because these feature remain. But my honest opinion is that if the time Byron had to devote to rc was limitless, they should be purged. I'm sure he has better things to do, though. Now, the big one, why should echo (and read) be built-in? If all a shell does is fork and exec commands, they need not be there. However, I would like to be able to use rc in the same manner as `awk' -- read some data, match on it using ~, mess with it with some external programs, and spit it out the other end. awk is great for some stuff, but it has it's limitations. For example, I want be be able to parse mail folders in rc. To do this efficiently in rc, I need echo and read to be built-in. (This was never done very much in sh because quoting becomes a nightmare.) Perhaps this is misguided, but it seems a modest investment (two primitives, both with historical precedent) for a vast increase in rc's potential. If echo becomes a de jure built-in, rather than remaining de facto, you can still use "fn echo { /bin/echo $* }". From rc-owner Tue May 25 19:14:48 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2704>; Tue, 25 May 1993 19:14:25 -0400 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25746; Tue, 25 May 93 19:14:11 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 191234.23234; Tue, 25 May 1993 19:12:34 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa07685; Tue, 25 May 93 18:41:13 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Differences between Duff's rc and Byron's Date: Tue, 25 May 1993 18:42:17 -0400 Message-Id: <9305251842.aa27768@ceres.srg.af.mil> A while ago it struck me that the man page only covered some of the differences between Duff's Plan 9 version of rc and Bryon's Unix version. So out of curiosity and a desire to understand rc better, I set out to assemble my own list of differences. The following is the best list that I have been able to assemble from Byron's and the Plan 9 man pages, Tom Duff's paper and miscellaneous info from the mailing list. If I've made any mistakes feel free to correct me. Any time there is a comparison below the Plan 9 form occurs first. If you want more detail on any of these please see the original sources listed above. - Command line switches Plan 9 Unix ------ ---- -c -c same -d -d no-op vs. debug enable SIGQUIT/SIGTERM -e -e same -i -i same -I force NON-interactive -l -l same -n -o -p -p no-op vs. disable function import -r debugging info -s -s print non-zero status vs. sh/csh compatibility -v -v same -V ??? -x -x same - builtin break and return Plan 9 doesn't have these but they're awfully handy. - <<< here strings This fixes something noted as a bug in the Plan 9 man page. - builtin flag It might be nice to have this Plan 9 feature. - . searching the path Plan 9 does this, it might be handy but it might also be very dangerous. - whatis -s option Byron added -s to show all the signal handling. - rfork vs. newpgrp (System dependent) Plan 9 has a more capable fork system call than Unix and rfork takes advantage of it. It might be interesting to try to emulate it, but then I've never even needed to use newpgrp. - if not vs. else This seems like an arbitrary difference. Syntactic sugar. - $" vs. $^ This seems like an arbitrary difference. - `{word} vs. `word On very rare occasions this saves me typing two braces, it seems like an arbitrary difference. - $status The difference here seems to make Byron's rc better adapted to Unix. - pattern matching, word vs. list This fixes something noted as a bug in the Plan 9 man page. - fn prompt Plan 9 doesn't have this but it's VERY handy. - builtin echo A concession to performance. - additional variables: history, apids, CDPATH, HOME, PATH Plan 9 may use history and not just not mention it in the man page, apids is a great idea, the rest are for Unix compatibility. - exec of builtins A bug fix IMHO. - `` This one seems like a gratuitous addition to me. - default prompt ('% ' ' ') vs. ('; ' '') Byron's reasons seem to make sense, and you can change it to whatever you want anyway. - startup file $home/lib/profile vs. $home/.rcrc An adaptation to Unix. - environment handling (system dependent) - different signal handlers (system dependent) - . -i (???) Duff's paper mentions this but the man page doesn't. From rc-owner Tue May 25 19:33:13 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2724>; Tue, 25 May 1993 19:32:55 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA02386; Tue, 25 May 1993 18:32:47 -0500 Message-Id: <9305252332.AA02386@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Differences between Duff's rc and Byron's Date: Tue, 25 May 1993 19:32:47 -0400 From: Alan Watson X-Mts: smtp | - . searching the path | | Plan 9 does this, it might be handy but it might also be very | dangerous. And can be simulated by suitably defining "fn . { ... }". Actually, reading the Plan9 man pages was somewhat depressing: two of the things I regard as unnecessary in Byron's rc ($^foo and newpgrp) have made it after a fashion in to Duff's implementation. From rc-owner Tue May 25 20:20:40 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2230>; Tue, 25 May 1993 20:20:26 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14518; Tue, 25 May 93 20:20:18 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 201910.25663; Tue, 25 May 1993 20:19:10 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa09161; Tue, 25 May 93 19:57:54 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Re: wishlist Date: Tue, 25 May 1993 19:58:52 -0400 Message-Id: <9305251958.aa28217@ceres.srg.af.mil> (Damn! How do I manage to get such vigorous "discussions" going?) Re: what to take out (Alan Watson) This was not my intent but I do have a favorite candidate, which never made sense to me: `` which is just syntactic sugar for ifs=(...) {...} Everything else seems like it really belongs. Re: empowering features/simplifications (Erik Quanstrom) I think rc has already done pretty well here, and can't think of any proposed addition that really seems like a big win to me. Possibly read so you can chew up text files (awk is probably a better choice), or flag so you can manipulate the behaviour. Nothing else seems like it gives you the kind of big win that lack of rescanning, variables as lists, clean quoting, or even builtin ~ does. Re: Conformance with Plan 9 rc (John Mackin) John correctly points out that you'll probably never be able to port a Unix rc script to Plan 9 or vice-versa just because the environments are so different, and that Byron has made some major improvements and fixed a number of the bugs listed in the Plan 9 man page. I still think it would be nice to keep the two as close as possible, especially for arbitrary differences like $" vs. $^. This makes the various Plan 9 docs and papers more useful and otherwise broadens our experience base. Tom From rc-owner Tue May 25 23:06:43 1993 Received: from netcomsv.netcom.com ([163.179.1.13]) by hawkwind.utcs.toronto.ed u with SMTP id <2408>; Tue, 25 May 1993 23:06:27 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA09091; Tue, 25 May 93 20:06:19 PDT Received: by netapp.netapp.com (4.1/SMI-4.1) id AA04958; Tue, 25 May 93 20:02:18 PDT Date: Tue, 25 May 1993 23:02:18 -0400 From: netapp!byron@netcom.com (Byron Rakitzis) Message-Id: <9305260302.AA04958@netapp.netapp.com> To: culliton@srg.af.mil, rc@hawkwind.utcs.toronto.edu Subject: Re: wishlist I think it is a little too late to change $^ to $", but maybe that's just me. I know it was a drag for me when I switched from if not to else, and that was when there were just a few rc users. Now I put the install base at 3 figures, possibly 4. I would have to have an extremely good reason to break existing scripts right now. From rc-owner Tue May 25 23:08:59 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2688>; Tue, 25 May 1993 23:08:39 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA05073; Tue, 25 May 1993 22:08:23 -0500 Message-Id: <9305260308.AA05073@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: wishlist Date: Tue, 25 May 1993 23:08:22 -0400 From: Alan Watson X-Mts: smtp So, there I was, walking home after work, muttering under my breath, and mulling over the analogy between rc having to exec to read a line and C having to perform a system call to read a char. I though I had the clincher in this argument. Then it dawned on me -- we can use buffered IO in rc (read many lines with one exec) exactly as we do in C (read many chars with one system call). The interface might be a little tricky, and one would want to be careful of having so much stuff in the environment, but it may well be possible. Therefore, I withdraw my request for a built-in read, withdraw my sugestion that echo should be a de jure built-in, and consequently withdraw my suggestion that herestrings be removed. To celebrate I may even go and compile up rc without echo. Sorry to have wasted your time with this one, Alan. From rc-owner Tue May 25 23:09:00 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2689>; Tue, 25 May 1993 23:08:49 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2591>; Tue, 25 May 1993 23:07:00 -0400 To: netapp!byron@netcom.com (Byron Rakitzis) cc: culliton@srg.srg.af.mil, rc@hawkwind.utcs.toronto.edu Subject: Re: wishlist In-reply-to: Your message of "Tue, 25 May 1993 23:02:18 EDT." <9305260302.AA04958@netapp.netapp.com> Date: Tue, 25 May 1993 23:06:54 -0400 From: Scott Schwartz Message-Id: <93May25.230700edt.2591@groucho.cs.psu.edu> You could add $" without removing $^. From rc-owner Wed May 26 02:58:26 1993 Received: from mail.swip.net ([192.71.220.11]) by hawkwind.utcs.toronto.edu wit h SMTP id <2714>; Wed, 26 May 1993 02:57:58 -0400 Received: from analytikerna.se (analytik.analytikerna.se) by mail.swip.net (5.6 5c8-/1.2) id AA14736; Wed, 26 May 1993 08:57:42 +0200 Received: from lynx.analytikerna by analytikerna.se (4.1/SMI-4.1) id AA14292; Wed, 26 May 93 08:57:52 +0200 Date: Wed, 26 May 1993 02:57:52 -0400 From: bk@analytikerna.se (Bengt KLEBERG) Message-Id: <9305260657.AA14292@analytikerna.se> To: rc@hawkwind.utcs.toronto.edu Subject: Re: wishlist > From rc-owner@hawkwind.utcs.toronto.edu Wed May 26 05:07:39 1993 > Date: Tue, 25 May 1993 23:02:18 -0400 > From: netapp!byron@netcom.com (Byron Rakitzis) > To: culliton@srg.af.mil, rc@hawkwind.utcs.toronto.edu > Subject: Re: wishlist > Content-Length: 329 > > I think it is a little too late to change $^ to $", but maybe that's > just me. I know it was a drag for me when I switched from if not to > else, and that was when there were just a few rc users. Now I put the > install base at 3 figures, possibly 4. I would have to have an extremely > good reason to break existing scripts right now. > The question is perhaps more rightly put as: How many uses $^ ( and would need to change to $" ). I must admit that I don't and therefore I am in favor for getting $" in. It might make me lookup what it is :-) I also think 'if not' was cute and would happily fix the (very) few 'else' that I have if I got it back. Bengt From rc-owner Wed May 26 05:37:49 1993 Received: from holly.harlequin.co.uk ([193.128.4.58]) by hawkwind.utcs.toronto. edu with SMTP id <2230>; Wed, 26 May 1993 05:37:22 -0400 Received: from piaget.harlqn.co.uk (piaget.harlequin.co.uk) by holly.harlequin. co.uk; Wed, 26 May 1993 10:37:44 +0100 Received: from morris.harlqn.co.uk by piaget.harlqn.co.uk; Wed, 26 May 93 10:37 :37 BST From: Richard Brooksby Date: Wed, 26 May 1993 05:34:08 -0400 Message-Id: <24412.9305260934@morris.harlqn.co.uk> To: rc@hawkwind.utcs.toronto.edu In-Reply-To: Bengt KLEBERG's message of Wed, 26 May 1993 02:57:52 -0400 <930526 0657.AA14292@analytikerna.se> Subject: else if not (Re: wishlist) bk@analytikerna.se (Bengt KLEBERG) wrote: > I also think 'if not' was cute and would happily fix the (very) few > 'else' that I have if I got it back. The if/else `problem' has always struck me as really stupid. BCPL and LISP get it right. Just do this: if() {} else {} when() {} Ho hum. --- Richard Brooksby ML Project / Symbolic Processing Division / Harlequin +44 223 872522 From rc-owner Wed May 26 12:54:43 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2688>; Wed, 26 May 1993 12:53:29 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA28028; Wed, 26 May 93 09:53:08 -0700 Received: by astro.mv.us.adobe.com; id AA27788; Wed, 26 May 93 09:53:55 -0700 Date: Wed, 26 May 1993 12:53:55 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9305261653.AA27788@astro.mv.us.adobe.com> To: culliton@srg.af.mil Subject: Re: Differences between Duff's rc and Byron's Cc: rc@hawkwind.utcs.toronto.edu if you look at the unix version (10th edition) of rc rather than the plan 9 version, some of the differences drop away. all of the following are in the bell labs unix version of rc, either exactly or almost identical to the versions in Byron's shell. > - Command line switches > -d -d no-op vs. debug enable SIGQUIT/SIGTERM > -p -p no-op vs. disable function import > - startup file $home/lib/profile vs. $home/.rcrc > - environment handling (system dependent) > - different signal handlers (system dependent) other comments: > - $" vs. $^ > This seems like an arbitrary difference. Byron's $^ preceeded td's $". if you look at older versions of the bell labs rc man page, it's not there. > - pattern matching, word vs. list > This fixes something noted as a bug in the Plan 9 man page. i don't know what you mean by this comment. i don't think Byron's ~ operator is any different from td's. > - additional variables: history, ... > Plan 9 may use history and not just not mention it in the man i think it does. i know it was a later addition to rc. > - . -i (???) > Duff's paper mentions this but the man page doesn't. it's just undocumented, but it's there. of the rest of the differences noted, the only ones which were not upward compatible were > - builtin flag > - if not vs. else > - $status and, of course, > - rfork vs. newpgrp (System dependent) which is not really a shell difference. (and, of course, the v10 version doesn't have rfork.) Tom-- thanks for doing this list. it was very informative to see just what the differences were. i was actually surprised by how few differences there really were. paul From rc-owner Wed May 26 13:52:00 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2720>; Wed, 26 May 1993 13:50:34 -0400 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA12512; Wed, 26 May 93 13:50:12 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 134827.21084; Wed, 26 May 1993 13:48:27 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa04808; Wed, 26 May 93 13:37:18 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: haahr@mv.us.adobe.com Subject: Re: Differences between Duff's rc and Byron's Cc: rc@hawkwind.utcs.toronto.edu Date: Wed, 26 May 1993 13:38:26 -0400 Message-Id: <9305261338.aa04012@ceres.srg.af.mil> Paul Hahr writes: > > - $" vs. $^ > > > This seems like an arbitrary difference. > Byron's $^ preceeded td's $". if you look at older versions of the > bell labs rc man page, it's not there. I seemed to remember something like this and wondered why Duff did it different. > > - pattern matching, word vs. list > > > This fixes something noted as a bug in the Plan 9 man page. > i don't know what you mean by this comment. i don't think Byron's > ~ operator is any different from td's. The Plan 9 man pages say "~ subject pattern ..." where subject is singular (Duff's paper says "a string") and under BUGS the Plan 9 man page says "There should be a way to match patterns against whole lists rather than just single strings." Byron allows subject to be a list. I also forgot one we discussed before, functions that look like path names, i.e. "fn /bin/csh { echo 'you''ve got to be kidding!' }" are allowed in Duff's rc. There are probably more minor differences like this that got missed. Tom From rc-owner Wed May 26 14:13:10 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2704>; Wed, 26 May 1993 14:12:32 -0400 To: rc Subject: Re: wishlist In-reply-to: bk's message of Wed, 26 May 93 02:57:52 -0400. <9305260657.AA14292@analytikerna.se> Date: Wed, 26 May 1993 13:51:34 -0400 From: Chris Siebenmann Message-Id: <93May26.141232edt.2704@hawkwind.utcs.toronto.edu> Let's not break things without an excellent reason. At a minimum, let's support both $^ and $" for one release, so people *don't* have to have a flag day where everything breaks until they fix it. - cks From rc-owner Wed May 26 14:13:36 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2726>; Wed, 26 May 1993 14:13:24 -0400 To: rc Subject: Re: else if not (Re: wishlist) In-reply-to: richard's message of Wed, 26 May 93 05:34:08 -0400. <24412.9305260934@morris.harlqn.co.uk> Date: Wed, 26 May 1993 13:52:48 -0400 From: Chris Siebenmann Message-Id: <93May26.141324edt.2726@hawkwind.utcs.toronto.edu> I believe Tom Duff has said in the past that 'if not' was a gory hack that he was trying hard to get rid of. I consider this a good reason not to introduce it back into Byron's rc. - cks From rc-owner Wed May 26 14:13:49 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2729>; Wed, 26 May 1993 14:13:34 -0400 To: rc Subject: Re: Differences between Duff's rc and Byron's In-reply-to: haahr's message of Wed, 26 May 93 12:53:55 -0400. <9305261653.AA27788@astro.mv.us.adobe.com> Date: Wed, 26 May 1993 13:55:28 -0400 From: Chris Siebenmann Message-Id: <93May26.141334edt.2729@hawkwind.utcs.toronto.edu> Tom Duff's rc has history, done via a file named in $history. It's not documented, but it's there. Ditto '. -i '. A number of things in Duff's rc aren't documented in the manpage, just in the C source and/or rcmain. - cks From rc-owner Wed May 26 14:24:56 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2735>; Wed, 26 May 1993 14:24:42 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25170; Wed, 26 May 93 14:24:31 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 142213.1547; Wed, 26 May 1993 14:22:13 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa05127; Wed, 26 May 93 13:48:17 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: alan@oldp.astro.wisc.edu Subject: Re: wishlist Cc: rc@hawkwind.utcs.toronto.edu Date: Wed, 26 May 1993 13:49:25 -0400 Message-Id: <9305261349.aa04090@ceres.srg.af.mil> > You can't use sed, as you don't know how much it buffers stuff up internally. > Same with awk. > > You cannot use ifs = $nl { foo = `{ cat } }, as you lose blank lines > and cannot tell if the final line ends in a $nl or not. I had enough > of that kind of stuff You're absolutely right. My first draft actually started out saying that sed wouldn't work for pipes because you couldn't rescan the input and provided an external command called "lines" (a generalization of "line"). Unfortunately when I came back from lunch the reason for this had slipped my mind, so it got cut. (How embarassing!) All the more reason to add read. Tom From rc-owner Wed May 26 14:25:39 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2745>; Wed, 26 May 1993 14:25:23 -0400 Received: from earth.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA21392; Wed, 26 May 93 14:25:06 -0400 Received: by earth.osf.org (5.65/4.7) id AA17370; Wed, 26 May 93 14:25:05 -0400 Date: Wed, 26 May 1993 14:25:05 -0400 From: rsalz@osf.org Message-Id: <9305261825.AA17370@earth.osf.org> To: friedman@gnu.ai.mit.edu Subject: Re: heirarchical lists, one more time. Cc: rc@hawkwind.utcs.toronto.edu > You could decide never to improve any program once it's written, I guess, > but I think that would also be an unfortunate choice. Yeah, well - That's why you get source - That's why you have alpha and beta tests - Byron and Paul have been VERY good about announcing UI freeze dates From rc-owner Wed May 26 14:32:40 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2704>; Wed, 26 May 1993 14:32:06 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA07893; Wed, 26 May 1993 12:29:13 -0500 Message-Id: <9305261729.AA07893@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: wishlist Date: Wed, 26 May 1993 13:29:13 -0400 From: Alan Watson X-Mts: smtp I didn't intend to cc that last message to the list. The C code is awfully embarrassing. From rc-owner Wed May 26 14:33:04 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2706>; Wed, 26 May 1993 14:32:49 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA07844; Wed, 26 May 1993 12:26:57 -0500 Message-Id: <9305261726.AA07844@oldp.astro.wisc.edu> To: culliton@srg.srg.af.mil (Tom Culliton x2278) Subject: Re: wishlist Cc: rc@hawkwind.utcs.toronto.edu Date: Wed, 26 May 1993 13:26:56 -0400 From: Alan Watson X-Mts: smtp You can't use sed, as you don't know how much it buffers stuff up internally. Same with awk. You cannot use ifs = $nl { foo = `{ cat } }, as you lose blank lines and cannot tell if the final line ends in a $nl or not. I had enough of that kind of stuff I coded this up in about 10 minutes last night -- it works as a technology demonstrator, but (a) the C code needs re-writing to read N chars first and then one char at a time until the end of the line, and (b) it all needs some better error checking. bufread reads a line at a time into the variable, including any trailing newline, and sets the variable to () at EOF. Hope this helps you get a start, Alan. fn copy { @ { exec <$1 >$2 while ( bufread line ibuf && ! ~ $#line 0 ) bufwrite line obuf bufflush obuf } } fn bufread { _var = $1 _buf = $2 { if ( ~ $#$_buf 0 ) { ifs = () { eval '*' '=' `{ ./buffill } } } else { * = $$_buf } $_var = $1 if ( ! ~ $#* 0 ) shift $_buf = $* } } fn bufwrite { _var = $1 _buf = $2 { if ( ~ $#$_buf 4 ) { bufflush $_buf $_buf = () } $_buf = ( $$_buf $$_var ) } } fn bufflush { _buf = $1 _text = () { * = $$_buf while ( ! ~ $#* 0 ) { _text = $text^$1 shift } echo -n $text } } buffill.c: #include #define N 256 #define writestr(fd,s) (write ((fd),(s), sizeof (s) - 1)) int main () { char c; char lastc; int n; writestr (1, "( "); n = 0; while (n < N || c != '\n') { if (read (0, &c, 1) != 1) break; if (n == 0 || lastc == '\n') writestr (1, "'"); if (c == '\'') writestr (1, "''"); else if (c == '\n') writestr (1, "\n' "); else write (1, &c, 1); lastc = c; n++; } if (n != 0 && c != '\n') writestr (1, "' "); writestr (1, ")"); return 0; } From rc-owner Wed May 26 14:52:20 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2230>; Wed, 26 May 1993 14:52:02 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA01697; Wed, 26 May 93 13:16:14 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 131528.29605; Wed, 26 May 1993 13:15:28 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa03809; Wed, 26 May 93 12:58:33 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: alan@oldp.astro.wisc.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: wishlist Date: Wed, 26 May 1993 12:59:40 -0400 Message-Id: <9305261259.aa03721@ceres.srg.af.mil> Alan finds a reason why he doesn't need read: > So, there I was, walking home after work, muttering under my breath, > and mulling over the analogy between rc having to exec to read a line > and C having to perform a system call to read a char. I though I had > the clincher in this argument. Then it dawned on me -- we can use > buffered IO in rc (read many lines with one exec) exactly as we do in C > (read many chars with one system call). Strangely enough it was thoughts along this line that that convinced me that read might be a good idea! My first thought was that if execing for each line was too slow why not just do something like this: buf = ``($nl) { cat } And then just step through the list in any of the usual ways. Of course the problem is that even rc may not be able to stuff the whole file into the environment, other programs could choke big time, and it would slow down forking. The next step is to get clever and use sed to grab chunks: eof=() buf = ``($nl) { sed 20q } if (~ $#buf 0) eof = 1; Of course this is also going to bloat the environment, albeit to a lesser extent, with the buffer, code to fetch from the buffer and transparently refill it when it empties, not to mention code to reset the buffer, etc. (I may write this up and post it later.) In shell scripts read is used for two different purposes, getting one line from a user, or chewing through a theoretically infinite input stream one line at a time. In the first case efficiency is usually not a concern, but in the second case it obviously is. The fact that the same generalized facility would serve both cases well, and that these are fairly common things to do, seem like a good argument for adding read. (or something like it) Tom From rc-owner Wed May 26 15:05:45 1993 Received: from albert.gnu.ai.mit.edu ([128.52.46.31]) by hawkwind.utcs.toronto. edu with SMTP id <2237>; Wed, 26 May 1993 15:05:29 -0400 Received: from trinity.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP id ; Wed, 26 May 93 15:05:06 -0400 Received: by trinity.gnu.ai.mit.edu (5.67/4.0) id ; Wed, 26 May 93 15:04:46 -0400 From: mycroft@gnu.ai.mit.edu Message-Id: <9305261904.AA01031@trinity.gnu.ai.mit.edu> Subject: Re: wishlist To: bk@analytikerna.se (Bengt KLEBERG) Date: Wed, 26 May 1993 15:04:40 -0400 Cc: rc@hawkwind.utcs.toronto.edu In-Reply-To: <9305260657.AA14292@analytikerna.se> from "Bengt KLEBERG" at May 2 6, 93 02:57:38 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 180 > The question is perhaps more rightly put as: How many uses $^ ( and > would need to change to $" ). I think nearly every rc script I've ever written has a $^ in it somewhere. From rc-owner Wed May 26 15:13:53 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2230>; Wed, 26 May 1993 15:13:32 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA28098; Wed, 26 May 93 10:05:43 -0700 Received: by astro.mv.us.adobe.com; id AA29590; Wed, 26 May 93 10:06:40 -0700 Date: Wed, 26 May 1993 13:06:40 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9305261706.AA29590@astro.mv.us.adobe.com> To: alan@oldp.astro.wisc.edu Subject: Re: Differences between Duff's rc and Byron's Cc: rc@hawkwind.utcs.toronto.edu > Actually, reading the Plan9 man pages was somewhat depressing: two of > the things I regard as unnecessary in Byron's rc ($^foo and newpgrp) > have made it after a fashion in to Duff's implementation. $^ is most definitely necessary. ok, you can simulate the operation with: fn flatten { var = $1 shift if (~$#* 0) { $var = '' return } $var = $1 shift for (i = $*) { $var = $$var ^ ' ' ^ $i } } and use flatten x $foo for x = $^foo but the operation itself is fundamental. the concatenation semantics just about require it. (eval, for example, does flattening internally.) newpgrp on the other hand is a hack. it's there because otherwise rc would be much less usable on some (admittedly broken) systems. paul From rc-owner Wed May 26 15:14:12 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2237>; Wed, 26 May 1993 15:14:00 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA28192; Wed, 26 May 93 10:23:54 -0700 Received: by astro.mv.us.adobe.com; id AA01005; Wed, 26 May 93 10:24:51 -0700 Date: Wed, 26 May 1993 13:24:51 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9305261724.AA01005@astro.mv.us.adobe.com> To: richard@harlequin.co.uk Subject: Re: else if not (Re: wishlist) Cc: rc@hawkwind.utcs.toronto.edu > The if/else `problem' has always struck me as really stupid. the only if/else problem in rc is that it's not compatible with td's rc. the reason is that if not semantics are awful, as is acknowledged in the rc paper. Byron introduced this one change because he thought it was an improvement worth being incompatible with the plan 9 version. i agree with him; the last time we hashed this out on the list it seemed that was the consensus. > BCPL and > LISP get it right. that's a matter of opinion. Byron and i picked scheme's cond semantics for es, because we thought that was right. paul From rc-owner Wed May 26 15:14:26 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2408>; Wed, 26 May 1993 15:14:10 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA28400; Wed, 26 May 93 10:57:41 -0700 Received: by astro.mv.us.adobe.com; id AA03677; Wed, 26 May 93 10:58:36 -0700 Date: Wed, 26 May 1993 13:58:36 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9305261758.AA03677@astro.mv.us.adobe.com> To: culliton@srg.af.mil Subject: Re: Differences between Duff's rc and Byron's Cc: rc@hawkwind.utcs.toronto.edu > The Plan 9 man pages say "~ subject pattern ..." where subject is > singular (Duff's paper says "a string") and under BUGS the Plan 9 man > page says "There should be a way to match patterns against whole lists > rather than just single strings." Byron allows subject to be a list. oh, i think i misinterpreted this comment. i had always thought it to mean that Duff wanted a way to match lists against lists. (in both rcs, ~ (a b) (b a) and ~ (a b) (a c) return true; my interpretation of Duff's comment was that he wanted something that would return false for both, since the lists are not identical.) my understanding was that Byron's and Duff's versions had exactly the same semantics for ~. can someone verify this? paul From rc-owner Wed May 26 15:26:03 1993 Received: from albert.gnu.ai.mit.edu ([128.52.46.31]) by hawkwind.utcs.toronto. edu with SMTP id <2230>; Wed, 26 May 1993 15:25:23 -0400 Received: from nutrimat.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP id ; Wed, 26 May 93 15:25:03 -0400 Received: by nutrimat.gnu.ai.mit.edu (15.11/4.0) id ; Wed, 26 May 93 15:25:00 edt Message-Id: <9305261925.AA00414@nutrimat.gnu.ai.mit.edu> From: friedman@gnu.ai.mit.edu (Noah Friedman) Sender: friedman@gnu.ai.mit.edu To: rsalz@osf.org Cc: rc@hawkwind.utcs.toronto.edu, es@hawkwind.utcs.toronto.edu Subject: Re: heirarchical lists, one more time. Reply-To: friedman@gnu.ai.mit.edu In-Reply-To: <9305261825.AA17370@earth.osf.org> (rsalz@osf.org) Date: Wed, 26 May 1993 16:24:58 -0400 >> You could decide never to improve any program once it's written, I guess, >> but I think that would also be an unfortunate choice. > >Yeah, well > - That's why you get source > - That's why you have alpha and beta tests > - Byron and Paul have been VERY good about announcing UI freeze dates I could fix the problem for myself, but I don't think distributing Noah's Own Version of rc will really help solve the general problem. Having N different flavors of the same shell is as bad as having N different flavors of unix. It has the baggage problem I spoke of. Alpha and beta tests don't seem to matter in this case. It was a documented "feature" that no one bothered to fix right the first time. Well, I don't think documenting arbitrary limitations in a program is an acceptable way of handling the problem. The GNU utilities could have compromised by having fixed buffer and line length limits just like most standard unix utilities do only making them larger. But that would have just put off the problem a little longer, and still failed to come through for someone's special case. That is at least one reason why people are using abominations like perl: Larry was very careful not to leave stupid arbitrary limitations in it. Of course, one can criticize that GNU programs are consequently larger and consume more resources, but I don't think this is a serious concern for rc and es because fixing them would consume a negligable amount of resources (namely, a couple more cycles and a few more bytes in the environment for a pathological case). I don't see what the UI has to do with fixing a quoting bug in the environment that you propagate. Who actually uses the particular implementation of array propagation to any particular advantage? I thought this was supposed to be transparent. Let's ask the rc/es user community: Do any of you actually *rely* on the ^A bug? Or do you just figure it'll never hit you? I have enough experience to know that it will hit *me* someday, because I abuse shells and find lots of bugs all the time. I am not suggesting this has to be fixed right this instance with a new release tomorrow, but I am reminding everyone that these problems will be harder to fix later. Since both rc and es are relatively new to the unix world and have comparatively small usage (compared with, say, csh), maintaining interoperability between them is not too painful. It seems like the best thing to do would be to coordinate a future date at which a version of rc and es would both be released simultaneously with this bug fix. From rc-owner Wed May 26 16:33:10 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2408>; Wed, 26 May 1993 16:31:34 -0400 To: rc Subject: Re: Differences between Duff's rc and Byron's In-reply-to: haahr's message of Wed, 26 May 93 13:58:36 -0400. <9305261758.AA03677@astro.mv.us.adobe.com> Date: Wed, 26 May 1993 16:31:25 -0400 From: Chris Siebenmann Message-Id: <93May26.163134edt.2408@hawkwind.utcs.toronto.edu> ~ (a b c) a in Duff's rc fails, while it succeeds in Byron's. - cks From rc-owner Wed May 26 16:34:30 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2237>; Wed, 26 May 1993 16:33:14 -0400 To: rc Subject: Re: Differences between Duff's rc and Byron's In-reply-to: haahr's message of Wed, 26 May 93 13:58:36 -0400. <9305261758.AA03677@astro.mv.us.adobe.com> Date: Wed, 26 May 1993 16:32:10 -0400 From: Chris Siebenmann Message-Id: <93May26.163314edt.2237@hawkwind.utcs.toronto.edu> (an addendum: it fails in a somewhat old version of Duff's rc. It may be different in current ones; someone with access to a Plan 9 system will have to be the one to check.) - cks From rc-owner Wed May 26 19:05:49 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2733>; Wed, 26 May 1993 19:04:29 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA13756; Wed, 26 May 1993 18:04:14 -0500 Message-Id: <9305262304.AA13756@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: execve bug on Ultrix 4.3 Date: Wed, 26 May 1993 19:04:14 -0400 From: Alan Watson X-Mts: smtp Kernel #! interpretation fails on Ultrix 4.3 if the first line of the script (including the #!, the trailing newline, and any trailing white space) is longer than 32 characters. Compiling up with execve.c seems to solve the problem, or at least delay it until the line is 256 characters long. Why, oh, why is this allowed to happen in the 1990s? Sorry, I forgot: all versions of Unix come with /dev/timemachine to take the user back to the 1970s. From rc-owner Wed May 26 20:44:36 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2726>; Wed, 26 May 1993 20:44:22 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA17386; Wed, 26 May 1993 19:44:15 -0500 Message-Id: <9305270044.AA17386@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: bug in ~ ? Date: Wed, 26 May 1993 20:44:15 -0400 From: Alan Watson X-Mts: smtp ; foo=() ; ~ $foo () bar && echo yes [a] ; ~ $foo () && echo yes [b] yes ; ~ () () && echo yes [c] yes ; foo=foo ; ~ $foo foo bar && echo yes [d] yes Question: why doesn't [a] echo yes? This is what I think is going on: rc normally takes the arguments to a command and makes them into a list, in the process of which any null lists are eliminated. While this the behaviour one normally wants, it doesn't seem right here. rc doesn't seem to amalgamate the first argument of ~ with the rest (from my reading of the grammar), so it is already a special case. From rc-owner Thu May 27 00:56:32 1993 Received: from netcomsv.netcom.com ([163.179.1.13]) by hawkwind.utcs.toronto.ed u with SMTP id <2685>; Thu, 27 May 1993 00:55:01 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA10646; Wed, 26 May 93 21:54:49 PDT Received: by netapp.netapp.com (4.1/SMI-4.1) id AA05584; Wed, 26 May 93 21:53:58 PDT Date: Thu, 27 May 1993 00:53:58 -0400 From: netapp!byron@netcom.com (Byron Rakitzis) Message-Id: <9305270453.AA05584@netapp.netapp.com> To: alan@oldp.astro.wisc.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: bug in ~ ? There are no heirarchical lists in rc. Therefore you can't embed the null list in an argument list to anything. ~ takes just two lists as arguments. Maybe this will make things clearer: ~ foo (foo bar) (FOO BAR) reduces to ~ (foo) (foo bar FOO BAR) and evaluates to true. The arguments to ~ don't enjoy any special property that you might imagine. They are just a word list. From rc-owner Thu May 27 01:03:56 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2689>; Thu, 27 May 1993 01:02:30 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA19690; Thu, 27 May 1993 00:02:11 -0500 Message-Id: <9305270502.AA19690@oldp.astro.wisc.edu> To: haahr@mv.us.adobe.com (Paul Haahr) Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: Differences between Duff's rc and Byron's Date: Thu, 27 May 1993 01:02:11 -0400 From: Alan Watson X-Mts: smtp > $^ is most definitely necessary. ok, you can simulate the operation with: > > ... > > but the operation itself is fundamental. the concatenation semantics just > about require it. (eval, for example, does flattening internally.) Sure, and the ability to malloc is fundamental, but that doesn't mean the user should be able to do it. You are confusing an internal implementation detail with an externally visible feature. The user need never type $^foo, although obviously rc needs to know what to do with $foo^' '^$bar. The only excuses for $^foo are typing convenience and speed, and I very much doubt the later is especially noticeable. > newpgrp on the other hand is a hack. it's there because otherwise rc > would be much less usable on some (admittedly broken) systems. Educate me: why can't you use the nice, nohup, et al. approach? I don't understand enough of why it's there in the first place to decide for myself. Where do you use it -- once per login-shell, or continually through a session, or what? And, hey, the test command on Ultrix is broken, and rc would be much more useable if it were built-in. :-) From rc-owner Thu May 27 01:32:51 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2706>; Thu, 27 May 1993 01:31:35 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA19953; Thu, 27 May 1993 00:31:30 -0500 Message-Id: <9305270531.AA19953@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: umask Date: Thu, 27 May 1993 01:31:30 -0400 From: Alan Watson X-Mts: smtp What a day. Is there a reason why rc barfs on a umask greater than 0777? I have just modifed one of my scripts to protect a temporary file by doing: umask = `{ umask } umask 077 ... umask $umask and it now doesn't work properly if I use an escape from vi inside MH, as MH sets umask to 7177 (quite why I don't know). sh and sh5 seem to perform a umask (value & 0777), csh and bash give an error message if the value is > 0777, but ksh goes ahead and does it. From rc-owner Thu May 27 02:48:13 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2720>; Thu, 27 May 1993 02:46:36 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA01408; Wed, 26 May 93 23:46:26 -0700 Received: by astro.mv.us.adobe.com; id AA05247; Wed, 26 May 93 23:47:23 -0700 Date: Thu, 27 May 1993 02:47:23 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9305270647.AA05247@astro.mv.us.adobe.com> To: alan@oldp.astro.wisc.edu Subject: Re: umask Cc: es@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu > Is there a reason why rc barfs on a umask greater than > 0777? probably because we never thought anyone would want one higher than that and nobody complained before. changed (i wouldn't really call it fixed) in es-0.9 paul From rc-owner Thu May 27 02:49:42 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2726>; Thu, 27 May 1993 02:48:20 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA01412; Wed, 26 May 93 23:47:36 -0700 Received: by astro.mv.us.adobe.com; id AA05256; Wed, 26 May 93 23:48:33 -0700 Date: Thu, 27 May 1993 02:48:33 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9305270648.AA05256@astro.mv.us.adobe.com> To: alan@oldp.astro.wisc.edu Subject: Re: Differences between Duff's rc and Byron's Cc: rc@hawkwind.utcs.toronto.edu > The user > need never type $^foo, although obviously rc needs to know what to do > with $foo^' '^$bar. why? all of rc's concatenation can be written in terms of loops. there's nothing magic about them (unlike ~ which can't be written as a function, due to the fact that one of its arguments isn't globbed). they are purely there for convenience, too. > The only excuses for $^foo are typing convenience and speed, and I very > much doubt the later is especially noticeable. > > newpgrp on the other hand is a hack. it's there because otherwise rc > > would be much less usable on some (admittedly broken) systems. > Educate me: why can't you use the nice, nohup, et al. approach? i did something like this for a while. $SHELL was a wrapper which did the newpgrp, set SHELL to rc, and exec'ed rc. worked, until i needed $SHELL in that context not to create a new pgrp for some other purpose. from my perspective, a processes' pgrp is similar to its signals, limits, etc. the shell manages those, so its not unreasonable for it to manage the pgrp if it manages those other things. > I > don't understand enough of why it's there in the first place to decide > for myself. Where do you use it -- once per login-shell, or > continually through a session, or what? once per window, in my fn prompt. if not, control-c in one window sends sigint to all the terminal windows. the vendor never noticed this since they assumed that all shells were like csh and did their own pgrp manipulation. > And, hey, the test command on Ultrix is broken, and rc would be much > more useable if it were built-in. :-) supply your own /usr/local/bin/test, if you really like test's semantics. or supply something better. paul From rc-owner Sat May 29 08:19:44 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2699>; Sat, 29 May 1993 08:18:36 -0400 Received: by mod.civil.su.oz.au id <28692>; Sat, 29 May 1993 22:18:13 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Sat, 29 May 1993 08:16:29 -0400 To: The rc Mailing List Subject: Alan's FAQ Message-ID: <199305292216.19310.rc.bajuy@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ I'd just like to give Alan a `Well done!' for his work on the FAQ list. Can anyone arrange an automatic monthly posting to comp.unix.shell? I think that would be a great idea. I have a number of suggestions for it which I'll just mail to Alan. OK, John. From rc-owner Sat May 29 08:41:59 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2706>; Sat, 29 May 1993 08:41:39 -0400 Received: by mod.civil.su.oz.au id <28692>; Sat, 29 May 1993 22:41:18 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Sat, 29 May 1993 08:34:45 -0400 To: The rc Mailing List Subject: Re: Differences between Duff's rc and Byron's In-Reply-To: <93May26.141334edt.2729@hawkwind.utcs.toronto.edu> Message-ID: <199305292234.19589.rc.bakad@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Chris wrote: Tom Duff's rc has history, done via a file named in $history. It's not documented, but it's there. I assume the basis for this statement is the set of early Duff sources that Chris has. I heard a rumour from the Plan 9 crowd over at Basser that $history had actually been _removed_ from rc since no one on Plan 9 used it; it seemed they found the 8 1/2 window program provided all the history they could want. I just this minute checked this -- I have no access to earlier Plan 9 sources, just the second (current) distribution, but I am certain that Chris's statement used to be correct, i.e. Duff's rc used to have $history. But as I said, I just now looked, and the rumour is true -- the one in the current Plan 9 CD doesn't have $history at all. To forestall possible misinterpretation, this is NOT a suggestion that $history should be removed from Byron's rc. `Just the facts.' OK, John. From rc-owner Sun May 30 19:08:33 1993 Received: from chalmers.se ([129.16.1.1]) by hawkwind.utcs.toronto.edu with SMT P id <2237>; Sun, 30 May 1993 19:08:03 -0400 Received: from hackes.dtek.chalmers.se by chalmers.se (5.60+IDA/3.14+gl) id AA0 9412; Mon, 31 May 93 01:07:48 +0200 Date: Sun, 30 May 1993 19:07:47 -0400 From: Magnus Homann Message-Id: <9305302307.AA11342@hackes.dtek.chalmers.se> Received: from hacke2.dtek.chalmers.se by hackes.dtek.chalmers.se (5.59+IDA+CTH /3.14+gl) id AA11342; Mon, 31 May 93 01:07:47 +0200 Received: by hacke2.dtek.chalmers.se (5.59+IDA+CTH/3.14+gl) id AA04169; Mon, 31 May 93 01:06:03 +0200 To: rc@hawkwind.utcs.toronto.edu Subject: rc and Emacs 19.10 The new emacs doesn't work very well with rc. If you use it in vt100-mode, it just hangs when you press any key. It(emacs) repeatedly tries to read() stdin, but read() returns "I/O error". This happens in a signalhandler called on SIGIO. The same goes for sh. Tcsh and csh on the other hand, manage emacs without problems. I think it's related to the different ways the shell spawn children. Unfortunately I don't know where to start looking. Is there anyone who might have a clue? I tried rc and then emacs from gdb, and then it worked!!! I'm sorry I don't tell you all the details, but that's because I don't understand what's happening :-) BTW, I'm on SunOS 4.1.3... Homann -- Magnus Homann "Just once, I want to hear you scream in pain." d0asta@dtek.chalmers.se "Play some Rap Music." -- The Last Boyscout From rc-owner Sun May 30 22:57:06 1993 Received: from cserve.cs.adfa.oz.au ([131.236.20.1]) by hawkwind.utcs.toronto.e du with SMTP id <2408>; Sun, 30 May 1993 22:56:40 -0400 Received: by cserve.cs.adfa.oz.au (4.1/1.34) id AA05064; Mon, 31 May 93 12:56:09 EST Newsgroups: adfa.rc Path: cjsv_sun.cs.adfa.oz.au!sserve!not-for-mail From: Christopher.Vance@adfa.oz.au (CJS Vance) To: Subject: Re: Alan's FAQ Message-Id: <1993May31.015033.26426@sserve.cc.adfa.oz.au> Originator: cjsv@ccadfa.cc.adfa.oz.au Sender: news@sserve.cc.adfa.oz.au Organization: University College, ADFA Canberra, Australia References: <199305292216.19310.rc.bajuy@civil.su.oz.au> Date: Sun, 30 May 1993 21:50:33 -0400 Apparently-To: rc@hawkwind.utcs.toronto.edu Apparently-To: cjsv In article <199305292216.19310.rc.bajuy@civil.su.oz.au> John (Most modern compu ters would break if you stood on them) Mackin writes: | I'd just like to give Alan a `Well done!' for his work on the FAQ list. Seconded. | Can anyone arrange an automatic monthly posting to comp.unix.shell? I | think that would be a great idea. I have a number of suggestions for it | which I'll just mail to Alan. I guess I could do this. -- Christopher From rc-owner Mon May 31 08:34:56 1993 Received: from x400gate.bnr.ca ([192.58.194.73]) by hawkwind.utcs.toronto.edu w ith SMTP id <2679>; Mon, 31 May 1993 08:34:22 -0400 X400-Received: by mta x400gate.bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 3 1 May 1993 08:32:45 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 31 May 1993 08:18:05 -04 00 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Sun, 30 May 1993 15:42:00 -04 00 Date: Sun, 30 May 1993 15:42:00 -0400 X400-Originator: /DD.ID=1619692/G=Hamish/I=HI/S=Macdonald/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.804:31.04.93.12.18.05] X400-Content-Type: P2-1984 (2) Content-Identifier: re:rc and Ema... From: "Hamish (H.I.) Macdonald" Sender: "Hamish (H.I.) Macdonald" Message-ID: <"22559 Mon May 31 08:18:53 1993"@bnr.ca> To: d0asta@dtek.chalmers.se Cc: rc@hawkwind.utcs.toronto.edu Subject: re:rc and Emacs 19.10 >>>>> On Sun May 30 19:10:00 1993, >>>>> d0asta@dtek.chalmers.se wrote: Magnus> The new emacs doesn't work very well with rc. If you use it in Magnus> vt100-mode, it just hangs when you press any key. It(emacs) repeatedly Magnus> tries to read() stdin, but read() returns "I/O error". Magnus> BTW, I'm on SunOS 4.1.3... I think this is more of a "non-job control shell on a particular version of Unix" problem. e.g. I have no problems starting emacs 19 from rc on HPUX 8.0. Other people have reported problems with starting emacs from "sh" as well. No problems on HPUX 8.0. Of course, HPUX 8.0 has it's own problems. "signal-process" doesn't appear to work for a process running under a pty. From rc-owner Thu Jun 3 07:19:11 1993 Received: from boeygen.nr.no ([156.116.1.2]) by hawkwind.utcs.toronto.edu with SMTP id <2408>; Thu, 3 Jun 1993 07:17:52 -0400 Received: from nr.no by boeygen.nr.no with SMTP (PP) id <05500-0@boeygen.nr.no> ; Thu, 3 Jun 1993 13:17:20 +0200 To: rc@hawkwind.utcs.toronto.edu Subject: pattern matching Date: Thu, 3 Jun 1993 07:17:17 -0400 From: Brynjulv Hauksson Message-ID: <"boeygen.nr.513:03.05.93.11.17.27"@nr.no> rc has been my login shell for about a year, and I don't understand how I managed so long using csh. I've read most of the discussions on this list about things users want added (and sometimes removed). I've had my own ideas about this from time to time, and forgotten most of them. There is however one idea I can't quite get rid of, and which I don't think has been mentioned on the list. (I'm not sure if the following qualifies as a serious wish for an rc extension, take it as a suggestion of a possible feature in some future shell if you wish). I think the builtin ~ is very useful, but there are times when I wish it would do more: leave a record somewhere of *what* and *how* the match succeded. This "record" should be a list, with one element for each meta-character or simple string segment that matched, in the order they occurred in the "subject". Example: subject pattern record -Php4 -?* ('-' 'P' 'hp4') I sometimes find myself doing things like: ~ $s pattern && var = `{echo $s | sed 'sed pattern'} This is a bit clumsy: - I need to specify a pattern twice, and in two different notations, since the standard utilities for pattern extraction use regular expressions and not "glob"-notation. - if I really want a list result, this can be surprisingly tricky: var = ``($special){echo $s | sed 'sed pattern using $special as a field separator'} can sometimes be made to work, but I need to be very careful about potential empty strings, and the choice of $special. I wrote an external command called `match' which could be used like: ; eval var '=(' ``(){match string pattern ...} ')' using a slightly modified version of the match-routine in the rc-source (the wanted list result is "almost available" as a side effect of the ~ command, in the sense that rc's match-routine could keep track of the needed information easily and cheaply). If string matches one of the patterns, match succeeds and prints the matching string in a format suitable for eval to standard output. If there is no match, it fails and prints nothing. There are some problems with this - you really need to invent yet another syntax and semantics for "glob"-pattern matching: - inserting literal "metacharacters" in the pattern needs a syntax different from the one rc uses. - you need to decide how to handle, and distinguish, various borderline cases. - matching lists against lists is messy - I still frequently need to specify patterns *twice*, once for for checking if there was a match (using `~') and once for doing the extraction (using `match'). In the end `match' did not turn out to be all that useful, although I still think "glob"-based pattern extraction could be very useful, provided it was built into the shell. Could this facility be grafted on to rc (or an rc-decendant)? Perhaps: 1) pattern matching in switch- and ~-commands could keep track of how they matched, and quietly assign a suitable list to some special variable, say `$**', on a succesful match. I don't think the cost of doing this would be prohibitive, but it would be a feature you'd have to pay for, whether you used it or not. (You could possibly reduce the cost somewhat by doing bookkeeping and assignment only under certain conditions, like if $** was undefined.) Anyway, this sort of "magic" variable and quiet sideeffect has a slightly perl-ish flavour, which I'm not sure if I like. 2) you could add a new operator, say `=~', with syntax and semantics like a cross between rc's `~' and `=': var =~ subject pattern could, if it succeded, assign a list of the result to var. Examples: ; x =~ -abcdef -?* && whatis x x=(- a bcdef) (One could conceivably make the existing ~-operator take an optional prefixed variable name. I haven't looked into what sort of complexities that would introduce into rc's grammar). Some examples of usage (assuming the $** hack): # crude basename fn basename { name = $1 suffix = $2 { while (~ $name */*) name = $**(3) ~ $name * ^ $suffix && name = $**(1) echo $name }} # remove a trailing newline from a string ; ~ $str * ^ $nl && str = $**(1) Potential gain from simple builtin pattern extraction: - most of *my* uses of sed/awk/expr for pattern based string handling would dissapear. I could use the same syntax and matching semantics as rc uses for matching. Simple pattern extraction would become accessible in a very convenient fashion, since I would normally need to specify a pattern *once* only. - you would get a limited builtin stringhandling capability. It seems that most shells, rc included, have builtin facilities for concatenating strings, while picking them apart is much harder. This seems like an asymmetry to me, which a builtin "glob" pattern extraction facility could partially remedy. - brynjulv From rc-owner Thu Jun 3 15:23:59 1993 Received: from ben.uknet.ac.uk ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2645>; Thu, 3 Jun 1993 15:23:15 -0400 Received: from a.gec-epl.co.uk by ben.uknet.ac.uk via PSS with NIFTP (PP) id ; Thu, 3 Jun 1993 20:22:51 +0100 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA01889; Thu, 3 Jun 93 20:24:05 BST Date: Thu, 3 Jun 1993 15:24:05 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9306031924.AA01889@zombie.gec-epl.co.uk> To: rc@hawkwind.utcs.toronto.edu Subject: $history on plan 9 X-Sun-Charset: US-ASCII Content-Length: 348 Earlier in the week I believe someone said that $history support has been removed from the plan 9 version of rc because 8.5 gave the users all the history they need. I hope Byron doesn't follow suit at some point in the future: one of the facilities I like most about rc is that its history can go back *months* if you can spare the disk space.... From rc-owner Thu Jun 3 15:36:56 1993 Received: from muse.cv.nrao.edu ([192.33.115.85]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Thu, 3 Jun 1993 15:36:43 -0400 Received: by muse.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA05120; Thu, 3 Jun 93 15:35:33 EDT From: dschieb@muse.CV.NRAO.EDU (Darrell Schiebel) Message-Id: <9306031935.AA05120@muse.cv.nrao.edu> Subject: Re: $history on plan 9 To: rc@hawkwind.utcs.toronto.edu Date: Thu, 3 Jun 1993 15:35:32 -0400 Cc: dschieb@muse.cv.nrao.edu (Darrell Schiebel) X-Mailer: ELM [version 2.3 PL11] > Earlier in the week I believe someone said that $history support has been > removed from the plan 9 version of rc because 8.5 gave the users all the > history they need. I hope Byron doesn't follow suit at some point in the > future: one of the facilities I like most about rc is that its history can > go back *months* if you can spare the disk space.... Does anyone know if the source to this '8 1/2' window system is available somewhere via FTP, or the chances of porting it to something like X?? thanks, Darrell Schiebel From rc-owner Thu Jun 3 15:49:21 1993 Received: from ben.uknet.ac.uk ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2701>; Thu, 3 Jun 1993 15:48:56 -0400 Received: from a.gec-epl.co.uk by ben.uknet.ac.uk via PSS with NIFTP (PP) id ; Thu, 3 Jun 1993 20:39:26 +0100 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA01911; Thu, 3 Jun 93 20:40:40 BST Date: Thu, 3 Jun 1993 15:40:40 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9306031940.AA01911@zombie.gec-epl.co.uk> To: rc@hawkwind.utcs.toronto.edu Subject: 8.5 on x X-Sun-Charset: US-ASCII Content-Length: 947 > From: dschieb%muse.CV.NRAO.EDU@gec-epl.co.uk (Darrell Schiebel) > Does anyone know if the source to this '8 1/2' window system > is available somewhere via FTP, or the chances of porting > it to something like X?? i don't know if the source is available outside of the plan 9 distribution, but there are two parts to your answer: (a) the fundamentals of 8.5 - the file serving - can't be ported to x under unix, because unix doesn't provide the right file primitives (although you might get something close using named pipes, unix sockets or a user- level nfs server, but you still don't get the union directories) (b) it's possible to produce a look-and-feel 8.5 window manager under unix (there is already a public-domain version of 9term available), but i'd rather not have one under x - the whole point of 8.5 is that it throws away all the baggage, and just does it right first time (bit like rc, really). From rc-owner Thu Jun 3 15:51:55 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto .edu with SMTP id <2724>; Thu, 3 Jun 1993 15:51:41 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA05 837 (5.65c/IDA-1.4.4 for ); Thu, 3 Jun 1993 15:51:2 5 -0400 Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA12918; Thu, 3 Jun 93 15:51:24 EDT From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9306031951.AA12918@penfold.cc.gatech.edu> Date: Thu, 3 Jun 1993 15:51:24 -0400 In-Reply-To: Darrell Schiebel's 33-line message on Jun 3, 3:35pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: dschieb@muse.CV.NRAO.EDU (Darrell Schiebel), rc@hawkwind.utcs.toronto.edu Subject: Re: $history on plan 9 8.5 is part of Plan 9. Plan 9 can be licensed by universities. Contact: Neera Kuckreja rm 2C557 ATT Bell Laboratories Murray Hill, N.J., 07974 U.S.A. +1 908 582-3855 neera@research.att.com No, we don't have it yet. Yes, I wish we did. Arnold P.S. The '9term' program gives the look and feel of 8.5 in an X environment. ftp to ftp.cs.su.oz.au:/pub/matty/9term and get the stuff there. It's neat. From rc-owner Thu Jun 3 15:59:30 1993 Received: from ben.uknet.ac.uk ([192.91.199.254]) by hawkwind.utcs.toronto.edu with SMTP id <2720>; Thu, 3 Jun 1993 15:59:09 -0400 Received: from a.gec-epl.co.uk by ben.uknet.ac.uk via PSS with NIFTP (PP) id ; Thu, 3 Jun 1993 20:58:45 +0100 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA01945; Thu, 3 Jun 93 20:59:59 BST Date: Thu, 3 Jun 1993 15:59:59 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9306031959.AA01945@zombie.gec-epl.co.uk> To: rc@hawkwind.utcs.toronto.edu Subject: 9term X-Sun-Charset: US-ASCII Content-Length: 481 > From: rsalz%osf.org@gec-epl.co.uk > > (there is already a public-domain version of 9term available), but i'd > where? tnx. > well, arnold beat me to answering this, but at the risk of turning this list into a discussion about 9term, i'd be interested in hearing from anyone who's got 9term running under solaris 2.x - i *think* i got an out-of-the-box version, and it didn't fly immediately - or after a couple of nights of hacking, and then i ran out of time. :-( steve From rc-owner Thu Jun 3 18:56:13 1993 Received: from netcomsv.netcom.com ([163.179.1.13]) by hawkwind.utcs.toronto.ed u with SMTP id <2735>; Thu, 3 Jun 1993 18:55:55 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA27178; Thu, 3 Jun 93 15:55:39 PDT Received: from ghoti.netapp.com by netapp.netapp.com (4.1/SMI-4.1) id AA01536; Thu, 3 Jun 93 14:58:12 PDT Received: by ghoti.netapp.com (4.1/SMI-4.1) id AA13382; Thu, 3 Jun 93 14:57:57 PDT Date: Thu, 3 Jun 1993 17:57:57 -0400 From: netapp!byron@netcom.com (Byron Rakitzis) Message-Id: <9306032157.AA13382@ghoti.netapp.com> To: rc@hawkwind.utcs.toronto.edu, steve@gec-epl.co.uk Subject: Re: $history on plan 9 Don't worry. I personally feel strongly about (1) backtracking on existing features, and (2) $history in particular. I think the labs people have strange priorities. Why was $history there for so many years in the first place if it was not useful? It's not like 8.5 is much different from any of the other 7.5 window systems that Rob has written... (I am thinking of the mux UI in particular) From rc-owner Fri Jun 4 08:21:51 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2744>; Fri, 4 Jun 1993 08:20:05 -0400 Received: from coltsfoot.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA10217; Fri, 4 Jun 93 08:19:24 -0400 Message-Id: <9306041219.AA10217@postman.osf.org> To: steve@gec-epl.co.uk (Steve_Kilbane) Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: 8.5 on x In-Reply-To: Message from steve@gec-epl.co.uk (Steve_Kilbane) <9306031940.AA01911@zombie.gec-epl.co.uk> . Date: Fri, 4 Jun 1993 08:19:23 -0400 From: John Robert LoVerso > but you still don't get the union directories) I would expect that something like Sun's translucent file system would be able to supply this. John From rc-owner Fri Jun 4 13:55:37 1993 Received: from muse.cv.nrao.edu ([192.33.115.85]) by hawkwind.utcs.toronto.edu with SMTP id <2726>; Fri, 4 Jun 1993 13:54:36 -0400 Received: by muse.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10693; Fri, 4 Jun 93 13:53:34 EDT From: dschieb@muse.CV.NRAO.EDU (Darrell Schiebel) Message-Id: <9306041753.AA10693@muse.cv.nrao.edu> Subject: Re: $history on plan 9 To: rc@hawkwind.utcs.toronto.edu Date: Fri, 4 Jun 1993 13:53:33 -0400 Cc: dschieb@muse.cv.nrao.edu (Darrell Schiebel) X-Mailer: ELM [version 2.3 PL11] > P.S. The '9term' program gives the look and feel of 8.5 in an X environment. > ftp to ftp.cs.su.oz.au:/pub/matty/9term and get the stuff there. It's neat. Thanks for all of the information. I compiled '9term' and it is pretty nice. However, I haven't been able to find a "history" mechanism that would warrant removing the '$history' hook... perhaps I've missed it. The only thing that is close is the 'bkwd' search on the third button, and it doesn't seem to support regular expressions. I like the GNU-readline approach much better. It seems that the most interesting part of '9term', unicode support, is not available, at least I assume it is not. The missing piece seems to be the fonts, the protection on 'ftp.cs.su.oz.au:/matty/unicode/libXg.utf.fonts.tar.Z' is '-rw-------'. Too bad. If I've missed something here, please let me know. thanks, Darrell Schiebe l From rc-owner Fri Jun 4 14:00:46 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto .edu with SMTP id <2732>; Fri, 4 Jun 1993 14:00:30 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA28 715 (5.65c/IDA-1.4.4 for ); Fri, 4 Jun 1993 14:00:2 6 -0400 Received: by penfold.cc.gatech.edu (4.1/SMI-4.1) id AA14560; Fri, 4 Jun 93 14:00:26 EDT From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <9306041800.AA14560@penfold.cc.gatech.edu> Date: Fri, 4 Jun 1993 14:00:25 -0400 In-Reply-To: Darrell Schiebel's 42-line message on Jun 4, 1:53pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: dschieb@muse.CV.NRAO.EDU (Darrell Schiebel), rc@hawkwind.utcs.toronto.edu Subject: Re: $history on plan 9 The "history" part is that you can scoot back with the scroll bar or page-up key, *edit the text in the window*, and then resubmit it (highlight the whole line and use "send" from the middle-button menu). This becomes incredibly natural in a very short time. The "hold mode" stuff is pretty neat too, although I don't use it nearly as much as I should. The Unicode fonts are copyrighted, and Matty has not yet gotten permission to distribute them. Sigh. From rc-owner Fri Jun 4 20:28:51 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2746>; Fri, 4 Jun 1993 20:28:22 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2537>; Fri, 4 Jun 1993 20:26:51 -0400 To: rc@hawkwind.utcs.toronto.edu Subject: Re: $history on plan 9 Date: Fri, 4 Jun 1993 20:27:44 -0400 From: Scott Schwartz Message-Id: <93Jun4.202651edt.2537@groucho.cs.psu.edu> Sam and 9term are indeed pretty neat, but (deep breath) I think emacs is generally better, at least in a Unix environment (cautious exhale). -- Scott (discordian at large) From rc-owner Sat Jun 5 05:42:10 1993 Received: from mail.swip.net ([192.71.220.11]) by hawkwind.utcs.toronto.edu wit h SMTP id <2751>; Sat, 5 Jun 1993 05:41:33 -0400 Received: from analytikerna.se (analytik.analytikerna.se) by mail.swip.net (5.6 5c8-/1.2) id AA15985; Sat, 5 Jun 1993 11:41:14 +0200 Received: from lynx.analytikerna by analytikerna.se (4.1/SMI-4.1) id AA22655; Sat, 5 Jun 93 11:41:35 +0200 Date: Sat, 5 Jun 1993 05:41:35 -0400 From: bk@analytikerna.se (Bengt KLEBERG) Message-Id: <9306050941.AA22655@analytikerna.se> To: rc@hawkwind.utcs.toronto.edu Subject: Subject: Re: 8.5 on x > From rc-owner@hawkwind.utcs.toronto.edu Fri Jun 4 14:24:13 1993 > To: steve@gec-epl.co.uk (Steve_Kilbane) > Cc: rc@hawkwind.utcs.toronto.edu > Subject: Re: 8.5 on x > Date: Fri, 4 Jun 1993 08:19:23 -0400 > From: John Robert LoVerso > Content-Length: 151 > > > but you still don't get the union directories) > > I would expect that something like Sun's translucent file system would be abl e > to supply this. > > John > Sun will not continue with TLFS. Sun Sweden mentioned this at a SweSUG meeting over a year ago. The replay was that one should not base any new projects on NeWS or TLFS. Can't say I'm sorry. Unix is getting very big as it is anyway. Bengt From rc-owner Sat Jun 5 06:49:31 1993 Received: from joyce.cs.su.OZ.AU ([129.78.8.208]) by hawkwind.utcs.toronto.edu with SMTP id <2753>; Sat, 5 Jun 1993 06:49:09 -0400 Received: from orthanc.cs.su.oz.au (for hawkwind.utcs.toronto.edu) with MHSnet; Sat, 05 Jun 1993 20:49:01 +1000 To: dschieb@muse.CV.NRAO.EDU Message-ID: <19930605202647.22292.frobozz@orthanc.cs.su.OZ.AU> In-Reply-To: <9306041753.AA10693@muse.cv.nrao.edu> From: matty@cs.su.oz.au (James Matthew Farrow) Date: Sat, 5 Jun 1993 06:26:47 -0400 Organisation: Basser Dept of Computer Science, Sydney University, Australia X-Name: James Matthew Farrow X-Face: B>D@!+;vE|ETmR!+pig${%L"["]tFj(v@m_F%@}o2q03)'6{jCds#> #sO^kokjP\LcmO}sB(,^SzSSq@v0x~UXrC \GJ3=i7FUOBLO}]EIuK(K4}LMg,=R7(#B3G&<"r1U~mct?!;M\z:lV Subject: Re: $history on plan 9 To: rc@hawkwind.utcs.toronto.edu Date: Fri, 4 Jun 1993 13:53:33 -0400 > P.S. The '9term' program gives the look and feel of 8.5 in an > X environment. ftp to ftp.cs.su.oz.au:/pub/matty/9term and get > the stuff there. It's neat. Thanks for all of the information. I compiled '9term' and it is pretty nice. However, I haven't been able to find a "history" mechanism that would warrant removing the '$history' hook... perhaps I've missed it. The only thing that is close is the 'bkwd' search on the third button, and it doesn't seem to support regular expressions. I like the GNU-readline approach much better. It seems that the most interesting part of '9term', unicode support, is not available, at least I assume it is not. The missing piece seems to be the fonts, the protection on 'ftp.cs.su.oz.au:/matty/unicode/libXg.utf.fonts.tar.Z' is '-rw-------'. Too bad. If I've missed something here, please let me know. thanks, Darrell Schiebel I'm currently trying to avoid legal wrangles over whether or not I'm allowed to distribute the font images. I mailed Charles Bigelow a few weeks back but have not had a reply yet. I'm about to mail him again to find out what's going on. Meanwhile at least some images won't have that problem because I'm preparing some myself. I've found with history that most of the time you're working in the immediate context, so you can see the command or it's only a page away. For the times when it's not I have a simple command (gh -- grep history) which greps the history file associated with the current window and a global file for this month and prints hits. Either way it ends up on the screen and you can just edit it and `send.' I've found that I couldn't (or wouldn't like to) do away with $history for the second reason. It's too convenient. I've found 9term and 8.5 seem to be incredible useful from the point of view of the `malleability' of the text on the screen. (How many times have you just wanted to add that `-g' flag to a 5 line cc line output by make and been foiled by xterm inserting CRs at the end of each line?) You still want the history, 'though, for the commands slip that out of your local context. I know not having history when I log in on Plan 9 is a pain although I'm still using Unix more than Plan 9 at the moment so I can't say what a different it makes. It just seems awkward not having it there when you're used to it. Matty. -- James Matthew Farrow | "For in that moment I beheld the ruin matty@cs.su.OZ.AU | of my existence. My world fell dark Basser Department of Computer Science | and my life became a shallow dream. Sydney University - FAX: +61 2 692 3838 | `Odi et amo. Excrucior.'" - Tlindah From rc-owner Sat Jun 5 08:40:44 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2755>; Sat, 5 Jun 1993 08:39:59 -0400 Received: by mod.civil.su.oz.au id <28693>; Sat, 5 Jun 1993 22:39:46 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Sat, 5 Jun 1993 08:35:30 -0400 To: The rc Mailing List cc: The es Mailing List Subject: here strings Message-ID: <199306052235.25314.rc.bakas@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Hands off here strings, you unprincipled boors! Real Example time (flog that dead horse, I know, but this was too good not to mail, and the old hands know how I feel about Real Examples): I had a directory full of files that had come from, ah, another operating system, and the names were all upper-case: for (f in *) mv $f `{tr A-Z a-z <<<$f} (Adjust your brain, and your $home/bin, as needed if your tr is infected with the SysVile square-bracket virus... they're _not_ character classes!) OK, John. From rc-owner Sat Jun 5 08:53:47 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2757>; Sat, 5 Jun 1993 08:53:36 -0400 Received: from idefix.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA29015; Sat, 5 Jun 1993 14:53:1 5 +0200 Received: by idefix.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA09468; Sat, 5 Jun 93 14:53:13 +0200 Date: Sat, 5 Jun 1993 08:53:13 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9306051253.AA09468@idefix.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: here strings Forwarding: Mail from 'John (Most modern computers would break if you stood on them) Mackin ' dated: Sat, 5 Jun 1993 08:35:30 -0400 Content-Length: 360 a directory full of files that had come from, ah, another operating system, and the names were all upper-case: for (f in *) mv $f `{tr A-Z a-z <<<$f} OK, John. Your lucky this worked because most (especially on older unixes) text utilities require their input to end in a '\n'. Then you'd have to for (f in *) mv $f `{echo $f | tr A-Z a-z} Malte From rc-owner Sat Jun 5 09:04:02 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2759>; Sat, 5 Jun 1993 09:03:46 -0400 Received: by mod.civil.su.oz.au id <28693>; Sat, 5 Jun 1993 23:03:19 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Sat, 5 Jun 1993 08:55:54 -0400 To: rc@hawkwind.utcs.toronto.edu Subject: Re: here strings In-Reply-To: <9306051253.AA09468@idefix.techfak.uni-bielefeld.de> Message-ID: <199306052255.25518.rc.bakay@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ [Me:] for (f in *) mv $f `{tr A-Z a-z <<<$f} [Malte:] Your [sic] lucky this worked because most (especially on older unixes) text utilities require their input to end in a '\n'. (let ((high-horse 'on)) Normally, I'd keep this private, but since Malte chose to toss a dart at my reputation on the list, I am replying to the same place. I have been a Unix professional for over ten years, and I am certainly N O T `lucky this worked.' I knew damn well that it would work. I am keenly aware of this historical development of Unix commands, and I know, and have known since the day I first used it (let's see, must have been on Sixth Edition in 1979) that "tr" is a plain _character-oriented_ command. It is not a text tool, it is a character tool. I know you know that. What I am telling you is that I always knew it. There was not the slightest bit of `luck' involved. If your tr needs a terminal newline, your tr is busted, end of discussion. ) OK, John. From rc-owner Sat Jun 5 12:43:43 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2761>; Sat, 5 Jun 1993 12:43:14 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA00477; Sat, 5 Jun 1993 11:42:48 -0500 Message-Id: <9306051642.AA00477@oldp.astro.wisc.edu> To: John (Most modern computers would break if you stood on them) Mackin Subject: Re: here strings Cc: rc@hawkwind.utcs.toronto.edu Date: Sat, 5 Jun 1993 12:42:48 -0400 From: Alan Watson X-Mts: smtp Sorry, John, but I'm not convinced by your example, although there may be something I have missed. The precise behaviour of your example can be reproduced by: for ( f in * ) mv $f `{ echo -n $f | tr A-Z a-z } assuming echo is built-in (or an external, non-SYSV echo). I strongly suspect that your here-string solution is not very much faster than this one, if echo is a built-in command. So, I would tentatively class your idiom as a speed hack on a system without a built-in echo (like some of the means of getting at the file system through the globber and builtin cd). As I see it, the justification for here-strings is that echo is not a necessarily available as a built-in, and so one cannot reliably convert a here-document to a a series of echoes. From rc-owner Sat Jun 5 14:38:53 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2749>; Sat, 5 Jun 1993 14:38:22 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA00855; Sat, 5 Jun 1993 13:38:17 -0500 Message-Id: <9306051838.AA00855@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: redirection and built-ins Date: Sat, 5 Jun 1993 14:38:17 -0400 From: Alan Watson X-Mts: smtp If rc were able to perform redirected built-in commands without forking, like a modern sh and es, would it be beneficial to change the grammar of a pipe to bind more closely to the right, rather than the left? At the moment, echo bar | read foo is a widely known failing of sh, but with these two changes it would work in rc. This is not a serious suggestion; I'm just interested exploring the design of rc. From rc-owner Sat Jun 5 14:44:35 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2763>; Sat, 5 Jun 1993 14:44:14 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA05084; Sat, 5 Jun 93 11:44:03 - 0700 Received: by astro.mv.us.adobe.com; id AA04299; Sat, 5 Jun 93 11:45:04 -0700 Date: Sat, 5 Jun 1993 14:45:04 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9306051845.AA04299@astro.mv.us.adobe.com> To: alan@oldp.astro.wisc.edu Subject: Re: redirection and built-ins Cc: rc@hawkwind.utcs.toronto.edu > At the moment, > echo bar | read foo > is a widely known failing of sh, but with these two changes it would > work in rc. the issue is not bindings of pipes, but when pipe forks. in rc and es, (though, i've heard, not in Tom Duff's rc) all components of pipelines are run in child processes. this is, imho, the cleanest model. i would be very upset to see it change. paul From rc-owner Sat Jun 5 14:59:53 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2766>; Sat, 5 Jun 1993 14:59:40 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA00975; Sat, 5 Jun 1993 13:59:14 -0500 Message-Id: <9306051859.AA00975@oldp.astro.wisc.edu> To: haahr@mv.us.adobe.com (Paul Haahr) Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: redirection and built-ins Date: Sat, 5 Jun 1993 14:59:13 -0400 From: Alan Watson X-Mts: smtp I suspect that the traditional implementation stems from the lack of redirection on built-ins in the orginal shell, but I could be wrong. Binding would matter the implementation of a pipeline avoided unnecessary forks (my order of binding would mean that the read rather than the echo was run in the current shell). From rc-owner Sun Jun 6 13:20:26 1993 Received: from albert.gnu.ai.mit.edu ([128.52.46.31]) by hawkwind.utcs.toronto. edu with SMTP id <2645>; Sun, 6 Jun 1993 13:19:20 -0400 Received: from trinity.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP id ; Sun, 6 Jun 93 13:18:58 -0400 Received: by trinity.gnu.ai.mit.edu (5.67/4.0) id ; Sun, 6 Jun 93 12:20:48 -0400 From: mycroft@gnu.ai.mit.edu Message-Id: <9306061620.AA02886@trinity.gnu.ai.mit.edu> Subject: Re: $history on plan 9 To: matty@cs.su.OZ.AU (James Matthew Farrow) Date: Sun, 6 Jun 1993 12:20:41 -0400 Cc: dschieb@muse.CV.NRAO.EDU, rc@hawkwind.utcs.toronto.edu In-Reply-To: <19930605202647.22292.frobozz@orthanc.cs.su.OZ.AU> from "James Mat thew Farrow" at Jun 5, 93 06:26:33 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 234 > (How many times have you just wanted to add that `-g' flag to a 5 > line cc line output by make and been foiled by xterm inserting CRs at > the end of each line?) Never, since I started using X11R5. Must be about 21 months now. From rc-owner Sun Jun 6 14:35:46 1993 Received: from groucho.cs.psu.edu ([130.203.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Sun, 6 Jun 1993 14:35:22 -0400 Received: from localhost by groucho.cs.psu.edu with SMTP id <2537>; Sun, 6 Jun 1993 14:33:36 -0400 To: mycroft@gnu.ai.mit.edu cc: matty@cs.su.oz.au (James Matthew Farrow), dschieb@muse.cv.nrao.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: $history on plan 9 In-reply-to: Your message of "Sun, 06 Jun 1993 12:20:41 EDT." <9306061620.AA02886@trinity.gnu.ai.mit.edu> Date: Sun, 6 Jun 1993 14:34:34 -0400 From: Scott Schwartz Message-Id: <93Jun6.143336edt.2537@groucho.cs.psu.edu> On the other hand, sometimes those long command lines won't fit into the tty input buffer. From rc-owner Sun Jun 6 20:34:30 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2726>; Sun, 6 Jun 1993 20:32:24 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA06856; Sun, 6 Jun 93 17:31:49 - 0700 Received: by astro.mv.us.adobe.com; id AA12043; Sun, 6 Jun 93 17:32:50 -0700 Date: Sun, 6 Jun 1993 20:32:50 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9306070032.AA12043@astro.mv.us.adobe.com> To: alan@oldp.astro.wisc.edu Subject: Re: redirection and built-ins Cc: rc@hawkwind.utcs.toronto.edu > I suspect that the traditional implementation stems from the lack of > redirection on built-ins in the orginal shell, but I could be wrong. i don't think so. it's the clearest and simplest implementation, and has completely obvious semantics. ``echo ... | read foo'' is not the appropriate construct in rc or es. the *right* way to that in one of these shells is foo = `{ echo ... } or foo = `` () { echo ... | { read foo | echo -n $foo } } if you really want read semantics. read hasn't made it to either of these shells yet. why are we talking about modifying fundamental parts of these shells to support inappropriate uses of (as-yet) unimplemented operations? paul From rc-owner Mon Jun 7 01:26:17 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2735>; Mon, 7 Jun 1993 01:24:00 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA07327; Mon, 7 Jun 1993 00:23:47 -0500 Message-Id: <9306070523.AA07327@oldp.astro.wisc.edu> To: haahr@mv.us.adobe.com (Paul Haahr) Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: redirection and built-ins Date: Mon, 7 Jun 1993 01:23:47 -0400 From: Alan Watson X-Mts: smtp | ``echo ... | read foo'' is not the appropriate construct in rc or es. Yeah, because it doesn't work; there is nothing intrinsicly `inappropriate' about it. I hadn't realised there was a lexicon of politically correct idioms in rc, but clearly I have been badly misinformed... | read hasn't made it to either of these shells yet. why are we talking | about modifying fundamental parts of these shells to support inappropriate | uses of (as-yet) unimplemented operations? Sorry, I didn't actually mean to imply that read should be a built-in, and I was actually thinking of a functionally-implemented read. When I mentioned rc forking to provide redirection for built-ins, I was also thinking about functions, but it was sloppy writing on my part. From rc-owner Mon Jun 7 04:45:46 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2645>; Mon, 7 Jun 1993 04:43:52 -0400 Received: from idefix.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA08117; Mon, 7 Jun 1993 10:42:1 0 +0200 Received: by idefix.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA09937; Mon, 7 Jun 93 10:42:08 +0200 Date: Mon, 7 Jun 1993 04:42:08 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9306070842.AA09937@idefix.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: here strings In-Reply-To: Mail from 'John (Most modern computers would break if you stood on them) Mackin ' dated: Sat, 5 Jun 1993 08:55:54 -0400 Content-Length: 916 So let me say I'm very sorry I didn't get the hint from your mail header: "John (Most modern computers would break if you stood on them) Mackin". But to all the non expert text tool users out there: The point is not all tools deal correctly with non-newline terminated here strings. I spent quite some time discovering this when I wrote a shell script that ran fine with path = ( /vol/gnu/bin ... ) but didn't with path = ( /bin ... ) on a Sparc running SunOS 4 and another running SunOS 5. ; /vol/gnu/bin/sed 's/a/e/g' <<< aaaaaa eeeeee ; /bin/sed 's/a/e/g' <<< aaaaaa ; Because of this, I refuse to use here strings since their semantic is confusing me and - if not avoidable - is replacable by "echo -n", unless someone can show me a counter example. I do not want to throw here strings out because that'll probably break a lot of existing scripts. I'd just wanted to state their superfluousness. Malte From rc-owner Mon Jun 7 11:24:07 1993 Received: from mail-relay-2.mv.us.adobe.com ([130.248.1.2]) by hawkwind.utcs.to ronto.edu with SMTP id <2645>; Mon, 7 Jun 1993 11:23:31 -0400 Received: by mail-relay-2.mv.us.adobe.com; id AA07951; Mon, 7 Jun 93 08:23:16 - 0700 Received: by astro.mv.us.adobe.com; id AA16980; Mon, 7 Jun 93 08:24:17 -0700 Date: Mon, 7 Jun 1993 11:24:17 -0400 From: haahr@mv.us.adobe.com (Paul Haahr) Message-Id: <9306071524.AA16980@astro.mv.us.adobe.com> To: rc@hawkwind.utcs.toronto.edu Subject: Re: redirection and built-ins Alan writes: > | ``echo ... | read foo'' is not the appropriate construct in rc or es. > Yeah, because it doesn't work; there is nothing intrinsicly > `inappropriate' about it. i disagree. it's inappropriate because rc already has a perfectly good mechanism for setting variables to the output of commands: backquotes. why is that not enough? what functionality does that lack? i don't think that the goal in rc was to provide a million different syntaxes for the same operation. > and I was actually thinking of a functionally-implemented read. what does this mean? (``functionally-implemented''? that it works? that it doesn't have side effects?) > When > I mentioned rc forking to provide redirection for built-ins, I was > also thinking about functions, but it was sloppy writing on my part. as far as i can tell, there are two issues here: (1) rc forks for all redirection operations, even ones which are applied to builtins and shell functions. (2) rc and es fork a child process for each component of a pipeline, even if some of the components are builtins or functions. (1) is handled differently in es, and seems to work ok. in my mind, it's a performance hack, and not a very good one, because from the bit of profiling that i've done it doesn't make that much of a difference. the mechanism we came up with for doing this in es could be applied to rc just fine, but it seems like a lot of work for very little payoff. (2), i think, is the right thing, because it's the only symmetric answer. in the pipeline a | b | c if all a, b, and c are shell functions, which one should run in the context of the shell? what should happen if the command is exit 1 | exit 2 | exit 3 ? i prefer the current rc/es answer which is: the shell does not exit, and the return status is (1 2 3). i believe that in Tom Duff's verion, the top-level shell exits with either 1 or 3, and Alan seems to argue that 3 is the right answer. paul From rc-owner Mon Jun 7 13:10:51 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2645>; Mon, 7 Jun 1993 13:10:26 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA08381; Mon, 7 Jun 1993 12:10:17 -0500 Message-Id: <9306071710.AA08381@oldp.astro.wisc.edu> To: haahr@mv.us.adobe.com (Paul Haahr) Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: redirection and built-ins Date: Mon, 7 Jun 1993 13:10:16 -0400 From: Alan Watson X-Mts: smtp Paul writes: > it's inappropriate because rc already has a perfectly good > mechanism for setting variables to the output of commands: backquotes. > why is that not enough? what functionality does that lack? Oh, the ability to encapsulate the process in a function (yes, I know that in es one could pass a program fragment, but this is the rc-list after all), and an easy way to get at the return value (yes, I know that may be fixed in a later version, but I'd still rather hide the grubby details in a function). > what does this mean? (``functionally-implemented''? that it works? > that it doesn't have side effects?) It means `implemented as a function'. > the mechanism we came up with for doing this [redirection on > built-ins without forking] in > es could be applied to rc just fine, but it seems like a lot of > work for very little payoff. Fine. I'm prepared to accept that answer; as I said in my original message, I'm only interested in exploring the possibilities, and I am not campaigning for either of these changes. I'm not concerned about the performance aspects, only the functionality. > what should happen if the command is > exit 1 | exit 2 | exit 3 > ? There will always be pathological cases: even now, if you have an exit in a function and run it with and without redirection, different things happen. I haven't heard of anyone losing any sleep about it. From rc-owner Tue Jun 15 16:46:16 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2706>; Tue, 15 Jun 1993 16:45:16 -0400 To: rc Subject: Why I want read to be a builtin: Date: Tue, 15 Jun 1993 16:45:08 -0400 From: Chris Siebenmann Message-Id: <93Jun15.164516edt.2706@hawkwind.utcs.toronto.edu> read.sh is a 'while read; do : ; done' loop; line.sh is a 'while line >/dev/null; do :; done' loop. : hawkwind.utcs ; wc -l foo; time ./read.sh ; Tue, 15 Jun 1993 19:18:24 -0400 Received: by jayg.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA15996; Tue, 15 Jun 1993 18:18:10 -0500 Message-Id: <9306152318.AA15996@jayg.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: FAQ system list Date: Tue, 15 Jun 1993 19:18:10 -0400 From: Alan Watson X-Mts: smtp As part of the FAQ list, I would like a table of architectures, OSes, and compilers with which rc is known to work. If you've managed to compile rc on a system which you do not see on this list, please drop me a line. Replies from RS/6000 and HP users would be especially welcome. Has anyone managed to get rc to compile on a VAX? I spent a frustrating hour battling vcc and pcc with unproto as my excalibur before retiring from the field, but we don't have gcc on our VAXen. Thanks to everyone who responded to this first time around. Alan. 1.4 Can I compile rc on a ... machine with ... operating system and ... compiler? rc is written in portable ANSI C, but it can be compiled by many older C compilers after passing the sources through unproto (get /pub/unix/unproto4.shar.Z by anonymous FTP from ftp.win.tue.nl). If you use gcc, make sure it is at least as new as v1.39. rc has been successfully compiled on systems with the following combinations of architectures, operating systems, and compilers: DEC MIPS Ultrix v4.[23] gcc v2 DEC MIPS Ultrix v4.3 cc [a][b] DEC Alpha OSF/1 v1.2 cc [a][b][n] DEC Alpha OSF/1 v1.2 cc -std1 [a][n] Sun SPARC Solaris v2 gcc v2 [c][n] Sun SPARC acc [c][d][n] Sun SPARC SunOS v4.1.3 cc [a][b][c][n] Sun SPARC SunOS v4.1.[123] gcc v2 [c][n] Sun SPARC BSD [c][n] Sun 68K SunOS 3.5 gcc v1 [c][n] Sun 68K SunOS v4.0.3 lcc [c][e][n] SGI Iris Irix v[45].x gcc v2 Apollo 68K DomainOS v10.4 cc [a][f][m] Apollo 10000 DomainOS v10.4 cc [a][f][m] Convex C1 ConvexOS v10.1 cc [a] Pyramid 9810 OSx 5.1a cc -Xa [a][f][g] IBM RS/6000 cc i386/i486 SCO-ODT SVR3 gcc v2 [h][i] i386/i486 SCO-ODT SVR3 cc [h][i] i386 Minix v1.5 [h] Cray Y-MP Unicos 6.1.7 scc [j][k] NeXT NeXT OS v2.x gcc v2 [l] NeXT NeXT OS v3.0 gcc v2 [l] Notes: [a] The native C compiler. [b] Sources pre-processed with unproto. [c] Sun's yacc has a memory leak -- use another implementation such as GNU bison (see 7.4). [d] The unbundled ANSI compiler. [e] rc v1.2. [f] BSD universe. [g] This compiler has no stdarg.h, but vararg.h sufficed. [h] Requires intervention by hand to get mksignal to work, because of deficient sh, awk, etc. [i] See 4.13. [j] Minor modifications required to prototypes. [k] See 4.13. [l] See 5.6. [m] See 5.5. [n] See 1.5. From rc-owner Tue Jun 15 19:26:28 1993 Received: from albert.gnu.ai.mit.edu ([128.52.46.31]) by hawkwind.utcs.toronto. edu with SMTP id <2738>; Tue, 15 Jun 1993 19:26:02 -0400 Received: from hal.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP id ; Tue, 15 Jun 93 19:25:48 -0400 Received: by hal.gnu.ai.mit.edu (AIX 3.2/UCB 5.64/4.0) id ; Tue, 15 Jun 1993 19:25:46 -0400 Date: Tue, 15 Jun 1993 19:25:46 -0400 From: mycroft@gnu.ai.mit.edu Message-Id: <9306152325.AA24562@hal.gnu.ai.mit.edu> To: alan@jayg.astro.wisc.edu Cc: rc@hawkwind.utcs.toronto.edu In-Reply-To: Alan Watson's message of Tue, 15 Jun 1993 19:18:10 -0400 <93061523 18.AA15996@jayg.astro.wisc.edu> Subject: FAQ system list Here are the environments I'm running it in which you didn't list: Sun 68k SunOS v4.1.1_U1 gcc i386/i486 NetBSD cc (which is gcc v1.39) i386/i486 NetBSD gcc (v2) RS/6000 AIX 3.2.1 cc From rc-owner Tue Jun 15 22:41:44 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2754>; Tue, 15 Jun 1993 22:41:20 -0400 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10354; Tue, 15 Jun 93 22:41:04 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 223959.27588; Tue, 15 Jun 1993 22:39:59 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa10193; Tue, 15 Jun 93 22:28:10 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: alan@jayg.astro.wisc.edu Subject: Re: FAQ system list Cc: rc@hawkwind.utcs.toronto.edu Date: Tue, 15 Jun 1993 22:27:13 -0400 Message-Id: <9306152227.aa22056@ceres.srg.af.mil> > i386/i486 SCO-ODT SVR3 gcc v2 [h][i] > i386/i486 SCO-ODT SVR3 cc [h][i] > > [h] Requires intervention by hand to get mksignal to work, > because of deficient sh, awk, etc. > [i] See 4.13. While I'm the first one to throw stones at SCO-ODT this needs to be clarified. The problem is not a deficiency in SCO the utilities, but rather a very complicated /usr/include/sys/signal.h with preprocessor conditionals that end up defeating the scripts assumptions. If the problem was with the utilities using gnu substitutes should fix it and they don't. Tom BTW - attached is the hacked version of SCO's sys/signal.h that I use to build a good rc. ------------------------------signal.hacked------------------------------ /* This is a hacked down version of /usr/include/sys/signal.h needed * because mksignal has problems with preprocessor conditionals. */ #define SIGHUP 1 /* hangup */ #define SIGINT 2 /* interrupt (rubout) */ #define SIGQUIT 3 /* quit (ASCII FS) */ #define SIGILL 4 /* illegal instruction (not reset when caught)*/ #define SIGTRAP 5 /* trace trap (not reset when caught) */ #define SIGIOT 6 /* IOT instruction */ #define SIGABRT 6 /* used by abort, replace SIGIOT in the future */ #define SIGEMT 7 /* EMT instruction */ #define SIGFPE 8 /* floating point exception */ #define SIGKILL 9 /* kill (cannot be caught or ignored) */ #define SIGBUS 10 /* bus error */ #define SIGSEGV 11 /* segmentation violation */ #define SIGSYS 12 /* bad argument to system call */ #define SIGPIPE 13 /* write on a pipe with no one to read it */ #define SIGALRM 14 /* alarm clock */ #define SIGTERM 15 /* software termination signal from kill */ #define SIGUSR1 16 /* user defined signal 1 */ #define SIGUSR2 17 /* user defined signal 2 */ #define SIGCLD 18 /* death of a child */ #define SIGPWR 19 /* power-fail restart */ #define SIGWINCH 20 /* window change */ /* SIGPHONE only used in UNIX/PC */ /*#define SIGPHONE 21*/ /* handset, line status change */ #define SIGPOLL 22 /* pollable event occured */ #define SIGCHLD SIGCLD /* compatibility */ #define SIGSTOP 23 /* sendable stop signal not from tty */ #define SIGTSTP 24 /* stop signal from tty */ #define SIGCONT 25 /* continue a stopped process */ #define SIGTTIN 26 /* to readers pgrp upon background tty read */ #define SIGTTOU 27 /* like TTIN for output if (tp->t_local&TOSTOP) */ #define SIGALL (~(sigset_t)0L) /* new for POSIX */ #define NSIG 28 /* The valid signal number is from 1 to NSIG-1 */ #define MAXSIG 32 /* size of u_signal[], NSIG-1 <= MAXSIG*/ /* MAXSIG is larger than we need now. */ /* In the future, we can add more signal */ /* number without changing user.h */ From rc-owner Wed Jun 16 03:38:49 1993 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu w ith SMTP id <2754>; Wed, 16 Jun 1993 03:38:15 -0400 Received: by quux.es.su.oz.au id <1147>; Wed, 16 Jun 1993 17:37:49 +1000 From: noel@es.su.oz.au Date: Wed, 16 Jun 1993 03:34:06 -0400 to: alan@jayg.astro.wisc.edu cc: rc@hawkwind.utcs.toronto.edu Subject: FAQ system list Message-ID: <199306161734.25111.out.bader@es.su.oz.au> I have had rc running in the following environments: RS6000 AIX 3.1.5 cc RS6000 AIX 3.2 cc RS6000 AIX 3.2.3 cc Sun4c SunOS 4.1.2 cc/unproto From rc-owner Wed Jun 16 11:03:00 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2706>; Wed, 16 Jun 1993 11:02:18 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA24353; Wed, 16 Jun 1993 10:02:03 -0500 Message-Id: <9306161502.AA24353@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: FAQ system list Date: Wed, 16 Jun 1993 11:02:02 -0400 From: Alan Watson X-Mts: smtp Some people have asked what the following footnotes refer to: [i] See 4.13. [k] See 4.13. [l] See 5.6. [m] See 5.5. [n] See 1.5. 1.5 recommends that rc should be statically linked on systems including those running SunOS, Solaris, and OSF/1. 4.13 mentions the deficient test in SCO Unix and the complete absence of /bin/test in Unicos (took me a while to figure out why trip.rc wasn't working...). 5.5 mentions that Apollos require a real binary for the login shell, not a script (and I though /etc/shells was bad to start with). 5.6 describes the NeXT window manager brain damage. From rc-owner Wed Jun 16 12:52:46 1993 Received: from albert.gnu.ai.mit.edu ([128.52.46.31]) by hawkwind.utcs.toronto. edu with SMTP id <2706>; Wed, 16 Jun 1993 12:52:18 -0400 Received: from hal.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP id ; Wed, 16 Jun 93 12:52:06 -0400 Received: by hal.gnu.ai.mit.edu (AIX 3.2/UCB 5.64/4.0) id ; Wed, 16 Jun 1993 12:52:05 -0400 Date: Wed, 16 Jun 1993 12:52:05 -0400 From: mycroft@gnu.ai.mit.edu Message-Id: <9306161652.AA19673@hal.gnu.ai.mit.edu> To: alan@oldp.astro.wisc.edu Cc: rc@hawkwind.utcs.toronto.edu In-Reply-To: Alan Watson's message of Wed, 16 Jun 1993 11:02:02 -0400 <93061615 02.AA24353@oldp.astro.wisc.edu> Subject: FAQ system list 4.13 mentions the deficient test in SCO Unix and the complete absence of /bin/test in Unicos (took me a while to figure out why trip.rc wasn't working...). Oh, I forgot about this. HP/UX 8.0 doesn't have /bin/test; 9.0 does. Also, any shell not listed in /etc/shells or beginning with `r' is considered `restricted', and any invocation of shell(3) will fail. This breaks a *lot* of things--even xrdb. From rc-owner Wed Jun 16 13:39:31 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2720>; Wed, 16 Jun 1993 13:39:09 -0400 Received: from idefix.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA00652; Wed, 16 Jun 1993 19:38: 40 +0200 Received: by idefix.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA00740; Wed, 16 Jun 93 19:38:39 +0200 Date: Wed, 16 Jun 1993 13:38:39 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9306161738.AA00740@idefix.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: FAQ system list In-Reply-To: Mail from 'Alan Watson ' dated: Wed, 16 Jun 1993 11:02:02 -0400 Content-Length: 235 1.5 recommends that rc should be statically linked on systems including those running SunOS, Solaris, and OSF/1. What does this mean? Have I been running rc for about 1 1/2 years without problems just by lucky chance ??? Malte From rc-owner Wed Jun 16 13:41:27 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2729>; Wed, 16 Jun 1993 13:41:11 -0400 To: rc Subject: Re: FAQ system list In-reply-to: malte's message of Wed, 16 Jun 93 13:38:39 -0400. <9306161738.AA00740@idefix.techfak.uni-bielefeld.de> Date: Wed, 16 Jun 1993 13:41:06 -0400 From: Chris Siebenmann Message-Id: <93Jun16.134111edt.2729@hawkwind.utcs.toronto.edu> | What does this mean? Have I been running rc for about 1 1/2 years without | problems just by lucky chance ??? At least on Solaris and SunOS, if you static-link rc it will run much faster (generally when forking programs). In fact, if you static-link everything that forks programs, your system performance will probably suddenly jump. It's quite remarkable. - cks From rc-owner Fri Jun 18 07:03:53 1993 Received: from faui33.informatik.uni-erlangen.de ([131.188.33.2]) by hawkwind.u tcs.toronto.edu with SMTP id <2771>; Fri, 18 Jun 1993 06:57:35 -0400 Received: from faui30a.informatik.uni-erlangen.de by immd3.informatik.uni-erlan gen.de with SMTP (5.64+/7.2b-FAU) id AA03915; Fri, 18 Jun 93 12:57:19 +0200 From: Stefan Dalibor Message-Id: <9306181057.AA03915@faui33.informatik.uni-erlangen.de> Date: Fri, 18 Jun 1993 06:57:17 -0400 To: rc@hawkwind.utcs.toronto.edu Subject: Re: FAQ system list > As part of the FAQ list, I would like a table of architectures, OSes, > and compilers with which rc is known to work. If you've managed to > compile rc on a system which you do not see on this list, please drop > me a line. You can add Motorola m88k on SYSTEM V/88 R32V3 to your list; I compiled rc-1.4 ok and it passed trip.rc successful. The following definitions in config.h were required: #define NOLIMITS /* SYSTEM V/88 is a rather dumb SysV R3 */ #define DEFAULTINTERP "/bin/sh" /* it is so dumb that even /bin/{true,false} * don't start with `#!/bin/sh'... */ #define PROTECT_ENV /* trip.rc fails without that */ Compilation was done with gcc (version 2.2.2) and Green Hills cc (version 1.8.5). To use the latter, unproto (version later than 1.4) is needed - but you should really try to avoid Green Hills cc if possible (it's the worst cc I ever saw); if you must, be sure ALL optimization flags are turned off. Stefan Dalibor (dalibor@immd3.uni-erlangen.de) From rc-owner Fri Jun 18 13:36:05 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2773>; Fri, 18 Jun 1993 13:33:11 -0400 Return-Path: TechFak.Uni-Bielefeld.DE!malte Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2771>; Fri, 18 Jun 1993 03:32:38 -0400 Received: from dahlie.techfak.uni-bielefeld.de (idefix.TechFak.Uni-Bielefeld.DE ) by techfac.TechFak.Uni-Bielefeld.DE id AA21169; Fri, 18 Jun 1993 09:31: 54 +0200 Received: by dahlie.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA00685; Fri, 18 Jun 93 09:31:53 +0200 Date: Fri, 18 Jun 1993 03:31:53 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9306180731.AA00685@dahlie.techfak.uni-bielefeld.de> To: rc-owner Subject: trace in rc Content-Length: 644 Resent-To: rc Resent-Date: Fri, 18 Jun 1993 13:33:08 -0400 Resent-From: Chris Siebenmann Resent-Message-Id: <93Jun18.133311edt.2773@hawkwind.utcs.toronto.edu> Hello, I've been thinking about how to implement a kind of "intelligent" trace facility in rc. Intelligent means I want to execute a function each time a command fails. One parameter to this function should be the name of the failed command. I thought about the prompt function, but that doesn't help in shell scripts. So I'd like to hear what you think about adding a function to rc which is called after invocation of any command or builtin, running interactively or not with the last command's name ( or names if it was a pipe ) as parameter. Then, fn prompt can be defined in terms of this function, as well as any trace function. Malte From rc-owner Sat Jun 19 20:37:04 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2783>; Sat, 19 Jun 1993 20:33:21 -0400 Return-Path: es.su.oz.au!noel Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu w ith SMTP id <2783>; Sat, 19 Jun 1993 20:03:48 -0400 Received: by quux.es.su.oz.au id <1156>; Sun, 20 Jun 1993 10:03:25 +1000 From: noel@es.su.oz.au Date: Sat, 19 Jun 1993 20:01:42 -0400 to: rc-owner Subject: Re: trace in rc In-Reply-To: <9306180731.AA00685@dahlie.techfak.uni-bielefeld.de> Message-ID: <199306201001.13129.out.badok@es.su.oz.au> Resent-To: rc Resent-Date: Sat, 19 Jun 1993 20:33:12 -0400 Resent-From: Chris Siebenmann Resent-Message-Id: <93Jun19.203321edt.2783@hawkwind.utcs.toronto.edu> From: malte@TechFak.Uni-Bielefeld.DE So I'd like to hear what you think about adding a function to rc which is called after invocation of any command or builtin, running NO. Leave rc alone. It isn't broken; don't fix it. From rc-owner Wed Jun 23 03:14:01 1993 Received: from oinker.ucsb.edu ([128.111.72.55]) by hawkwind.utcs.toronto.edu w ith SMTP id <2706>; Wed, 23 Jun 1993 03:12:23 -0400 Received: from localhost by oinker.ucsb.edu with SMTP id AA25404 (5.65c/IDA-1.4.4 for ); Wed, 23 Jun 1993 00:12: 15 -0700 Message-Id: <199306230712.AA25404@oinker.ucsb.edu> To: rc@hawkwind.utcs.toronto.edu Subject: I need a binary for a VAXstation Reply-To: rearl@oinker.ucsb.edu Date: Wed, 23 Jun 1993 02:12:14 -0400 From: Robert Earl Does anyone have a precompiled binary of rc for a VAXstation 3100 running Ultrix 4.2 or similar? I'm in dire need cos I don't have gcc on this machine (yet), and unprotoize isn't helping (enough). Thanks, --robert From rc-owner Tue Jun 29 00:16:39 1993 Received: from plg.uwaterloo.ca ([129.97.140.10]) by hawkwind.utcs.toronto.edu with SMTP id <2744>; Tue, 29 Jun 1993 00:15:24 -0400 Received: by plg.uwaterloo.ca id <28962>; Tue, 29 Jun 1993 00:15:17 -0400 From: Dave Mason To: rc@hawkwind.utcs.toronto.edu In-reply-to: <9306152318.AA15996@jayg.astro.wisc.edu> (message from Alan Watson on Tue, 15 Jun 1993 19:18:10 -0400) Subject: rc on Linux? X-Face: %Q_F^9R-:'3MM7eZ6@E.x@f\*bgatzGv-8d%I~L[p^.F)3QF{kq\UTsu|e#?)3FPwJNvPPB !s*He|-*M^p*~bh"Nywm5NLL\\Rl3r(hWHY*F:$/RdKV*bS";n&#\Ov@*=]mu\}6tP Date: Tue, 29 Jun 1993 00:15:02 -0400 I built it, after hacking some include file stuff for mksignal, but it consistently exits on an intr signal. Please!!! I'm desperate!! I can't take much more of this bash stuff... Thanks ../Dave From rc-owner Wed Jul 7 09:17:46 1993 Received: from cheviot.ncl.ac.uk ([128.240.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2772>; Wed, 7 Jul 1993 09:16:09 -0400 Received: from ncl.bygate (bygate.ncl.ac.uk) by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Wed, 7 Jul 1993 14:15:52 +0100 From: Gerry.Tomlinson@newcastle.ac.uk Message-Id: Subject: problem with B.rc To: rc@hawkwind.utcs.toronto.edu Date: Wed, 7 Jul 1993 09:15:48 -0400 X-Mailer: ELM [version 2.3 PL11] I've just started using sam 3.0 and was surprised to find that the B.rc script provided doesn't work whereas B.sh does (sparc sunos 4.1.1 with rc 1.4). rc doesn't seem to be able to write to sam's fifo, any ideas why not? Gerry --- Gerry.Tomlinson@newcastle.ac.uk Department of Computing Science, University of Newcastle, Tel: +44 91 222 8139 Newcastle upon Tyne, NE1 7RU, United Kingdom. Fax: +44 91 222 8232 From rc-owner Wed Jul 7 10:46:54 1993 Received: from cheviot.ncl.ac.uk ([128.240.2.10]) by hawkwind.utcs.toronto.edu with SMTP id <2772>; Wed, 7 Jul 1993 10:46:35 -0400 Received: from ncl.bygate (bygate.ncl.ac.uk) by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Wed, 7 Jul 1993 15:46:16 +0100 From: Gerry.Tomlinson@newcastle.ac.uk Message-Id: Subject: Re: problem with B.rc To: schwartz@groucho.cse.psu.edu (Scott Schwartz) Date: Wed, 7 Jul 1993 10:46:12 -0400 Cc: rc@hawkwind.utcs.toronto.edu In-Reply-To: <93Jul7.092754edt.2601@groucho.cse.psu.edu>; from "Scott Schwartz" at Jul 7, 93 9:28 am X-Mailer: ELM [version 2.3 PL11] > > Do you have tmpfs mounted on /tmp? tmpfs is buggy in 4.1.1 and can't > deal with fifos. > of course - I forgot! thanks, Gerry. From rc-owner Thu Jul 8 22:51:34 1993 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.toronto.ed u with SMTP id <2777>; Thu, 8 Jul 1993 22:50:41 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <2591>; Thu, 8 Jul 1993 22:49:10 -0400 To: rc@hawkwind.utcs.toronto.edu Subject: the one true use for ^Z Date: Thu, 8 Jul 1993 22:49:59 -0400 From: Scott Schwartz Message-Id: <93Jul8.224910edt.2591@groucho.cse.psu.edu> in the tty driver, it flushes pending input, independent of what the shell does with sigtstp. ; stty susp '^z' ; fn sigtstp {} ; sleep 5 ls ^Z ; From rc-owner Fri Jul 9 02:01:37 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2780>; Fri, 9 Jul 1993 02:01:11 -0400 Received: by mod.civil.su.oz.au id <28694>; Fri, 9 Jul 1993 15:09:51 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Fri, 9 Jul 1993 00:54:51 -0400 To: The rc Mailing List Subject: A truly revolting feature Message-ID: <199307091454.931.rc.bakis@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ I won't name the person whose idea this was since it isn't really his fault, and my intent isn't to hold _him_ up to ridicule. Rather it is to shed light into one of the darkest crannies I have yet seen in the lexical analyser in /bin/sh, so that we can all feel extra-glad that we've seen the light and changed to better shells. Many months ago, I told this man about rc and suggested that he should take a look at it. I showed him Duff's document. He went as far as building it and putting it in his machine's /usr/local/bin, and giving it a try. For some reason, he hasn't changed to rc, but he sent me mail at the time saying that he was impressed by the ability to mouse the whole line with the "; " prompt. I pointed out to him that he could do that under sh also by using the Pike prompt style (": ;"), and then never heard any more from him about it. The other day I was in his office and he proudly showed me what he'd come up with: the ability to mouse the whole line _even though PS1 had the standard value of "$ "_. He had put the following in $home/bin/ ^ '$': #!/bin/sh exec "$@" Much to my nausea, it turns out that sh is quite prepared to regard a bare $ sign as a plain old "word", and search the path for it if it stands in command position... Of course, this has to be a script and not a function, since sh's function names have to be "identifer"s. But, how horrendous can you get? Yeuch. OK, John. From rc-owner Fri Jul 9 13:16:53 1993 Received: from faui33.informatik.uni-erlangen.de ([131.188.33.2]) by hawkwind.u tcs.toronto.edu with SMTP id <2777>; Fri, 9 Jul 1993 13:15:58 -0400 Received: from faui30a.informatik.uni-erlangen.de by immd3.informatik.uni-erlan gen.de with SMTP (5.64+/7.2b-FAU) id AA02710; Fri, 9 Jul 93 19:15:37 +0200 From: Stefan Dalibor Message-Id: <9307091715.AA02710@faui33.informatik.uni-erlangen.de> Date: Fri, 9 Jul 1993 13:15:34 -0400 To: rc@hawkwind.utcs.toronto.edu Subject: To patch or not to patch? Hi, scanning through the rc-list archive, I saw mails containing patches for rc-1.4. This reveals 2 questions: 1. Does anybody maintain some kind of `official' patch-archive for rc or should I just apply what's on the list? 2. An upcoming release 1.5 is mentioned; will this be released `Real Soon Now' (in this case I'd rather switch than patch)? Bye, Stefan -- Stefan Dalibor dalibor@immd3.uni-erlangen.de From rc-owner Mon Jul 19 14:40:40 1993 Received: from hydra.Helsinki.FI ([128.214.4.29]) by hawkwind.utcs.toronto.edu with SMTP id <2221>; Mon, 19 Jul 1993 14:39:02 -0400 Received: by hydra.Helsinki.FI (4.1/SMI-4.1/39) id AA28242; Mon, 19 Jul 93 21:38:48 +0300 Date: Mon, 19 Jul 1993 14:38:48 -0400 From: Lars.Wirzenius@cs.Helsinki.FI (Lars Wirzenius) Message-Id: <9307191838.AA28242@hydra.Helsinki.FI> X-Mailer: Mail User's Shell (7.2.0 10/31/90) To: rc@hawkwind.utcs.toronto.edu Subject: subscribe lars.wirzenius@helsinki.fi From rc-owner Sat Jul 24 20:46:12 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2732>; Sat, 24 Jul 1993 20:44:56 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA21203; Sat, 24 Jul 1993 19:44:42 -0500 Message-Id: <9307250044.AA21203@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: rc FAQ list Date: Sat, 24 Jul 1993 20:44:42 -0400 From: Alan Watson X-Mts: smtp I have put a revised version of the prototype rc FAQ list up for anonymous FTP as /pub/rc/rc-FAQ on oldp.astro.wisc.edu. Many, many thanks to everyone who commented on earlier versions or sent me details of systems on which rc works (as far as I can tell, just about any system that begins with a U or ends with an X). Most of the improvements between v1.19 and v2.5 are directly the result of these comments. I very much welcome comments on the current version, and will maintain an errata file as before. I'd like to submit this for approval to the news.answers moderator (to appear in comp.unix.shell, comp.answers, and news.answers) sometime in the next couple of months (depending on your comments). Alan. P.S. I had a look at the zsh FAQ whilst I was revising -- the features just blew my mind, but nothing prepared me for the final line of the acknowledgements. Is it just me, or do these people really have their own version of reality? From rc-owner Sat Jul 24 21:17:54 1993 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.toronto.ed u with SMTP id <2732>; Sat, 24 Jul 1993 21:17:34 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <2591>; Sat, 24 Ju l 1993 21:16:05 -0400 To: Alan Watson cc: rc@hawkwind.utcs.toronto.edu Subject: Re: rc FAQ list In-reply-to: Your message of "Sat, 24 Jul 1993 20:44:42 EDT." <9307250044.AA21203@oldp.astro.wisc.edu> Date: Sat, 24 Jul 1993 21:16:45 -0400 From: Scott Schwartz Message-Id: <93Jul24.211605edt.2591@groucho.cse.psu.edu> | Is it just me, or do these people really have their | own version of reality? Doesn't everybody? :-) A friend of mine used to say, "who needs tcsh when you can run rc in an emacs shell buffer". Anyway, zsh does have some good ideas that it wouldn't hurt rc to adopt (ok, ok, es maybe.:-)). My two favorites: builtin read, and recursive glob. From rc-owner Sat Jul 24 22:37:33 1993 Received: from ncar.UCAR.EDU ([128.117.64.4]) by hawkwind.utcs.toronto.edu with SMTP id <2733>; Sat, 24 Jul 1993 22:37:09 -0400 Received: from niwot.scd.ucar.edu by ncar.ucar.EDU (5.65/ NCAR Central Post Off ice 03/11/93) id AA23674; Sat, 24 Jul 93 20:37:01 MDT From: djc@niwot.scd.ucar.EDU (Dennis Colarelli) Message-Id: <9307250236.AA20501@niwot.scd.ucar.EDU> Received: by niwot.scd.ucar.EDU (5.65/ NCAR Mail Server 04/10/90) id AA20501; Sat, 24 Jul 93 20:36:59 MDT Subject: Re: rc FAQ list To: alan@oldp.astro.wisc.edu (Alan Watson) Date: Sat, 24 Jul 1993 22:36:59 -0400 Cc: rc@hawkwind.utcs.toronto.edu In-Reply-To: <9307250044.AA21203@oldp.astro.wisc.edu>; from "Alan Watson" at Ju l 24, 93 8:44 pm X-Mailer: ELM [version 2.3 PL11] > Alan. > > P.S. I had a look at the zsh FAQ whilst I was revising -- the features > just blew my mind, but nothing prepared me for the final line of the > acknowledgements. Is it just me, or do these people really have their > own version of reality? > My experience on design is that: 1. It's easy to make things complicated 2. It's difficult to make things easy Trying to be as objective as possible, I find zsh more like (1) and rc like (2) (i.e., the design of rc requires less cognative dissonance during application than zsh). What's really wierd in this analysis is how zealous people are about their favorite shell. Dennis rc uber allis From rc-owner Sat Jul 24 23:06:57 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2733>; Sat, 24 Jul 1993 23:06:38 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA23269; Sat, 24 Jul 1993 22:06:14 -0500 Message-Id: <9307250306.AA23269@oldp.astro.wisc.edu> To: Scott Schwartz , djc@niwot.scd.ucar.EDU (Dennis Colarelli) Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: rc FAQ list Date: Sat, 24 Jul 1993 23:06:13 -0400 From: Alan Watson X-Mts: smtp To clarify my last message, the final line of the acknowledgements for the zsh FAQ list is: The world is eternally in the debt of Paul Falstad for inventing zsh in the first place. and it is this, and not the list of features in zsh, that causes me to doubt the author's grip on reality. Even the perl hackers haven't deified Larry Wall. From rc-owner Mon Jul 26 05:40:02 1993 Received: from holly.harlequin.co.uk ([193.128.4.58]) by hawkwind.utcs.toronto. edu with SMTP id <2738>; Mon, 26 Jul 1993 05:38:53 -0400 Received: from piaget.harlequin.co.uk by holly.harlequin.co.uk; Mon, 26 Jul 199 3 10:00:32 +0100 Received: from morris.harlequin.co.uk by piaget.harlequin.co.uk; Mon, 26 Jul 93 10:39:22 BST Date: Mon, 26 Jul 1993 05:33:37 -0400 From: Richard Brooksby To: Scott Schwartz Cc: Alan Watson , rc@hawkwind.utcs.toronto.edu X-Mailer: MM 0.90 Subject: Re: rc FAQ list In-Reply-To: <93Jul24.211605edt.2591@groucho.cse.psu.edu> Sat, 24 Jul 1993 21:16:45 -0400 Message-Id: > Anyway, zsh does have some good ideas that it wouldn't hurt rc to > adopt (ok, ok, es maybe.:-)). My two favorites: builtin read, and > recursive glob. I used zsh before I discovered rc, but for one reason only: recursive globbing. Zsh's globbing is better than find(1). I want a zsh-style recursive globbing program so that I can do: ls `{glob ****/*(W^@)} I realize that I could rip the code out of zsh, but I just don't have the time. --- Richard Brooksby ML Project and Collaborative Research / Harlequin +44 223 872522 (voice) / +44 223 872519 (fax) From rc-owner Mon Jul 26 06:00:44 1993 Received: from relay.pipex.net ([158.43.128.1]) by hawkwind.utcs.toronto.edu wi th SMTP id <2742>; Mon, 26 Jul 1993 06:00:26 -0400 Received: from pipex.net by relay.pipex.net with SMTP (PP) id <22060-0@relay.pipex.net>; Mon, 26 Jul 1993 10:59:42 +0100 To: Richard Brooksby Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: rc FAQ list In-Reply-To: From: Tim.Goodwin@pipex.net Date: Mon, 26 Jul 1993 05:58:00 -0400 Message-ID: <"relay.pipe.071:26.06.93.09.59.50"@pipex.net> > ls `{glob ****/*(W^@)} Can you enlighten us as to what this means? Tim. From rc-owner Tue Jul 27 22:16:52 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2752>; Tue, 27 Jul 1993 22:15:19 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA09362; Tue, 27 Jul 1993 21:15:12 -0500 Message-Id: <9307280215.AA09362@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: pathos script Date: Tue, 27 Jul 1993 22:15:11 -0400 From: Alan Watson X-Mts: smtp About a year ago John Mackin posted a pathos script. The idea was that you could use it in a front-end version of a standard command to invoke the a command further down the path. John noted that there was a problem if if a script got exec-ed with a relative pathname. I think I've come up with a way to get around this. All of those pwds can take a little while, but the additional bullet-proofing seems worthwhile to me as it doesn't cause much of a burden in the normal case. I prefer to use: exec `{ pathos $0 } $* as it alleviates the need to protect variables. On failure, pathos prints an error message on stderr and false on stdout, which I think is quite a nice way to deal with that situation. BTW, John, why did you choose the name `pathos'? Alan. #! /tmp/alan/bin/rc -- if ( ! ~ $#* 1 ) { echo >[2=1] usage: pathos path echo false exit 1 } thisdir = `{ dirname $1 } thisbase = `{ basename $1 } # shift $path past $thisdir * = $path if ( ~ $thisdir $* ) { while ( ! ~ $thisdir $1 ) { shift } } else { thisdir = `{ builtin cd $thisdir ; builtin pwd } while ( ! ~ $#* 0 && ! ~ $thisdir `{ builtin cd $1 ; builtin pwd } ) { shift } if ( ~ $#* 0 ) { echo >[1=2] pathos: unable to find $thisdir in path echo false exit 1 } } shift # look for executable $thisbase in remainder of $path # if whatis succeeds, it prints the path on stdout for us while ( ! ~ $#* 0 ) { if ( whatis $1/$thisbase >[2=] ) { exit 0 } shift } echo >[1=2] pathos: unable to find $thisbase echo false exit 1 # end-of-file From rc-owner Wed Jul 28 09:22:41 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2752>; Wed, 28 Jul 1993 09:22:11 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA10360; Wed, 28 Jul 1993 08:21:58 -0500 Message-Id: <9307281321.AA10360@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: pathos script Date: Wed, 28 Jul 1993 09:21:57 -0400 From: Alan Watson X-Mts: smtp Oops. That first `echo >[2=1]' should be `echo >[1=2]'. From rc-owner Fri Aug 13 16:54:30 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2685>; Fri, 13 Aug 1993 16:52:57 -0400 Return-Path: immd3.informatik.uni-erlangen.de!dalibor Received: from faui33.informatik.uni-erlangen.de ([131.188.33.2]) by hawkwind.u tcs.toronto.edu with SMTP id <2685>; Fri, 13 Aug 1993 11:47:48 -0400 Received: from faui30a.informatik.uni-erlangen.de by immd3.informatik.uni-erlan gen.de with SMTP (5.64+/7.2b-FAU) id AA03866; Fri, 13 Aug 93 17:47:35 +0200 From: Stefan Dalibor Message-Id: <9308131547.AA03866@faui33.informatik.uni-erlangen.de> Date: Fri, 13 Aug 1993 11:47:34 -0400 To: rc-owner Subject: Question about input redirection in -c Reply-To: dalibor@immd3.informatik.uni-erlangen.de Resent-To: rc Resent-Date: Fri, 13 Aug 1993 16:52:48 -0400 Resent-From: Chris Siebenmann Resent-Message-Id: <93Aug13.165257edt.2685@hawkwind.utcs.toronto.edu> Hi, from the manpage: -c If -c is present, commands are executed from the immediately following argument. Any further arguments to rc are placed in $*. and: exec [arg ...] Replaces rc with the given command. If the exec con- tains only redirections, then these redirections apply to the current shell and the shell does not exit. For example, exec >[2] err.out places further output to standard error in the file err.out. this made me think rc -c 'pwd; . /dev/tty' would have the same effect as rc -c 'pwd; exec ; Fri, 13 Aug 1993 17:41:30 -0400 Return-Path: netcom.com!netapp!ghoti.netapp.com!byron Received: from netcomsv.netcom.com ([163.179.1.13]) by hawkwind.utcs.toronto.ed u with SMTP id <2689>; Fri, 13 Aug 1993 17:40:29 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA29703; Fri, 13 Aug 93 14:16:19 PDT Received: from ghoti.netapp.com by netapp.com (4.1/SMI-4.1) id AA15138; Fri, 13 Aug 93 14:17:30 PDT Received: by ghoti.netapp.com (4.1/SMI-4.1) id AA29751; Fri, 13 Aug 93 14:17:13 PDT Date: Fri, 13 Aug 1993 17:17:13 -0400 From: Byron Rakitzis Message-Id: <9308132117.AA29751@ghoti.netapp.com> To: dalibor@immd3.informatik.uni-erlangen.de, rc-owner Subject: Re: Question about input redirection in -c Resent-To: rc Resent-Date: Fri, 13 Aug 1993 17:41:17 -0400 Resent-From: Chris Siebenmann Resent-Message-Id: <93Aug13.174130edt.2689@hawkwind.utcs.toronto.edu> exec; Mon, 16 Aug 1993 12:19:25 -0400 Received: from schroeder.nosc.mil by trout.nosc.mil (5.59/1.27) id AA16787; Mon, 16 Aug 93 09:19:09 PDT Message-Id: <9308161619.AA16787@trout.nosc.mil> Received: by peanuts.nosc.mil; Mon, 16 Aug 93 09:19:04 PDT Date: Mon, 16 Aug 1993 12:19:04 -0400 From: broman@peanuts.nosc.mil (Vincent Broman) To: rc@hawkwind.utcs.toronto.edu Subject: How to edit filenames in rc scripts without sed Reply-To: broman@trout.nosc.mil One of the csh features I find useful, and don't know how to emulate easily in rc, is the variable substitution with modifiers. This lets you edit filenames to a certain degree without execing sed all over the place. E.g. undoing patches with: foreach f (*.orig) mv $f $f:r end is nicer than for ( f in *.orig ) mv $f `{echo $f | sed -e 's/\.[a-z]*$//'} I've tried thinking up ways to get this effect by manipulating the IFS to include '.' but I still get `{echo $f| ...stuff... } Any ideas how to do basic filename modifications cleanly in rc? Vincent Broman, code 572 Bayside Phone: +1 619 553 1641 Naval Command Control and Ocean Surveillance Center, RDT&E Div. San Diego, CA 92152-6147, USA Email: broman@nosc.mil From rc-owner Mon Aug 16 12:31:31 1993 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.e du with SMTP id <2699>; Mon, 16 Aug 1993 12:31:17 -0400 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Mon, 16 Aug 1993 17:30:19 +0100 Received: by zombie. (5.0/SMI-SVR4) id AA13738; Mon, 16 Aug 93 17:30:19 BST Date: Mon, 16 Aug 1993 12:30:19 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Illegal-Object: Syntax error in Message-Id: value found on hawkwind.utcs.toront o.edu: Message-Id: <9308161630.AA13738@zombie.> ^-illegal subdomain in domai n To: broman Subject: Re: How to edit filenames in rc scripts without sed Cc: rc@hawkwind.utcs.toronto.edu X-Sun-Charset: US-ASCII Content-Length: 276 For the (vaguely frequent) mv and cp commands, i use specialised commands that allow wildcards, called 'move' and 'copy': ; mv '*.c' '*.c.old' for anything else, i'm into the once-per-month-if-that kind of command, and using sed's quicker than thinking about it:-). steve From rc-owner Mon Aug 16 13:08:53 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2702>; Mon, 16 Aug 1993 13:08:35 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA17951; Mon, 16 Aug 1993 12:08:25 -0500 Message-Id: <9308161708.AA17951@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: How to edit filenames in rc scripts without sed Date: Mon, 16 Aug 1993 13:08:24 -0400 From: Alan Watson X-Mts: smtp I concur with Steve. However, I would like to point out one possible problem with basename in this regard -- many basename executables are /bin/sh scripts which call expr three times. On my machine, the difference in speed between the /bin/sh-based system basename and the pure-binary GNU basename is a factor of 4 (which is the difference in the number of fork/exec pairs). Anything based on ifs separation will probably come to grief on file names containing repeated dots, such as `foo..bar'. Alan. From rc-owner Wed Aug 18 12:53:12 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2728>; Wed, 18 Aug 1993 12:51:08 -0400 Return-Path: immd3.informatik.uni-erlangen.de!dalibor Received: from faui33.informatik.uni-erlangen.de ([131.188.33.2]) by hawkwind.u tcs.toronto.edu with SMTP id <2727>; Wed, 18 Aug 1993 03:47:48 -0400 Received: from faui30a.informatik.uni-erlangen.de by immd3.informatik.uni-erlan gen.de with SMTP (5.64+/7.2b-FAU) id AA13051; Wed, 18 Aug 93 09:47:27 +0200 From: Stefan Dalibor Message-Id: <9308180747.AA13051@faui33.informatik.uni-erlangen.de> Date: Wed, 18 Aug 1993 03:47:25 -0400 To: rc-owner Subject: Re: Question about input redirection in -c Reply-To: dalibor@immd3.informatik.uni-erlangen.de Resent-To: rc Resent-Date: Wed, 18 Aug 1993 12:50:58 -0400 Resent-From: Chris Siebenmann Resent-Message-Id: <93Aug18.125108edt.2728@hawkwind.utcs.toronto.edu> > I.e., you are conflating "stdin" with "the place rc reads commands > from". Yes, thanks - I was indeed under the impression that `<' would do input source redirection, not just file-descriptor manipulation. In the end, it turned out to be easy (like most things with rc): rc -c 'pwd; exec <0=]; . -i /dev/tty' does what I want (use readline() when sourcing the tty). Some memory nitpicking: Purify suggested the following changes to input.c; the first hunk avoids a memory leak when using rc with readline (the documentation for GNU-readline says that the strings returned by readline() should be freed if no longer needed), the second prevents accessing uninitialized memory (as istack's fd-component isn't initialized by pushstring()). The diffs are against plain rc-1.4. Purify detected a few other minor memory leaks, but I leave it to the author to plug them in the next release, as promised in an earlier message :). Stefan *** rc-1.4/input.c Fri Dec 11 10:21:17 1992 --- input.c Tue Aug 17 17:04:51 1993 *************** *** 129,132 **** --- 129,133 ---- strcpy(inbuf+2, rlinebuf); strcat(inbuf+2, "\n"); + efree(rlinebuf); } } else *************** *** 214,222 **** efree(inbuf); --istack; ! realgchar = (istack->t == iString ? stringgchar : fdgchar); ! if (istack->fd == -1) { /* top of input stack */ realgchar = dead; realugchar = ugdead; } last = istack->last; eofread = istack->eofread; --- 215,226 ---- efree(inbuf); --istack; ! if(istack->t == iString) ! realgchar = stringgchar; ! else if (istack->fd == -1) { /* top of input stack */ realgchar = dead; realugchar = ugdead; } + else + realgchar = fdgchar; last = istack->last; eofread = istack->eofread; From rc-owner Sat Sep 4 14:49:41 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2749>; Sat, 4 Sep 1993 14:46:52 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA11931; Sat, 4 Sep 1993 13:46:40 -0500 Message-Id: <9309041846.AA11931@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: rc FAQ list Date: Sat, 4 Sep 1993 14:46:39 -0400 From: Alan Watson X-Mts: smtp Coming to a news feed near you. Multiple times, in fact. There's nothing quite like screwing up before an audience of thousands of your peers when it comes to putting a crimp in your day, is there? I'll be making future (single) postings on or around the 5th of each month. The major difference between this version and the last is that the heterogeneous cluster section has become more sane Thanks to everyone who helped get this of the ground, Alan. From rc-owner Sat Sep 4 18:13:27 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2749>; Sat, 4 Sep 1993 18:10:53 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA13356; Sat, 4 Sep 1993 17:10:50 -0500 Message-Id: <9309042210.AA13356@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: RCRC Date: Sat, 4 Sep 1993 18:10:49 -0400 From: Alan Watson X-Mts: smtp Although we have all worked out our own favorite work-arounds for the rsh problem, I think I've come up with an rc specific solution which is quite elegant: During start-up, rc examines the environment variable RCRC. If the variable is set, rc attempts to source the file to which it refers; otherwise it sources .rcrc. Before sourcing the file, rc sets RCRC to be the null string. If the attempt to source the file fails, rc does not report an error. So what happens in some common situations? login: RCRC is unset, so rc sets it to "" and sources .rcrc. rsh: ditto. exec of rc from beneath a login/rsh shell: RCRC is set to "", so the open() fails and nothing gets sourced. All this seems to cost us in performance terms is a getenv() and open() after each exec, and I very much doubt anyone will notice that. We gain a useful improvement in rc's interaction with the rest of UNIX, and open up an interesting means to customize environments (by setting RCRC in .rcrc). Some things will break (like running rc in a clean environment from env), but I can't think of anything too important. If you don't like the silence on error, then have rc set RCRC to /dev/null before sourcing the file it points to. Any comments? From rc-owner Sat Sep 4 18:22:38 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2751>; Sat, 4 Sep 1993 18:20:17 -0400 To: rc Subject: Re: RCRC In-reply-to: alan's message of Sat, 04 Sep 93 18:10:49 -0400. <9309042210.AA13356@oldp.astro.wisc.edu> Date: Sat, 4 Sep 1993 18:20:09 -0400 From: Chris Siebenmann Message-Id: <93Sep4.182017edt.2751@hawkwind.utcs.toronto.edu> My .rcrc produces output; sourcing it on rsh will thus produce errors from things like rdist and rcp. Rsh is different from a login; treating them the same is a mistake. - cks From rc-owner Sat Sep 4 19:06:18 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2749>; Sat, 4 Sep 1993 19:06:06 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA14291; Sat, 4 Sep 1993 18:05:58 -0500 Message-Id: <9309042305.AA14291@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: RCRC Date: Sat, 4 Sep 1993 19:05:57 -0400 From: Alan Watson X-Mts: smtp I don't propose to treat them the same within .rcrc. The rc that I eventually exec from rsh sources my .rcrc at the moment, so I have the following in my .rcrc: [set path, define fns, etc.] if ( test -t 0 ) { [set tty, check mail, etc.] } There are many variations on this. Yes, you will have to rewrite your .rcrc, but I was assuming that most people were already using wrappers around rsh or rc to source .rcrc. Perhaps I was wrong. From rc-owner Sun Sep 5 08:17:11 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2752>; Sun, 5 Sep 1993 08:16:30 -0400 Received: by mod.civil.su.oz.au id <28700>; Sun, 5 Sep 1993 22:15:44 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Sun, 5 Sep 1993 08:00:12 -0400 To: The rc Mailing List Subject: Re: RCRC In-Reply-To: <9309042210.AA13356@oldp.astro.wisc.edu> Message-ID: <199309052200.22034.rc.bakup@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ I am afraid I think Alan's idea is terrible. You said it yourself, Alan: `[W]e have all worked out our own favorite work-arounds for the rsh problem.' The problems with this idea are several-fold. Firstly, and least seriously: you're adding overhead on every rc startup in order to see whether something needs to be done that will only happen a tiny minority of times. Yes, the added overhead is small. It's still there. Secondly, I add my voice to Chris's objection: rsh is different from a login. The _correct_ solution to this problem is simple: a wrapper around rsh. Thirdly, and more seriously, the proposal involves changing rc's code, and the semantics of its startup. This is bad. We should need a _tremendously_ good reason to make any such changes to rc at this late stage: its semantics should be viewed as set in stone, or as close to it as makes no difference. I hardly think any imagined payoff here can be worth the price. Fourthly, lastly and the final nail in the idea's coffin: it's not portable and cannot be made portable. [I'm surprised, Alan, that someone with your extensive knowledge of UNIX history could make this mistake.] On _real_ (say, Seventh Edition) UNIX systems, attempts to open the null string for read _succeed_, and open the current directory (always assuming, of course, that the current directory's mode allows it to be opened for read). This is actually a logical necessity: the degenerate non-rooted pathname must refer to the current directory. Indeed, it even says it does in Thompson & Ritchie. `Modern' UNIX systems that call opening '' for read an error are broken. Even if you don't accept that, the fact that some systems _will_ open '' for read means that there is NO pathname that you can use that you can guarantee will not be able to be opened for read, if you want the code to be portable. (Please don't suggest opening it for write. Yes, I know that would `work,' if you call that working.) Sorry, Alan, I can't go for this one. OK, John. From rc-owner Tue Sep 14 06:00:01 1993 Received: from SINet.SLB.COM ([163.185.18.1]) by hawkwind.utcs.toronto.edu with SMTP id <2755>; Tue, 14 Sep 1993 05:57:22 -0400 Received: from sndrtr.psi by SINet.SLB.COM id AA20951; Tue, 14 Sep 93 10:00:10 GMT From: gjv%atlas%cesar@crbca1.SINet.SLB.COM Message-Id: <9309141000.AA20951@SINet.SLB.COM> Apparently-To: "hawkwind.utcs.toronto.edu::rc" X-Vms-From: PSI%CRBCA1::CESAR::ATLAS::"gjv" X-Vms-To: HERMES::M_MAILNOW::M_INTERNET::HAWKWIND.UTCS.TORONTO.EDU::RC Received: by DniMail (v1.0); Tue Sep 14 11:56:35 1993 MET DST Received: from pyxis by atlas.atlasnis (4.1/SMI-4.1-DNI) id AA26978; Tue, 14 Sep 93 11:56:18 +0200 To: rc%hawkwind.utcs.toronto.edu%m_internet%m_mailnow%hermes.DECnet@cesar. sedalia.sinet.slb.com Reply-To: vons@cesar.crbca1.sinet.slb.com Return-Receipt-To: vons@cesar.crbca1.sinet.slb.com Subject: Something for the FAQ ? Date: Tue, 14 Sep 1993 05:56:23 -0400 Hello all, I was just wondering, is there a collection of useful functions somewhere? I found some in the FAQ and in the mail list archive of course, but I assume that there are a lot more useful things out there, which could be made more accessible when added to the FAQ for example. What made me think of this is the following: I'm using the prompt function for the initialisation of interactive subshells, but this makes $status unusable if you aren't careful. I came up with the following, which seems to work nicely. (init is a function to initialise the subshell). fn prompt { s=$status { if ( ! ~ $ipid $pid ) { ipid=$pid # one time call to init_shell(), initialises interactive subshell init_shell } return $s } } You can't simply save&restore $status, since the assignment to $status itself would change the status. I also wrote the next functions in order to be able to clean up my $path (removing duplicates), or to remove an entry. # remove(varname, elt) removes elt from $varname fn remove { vn=$1 e=$2 o=() *=$$vn{ while( ! ~ $#* 0) { ~ $*(1) $e || o=($o $*(1) ) shift } $vn=$o } } # clean(varname) removes all double entries from $varname, keeping the first fn clean { vn=$1 o=() *=$$vn{ while( ! ~ $#* 0) { ~ $o $*(1) || o=($o $*(1) ) shift } $vn=$o } } # example clean path remove path /usr/bin The only thing to add is the support for ':' separated lists, like MANPATH,FONTPATH,HELPPATH,LD_LIBRARY_PATH which don't have a list-equivalent like PATH/path. Thought it might be useful to have this kind of stuff in a place where it can easily be found, like the FAQ for example. Gert-Jan --------------------------------------------------- J.G. Vons E-Mail: vons@cesar.crbca1.sinet.slb.com From rc-owner Wed Sep 15 13:40:30 1993 Received: from dealer.Cards.COM ([192.133.70.2]) by hawkwind.utcs.toronto.edu w ith SMTP id <2060>; Wed, 15 Sep 1993 13:38:09 -0400 Received: from monte (monte.cards.com) by dealer.Cards.COM (4.1/mls/3.2) id AA07316; Wed, 15 Sep 93 13:37:44 EDT Message-Id: <9309151737.AA07316@dealer.Cards.COM> Received: by monte (4.1/mls/3.2) id AA04685; Wed, 15 Sep 93 13:37:43 EDT From: carvell@Cards.COM Subject: Need help with input loop (long) To: rc@hawkwind.utcs.toronto.edu Date: Wed, 15 Sep 1993 13:37:42 -0400 Content-Type: text Content-Length: 3588 Folks, I'm having a strange problem and I hoped some kind soul out there could help me. I'm sure i'ts something obvious but for the life of me I can't spot it. I am using a Sun SPARC IPC running SunOS 4.1.3. My rc was compiled with gcc and includes GNU readline. Below is a scaled down version of the script which exhibits the behavior in question. What I would LIKE to see happen is, I type in lines of text and each line is echoed. When I hit ^D to end my input, the break should execute, and the script should drop out of the while loop and exit. What is ACTUALLY happening is, when I hit ^D, I get an error "read: Bad file number" and a message "Your input was: BOTTOM OF LOOP". Then it goes back to the top of the loop (even though the trace shows that break is being executed!!!) and gives me another prompt. It looks like the echo at the bottom of the loop is being fed back into line. To implement my read function, I'm using the UNIX (or at least Sun UNIX) line program. Basically it echoes input from stdin, and returns a status of 1 on eof (I've verified this). If any of you rc gurus can show me what I'm doing wrong, I would REALLY REALLY appreciate it. Sadly, I'm the only rc user at my site; everybody else here is still in the dark ages with /bin/sh. Gary -- Gary Carvell Galaxy Global Corporation Mail: carvell@cards.com Voice: 304-363-1759 Fax: 304-363-1766 - - - file: trythis - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #!/usr/local/bin/rc # read var # read stdin into a variable; return a status of 1 on eof fn read { $1=`{/usr/bin/line; if(! ~ $status 0) return 1} } fn trythis { while() { echo -n '-> ' read input if(! ~ $status 0) break echo Your input was: $input } echo BOTTOM OF LOOP } trythis - - - sample output - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /home/dealer/carvell- trythis -> hi there Your input was: hi there -> testing Your input was: testing -> read: Bad file number <--- [here I hit ^D at the prompt] Your input was: BOTTOM OF LOOP -> read: Bad file number "" Your input was: BOTTOM OF LOOP -> read: Bad file number "" Your input was: BOTTOM OF LOOP -> ^C /home/dealer/carvell- - - - sample output when using -x flag on rc - - - - - - - - - - - - - - - - - /home/dealer/carvell- trythis fn read {$1=`{/usr/bin/line;if(! ~ $status 0)return 1}} fn trythis {while(()){echo -n '-> ';read input;if(! ~ $status 0)break;echo Your inp ut was: $input};echo BOTTOM OF LOOP} trythis echo -n '-> ' -> read input /usr/bin/line hi there ~ 0 0 input=(hi there) ~ 0 0 echo Your input was: hi there Your input was: hi there echo -n '-> ' -> read input /usr/bin/line testing ~ 0 0 input=testing ~ 0 0 echo Your input was: testing Your input was: testing echo -n '-> ' -> read input /usr/bin/line ~ 1 0 return 1 ~ 1 0 break echo BOTTOM OF LOOP read: Bad file number <----- !!!! input=(BOTTOM OF LOOP) ~ 0 0 echo Your input was: BOTTOM OF LOOP Your input was: BOTTOM OF LOOP echo -n '-> ' -> read input /usr/bin/line ~ 1 0 return 1 ~ 1 0 break echo BOTTOM OF LOOP read: Bad file number <----- !!!! input=(BOTTOM OF LOOP) ~ 0 0 echo Your input was: BOTTOM OF LOOP Your input was: BOTTOM OF LOOP echo -n '-> ' -> read input /usr/bin/line ~ 1 0 return 1 ~ 1 0 break echo BOTTOM OF LOOP read: Bad file number <----- !!!! input=(BOTTOM OF LOOP) ~ 0 0 echo Your input was: BOTTOM OF LOOP Your input was: BOTTOM OF LOOP echo -n '-> ' -> read input /usr/bin/line ^C /home/dealer/carvell- From rc-owner Wed Sep 15 13:56:17 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2060>; Wed, 15 Sep 1993 13:55:58 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA08815; Wed, 15 Sep 1993 19:55: 37 +0200 Received: by dahlie.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA07154; Wed, 15 Sep 93 19:55:36 +0200 Date: Wed, 15 Sep 1993 13:55:36 -0400 From: malte@TechFak.Uni-Bielefeld.DE To: Message-Id: <9309151755.AA07154@dahlie.techfak.uni-bielefeld.de> Content-Type: text Content-Length: 627 Apparently-To: rc@hawkwind.utcs.toronto.edu Just because there's some life sign on this list again: What I really do miss in rc is orthogonality in list operators. There's a left shift "shift [n]", but no right shift. I'd like to propose negative shift values to implement this. There's a simple way to pick some element from a list, but not to drop one. Maybe we could use negative numbers for that too, e.g. droppping the fifth element from a list reads "$x(-5)". Then, the solution to the annoying problem of dropping the last element from a list is "last = $x(-$#x)" What do you think of this? Will it break scripts ( besides already broken ones )? Malte From rc-owner Wed Sep 15 13:56:48 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2062>; Wed, 15 Sep 1993 13:56:30 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA08819; Wed, 15 Sep 1993 19:55: 53 +0200 Received: by dahlie.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA07158; Wed, 15 Sep 93 19:55:51 +0200 Date: Wed, 15 Sep 1993 13:55:51 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9309151755.AA07158@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: list operators Content-Length: 627 Just because there's some life sign on this list again: What I really do miss in rc is orthogonality in list operators. There's a left shift "shift [n]", but no right shift. I'd like to propose negative shift values to implement this. There's a simple way to pick some element from a list, but not to drop one. Maybe we could use negative numbers for that too, e.g. droppping the fifth element from a list reads "$x(-5)". Then, the solution to the annoying problem of dropping the last element from a list is "last = $x(-$#x)" What do you think of this? Will it break scripts ( besides already broken ones )? Malte From rc-owner Wed Sep 15 14:07:06 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2060>; Wed, 15 Sep 1993 14:06:49 -0400 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA03799; Wed, 15 Sep 93 14:06:28 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA27510; Wed, 15 Sep 93 14:07: 00 -0400 Date: Wed, 15 Sep 1993 14:07:00 -0400 From: rsalz@osf.org Message-Id: <9309151807.AA27510@sulphur.osf.org> To: rc-owner@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: list operators Err, what's wrong with foo=('' $foo) to implement right shift? From rc-owner Wed Sep 15 14:38:55 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2060>; Wed, 15 Sep 1993 14:29:46 -0400 Received: from farn.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA08955; Wed, 15 Sep 1993 20:28: 58 +0200 Received: by farn.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA08875; Wed, 15 Sep 93 20:28:58 +0200 Date: Wed, 15 Sep 1993 14:28:58 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9309151828.AA08875@farn.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: list operators Content-Length: 320 Sorry, but what I mean is (left) shift ; * = ( 1 2 ) ; echo $* 1 2 ; shift ; echo $* 2 ; shift ; echo $* ; shift cannot shift right shift ; * = ( 4 5 6 7 ) ; echo $* 4 5 6 7 ; shift -3 ; echo $* 4 and dropping one element from a list: * = ( 1 2 3 4 ) ; echo $*(-3) 3 ; echo $* 1 2 4 Malte From rc-owner Wed Sep 15 14:52:35 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2062>; Wed, 15 Sep 1993 14:52:07 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA26050; Wed, 15 Sep 1993 13:52:03 -0500 Message-Id: <9309151852.AA26050@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Need help with input loop (long) Date: Wed, 15 Sep 1993 14:52:03 -0400 From: Alan Watson X-Mts: smtp > fn read { > $1=`{/usr/bin/line; if(! ~ $status 0) return 1} > } I believe your attempt to return from a command substitution within a function is causing rc to get thoroughly confused. I must admit that I can't decide whether to be appalled or impressed by your novel use of this construct! Getting read right it tricky. I recommend the read command in the FAQ (although make sure you have $nl defined -- fixed in the next version). Alan. From rc-owner Wed Sep 15 15:01:10 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2060>; Wed, 15 Sep 1993 15:00:54 -0400 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA08474; Wed, 15 Sep 93 15:00:30 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA27956; Wed, 15 Sep 93 15:01: 03 -0400 Date: Wed, 15 Sep 1993 15:01:03 -0400 From: rsalz@osf.org Message-Id: <9309151901.AA27956@sulphur.osf.org> To: rc-owner@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: list operators ; * = ( 4 5 6 7 ) ; echo $* 4 5 6 7 ; shift -3 ; echo $* 4 # rshift varname count fn rshift { i=() save=() tmp=() { count=`{ expr $#$1 - $2 } ~ $count -* && { echo cannot rshift >[1=2]; return 1 } save=$1 *=( $$1 ) for (i) { tmp=( $tmp $i ) ~ $#tmp $count && break } $save=( $tmp ) } } rn rshift-test { foo=(1 2 3 4 5 6) echo foo before is $foo rshift foo 2 echo foo after is $foo echo echo foo before is $foo rshift foo 12 || echo rshift failed. echo foo after is $foo } foo before is 1 2 3 4 5 6 foo after is 1 2 3 4 foo before is 1 2 3 4 cannot rshift rshift failed. foo after is 1 2 3 4 From rc-owner Wed Sep 15 15:47:44 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2060>; Wed, 15 Sep 1993 15:47:13 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21415; Wed, 15 Sep 93 15:47:03 -0400 Received: from srg.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 154600.22919; Wed, 15 Sep 1993 15:46:00 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa01257; Wed, 15 Sep 93 15:37:41 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: malte@techfak.uni-bielefeld.de, rc@hawkwind.utcs.toronto.edu Subject: Re: list operators Date: Wed, 15 Sep 1993 15:38:27 -0400 Message-Id: <9309151538.aa26471@ceres.srg.af.mil> I'm not much worried about these proposals because I just can't imagine Byron incorporating them into the mainstream rc, but also just couldn't resist making some comment on the second one. > and dropping one element from a list: > > * = ( 1 2 3 4 ) > ; echo $*(-3) > 3 > ; echo $* > 1 2 4 > > Malte The proposed syntax is a REALLY BAD IDEA. Now something like: ; x = ( 1 2 3 4 5 ) ; y = $x(-3) # all members except 3 ; echo $x 1 2 3 4 5 ; echo $y 1 2 4 5 might be reasonable, but having a reference to the list modify it (without assignment) is really disgustingly bad taste. Tom From rc-owner Wed Sep 15 16:10:07 1993 Received: from duality.gnu.ai.mit.edu ([128.52.46.236]) by hawkwind.utcs.toront o.edu with SMTP id <2060>; Wed, 15 Sep 1993 16:09:41 -0400 Received: from localhost (mycroft@localhost) by duality.gnu.ai.mit.edu (8.3/8.3 ) id QAA02254; Wed, 15 Sep 1993 16:08:41 -0400 Date: Wed, 15 Sep 1993 16:08:41 -0400 From: Charles Hannum Message-Id: <199309152008.QAA02254@duality.gnu.ai.mit.edu> To: culliton@srg.srg.af.mil CC: malte@techfak.uni-bielefeld.de, rc@hawkwind.utcs.toronto.edu In-reply-to: <9309151538.aa26471@ceres.srg.af.mil> (culliton@srg.srg.af.mil) Subject: Re: list operators ; x = ( 1 2 3 4 5 ) ; y = $x(-3) # all members except 3 Having that be `all members except the 3rd one' would be okay. Having it be `all members except the one that matches the string `3'' would be gross. The latter requires a different syntax. From rc-owner Wed Sep 15 16:48:21 1993 Received: from boeygen.nr.no ([156.116.1.2]) by hawkwind.utcs.toronto.edu with SMTP id <2060>; Wed, 15 Sep 1993 16:47:26 -0400 Received: from nr.no by boeygen.nr.no with SMTP (PP) id <19171-0@boeygen.nr.no> ; Wed, 15 Sep 1993 22:47:10 +0200 To: rc@hawkwind.utcs.toronto.edu Subject: Re: list operators Date: Wed, 15 Sep 1993 16:47:08 -0400 From: Brynjulv Hauksson Message-ID: <"boeygen.nr.173:15.08.93.20.47.12"@nr.no> When I started using rc I thought it lacked some list operators, and eventually placed these definitions in my `.rcrc': # vshift var [num] -- shift $var num (default 1) places fn vshift {v = $1 n = $2 {* = $$v && shift $n && $v = $*}} # vrev var -- reverse the list in $var fn vrev {v = $1 d = () {* = $$v && for(i in $*){d = ($i $d)} && $v = $d}} # vchop var [num] -- remove last num (default 1) elems of $var fn vchop {v = $1 {vrev $v && vshift $v $2 && vrev $v}} There are probably faster, more elegant and/or more robust ways of doing it. I haven't worried much about it, since it turned out that I almost never use these functions anyway :-) - brynjulv From rc-owner Wed Sep 15 17:14:33 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2060>; Wed, 15 Sep 1993 17:14:10 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25272; Wed, 15 Sep 93 17:14:03 -0400 Received: from srg.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 171301.1389; Wed, 15 Sep 1993 17:13:01 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa03038; Wed, 15 Sep 93 17:03:25 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: culliton@srg.srg.af.mil, mycroft@duality.gnu.ai.mit.edu Subject: Re: list operators Cc: malte@techfak.uni-bielefeld.de, rc@hawkwind.utcs.toronto.edu Date: Wed, 15 Sep 1993 17:04:08 -0400 Message-Id: <9309151704.aa26993@ceres.srg.af.mil> >> ; x = ( 1 2 3 4 5 ) >> ; y = $x(-3) # all members except 3 > >Having that be `all members except the 3rd one' would be okay. Having >it be `all members except the one that matches the string `3'' would >be gross. The latter requires a different syntax. Agreed, that was my intention, to exclude the 3rd element. ; x=(a b c d e) ; echo $x(-1 -5) b c d It's probably/hopefully just academic anyways. We really shouldn't be making changes like this to rc at this point in the game. From rc-owner Wed Sep 15 23:56:21 1993 Received: from netcomsv.netcom.com ([163.179.1.13]) by hawkwind.utcs.toronto.ed u with SMTP id <2062>; Wed, 15 Sep 1993 23:56:00 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA19016; Wed, 15 Sep 93 11:31:24 PDT Received: from ghoti.netapp.com by netapp.com (4.1/SMI-4.1) id AA11377; Wed, 15 Sep 93 11:29:20 PDT Received: by ghoti.netapp.com (4.1/SMI-4.1) id AA09696; Wed, 15 Sep 93 11:29:11 PDT Date: Wed, 15 Sep 1993 14:29:11 -0400 From: byron@ghoti.netapp.com (Byron Rakitzis) Message-Id: <9309151829.AA09696@ghoti.netapp.com> To: malte@techfak.uni-bielefeld.de, rc@hawkwind.utcs.toronto.edu Subject: Re: list operators >What I really do miss in rc is orthogonality in list operators. > There's a left shift "shift [n]", but no right shift. Hm. I think you could make the same argument about lisp. There is no way to shift right, other than by applying rev, cdr, rev. What is wrong with defining a function in rc to do this for you? From rc-owner Thu Sep 16 06:12:21 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2062>; Thu, 16 Sep 1993 06:11:26 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA15850; Thu, 16 Sep 1993 12:11: 04 +0200 Received: by dahlie.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA08368; Thu, 16 Sep 93 12:11:02 +0200 Date: Thu, 16 Sep 1993 06:11:02 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9309161011.AA08368@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: list operators Content-Length: 1095 Thanks to all of you for your quick answers! But let my summarize and the take the discussion a little further: 1) It is too late to introduce changes It's not really a change since it doesn't change the semantics of existing, valid scripts. 2) The syntax is bad Yes !! Maybe its an alt.tasteless candidate. 3) A semantic improvement I should have thought of that! Of course, ; x = ( 1 2 3 4 ) echo $x( -1 -3 ) 2 4 is much better. 4) Why not use a function Thanks to all who disclosed their solutions, but I already had some. I think, there's more then one point of view to it: Experienced rc users certainly don't have problems to write a function doing the work, to put it in some kind of library and to reuse it on other occasions. But the notion of "omit it if you can write a function" doesn't help novices and - be honest to yourself - isn't it boring that you always have to source some other file to include a function in your script ( . /some/file || exit )? So it's speed and beauty vs usability. I'm still convinced my suggestions enhance both. Malte From rc-owner Fri Sep 17 09:15:09 1993 Received: from SINet.SLB.COM ([163.185.18.1]) by hawkwind.utcs.toronto.edu with SMTP id <2062>; Fri, 17 Sep 1993 09:12:25 -0400 Received: from snmrtr.psi by SINet.SLB.COM id AA21670; Fri, 17 Sep 93 13:15:02 GMT From: gjv%atlas%cesar@crbca1.SINet.SLB.COM Message-Id: <9309171315.AA21670@SINet.SLB.COM> Apparently-To: "hawkwind.utcs.toronto.edu::rc" X-Vms-From: PSI%CRBCA1::CESAR::ATLAS::"gjv" X-Vms-To: HERMES::M_MAILNOW::M_INTERNET::HAWKWIND.UTCS.TORONTO.EDU::RC Received: by DniMail (v1.0); Fri Sep 17 15:11:08 1993 MET DST Received: from pyxis by atlas.atlasnis (4.1/SMI-4.1-DNI) id AA08319; Fri, 17 Sep 93 15:10:30 +0200 To: rc%hawkwind.utcs.toronto.edu%m_internet%m_mailnow%hermes.DECnet@cesar. sedalia.sinet.slb.com Reply-To: vons@cesar.crbca1.sinet.slb.com Subject: Another vote for a built-in read function Date: Fri, 17 Sep 1993 09:10:54 -0400 Hello all, When processing text files in sh scripts, I often use something like the following: while read a | while read a b do or do # some sh stuff # some sh stuff done < /some/file done This works fine, but how do you do something like that in rc ? It works if you write (don't care about the tab-char for the moment): ifs=($nl) { for(line in `{cat /some/file}) { ifs=(' ' $nl) eval 'word=('$line')' a=$word(1) b=$word(2) # do rc stuff } } or while (read line) # using the read function from the FAQ { eval 'word=('$line')' a=$word(1) b=$word(2) # do rc stuff } < /some/file IMHO, having to fork&exec a cat to read from a file is a sad thing, not to mention the ugly hack to get at the words. The second one with the read is simply terribly slow, about a 100 times slower than a similar sh script. Can't we just add a builtin read which uses the $ifs when converting the input line to a list ? Something like echo a b | {read words; echo $#words ; echo $words(1); echo $words(2) } would give 2 a b Of course I could write a function for this, but that basically means that the ugly hack is moved elsewhere. And another thing, just try 'read lines' with the read function from the FAQ. It returns an empty string because there is a private variable with the same name inside the read function. This means that you must always be aware of what is going inside the read(). It is not just speed here, there is some simplicity and/or elegance involved as well. Same as the builtin echo, you know what it does, no problems with external bsd/sysv echo differences, \-escapes and all that. And the speed is a nice extra of course. What do you al think of this ? Gert-Jan PS: I think that a \-escape would be a good idea too. We have some company tools here that usually have an '=' in the argument list, while others (and lpr as well) use the '-# '. Putting these chars between quotes works of course, but simply prefixing them with a \ is much simpler/nicer. And don't forget that the \ is already in use in order to escape a newline, so it is not completely new anyway. It is just confusing when you know about the backslash mechanism, in rc it continues to work at end-of-line but stops doing so in other cases. --------------------------------------------------- J.G. Vons E-Mail: vons@cesar.crbca1.sinet.slb.com From rc-owner Fri Sep 17 09:36:17 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2237>; Fri, 17 Sep 1993 09:36:00 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA24901; Fri, 17 Sep 1993 15:35: 31 +0200 Received: by dahlie.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA11887; Fri, 17 Sep 93 15:35:29 +0200 Date: Fri, 17 Sep 1993 09:35:29 -0400 From: malte@TechFak.Uni-Bielefeld.DE To: Message-Id: <9309171335.AA11887@dahlie.techfak.uni-bielefeld.de> Content-Type: text Content-Length: 414 Apparently-To: rc@hawkwind.utcs.toronto.edu I have not decided yet wether a builtin read is a good idea or not. Meanwhile let me help you with this for( line in `` ($nl) { cat /some/file }){ words = `{ echo $line } } But I don't understand how your second solution works because there must be something wrong with input redirection. My rc behaves like this: ; while( echo outside ){ echo inside } > /dev/null outside outside .. Malte From rc-owner Fri Sep 17 09:56:05 1993 Received: from SINet.SLB.COM ([163.185.18.1]) by hawkwind.utcs.toronto.edu with SMTP id <2461>; Fri, 17 Sep 1993 09:55:49 -0400 Received: from snmrtr.psi by SINet.SLB.COM id AA24431; Fri, 17 Sep 93 13:58:30 GMT From: gjv%atlas%cesar@crbca1.SINet.SLB.COM Message-Id: <9309171358.AA24431@SINet.SLB.COM> Apparently-To: "hawkwind.utcs.toronto.edu::rc" X-Vms-From: PSI%CRBCA1::CESAR::ATLAS::"gjv" X-Vms-To: HERMES::M_MAILNOW::M_INTERNET::HAWKWIND.UTCS.TORONTO.EDU::RC Received: by DniMail (v1.0); Fri Sep 17 15:54:37 1993 MET DST Received: from pyxis by atlas.atlasnis (4.1/SMI-4.1-DNI) id AA12228; Fri, 17 Sep 93 15:54:04 +0200 To: rc%hawkwind.utcs.toronto.edu%m_internet%m_mailnow%hermes.DECnet@cesar. sedalia.sinet.slb.com Subject: Re: builtin read In-Reply-To: Your message of "Fri, 17 Sep 1993 15:36:01 +0200." Reply-To: vons@cesar.crbca1.sinet.slb.com Return-Receipt-To: vons@cesar.crbca1.sinet.slb.com Date: Fri, 17 Sep 1993 09:54:29 -0400 |I have not decided yet wether a builtin read is a good idea or not. |Meanwhile let me help you with this | | for( line in `` ($nl) { cat /some/file }){ | words = `{ echo $line } | } Agreed, it looks better than what I came up with, but my objections remain the same. You still need to fork&exec a cat, and it remains a bit cludgy IMHO. |But I don't understand how your second solution works because there |must be something wrong with input redirection. My rc behaves like this: | | ; while( echo outside ){ echo inside } > /dev/null | outside | outside | .. Oops, typo in my mail I guess, forgot the accolades around the whole while+body. Applying it to your example, it becomes ; { while (echo outside) {echo inside} } > /dev/null which works as I intended. I'm not yet convinced though, a builtin read makes the shell more complete IMHO, not to mention that it would make it easier to pass scripts around. If someone else wants to use a script of mine, who guarantees that he/she has an identical read function in his environment, and in case I add a read function to my script, should I use awk, "sh -c 'read a;echo $a'", /usr/bin/line, ... ???? And I think that performance is a reasonable argument here as well. Gert-Jan --------------------------------------------------- J.G. Vons E-Mail: vons@cesar.crbca1.sinet.slb.com From rc-owner Fri Sep 17 12:58:42 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2062>; Fri, 17 Sep 1993 12:58:07 -0400 To: rc Subject: Re: Another vote for a built-in read function In-reply-to: gjv%atlas%cesar's message of Fri, 17 Sep 93 09:10:54 -0400. <9309171315.AA21670@SINet.SLB.COM> Date: Fri, 17 Sep 1993 12:58:00 -0400 From: Chris Siebenmann Message-Id: <93Sep17.125807edt.2062@hawkwind.utcs.toronto.edu> The last thing rc needs is MORE quoting. One of the core design features is that the quoting rules are simple, regular, predictable, and minimal; adding \ as another quoting operator is none of the above. If we're going to make any changes to quoting, we should remove \'s special magic at the end of lines. - cks From rc-owner Fri Sep 17 13:33:26 1993 Received: from faui45.informatik.uni-erlangen.de ([131.188.1.45]) by hawkwind.u tcs.toronto.edu with SMTP id <2237>; Fri, 17 Sep 1993 13:33:04 -0400 Received: from faui30.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA16599 (5.65c-5/7.3v-FAU); Fri, 17 Sep 1993 19:32:50 +0200 Received: from faui30a.informatik.uni-erlangen.de by immd3.informatik.uni-erlan gen.de with SMTP; id AA01259 (5.65c-5/7.3v-FAU); Fri, 17 Sep 1993 19:32:44 +0200 From: Stefan Dalibor Message-Id: <199309171732.AA01259@faui30.informatik.uni-erlangen.de> Date: Fri, 17 Sep 1993 13:32:47 -0400 To: rc@hawkwind.utcs.toronto.edu Subject: Re: list operators Reply-To: Stefan.Dalibor@informatik.uni-erlangen.de Hi, as it seems to be list-op wishing-time, here are my favourites: 1. Cartesian products of lists; it can of course be done with functions (and I can live with that in scripts, though I don't like it), but I use this *very* often as globbing construct and having to type the rc equivalent of e.g. what {{$O/bin,~/bin}/{sun*,m88k,ptx},src/{zrc,xvt}}/{zrc,rc,sysconf,xvt} interactively can be extremely tedious. IMHO it seems also a bit inconsequent to implement cartesian products only for the case of 1 x n elements; I'd vote for implementing the general n x m case which includes the former. 2. Assignment to list elements, e.g. `path(5)=/local/bin'. I think there should be no need to use a function for such an atomic operation. Both items can be justified by (and will of course be rejected for) the same reasons as the earlier proposals; I posted them yet because much to my surprise, the absence of these constructs (and not the usual like job-control, user-name-expansion, completion, builtins etc.) was the reason that one of the few colleagues I was able to interest in rc dropped it finally and keeps on using tcsh... so I think this can at least be filed as a curiosity. Bye, Stefan From rc-owner Fri Sep 17 14:19:29 1993 Received: from SINet.SLB.COM ([163.185.18.1]) by hawkwind.utcs.toronto.edu with SMTP id <2408>; Fri, 17 Sep 1993 14:19:01 -0400 Received: from sndrtr.psi by SINet.SLB.COM id AA10122; Fri, 17 Sep 93 18:21:37 GMT From: gjv%atlas%cesar@crbca1.SINet.SLB.COM Message-Id: <9309171821.AA10122@SINet.SLB.COM> Apparently-To: "hawkwind.utcs.toronto.edu::rc" X-Vms-From: PSI%CRBCA1::CESAR::ATLAS::"gjv" X-Vms-To: HERMES::M_MAILNOW::M_INTERNET::HAWKWIND.UTCS.TORONTO.EDU::RC Received: by DniMail (v1.0); Fri Sep 17 20:17:42 1993 MET DST Received: from pyxis by atlas.atlasnis (4.1/SMI-4.1-DNI) id AA19584; Fri, 17 Sep 93 20:17:32 +0200 To: rc%hawkwind.utcs.toronto.edu%m_internet%m_mailnow%hermes.DECnet@cesar. sedalia.sinet.slb.com Reply-To: vons@cesar.crbca1.sinet.slb.com In-Reply-To: Your message of "Fri, 17 Sep 1993 19:00:35 +0200." Subject: Re: Another vote for a built-in read function Date: Fri, 17 Sep 1993 14:17:58 -0400 |The last thing rc needs is MORE quoting. One of the core design features |is that the quoting rules are simple, regular, predictable, and minimal; |adding \ as another quoting operator is none of the above. It remains simple and predictable, it's just not minimal anymore. But since it is actually a question of convenience, I could think about other solutions (e.g. automatic quoting of '=' and '#' in readline(), if I'm really desperate :) | If we're going |to make any changes to quoting, we should remove \'s special magic at the |end of lines. Well, at least it would be consistent. More or less assuming that the backslash won't make it, it is worth considering. But what about a builtin read function ? Gert-Jan --------------------------------------------------- J.G. Vons E-Mail: vons@cesar.crbca1.sinet.slb.com From rc-owner Fri Sep 17 15:51:35 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2663>; Fri, 17 Sep 1993 15:50:44 -0400 To: rc Subject: changes to rc Date: Fri, 17 Sep 1993 15:50:32 -0400 From: Chris Siebenmann Message-Id: <93Sep17.155044edt.2663@hawkwind.utcs.toronto.edu> I have a suggestion for people proposing changes to rc: the best way to persuade people that it's a good idea is to implement it in your version and then post the code so other people can try it out. We can argue for ages about the merits of various features, but we're doing it in a vaccum. For example, I'd imagine that a builtin read would be much more likely to be accepted if someone produced a good implementation of it (say, one that respected IFS and so on), and posted said implementation. I know I'd stick it into my version. - cks From rc-owner Fri Sep 17 15:54:47 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2679>; Fri, 17 Sep 1993 15:54:29 -0400 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA13322; Fri, 17 Sep 93 15:54:03 -0400 Received: from srg.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 155240.24376; Fri, 17 Sep 1993 15:52:40 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa21993; Fri, 17 Sep 93 15:28:27 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Re: Another vote for a built-in read function Date: Fri, 17 Sep 1993 15:29:17 -0400 Message-Id: <9309171529.aa25902@ceres.srg.af.mil> I'm for adding builtin read, even if it's just to cut down on the amount of discussion here about adding it as builtin, and/or how to implement a read function. ;-) ;-) ;-) On a more serious note, I tend to flip-flop on whether read should be builtin or not. It's definitely the strongest contender of all the proposals that have been made, but at the moment I lean towards the "Not" side. My current thinking is along the lines of, "rc is supposed to be a shell, not a text filter", which seems at least as compelling as Boyd's famous comment that a shell should run commands not have them built into it. Tom From rc-owner Fri Sep 17 19:19:33 1993 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.toronto.ed u with SMTP id <2237>; Fri, 17 Sep 1993 19:19:04 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <2537>; Fri, 17 Se p 1993 19:18:54 -0400 To: rc@hawkwind.utcs.toronto.edu Subject: Re: Another vote for a built-in read function In-reply-to: Your message of "Fri, 17 Sep 1993 15:29:17 EDT." <9309171529.aa25902@ceres.srg.af.mil> Date: Fri, 17 Sep 1993 19:18:52 -0400 From: Scott Schwartz Message-Id: <93Sep17.191854edt.2537@groucho.cse.psu.edu> | Boyd's famous comment that a shell should run commands not have them | built into it. Well, just to throw some oil on the fire, check out alt.os.multics for some relevent and incisive thoughts on this topic. From rc-owner Sun Sep 19 16:21:46 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2062>; Sun, 19 Sep 1993 16:20:18 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA16251; Sun, 19 Sep 93 16:20:03 -0400 Received: from srg.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 161830.4849; Sun, 19 Sep 1993 16:18:30 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa14265; Sun, 19 Sep 93 15:59:23 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu, schwartz@groucho.cse.psu.edu Subject: Re: Another vote for a built-in read function Date: Sun, 19 Sep 1993 15:59:21 -0400 Message-Id: <9309191559.aa00656@ceres.srg.af.mil> > | Boyd's famous comment that a shell should run commands not have them > | built into it. > > Well, just to throw some oil on the fire, check out alt.os.multics for > some relevent and incisive thoughts on this topic. I suspect that there are a lot of us without easy access to that news group. (or just too busy to look) Could you summarize for us? Or at least indicate which way the discussion was leaning? Tom From rc-owner Sun Sep 19 16:33:12 1993 Received: from netmail.microsoft.com ([131.107.1.3]) by hawkwind.utcs.toronto.e du with SMTP id <2664>; Sun, 19 Sep 1993 16:32:56 -0400 Received: by netmail.microsoft.com (5.65/25-eef) id AA01761; Sun, 19 Sep 93 13:31:54 -0700 From: raymondc@microsoft.com Message-Id: <9309192031.AA01761@netmail.microsoft.com> To: rc@hawkwind.utcs.toronto.edu Subject: changes to rc Date: Sun, 19 Sep 1993 09:32:06 -0400 Chris Siebenmann makes the very sane suggestion: : the best way to persuade people that it's a good idea is to implement it : in your version and then post the code so other people can try it out. I agree wholeheartedly. We can argue 'til we're blue in the face about this and other weeny details, and still not get anywhere. I've learned that when things get into the blue-in-the-face stage, the way to settle the argument is to *JUST DO IT*. Sometimes you win, sometimes you lose, but at least you'll know your proposal got a fair shake. ObRC: Hey Byron, how close are we to 1.5? -- Raymond (not rc) Chen (raymondc@microsoft.com) From rc-owner Sun Sep 19 17:06:36 1993 Received: from netcomsv.netcom.com ([163.179.1.13]) by hawkwind.utcs.toronto.ed u with SMTP id <2062>; Sun, 19 Sep 1993 17:06:08 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA27292; Sun, 19 Sep 93 14:05:38 PDT Received: by netapp.com (4.1/SMI-4.1) id AA29805; Sun, 19 Sep 93 13:48:19 PDT Date: Sun, 19 Sep 1993 16:48:19 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9309192048.AA29805@netapp.com> To: raymondc@microsoft.com, rc@hawkwind.utcs.toronto.edu Subject: Re: changes to rc >ObRC: Hey Byron, how close are we to 1.5? Well, as long as you are asking "in public" I may as well answer "in public". The truth is that I simply cannot offer any promises. I have made too many guesses and subsequent excuses to even hazard something now. I think I need a few days' worth of concentration, mainly to "fault in" all the issues that have been discussed over the last year or so and to reach some conclusions of my own. So far I have been unable to do this due to the many things keeping me active in my personal and professional life. The Network Appliance software is close to release 1.1 now, and once the smoke clears I will possibly have some time to concentrate on rc. Bug me in a few weeks again.. From rc-owner Sun Sep 19 22:45:41 1993 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.toronto.ed u with SMTP id <2230>; Sun, 19 Sep 1993 22:45:15 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <2539>; Sun, 19 Se p 1993 22:44:52 -0400 To: culliton@srg.srg.af.mil (Tom Culliton x2278) cc: rc@hawkwind.utcs.toronto.edu Subject: Re: Another vote for a built-in read function In-reply-to: Your message of "Sun, 19 Sep 1993 15:59:21 EDT." <9309191559.aa00656@ceres.srg.af.mil> Date: Sun, 19 Sep 1993 22:44:39 -0400 From: Scott Schwartz Message-Id: <93Sep19.224452edt.2539@groucho.cse.psu.edu> | I suspect that there are a lot of us without easy access to that news | group. (or just too busy to look) Could you summarize for us? Or at | least indicate which way the discussion was leaning? Sure. There are two basic points, which I'll try to explain as best I can given that I've only read about multics, but used some of its descendants (prime's primos and apollo's domain). One is that multics has pervasive dynamic linking. The fundamental unit of sharing is the procedure. Any procedure in any file in your search path can be called at any time. Your environment is one big process, you don't fork to run programs, you just call their entry points as subroutines. The second is that there is a convention of using "active functions" in the command language. That means that commands see of they are being called interactively, in which case they print their output, or being called as subroutines, in which case they pass their output back by returning a pointer to a buffer. The upshot is that in multics, if you have a command to read a line named >bin>line, and >bin is in your search path, you can call it from your program by calling a routine named line_ and it will be exactly as if it were a "builtin", because it is. There was an interesting discussion between Peter da Silva and Olin Sibert over the find command. Olin pointed out that ``find ... -exec ...'' is more multics-like than unix-like, but unix has to use xargs as yet another performance hack, with concomitant correctness problems. I can post Olin's whole article or forward it to anyone who's interested. (As an aside, the word "glob" in unix comes from a command in multics named "global", making it more like globbing in zsh.) In my view, and the reason I brought this up at all, a real problem in Unix, and in posix like systems, is that the unit of sharing is wrong. The best you can do is write text down pipes to forked processes. Sometimes that is fine, but very often it is not enough, or just plain wrong, and the rc community has encountered a perfect example of this. Similar issues came up in comp.lang.tcl a while back. In a unix setting, having a language primative for doing dynamic loading is about the best compromise you can achieve. And now for a diatribe; please skip to the end if I'm annoying you. :-) This wrongness is very bad because it distorts programmers ideas of what should be reusable; in the end, nothing is. Consider, why does ftp have its own subroutine for doing globbing? I mean, if you can't just call the globbing routine in the shell, why can't you at least use the same damn library routine? There isn't any! You don't need system sources to get it right, just a libsh.a with a sensible api! (The latter is complicated by the fact that we insist on using a '70s vintage programming language that has basically no support for code reuse, and still manages to be an improvement over its "successor".) From rc-owner Mon Sep 20 05:44:19 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2679>; Mon, 20 Sep 1993 05:43:18 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA06266; Mon, 20 Sep 1993 11:42: 20 +0200 Received: by dahlie.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA16182; Mon, 20 Sep 93 11:42:19 +0200 Date: Mon, 20 Sep 1993 05:42:19 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9309200942.AA16182@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: builtins, changes et al Content-Length: 987 Why not discuss changes and/or additions to rc until blue-in-the-face? I for myself am very grateful for the reponses I received in return to my last proposal 'cause if I had already implemented it, I'd have to rework the code now. I don't think this forum should evolve into some kind of beta test group. And about reusability, libsh.a (librc.a in this case): As someone else already stated, there is no easy way to ensure that your shell scripts uses the same version of some not builtin feature, making it difficult to pass them on to others. The multics approach stems from a time where networking was a thing of the future. Who can assure that gnuerks@macrohard.com.orion won't receive the necessary library module lightyears after my script? Now back to the real world, I don't like the idea of a builtin read with sh semantics too much. I'd prefer a more general solution, some kind of printf - scanf pair which is _not_ builtin. It's already part of the GNU shellutils. Malte From rc-owner Mon Sep 20 09:21:01 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2688>; Mon, 20 Sep 1993 09:20:30 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA13632; Mon, 20 Sep 1993 08:20:19 -0500 Message-Id: <9309201320.AA13632@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: builtins, changes et al Date: Mon, 20 Sep 1993 09:20:18 -0400 From: Alan Watson X-Mts: smtp > I don't like the idea of a builtin read > with sh semantics too much. I'd prefer a more general solution, > some kind of printf - scanf pair which is _not_ builtin. It's already > part of the GNU shellutils. The people who have expressed a desire for a built in read (including myself) have normally used performance as their justification (in the same way that echo is justified). Your suggestion does nothing for that. I feel that the man page for and implementation of a shell level scanf will be horrid. From rc-owner Mon Sep 20 15:09:32 1993 Received: from yonge.csri.toronto.edu ([128.100.1.2]) by hawkwind.utcs.toronto. edu with SMTP id <2192>; Mon, 20 Sep 1993 15:09:07 -0400 Received: from redvax by yonge.csri.toronto.edu with UUCP id <14481>; Mon, 20 S ep 1993 15:08:53 -0400 Received: by redvax.mimosa.com.mimosa.com (4.0/SMI-4.0) id AA12033; Mon, 20 Sep 93 15:08:06 EDT Date: Mon, 20 Sep 1993 15:08:06 -0400 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <9309201908.AA12033@redvax.mimosa.com.mimosa.com> To: rc@hawkwind.utcs.toronto.edu Subject: read; string manipulation | I feel that the man page for and implementation of a shell level scanf | will be horrid. As is the manual for the C scanf! What a crock. [I'm an ex-X3J11 member.] ================ | The people who have expressed a desire for a built in read (including | myself) have normally used performance as their justification (in the | same way that echo is justified). I want it for performance reasons. But unlike most performance reasons, the difference is so great that it is a qualitative difference. The performance difference is great enough to legitimately affect ones programming style. I also want one for the practical reason of making it part of the common language of rc. This is different from making it a primitive in the implementation sense. In my experience with sh, I have found "read" to be quite useful. On the other hand, very few of my uses of read do anything but stuff the whole line, with no interpretation, into a variable. I think that using IFS or scanf-like semantics is overkill. ================ WARNING: the following is not politically correct. It is also veering off topic. Furthermore, it is a poorly thought-out "dump" of my thoughts -- I don't have the time to put them in order. I hope that it inspires some thought. I do see a need for more string manipulation in rc, and not tied the "read" as scanf would be. I realize that going too far would be a mistake, but sed is so awkward and slow. I don't have a concrete suggestion. What I have most felt the need for is a facility like ed's (and sed's) substitute command, including the \( and \) capability. I see three parts in the design of such a construct: - how to analyze a string (parse it) - how to synthesize a string (build a new string that depends on parts of the old) - how to jam this into RC Analysis facility: to make it more rc-like, I would use the less-powerful sh/rc regular expressions, not ed's. We need a clean and simple notation for string synthesis. This is a difficult area in which to strike the right balance between simplicity and power. I favour simplicity -- if you really need power, use another tool. I don't have a recommendation for synthesis, but I do have a few thoughts. I welcome any others. ==== I recently discovered the MSDOS command "rename" has an interesting feature that perhaps indicates a way. An example first: ren dog.* cat.* This means: for each file matching dog.*, rename it cat, with the same extension as it had before. Any file whose name matches the first regular expression is renamed to the second regular expression with each operator in the second replaced with the characters that matched the corresponding (!) operator in the first expression. Clearly this does not suit rc-style command execution since globing is done before the command is invoked (except for a few built-in commands in rc). What it does is present a cute notation for string synthesis where a correspondence is imputed between regular expression operators. This would obviate the need for the \( and \) notation, at some expense in power, and *perhaps* an increase in intuitiveness and visual clarity. The main loss of power is that components cannot be freely reordered. [Warning: this kind of logic might lead to something like C's bizarre declaration syntax.] I leave this path unexplored. ==== A regular expression match in rc could have the side effect of setting variables with the matched components. - There are too many components to have a variable for each. Perhaps a variable for each explicit RE operator would make sense. The other parts are literal, so they can simply be retyped. - The variables could reasonably be a single list variable, with subscription used to access the desired component. There needs to be a convention for numbering the components. The ed \( \) convention of numbering left to right seems obvious. - On the other hand, SNOBOL allows naming of matched components. This is quite useful and powerful, but in my opinion it makes the patterns messier. I think we can afford to live without this power. - What if several strings are matched by a regular expression? Where could the matches for each be recorded? A matrix would be needed. A different list variable could be used for each matched string, or, transposing, a different list variable could be used for each regular expression operator. Simpler would be to only record the last match's parse. ==== Where would such a feature hook in? - The ~ command could have the side-effect of setting the positional variables if ( ~ $x *.c ) dest=$match(1).o - The switch statement could have that side-effect switch ( $x ) { case *.c dest=$match(1).o } - The for statement could have the side-effect, or even to set its control variable to a synthetic expression. (Perhaps someone knows how Miranda list comprehensions and can import some inspiration.) for (x is $match(1).o in *.c) { ... } I wish there were a pretty functional notation. The way ~ takes multiple patterns seems a bit weak. For our purpose, it would be nice if the syntax of ~ were: ~ subject pattern [synthesis] so that the result could optionally be specified by some sort of synthesizing expression (perhaps even the MSDOS rename kind). Of course, the result is in the result variable, so we still don't have a functional notation. Hugh Redelmeier hugh@mimosa.com or {utcsri, uunet!attcan, utzoo, scocan}!redvax!hugh When all else fails: hugh@csri.toronto.edu voice: +1 416 482-8253 From rc-owner Mon Sep 20 18:19:39 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2192>; Mon, 20 Sep 1993 18:18:27 -0400 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05691; Mon, 20 Sep 93 18:18:04 -0400 Received: from srg.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 181654.10292; Mon, 20 Sep 1993 18:16:54 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa14025; Mon, 20 Sep 93 18:11:50 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Thoughts on a builtin read Date: Mon, 20 Sep 1993 18:11:51 -0400 Message-Id: <9309201811.aa08861@ceres.srg.af.mil> After all the recent discussion about builtin read, it is starting to sound like something that will happen, at the very least as a common addon. Given this, it's time to examine the design options and try to come up with something reasonable. After a bit of thought I came up with the following: To keep things in the spirit of rc, simplicity should be our guiding principle. This shapes most of the design decisions discussed below. 1) One string rather than IFS seperation of fields - simplicity - preserves information, such as runs of blanks - field splitting can always be done later with backquote: read x;x=(`{echo -- $x}) 2) Single variable rather than multiple variables - simplicity - you can always split the fields as above and use subscripts 3) Good behaviour on EOF. - return 1 on EOF, 0 otherwise - save any text on the line before EOF 4) Should strip the newline - This makes "read x;echo -- $x" work right. 5) Doesn't honor \ at EOL for continuation - simplicity 6) If interactive and compiled with readline, use that to get input. - consistency Aside from the last item, Alan Watson has already presented what looks like a reasonable implementation way back on May 17th of this year. (It could be packaged a bit better to fit in with the current addon scheme and be easier to install.) The case for a builtin read could be much better evaluated if some folks would try his version and report back on their experiances. Tom PS - with Alan's permission I'll repackage his read routine as a proper patch so it's easier to try. Alan? From rc-owner Mon Sep 20 21:25:17 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2060>; Mon, 20 Sep 1993 21:24:24 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AB22226; Mon, 20 Sep 93 21:24:07 -0400 Received: from srg.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 212256.20507; Mon, 20 Sep 1993 21:22:56 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa16151; Mon, 20 Sep 93 20:33:47 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: A potentially useful patch Date: Mon, 20 Sep 1993 20:33:48 -0400 Message-Id: <9309202033.aa10448@ceres.srg.af.mil> Sigh.... While trying to get Alan's read integrated I rediscovered that SCO-ODT 1.1 has a broken realloc. It dumps core when it gets a null pointer for the old buffer. Fortunately Byron's code doesn't seem to rely on this behaviour. Just in case though, here's a patch for other folks in the same boat. Tom *** config.h.old Wed Feb 3 15:37:36 1993 --- config.h Mon Sep 20 20:29:01 1993 *************** *** 108,113 **** --- 108,122 ---- #define NOJOB */ + /* + * SCO-ODT 1.1 has a broken realloc which dumps core when it gets a null + * pointer for the old buffer. Byron's code doesn't seem to rely on this + * behaviour, but just in case something in the future does, you can define + * this to enable a fanny shield. Don't do it unless you know that you + * have this problem. + #define BROKENREALLOC + */ + /* Beginning of defaults section: */ #ifndef CUSTOM *** nalloc.c.old Thu Feb 27 02:22:10 1992 --- nalloc.c Mon Sep 20 19:43:52 1993 *************** *** 122,127 **** --- 122,132 ---- extern void *erealloc(void *p, SIZE_T n) { extern void *realloc(void *, SIZE_T); + #ifdef BROKENREALLOC + if (!p) { + p = ealloc(n); + } else + #endif if ((p = realloc(p, n)) == NULL) { uerror("realloc"); rc_exit(1); From rc-owner Tue Sep 21 02:52:03 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2223>; Tue, 21 Sep 1993 02:51:31 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA13638; Tue, 21 Sep 1993 08:51: 21 +0200 Received: by dahlie.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA18498; Tue, 21 Sep 93 08:51:19 +0200 Date: Tue, 21 Sep 1993 02:51:19 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9309210651.AA18498@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Thoughts on a builtin read Content-Length: 749 [ Tom Culliton x2278 wrote: ] To keep things in the spirit of rc, simplicity should be our guiding principle. This shapes most of the design decisions discussed below. I always thought useability was the point .. 1) One string rather than IFS seperation of fields - simplicity - preserves information, such as runs of blanks - field splitting can always be done later with backquote: read x;x=(`{echo -- $x}) ... 4) Should strip the newline - This makes "read x;echo -- $x" work right. 5) Doesn't honor \ at EOL for continuation - simplicity This is an inconsistency. I'd very much prefer the usual "x = `read" or "x = `` ( $some_ifs_list ) { read }" Malte From rc-owner Tue Sep 21 10:18:46 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2223>; Tue, 21 Sep 1993 10:17:48 -0400 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA03763; Tue, 21 Sep 93 10:17:28 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA12232; Tue, 21 Sep 93 10:17: 54 -0400 Date: Tue, 21 Sep 1993 10:17:54 -0400 From: rsalz@osf.org Message-Id: <9309211417.AA12232@sulphur.osf.org> To: culliton@srg.af.mil, rc@hawkwind.utcs.toronto.edu Subject: Re: A potentially useful patch I absolutely hate it when people use #ifdef to break up C flow of control statements. This seems cleaner and fits Byron's coding style (using !p for p == NULL -- ick!): extern void *erealloc(void *p, SIZE_T n) { extern void *realloc(void *, SIZE_T); + #ifdef BROKENREALLOC + if (p == NULL) + return ealloc(n); + #endif if ((p = realloc(p, n)) == NULL) { uerror("realloc"); rc_exit(1); } return p; } /r$ From rc-owner Tue Sep 21 10:19:55 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2664>; Tue, 21 Sep 1993 10:19:42 -0400 To: rc Subject: Re: Thoughts on a builtin read In-reply-to: malte's message of Tue, 21 Sep 93 02:51:19 -0400. <9309210651.AA18498@dahlie.techfak.uni-bielefeld.de> Date: Tue, 21 Sep 1993 10:19:38 -0400 From: Chris Siebenmann Message-Id: <93Sep21.101942edt.2664@hawkwind.utcs.toronto.edu> If rc's read becomes a builtin version of line, I think we need some optimization of forks in rc, since currently x = `BUILTIN results in rc forking. - cks From rc-owner Tue Sep 21 10:20:25 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2679>; Tue, 21 Sep 1993 10:20:09 -0400 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA03965; Tue, 21 Sep 93 10:19:39 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA12243; Tue, 21 Sep 93 10:20: 05 -0400 Date: Tue, 21 Sep 1993 10:20:05 -0400 From: rsalz@osf.org Message-Id: <9309211420.AA12243@sulphur.osf.org> To: malte@techfak.uni-bielefeld.de, rc@hawkwind.utcs.toronto.edu Subject: Re: Thoughts on a builtin read > This is an inconsistency. I'd very much prefer the usual > "x = `read" > or "x = `` ( $some_ifs_list ) { read }" Please explain how you would write a "read until EOF loop". Don't confuse EOF with blank lines. I think Tom's list is right-on. /r$ From rc-owner Tue Sep 21 10:34:43 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2223>; Tue, 21 Sep 1993 10:34:23 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA16123; Tue, 21 Sep 1993 16:33: 16 +0200 Received: by dahlie.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA20494; Tue, 21 Sep 93 16:33:15 +0200 Date: Tue, 21 Sep 1993 10:33:15 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9309211433.AA20494@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Thoughts on a builtin read Content-Length: 505 [ rsalz@osf.org wrote ]: > This is an inconsistency. I'd very much prefer the usual > "x = `read" > or "x = `` ( $some_ifs_list ) { read }" Please explain how you would write a "read until EOF loop". Don't confuse EOF with blank lines. Well, let me put it this way: I always wanted $status to reflect the exit status of the backquote command, not the assignment. To give another example of my "disgustingly bad taste", this will allow "while( x = `{ ... } ) ..." to work, too. Malte From rc-owner Tue Sep 21 11:09:56 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2223>; Tue, 21 Sep 1993 11:09:32 -0400 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA08143; Tue, 21 Sep 93 11:09:24 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA12434; Tue, 21 Sep 93 11:09: 50 -0400 Date: Tue, 21 Sep 1993 11:09:50 -0400 From: rsalz@osf.org Message-Id: <9309211509.AA12434@sulphur.osf.org> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Thoughts on a builtin read >Well, let me put it this way: I always wanted $status to reflect >the exit status of the backquote command, not the assignment. Let me make sure I understand. You want to be able to write this: x=`read I understand the consistency argument. Since most uses of read will be in a "read until EOF loop," however, you would require that other changes be made to rc. I think this is enough to kill your idea. Anyhow, let's take a look at your idea. That is, x=`foobar should set $status to the exit value of foobar. What should x=foobar set $status to? Leave it unchanged? What about x=* if the directory is empty? And if it isn't? What about x=/foo/* when /foo doesn't exist? You are making a simple shell very complicated, don't you think? /r$ From rc-owner Tue Sep 21 11:16:28 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2192>; Tue, 21 Sep 1993 11:15:43 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA00524; Tue, 21 Sep 1993 10:15:26 -0500 Message-Id: <9309211515.AA00524@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Thoughts on a builtin read Date: Tue, 21 Sep 1993 11:15:26 -0400 From: Alan Watson X-Mts: smtp >This is an inconsistency. I'd very much prefer the usual > "x = `read" > or "x = `` ( $some_ifs_list ) { read }" Something along the lines of: fn read { if (builtin read LINE) { echo $LINE return 0 } else { echo $LINE return 1 } } I would not mind Malte's suggestion as the primitive -- it seems fairly easy to convert one to the other with a simple function. From rc-owner Tue Sep 21 11:57:23 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <2192>; Tue, 21 Sep 1993 11:56:31 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA16587; Tue, 21 Sep 1993 17:56: 18 +0200 Received: by dahlie.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA20736; Tue, 21 Sep 93 17:56:15 +0200 Date: Tue, 21 Sep 1993 11:56:15 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9309211556.AA20736@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Thoughts on a builtin read Content-Length: 2090 [ rsalz@osf.org wrote ]: Anyhow, let's take a look at your idea. That is, x=`foobar hould set $status to the exit value of foobar. What should x=foobar set $status to? Leave it unchanged? What about x=* if the directory is empty? And if it isn't? What about x=/foo/* when /foo doesn't exist? Yes, an assignment leaves the status unchanged. Your file name expansion examples are just a shorthand for x = `{ glob /foo/* } # glob == echo Currently, neither "x=*" nor "x=`{ glob *}" sets $status to some reasonable value, it is just 0 -- always! You are making a simple shell very complicated, don't you think? Complicated is your word for it, I'd rather call it more usable. I have frequently had the problem to distinguish between a failed backquote command and a command producing no output. There may be better solutions then this x = `{ foo || echo '!@#$%^&*()' } if( ~ $x '!@#$%^&*()' ) ... but it seems to me to be a FAQ. The person who started this thread had just this problem. I don't mean to offend anybody, but I have the impression that because Tom Duff invented this shell there can't be anything wrong. But if one takes a closer look, one sees quite a few sh'isms still in it, e.g shift. I think rc in its original form and in its current form is an excellent point to start a shell project. This is why I post all this to this list and have it discussed instead of just implementing it for myself. Be assured though, that I very much appreciate different opinions. Back to the read problem: Currently there is no builtin which assigns a value to a variable ( except for the special variables of course ). There's been a discussion on shift shifting arbitrary lists with the proposed syntax being "shift x 2" probably because "x = `{ shift x 2 }" isn't too elegant. If this makes its way into rc, I don't mind if read expects a variable as a command line parameter. But since I don't care if some functionality is built into the shell, I'd prefer the backquote substitution solution. Malte From rc-owner Tue Sep 21 12:45:05 1993 Received: from netcomsv.netcom.com ([163.179.1.14]) by hawkwind.utcs.toronto.ed u with SMTP id <2192>; Tue, 21 Sep 1993 12:44:39 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA26668; Tue, 21 Sep 93 09:44:56 PDT Received: by netapp.com (4.1/SMI-4.1) id AA09070; Tue, 21 Sep 93 09:36:23 PDT Date: Tue, 21 Sep 1993 12:36:23 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9309211636.AA09070@netapp.com> To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Thoughts on a builtin read cks: > If rc's read becomes a builtin version of line, I think we need some >optimization of forks in rc, since currently > x = `BUILTIN >results in rc forking. I don't see how this could be avoided unless you define a whole new i/o model internal to rc just for builtins and the backquote splitter to use. It looks like that would involve reinventing the OS inside rc, so it would lead me to suggest that Unix fork is just broken (i.e., it should be faster) but this is not a very productive avenue to pursue. It's a shame when you can't use the Unix style when programming in Unix. Is it time to move onto something else? From rc-owner Tue Sep 21 12:51:34 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2223>; Tue, 21 Sep 1993 12:51:04 -0400 To: rc Subject: Re: Thoughts on a builtin read In-reply-to: byron's message of Tue, 21 Sep 93 12:36:23 -0400. <9309211636.AA09070@netapp.com> Date: Tue, 21 Sep 1993 12:50:50 -0400 From: Chris Siebenmann Message-Id: <93Sep21.125104edt.2223@hawkwind.utcs.toronto.edu> IMHO this is thus an argument against read as a backquote operator, since one strong reason to put it into the shell in the first place is for efficiency reasons. I'm not particularly eager to see someone have to change rc's perfectly fine and working i/o system for backquote operators. - cks From rc-owner Tue Sep 21 12:53:58 1993 Received: from SINet.SLB.COM ([163.185.18.1]) by hawkwind.utcs.toronto.edu with SMTP id <2664>; Tue, 21 Sep 1993 12:53:45 -0400 Received: from snmrtr.psi by SINet.SLB.COM id AA00816; Tue, 21 Sep 93 16:56:19 GMT From: gjv%atlas%cesar@crbca1.SINet.SLB.COM Message-Id: <9309211656.AA00816@SINet.SLB.COM> Apparently-To: "hawkwind.utcs.toronto.edu::rc" X-Vms-From: PSI%CRBCA1::CESAR::ATLAS::"gjv" X-Vms-To: HERMES::M_MAILNOW::M_INTERNET::HAWKWIND.UTCS.TORONTO.EDU::RC Received: by DniMail (v1.0); Tue Sep 21 18:52:02 1993 MET DST Received: from pyxis by atlas.atlasnis (4.1/SMI-4.1-DNI) id AA13907; Tue, 21 Sep 93 18:51:45 +0200 To: rc%hawkwind.utcs.toronto.edu%m_internet%m_mailnow%hermes.DECnet@cesar. sedalia.sinet.slb.com Subject: Re: Thoughts on a builtin read In-Reply-To: Your message of "Tue, 21 Sep 1993 17:57:14 +0200." Reply-To: vons@cesar.crbca1.sinet.slb.com Date: Tue, 21 Sep 1993 12:52:34 -0400 [Malte wrote:] |[ rsalz@osf.org wrote ]: | set $status to? Leave it unchanged? What about | x=* | if the directory is empty? And if it isn't? What about This sets x to '*', no error whatsoever. | x=/foo/* | when /foo doesn't exist? This sets x to '/foo/*', again no error. |Yes, an assignment leaves the status unchanged. Your file name expansion |examples are just a shorthand for | x = `{ glob /foo/* } # glob == echo I agree on this, It would be nice if the status reflects the result of the evaluation of the right-hand side, not that of the assignment itself. If you 'redefine' $status this way, it is also possible to save and restore its value, something you currently can't (see my earlier mail on the problems with $status and the prompt function). The only problem here may be the following: ; a=(b c) ; $a="foo" multi-word variable name ; echo $status 1 However, an rc-script aborts if you try this, so you can't check $status anyway. |There's been a discussion on shift shifting arbitrary lists with the |proposed syntax being "shift x 2" probably because "x = `{ shift x 2 }" |isn't too elegant. If this makes its way into rc, I don't mind if read |expects a variable as a command line parameter. As Chris said, a `BUILTIN currently always forks, which is a disadvantage of an implementation like "x=`{shift x 2}" or "x=`{read a; echo $a}" in order to get a set of words in 'x'. And since the $$ construction already allows a function like 'append x (a b c)' in order to modify the variable 'x', a 'read x' or 'shift x 2' is not introducing something new. Personally, I think that s = shift 2 $s s = shift 2 (what ever list) l = read l2 = read [1=3] # would this read from descriptor 3 ? would also be quite elegant, avoiding the builtins taking variable names. But as mentioned above, this causes problems with the current implementation of $status. Gert-Jan --------------------------------------------------- J.G. Vons E-Mail: vons@cesar.crbca1.sinet.slb.com From rc-owner Tue Sep 21 12:58:41 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto .edu with SMTP id <2683>; Tue, 21 Sep 1993 12:58:26 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA25 552 (5.65c/IDA-1.4.4 for ); Tue, 21 Sep 1993 12:58: 18 -0400 Received: by penfold.cc.gatech.edu id AA03595 (5.65c/IDA-1.4.4 for rc@hawkwind.utcs.utoronto.ca); Tue, 21 Sep 1993 12:58:13 -0400 From: Arnold Robbins Message-Id: <199309211658.AA03595@penfold.cc.gatech.edu> Date: Tue, 21 Sep 1993 12:58:13 -0400 In-Reply-To: Byron Rakitzis's 33-line message on Sep 21, 12:36pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rc@hawkwind.utcs.utoronto.ca Subject: Re: Thoughts on a builtin read > Is it time to move onto something else? It has been for some time, now. Why do you think Plan 9 was invented? Alas, the commercial world is just now discovering Unix, and the universities (at least around here) just want to Get The Next Paper Written using frame or whatever. Heaven forbid they should actually *use* an experimental, but state of the art distributed system. "Unix is dead, and not only that, it's starting to smell pretty bad too." -- Rob Pike I don't believe in The Gospel According to Pike for everything, but a lot of the time he's right... Just spouting off steam, Arnold From rc-owner Tue Sep 21 13:02:24 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2689>; Tue, 21 Sep 1993 13:02:10 -0400 To: rc Subject: Re: Thoughts on a builtin read In-reply-to: malte's message of Tue, 21 Sep 93 11:56:15 -0400. <9309211556.AA20736@dahlie.techfak.uni-bielefeld.de> Date: Tue, 21 Sep 1993 13:02:04 -0400 From: Chris Siebenmann Message-Id: <93Sep21.130210edt.2689@hawkwind.utcs.toronto.edu> Malte brings up the desire for shift to shift things besides $*. This has been thoroughly beaten to death in the mailing list; see my message <91Sep11.132925edt.2708@hawkwind.utcs.toronto.edu>, which has a supershift function which involves no backquotes and no risk of carefully quoted variables 'escaping'. You can find it in the first mailing list archive on archone.tamu.edu, /pub/rc/rc-list.1991.Z. I highly recommend reading the mailing list archives; many issues have been discussed and summarized there. - cks [to save people's time, here's the function again: # 'supershift' function for rc. # usage: # sshift varname # sshift varname number # shifts the list varname by number (default 1) positions. fn sshift { if (~ $#* 1 ) { _sshift $1 1 $$1 } else { _sshift $1 $2 $$1 } } # this function does most of the work. # _sshift NAME COUNT LISTELEMS # shift LISTELEMS COUNT items left, and assign the result to NAME. fn _sshift { _vn=() { _vn=$1; shift; shift $1; shift; $_vn=$* } } ] From rc-owner Tue Sep 21 13:19:32 1993 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.toronto.edu w ith SMTP id <2192>; Tue, 21 Sep 1993 13:19:11 -0400 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA17921; Tue, 21 Sep 93 13:11:02 -0400 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA12822; Tue, 21 Sep 93 13:11: 28 -0400 Date: Tue, 21 Sep 1993 13:11:28 -0400 From: rsalz@osf.org Message-Id: <9309211711.AA12822@sulphur.osf.org> To: rc-owner@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Thoughts on a builtin read >Alas, the commercial world is just now discovering Unix, and the universities >(at least around here) just want to Get The Next Paper Written using frame >or whatever. Heaven forbid they should actually *use* an experimental, but >state of the art distributed system. Why would anyone who wants to write a paper want to use a research system? /r4 From rc-owner Tue Sep 21 13:20:42 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2223>; Tue, 21 Sep 1993 13:20:24 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA15915; Tue, 21 Sep 93 12:17:06 -0400 Received: from srg.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 121557.5331; Tue, 21 Sep 1993 12:15:57 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa02967; Tue, 21 Sep 93 11:54:44 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Re: Thoughts on a builtin read Date: Tue, 21 Sep 1993 11:54:45 -0400 Message-Id: <9309211154.aa16146@ceres.srg.af.mil> Oh, where to start.... Rich is right about the patch for nalloc.c, his version is better style. For Malte, simplicity is often the same as usability, it takes a lot fewer brain cells to remember and correctly use something simple vs. something complex. Maybe I'm just getting old, but I find myself running low on brain cells pretty regularly these days. What really convinced me that rc's read should be simple was looking at the one in ksh. What a monstrosity! 8-P The other idea that Malte mentioned, having read act like line, does have a certain appeal. It's may even be cleaner because it doesn't add another way of setting variables. And as Alan points out, a simple function can easily convert one form to the other. The only problem is that you always need a `{} and thus an extra fork to do anything with it. For Chris, if you don't care about setting a different ifs, you can split the line without a fork by using eval: read x;eval 'x=('$x')' Of course if you want to split up the fields of /etc/passwd on ':' you'll still need to fork. Producing your own version of read, that splits the input line using ifs, should be easy if you generalize the backquote code in glom.c. Go for it! ;-) Finally, Alan has given me the go ahead to repost his version of read as a patch. The current version doesn't support readline yet, so maybe I'll try to hack that in after lunch. Tom From rc-owner Tue Sep 21 13:26:59 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto .edu with SMTP id <2192>; Tue, 21 Sep 1993 13:26:40 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA26 779 (5.65c/IDA-1.4.4 for ); Tue, 21 Sep 1993 13:26: 33 -0400 Received: by penfold.cc.gatech.edu id AA03698 (5.65c/IDA-1.4.4 for rc@hawkwind.utcs.toronto.edu); Tue, 21 Sep 1993 13:26:31 -0400 From: Arnold Robbins Message-Id: <199309211726.AA03698@penfold.cc.gatech.edu> Date: Tue, 21 Sep 1993 13:26:30 -0400 In-Reply-To: rsalz@osf.org's 23-line message on Sep 21, 1:11pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rc@hawkwind.utcs.toronto.edu Subject: Re: Thoughts on a builtin read > >Alas, the commercial world is just now discovering Unix, and the universitie s > >(at least around here) just want to Get The Next Paper Written using frame > >or whatever. Heaven forbid they should actually *use* an experimental, but > >state of the art distributed system. > > Why would anyone who wants to write a paper want to use a research system? It is my contention that much of the usability/success of Unix came from the fact that it was *used*, and not just built and then mined for research results, the way most university os's are. I think if people put Plan 9 into production for day to day use, including grungy things like writing papers, they might end up with more productive environments for themselves. (This would be true of other os's as well, eg Clouds here at GT.) Maybe I'm wrong. But the attitude of "I just want to get my job done, I don't care about elegance/non-elegance of my environment" just leads us to DOS, Novell, and Windows NT. Yuck. Arnold From rc-owner Tue Sep 21 17:09:48 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2223>; Tue, 21 Sep 1993 17:09:03 -0400 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA00959; Tue, 21 Sep 93 17:08:27 -0400 Received: from srg.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 170612.20930; Tue, 21 Sep 1993 17:06:12 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa08987; Tue, 21 Sep 93 17:01:33 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: A patch to add builtin read Date: Tue, 21 Sep 1993 17:01:36 -0400 Message-Id: <9309211701.aa18991@ceres.srg.af.mil> OK, here it is. I've hacked up Alan's read to support readline and make my earlier realloc patch unnecessary, and made context diff's of all the affected files. The diffs assume you've been keeping up with the bug fix patches posted here. (If anyone wants a complete set of diffs against a virgin copy of 1.4 let me know and I'll mail it to you.) You'll also have to create the addon directory before applying the patch and fiddle your makefile appropriately to enable this. It trips clean and an hour of poking at it hasn't turned up any obvious stupidity. Please let me know if you turn anything up. Tom ------------------------------------------------------------------------------ *** addon.h.old Mon Sep 20 20:41:32 1993 --- addon.h Mon Sep 20 18:55:16 1993 *************** *** 36,38 **** --- 36,55 ---- extern void b_test(char **av); #endif + + #ifdef READ + + #undef ADDONS + #ifndef DWS + #define ADDONS { b_read, "read" }, + #else + #define ADDONS { b_read, "read" },\ + { b_access, "access" },\ + { b_test, "test" },\ + { b_test, "[" }, + #endif + + + extern void b_read(char **av); + + #endif *** addon.c.old Mon Sep 20 20:41:24 1993 --- addon.c Mon Sep 20 18:29:21 1993 *************** *** 20,22 **** --- 20,35 ---- #include "addon/test.c" #endif + + #ifdef READ + #ifndef DWS + #include + + #include "rc.h" /* for bool TRUE, FALSE */ + #include "addon.h" + #endif + + + #include "addon/read.c" + + #endif *** input.c.old Mon Sep 20 20:54:42 1993 --- input.c Tue Sep 21 15:29:11 1993 *************** *** 85,91 **** #ifdef READLINE #ifndef SVSIGS ! static char *rc_readline(char *prompt) { char *r; interrupt_happened = FALSE; if (!setjmp(slowbuf.j)) { --- 85,91 ---- #ifdef READLINE #ifndef SVSIGS ! char *rc_readline(char *prompt) { char *r; interrupt_happened = FALSE; if (!setjmp(slowbuf.j)) { *** addon/read.c.old Tue Sep 21 16:32:09 1993 --- addon/read.c Tue Sep 21 16:01:08 1993 *************** *** 0 **** --- 1,80 ---- + /* + b_reads -- read a single line, terminated by \n or EOF, from the standard + input, and assign the line without the terminator to av[1]. + */ + + #ifdef READLINE + #ifndef SVSIGS + extern char *rc_readline(char *); + #else + extern char *readline(char *); + #define rc_readline readline + #endif /* SVSIGS */ + extern void add_history(char *); + #endif + + static int + readchar(int fd) + { + unsigned char c; + + if (read(fd, &c, 1) == 1) + return c; + else + return EOF; + } + + void + b_read(char **av) + { + char *name; + int c; + char *line; + SIZE_T len; + SIZE_T max_len; + SIZE_T max_len_quantum; + + /* check usage is "read name" */ + if (av[1] == NULL) + rc_error("missing variable name"); + if (av[2] != NULL) + rc_error("too many arguments to read"); + name = av[1]; + + #ifdef READLINE + if (isatty(0)) { + line = rc_readline(NULL); + if (line == NULL) { + line = ealloc(1); + *line = '\0'; + c = EOF; + } else { + if (*line != '\0') + add_history(line); + c = '\n'; + } + } else + #endif + { + /* read a single line from stdin */ + len = 0; + max_len = max_len_quantum = 256; + line = ealloc(max_len); + do { + c = readchar(0); + if (len == max_len) + line = erealloc(line, max_len += max_len_quantu m); + if (c == '\n' || c == EOF) + line[len] = 0; + else + line[len] = c; + len++; + } while (c != '\n' && c != EOF); + } + /* assign whatever we read to the variable */ + assign(word(name, NULL), word(line, NULL), FALSE); + efree(line); + + /* return TRUE if we terminated with a \n, otherwise FALSE */ + set(c == '\n'); + } *** addon/trip.read.old Tue Sep 21 16:32:09 1993 --- addon/trip.read Mon Sep 20 20:46:40 1993 *************** *** 0 **** --- 1,53 ---- + # trip.read -- check a read implementation performs like a true v7 sh read + + fn check { + echo $1 $2 + ./rc -c $2 + if ( ! ~ $status $1 ) { + echo failed: $2 + } + } + + check 0 true + check 1 false + + nl = ' + ' + ifs = $nl + + file = /etc/passwd + first = `{ cat $file } + first = $first(1) + + echo 'start of trip.read' + + # check read X and read '*' return 0 + check 0 'exec <$file ; read X' + check 0 'exec <$file ; read ''*''' + + # check read, read 1, read '=', and read '' return 1 + check 1 'exec <$file ; read' + check 1 'exec <$file ; read 1' + check 1 'exec <$file ; read ''=''' + check 1 'exec <$file ; read ''''' + + # check read X correctly reads first line + check 0 'exec <$file; read X ; ~ $X $first' + check 0 'echo -n $first | { read X ; ~ $X $first }' + + # check read '*' correctly reads first line, preserves $0 + check 0 'exec <$file ; old0 = $0 ; read ''*'' ; ~ $0 $old0 && ~ $1 $first && ~ $#* 1' + + # check read returns 1 on EOF and I/O error + check 1 'exec ; Wed, 22 Sep 1993 08:53:01 -0400 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA23786; Wed, 22 Sep 1993 14:52: 33 +0200 Received: by dahlie.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA00848; Wed, 22 Sep 93 14:52:32 +0200 Date: Wed, 22 Sep 1993 08:52:32 -0400 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9309221252.AA00848@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: builtins and more Content-Length: 2229 If simplicity is often the same as useability, then let me remind you of the shift operator. Can there be a cleaner concept than the existing of list and variables ? And isn't * just another variable except for the property of being initialized at function invocation ? So how comes that shift cannot shift variables other than * ? Probably because in sh variables aren't lists. I find it much harder to remember to include some file to overload the shift functionality. Not talking about the additional security checking involved if a script may be executed by root. So consequently simplicity means enhancing the shift operators functionality. And even if you think this is false, have you ever thought about "x = ( 1 2 3 ) echo $x(0)" ? Why is $*(0) a special case ? Wouldn't it be cleaner to have another special variable for that ? And what about omitting shift ? Here's the sceleton of a function as a replacement for shift: fn shift { switch( $#* ){ case 0; echo cannot $0 >[1=2]; return 1; case 1; return 0; case *; n = ( 1 1 ){ while(){ echo $*($#n); if( ~ $#n $#* ) { break; } else { n = ( $n 1 ) } } } return 0 } } Instead of "shift" you'll have to type * = `{ shift $* } So, having raised all these questions: I think there is a very close connection between datastructures and algorithms on them. With the fundamental data- structure being lists, I miss the necessary operators (operations). About the performance of a backquote-style read: I have checked the difference between while(){ echo `{ /bin/echo true }} and while(){ echo `{ echo true }} on my favourite machine. It seems to me that the exec(2) is by far more expensive than the fork(2). So the backquote solution may be a good compromise between clearity and performance. Btw, I dimly remember Byron asked for a rc wish list sometime around Xmas. Wasn't this meant to be a request for possible improvements ? I mean, even changes to rc syntax and semantics ? Malte From rc-owner Wed Sep 22 12:51:22 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2679>; Wed, 22 Sep 1993 12:50:02 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA07184; Wed, 22 Sep 1993 11:49:42 -0500 Message-Id: <9309221649.AA07184@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: builtins and more Date: Wed, 22 Sep 1993 12:49:42 -0400 From: Alan Watson X-Mts: smtp Malte writes: > About the performance of a backquote-style read: > I have checked the difference between > while(){ echo `{ /bin/echo true }} > and > while(){ echo `{ echo true }} > on my favourite machine. It seems to me that the exec(2) is by far more > expensive than the fork(2). So the backquote solution may be a good compromis e > between clearity and performance. On DEC MIPS and Alpha machines, fork and exec are both take approximately the same time. Read is a perfomance hack, and a worse one than builtin echo; it isn't as elegant as `line, but it is fast enough to be much more useful. I would much rather see fork and exec speeded up by a few orders of magnitude, but we all know that isn't going to happen. From rc-owner Wed Sep 22 12:58:09 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2689>; Wed, 22 Sep 1993 12:57:52 -0400 To: rc Subject: Re: builtins and more In-reply-to: malte's message of Wed, 22 Sep 93 08:52:32 -0400. <9309221252.AA00848@dahlie.techfak.uni-bielefeld.de> Date: Wed, 22 Sep 1993 12:57:45 -0400 From: Chris Siebenmann Message-Id: <93Sep22.125752edt.2689@hawkwind.utcs.toronto.edu> A shift operator that has to be used as 'x=`{shift $foo}' is a bad shift operator; it can't be applied to arbitrary lists. Consider a list with an element that has a space in it, or a newline. - cks From rc-owner Wed Sep 22 13:19:18 1993 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.toronto.e du with SMTP id <2701>; Wed, 22 Sep 1993 13:18:57 -0400 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Wed, 22 Sep 1993 18:18:17 +0100 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA01615; Wed, 22 Sep 93 18:18:08 BST Date: Wed, 22 Sep 1993 13:18:08 -0400 From: steve@gec-epl.co.uk (Steve_Kilbane) Message-Id: <9309221718.AA01615@zombie.gec-epl.co.uk> To: arnold Subject: Re: Thoughts on a builtin read Cc: rc@hawkwind.utcs.toronto.edu X-Sun-Charset: US-ASCII Content-Length: 1228 > I think if people put Plan 9 into production for day to day use, > including grungy things like writing papers, they might end up with > more productive environments for themselves. (This would be true of other > os's as well, eg Clouds here at GT.) maybe. depends on whether they had access to other machines, too. at minster.york.ac.uk, the students use a plan 9-like os running on 386 boxes, but last i saw, i hadn't seen any students doing anything more than running a load of remote shells onto the file server (which happens to run AIX). me, i'd play with the local os, and have fun, but generally it doesn't look that different from unix anyway (the shared environment and lack of links are the main places where you see the join) - it's only when you get into the programming that you see where the kludges have been removed. > Maybe I'm wrong. But the attitude of "I just want to get my job done, I don't > care about elegance/non-elegance of my environment" just leads us to > DOS, Novell, and Windows NT. Yuck. kinda, but inertia was the main thing for dos, and pretty icons is the big mover for nt, i reckon. it's a sad world. still, this is off the track of rc. 9fans might be better, but i doubt it. steve From rc-owner Wed Sep 22 13:30:08 1993 Received: from colossus.apple.com ([130.43.2.6]) by hawkwind.utcs.toronto.edu w ith SMTP id <2704>; Wed, 22 Sep 1993 13:29:47 -0400 Received: from talisman.kaleida.com by colossus.apple.com with SMTP (5.65/22-Ju n-1993-eef) id AA11374; Wed, 22 Sep 93 10:23:13 -0700 for Received: from [130.43.11.206] (kip-16.kaleida.com) by talisman.kaleida.com (4. 1/SMI-4.1) id AA17501; Wed, 22 Sep 93 10:21:14 PDT Date: Wed, 22 Sep 1993 13:21:12 -0400 Message-Id: <9309221721.AA17501@talisman.kaleida.com> To: rc@hawkwind.utcs.toronto.edu From: haahr@kaleida.com (Paul Haahr) X-Sender: haahr@talisman.kaleida.com Subject: shift biased as i might be, i'd like to point out the existence of es's solution to the shift question: + no shift builtin + ... accepted in subscript arguments, where $x(m ... n) means all elements of x between the mth mth and nth (inclusive). if m is omitted, 1 is assumed. if n is a omitted, $#x is assumed. anyway, that's it. while * = $*(2 ...) is not as clean as shift the flexibility is, imho, worth it. From rc-owner Wed Sep 22 14:19:13 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2707>; Wed, 22 Sep 1993 14:18:27 -0400 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09283; Wed, 22 Sep 93 14:15:52 -0400 Received: from srg.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 141432.16808; Wed, 22 Sep 1993 14:14:32 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa05570; Wed, 22 Sep 93 14:05:04 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: haahr@kaleida.com, rc@hawkwind.utcs.toronto.edu Subject: Re: shift Date: Wed, 22 Sep 1993 14:05:10 -0400 Message-Id: <9309221405.aa26790@ceres.srg.af.mil> > + ... accepted in subscript arguments, where > $x(m ... n) means all elements of x between the mth > mth and nth (inclusive). if m is omitted, 1 is assumed. > if n is a omitted, $#x is assumed. Beautiful! A really neat idea, but kind of a big change at this stage in the game, especially if we remove shift too. Tom From rc-owner Wed Sep 22 14:25:20 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2714>; Wed, 22 Sep 1993 14:24:52 -0400 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA24965; Wed, 22 Sep 93 13:47:05 -0400 Received: from srg.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 134526.25532; Wed, 22 Sep 1993 13:45:26 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa03473; Wed, 22 Sep 93 13:41:03 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: List of known gotchas and patches Date: Wed, 22 Sep 1993 13:41:07 -0400 Message-Id: <9309221341.aa26638@ceres.srg.af.mil> Here is my best attempt at an "authoritative" list of known problems and patches for rc-1.4 drawn from the mailing list and private mail. There have been several requests for this information in the past but up until now the only answer has been to wade through the list archives. I've tried to filter out bogus patches, mistaken bug reports, wish list items, and so on. If anyone spots any errors or omissions in this list please let me know. (My "Pile-O-Patches" offering includes all the one listed below except for the ones with disclaimers.) Tom ------------------------------------------------------------------------------ KNOWN PORTING PROBLEMS - Some versions of yacc (Sun) use malloc in a way that can cause a memory leak. - Some machines (SCO, HPUX) have a signal.h which the mksignal script can't parse properly. - Some machines (HP, Apollo?) have a problem with the use of varargs.h - Old versions of GCC (pre 1.39) generated bad code in a couple of places for some machines (80386, 80486). KNOWN LIMITATIONS - The rc globber will not pass through an unreadable directory the way that sh will. - Setting a umask higher than 0777 doesn't work. (Is this really a problem?) - When a signal handler is invoked it can change the value of $status asynchronously, causing a test or status report to get bogus results. KNOWN "GOOD" PATCHES - Patch to input.c June 3, '92 by Tom Culliton fixes readline support. - Patch to main.c June 16, '92 by Rich Salz and Boyd Roberts adds -s command line switch. NOTE - This patch has since been modified so that -s does not imply -i. - Patch to footobar.c October 12, '92 by Donn Cave fixes problem with assigning an empty string to a variable. - Patch to glob.c and lex.c November 10, '92 by Brendan Kehoe adds ~ as an alias for $home. DISCLAIMER - I haven't tried this patch personally but no one has complained about it publicly. Reposted January 18, '93. - Patch to print.c January 13, '93 by Scott Merrilees is a work around for the HP problem with vararg. DISCLAIMER - I haven't tried this patch personally but no one has complained about it publicly. This patch is only for HPUX. - Patch to lex.c and input.c May 13, '93 by Tom Culliton fixes an obscure problem with readline support and prompts. - Patch to trip.rc May 13, '93 by Tom Culliton fixes a typo which reversed !~ to ~!. WARNING - This patch may not work! There are long lines and non-printable characters in trip.rc that can screw up the patch program. - Patch to input.c August 18, '93 by Stefan Dalibor fixes a memory leak and an uninitialized memory access detected by Purify. - Patch to nalloc.c September 20, '93 by Tom Culliton is a work around for the broken realloc in SCO ODT 1.1. Rich Salz suggested a more stylish version of the same patch September 21, '93. - Patch to addon.[ch], addon/read.c and addon/trip.read September 21, '93 by Tom Culliton and Alan Watson adds builtin read. From rc-owner Wed Sep 22 20:03:48 1993 Received: from ccadfa.cc.adfa.oz.au ([131.236.1.2]) by hawkwind.utcs.toronto.ed u with SMTP id <2664>; Wed, 22 Sep 1993 19:59:36 -0400 Received: by ccadfa.cc.adfa.oz.au (5.65c/1.34) id AA20446; Thu, 23 Sep 1993 09:59:18 +1000 Message-Id: <199309222359.AA20446@ccadfa.cc.adfa.oz.au> From: Christopher.Vance@adfa.oz.au (CJS Vance) Organization: Computer Science, University College, University of New South Wal es, Canberra To: rc@hawkwind.utcs.toronto.edu Subject: Re: List of known gotchas and patches References: <9309221341.aa26638@ceres.srg.af.mil> Date: Wed, 22 Sep 1993 19:59:18 -0400 Sender: cjsv@ccadfa.cc.adfa.oz.au In message <9309221341.aa26638@ceres.srg.af.mil> culliton@srg.af.mil (Tom Culli ton x2278) writes: | KNOWN PORTING PROBLEMS | - Some machines (HP, Apollo?) have a problem with the use of varargs.h I seem to remember not too much problem with the Apollos, but the Pyramid did have problems with no stdarg.h and needing varargs.h instead. I haven't submitted patches to anyone, but if they're wanted, I can mail them. Changes were required to a number of files to get the same source compiled on Pyramid, Sun, Apollo, Convex. Picky or not-quite-ANSI compilers were a pain, but I eventually had them all happy. -- Christopher From rc-owner Thu Sep 23 03:33:05 1993 Received: from SINet.SLB.COM ([163.185.18.1]) by hawkwind.utcs.toronto.edu with SMTP id <2689>; Thu, 23 Sep 1993 03:32:03 -0400 Received: from snmrtr.psi by SINet.SLB.COM id AA19392; Thu, 23 Sep 93 07:34:43 GMT From: gjv%atlas%cesar@crbca1.SINet.SLB.COM Message-Id: <9309230734.AA19392@SINet.SLB.COM> Apparently-To: "hawkwind.utcs.toronto.edu::rc" X-Vms-From: PSI%CRBCA1::CESAR::ATLAS::"gjv" X-Vms-To: HERMES::M_MAILNOW::M_INTERNET::HAWKWIND.UTCS.TORONTO.EDU::RC Received: by DniMail (v1.0); Thu Sep 23 09:30:17 1993 MET DST Received: from pyxis by atlas.atlasnis (4.1/SMI-4.1-DNI) id AA11959; Thu, 23 Sep 93 09:30:00 +0200 To: rc%hawkwind.utcs.toronto.edu%m_internet%m_mailnow%hermes.DECnet@cesar. sedalia.sinet.slb.com Subject: Re: A patch to add builtin read (small bug) In-Reply-To: Your message of "Tue, 21 Sep 1993 23:11:29 +0200." Reply-To: vons@cesar.crbca1.sinet.slb.com Date: Thu, 23 Sep 1993 03:30:58 -0400 | The diffs assume you've been keeping up with the bug |fix patches posted here. (If anyone wants a complete set of diffs |against a virgin copy of 1.4 let me know and I'll mail it to you.) The patch dropped in nicely in my virgin 1.4, no problems. I was just wondering about the following case: ; x=(foo bar) ; read x < /dev/null ; echo $status 1 ; whatis x x=(foo bar) This suggests that something has been read before encountering EOF, which is obviously not the case, so I assume the read should set x to ''. |For Chris, if you don't care about setting a different ifs, you can |split the line without a fork by using eval: | read x;eval 'x=('$x')' This doesn't work: ; read x;eval 'x=('$x')' a line with a # in the middle line 1: syntax error near eof ; ; read x;eval 'x=('$x')' a line with a = in the middle line 1: syntax error near '=' ; The 'trick' with the echo works however, fork()-ing every time: ; read x; x= `{echo $x} a line with a # in the middle ; whatis x x=(a line with a '#' in the middle) ; If a read function is added, why not make it a bit more practical by using $ifs? If makes it more useful, and the code above a bit more elegant. I wouldn't mind adding this myself, but I'm not too familiar with the rc internals. Gert-Jan --------------------------------------------------- J.G. Vons E-Mail: vons@cesar.crbca1.sinet.slb.com From rc-owner Thu Sep 23 11:31:13 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2683>; Thu, 23 Sep 1993 11:30:30 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04699; Thu, 23 Sep 93 11:30:16 -0400 Received: from srg.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 112841.16827; Thu, 23 Sep 1993 11:28:41 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa07017; Thu, 23 Sep 93 11:19:17 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu, vons@cesar.crbca1.sinet.slb.com Subject: Re: A patch to add builtin read (small bug) Date: Thu, 23 Sep 1993 11:19:22 -0400 Message-Id: <9309231119.aa03974@ceres.srg.af.mil> > The patch dropped in nicely in my virgin 1.4, no problems. At least one of those bug fixes I mentioned prevents a crash, you really should look into them. > I was just wondering about the following case: > > ; x=(foo bar) > ; read x < /dev/null > ; echo $status > 1 > ; whatis x > x=(foo bar) > > This suggests that something has been read before encountering EOF, > which is obviously not the case, so I assume the read should set x to ''. Doing: read x |For Chris, if you don't care about setting a different ifs, you can > |split the line without a fork by using eval: > | read x;eval 'x=('$x')' > > This doesn't work: (Examples with embedded '#' and '=' deleted) Yeah, it's a stunt, and I should have made the standard disclaimer that pathalogical cases would kill it. > If a read function is added, why not make it a bit more practical by using > $ifs? If makes it more useful, and the code above a bit more elegant. > I wouldn't mind adding this myself, but I'm not too familiar with the > rc internals. > > Gert-Jan Because you lose information that you can't get back. For example if you are trying to parse the entries from /etc/passwd to find the home directories, and the comment field is blank: joeblow:x:200:50::/usr/joeblow:/bin/rc You get the following list: x=(joeblow x 200 50 /usr/joeblow /bin/rc) and when you try to retrieve $x(6) which should be the directory you get /bin/rc instead! This may not be the worlds best example but I hope my point is clear. The way read works now preserves potentially important information. Tom From rc-owner Thu Sep 23 11:36:57 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto .edu with SMTP id <2689>; Thu, 23 Sep 1993 11:36:41 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA02 220 (5.65c/IDA-1.4.4 for ); Thu, 23 Sep 1993 11:36: 19 -0400 Received: by penfold.cc.gatech.edu id AA02323 (5.65c/IDA-1.4.4); Thu, 23 Sep 1993 11:36:16 -0400 From: Arnold Robbins Message-Id: <199309231536.AA02323@penfold.cc.gatech.edu> Date: Thu, 23 Sep 1993 11:36:13 -0400 In-Reply-To: Tom Culliton x2278's 78-line message on Sep 23, 11:19am X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: culliton@srg.srg.af.mil (Tom Culliton x2278), rc@hawkwind.utcs.toronto.edu, vons@cesar.crbca1.sinet.slb.com Subject: Re: A patch to add builtin read (small bug) > Doing: > > read x > doesn't work either, but my brain isn't working well emough at the > moment to figure out why. Anybody got a clue? Doesn't rc fork builtins when they're redirected? This may be why redirections on read didn't show up in /bin/sh until System III or System V. (One of the sh man pages from ~ 5.0 says something like "redirections on read are *now* allowed" - emphasis mine.) Arnold From rc-owner Thu Sep 23 12:05:06 1993 Received: from SINet.SLB.COM ([163.185.18.1]) by hawkwind.utcs.toronto.edu with SMTP id <2683>; Thu, 23 Sep 1993 12:04:43 -0400 Received: from snmrtr.psi by SINet.SLB.COM id AA09004; Thu, 23 Sep 93 16:07:33 GMT From: gjv%atlas%cesar@crbca1.SINet.SLB.COM Message-Id: <9309231607.AA09004@SINet.SLB.COM> Apparently-To: "hawkwind.utcs.toronto.edu::rc" X-Vms-From: PSI%CRBCA1::CESAR::ATLAS::"gjv" X-Vms-To: HERMES::M_MAILNOW::M_INTERNET::HAWKWIND.UTCS.TORONTO.EDU::RC Received: by DniMail (v1.0); Thu Sep 23 18:03:02 1993 MET DST Received: from pyxis by atlas.atlasnis (4.1/SMI-4.1-DNI) id AA19946; Thu, 23 Sep 93 18:02:46 +0200 To: rc%hawkwind.utcs.toronto.edu%m_internet%m_mailnow%hermes.DECnet@cesar. sedalia.sinet.slb.com Subject: Re: A patch to add builtin read (small bug) In-Reply-To: Your message of "Thu, 23 Sep 1993 17:28:11 +0200." Reply-To: vons@cesar.crbca1.sinet.slb.com Date: Thu, 23 Sep 1993 12:03:47 -0400 [Tom wrote:] |At least one of those bug fixes I mentioned prevents a crash, you really |should look into them. Ok, someone has a "jumbo" patch against a vanilla 1.4 ? (saves me from scanning the archive for the actual patches). |[ Re: read x;eval 'x=('$x')'] | |Yeah, it's a stunt, and I should have made the standard disclaimer that |pathalogical cases would kill it. A hopefully not_so_pathological example: The password file may have * in the password field for some special users, which gets expanded to all files in the current directory... |[ Re: ifs aware read function] | |Because you lose information that you can't get back. For example if |you are trying to parse the entries from /etc/passwd to find the home |directories, and the comment field is blank: | |[example with blank fields deleted] | |and when you try to retrieve $x(6) which should be the directory you get |/bin/rc instead! This may not be the worlds best example but I hope my |point is clear. The way read works now preserves potentially important |information. Ok, good example, but an ifs aware read still allows you to set ifs to newline before reading, giving you the functionality of the current read. The risk of loosing information is my responsability I think, it is not up to the read function to keep me from doing so. Gert-Jan --------------------------------------------------- J.G. Vons E-Mail: vons@cesar.crbca1.sinet.slb.com From rc-owner Thu Sep 23 15:24:20 1993 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.toronto .edu with SMTP id <2664>; Thu, 23 Sep 1993 15:03:27 -0400 Received: from penfold.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA11 173 (5.65c/IDA-1.4.4 for ); Thu, 23 Sep 1993 14:57: 46 -0400 Received: by penfold.cc.gatech.edu id AA02580 (5.65c/IDA-1.4.4 for rc@hawkwind.utcs.toronto.edu); Thu, 23 Sep 1993 14:57:44 -0400 From: Arnold Robbins Message-Id: <199309231857.AA02580@penfold.cc.gatech.edu> Date: Thu, 23 Sep 1993 14:57:43 -0400 X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rc@hawkwind.utcs.toronto.edu Subject: forking builtins althouh i'm sure to be flamed for mentioning the name 'ksh', much of that shell's performance comes from strenous effort to avoid forking of builtins upon redirection. i am not advocating that byron rework rc or anything like that. except for read, it's not a major problem with the other builtiins, i'm just remarking upon it. From rc-owner Thu Sep 23 17:33:00 1993 Received: from colossus.apple.com ([130.43.2.6]) by hawkwind.utcs.toronto.edu w ith SMTP id <2704>; Thu, 23 Sep 1993 17:31:17 -0400 Received: from talisman.kaleida.com by colossus.apple.com with SMTP (5.65/22-Ju n-1993-eef) id AA27982; Thu, 23 Sep 93 14:02:39 -0700 for Received: from phaahr.kaleida.com by talisman.kaleida.com (4.1/SMI-4.1) id AA00244; Thu, 23 Sep 93 14:00:37 PDT Message-Id: <9309232100.AA00244@talisman.kaleida.com> Date: Thu, 23 Sep 1993 18:02:26 -0400 To: Arnold Robbins From: haahr@kaleida.com (Paul Haahr) X-Sender: haahr@talisman.kaleida.com Subject: Re: forking builtins Cc: rc@hawkwind.utcs.toronto.edu >althouh i'm sure to be flamed for mentioning the name 'ksh', much of that >shell's performance comes from strenous effort to avoid forking of builtins >upon redirection. it's not that hard conceptually, it just takes some effort to make sure you catch every reference to file descriptors. Byron and i came up with a strategy for es that works. see es's fd.c for details. but strenuous it is not. >i am not advocating that byron rework rc or anything like that. except for >read, it's not a major problem with the other builtiins, i'm just remarking >upon it. echo could also use it. From rc-owner Thu Sep 23 18:08:28 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2699>; Thu, 23 Sep 1993 18:07:58 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26484; Thu, 23 Sep 93 14:55:06 -0400 Received: from srg.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 145241.2523; Thu, 23 Sep 1993 14:52:41 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa04867; Thu, 23 Sep 93 14:10:27 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: arnold@cc.gatech.edu, culliton@srg.srg.af.mil, rc@hawkwind.utcs.toronto.edu, vons@cesar.crbca1.sinet.slb.com Subject: Re: A patch to add builtin read (small bug) Date: Thu, 23 Sep 1993 14:10:08 -0400 Message-Id: <9309231410.aa05022@ceres.srg.af.mil> > Doesn't rc fork builtins when they're redirected? This may be why > redirections on read didn't show up in /bin/sh until System III or > System V. That sounds like the right answer to me and since no other builtin command takes input... Sigh... This is looking like a bigger job than expected. If it's not obvious how to fix this I may withdraw the read patch until someone can do it right. Tom From rc-owner Thu Sep 23 20:17:19 1993 Received: from plg.uwaterloo.ca ([129.97.140.10]) by hawkwind.utcs.toronto.edu with SMTP id <2664>; Thu, 23 Sep 1993 20:15:01 -0400 Received: by plg.uwaterloo.ca id <230427>; Thu, 23 Sep 1993 20:14:27 -0400 From: Dave Mason To: dws@ssec.wisc.edu CC: es@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu In-reply-to: <9309232223.AA27120@ssec.ssec.wisc.edu> (dws@ssec.wisc.edu) Subject: distinguishing shells X-Face: %Q_F^9R-:'3MM7eZ6@E.x@f\*bgatzGv-8d%I~L[p^.F)3QF{kq\UTsu|e#?)3FPwJNvPPB !s*He|-*M^p*~bh"Nywm5NLL\\Rl3r(hWHY*F:$/RdKV*bS";n&#\Ov@*=]mu\}6tP Date: Thu, 23 Sep 1993 20:14:20 -0400 DaviD W Sanderson asked for a way to differentiate between rc/es and the other shells. This works: y=`echo`false;$y&&echo rc or es||echo sh (it *does* expect there to be a false accessible to /bin/sh, but that seems fairly likely, and it doesn't require anything for the rc side.) In trying a few things, one of my ideas was to: $SHELL -c '~ 5 5 2>/dev/null' && echo rc || echo sh To my surprise, rc gave a syntax error because the ~ builtin doesn't accept I/O redirection. (It actually doesn't work anyway because /bin/sh complains about '~ not found' before the stderr redirect.) ../Dave (I forwarded this to the rc list in case anyone there needed it too.) From rc-owner Thu Sep 23 20:18:35 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <2683>; Thu, 23 Sep 1993 20:18:21 -0400 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21700; Thu, 23 Sep 93 20:18:10 -0400 Received: from srg.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 201649.13215; Thu, 23 Sep 1993 20:16:49 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa20089; Thu, 23 Sep 93 20:03:47 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: arnold@cc.gatech.edu, haahr@kaleida.com Subject: Re: forking builtins Cc: rc@hawkwind.utcs.toronto.edu Date: Thu, 23 Sep 1993 20:03:45 -0400 Message-Id: <9309232003.aa07101@ceres.srg.af.mil> > >i am not advocating that byron rework rc or anything like that. except for > >read, it's not a major problem with the other builtiins, i'm just remarking > >upon it. > > echo could also use it. It would also make "whatis -s >handlers" work! :-) Right now thats the only glitch in being able to capture your current environment. Tom From rc-owner Fri Sep 24 03:35:11 1993 Received: from munnari.oz.au ([128.250.1.21]) by hawkwind.utcs.toronto.edu with SMTP id <2645>; Fri, 24 Sep 1993 03:34:35 -0400 Received: from maxim.gba.oz (via mulga) by munnari.oz.au with SunIII (5.83--+1. 3.1+0.50) id AA19554; Fri, 24 Sep 1993 17:33:16 +1000 (from gjb@maxim.gba.oz.au) Received: by maxim.gba.oz.au (5.65c/gba-0.2) id AA07610; Fri, 24 Sep 1993 17:24:57 +1000 From: gjb@maxim.gba.oz.au (Greg Black) Posted-Date: Fri, 24 Sep 1993 17:24:56 -40962758 (AEST) Message-Id: <199309240724.AA07610@maxim.gba.oz.au> Subject: Unsubscribe To: rc@hawkwind.utcs.toronto.edu Cc: gjb@gba.oz.au Reply-To: gjb%gba.oz.au@tmxmelb.mhs.oz.au (Greg Black) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 876 Date: Fri, 24 Sep 1993 03:34:28 -0400 I need to unsubscribe an earlier incarnation of myself from this mailing list. All my records of how to do this died when my access died, so I cannot look anything up. If the list maintainer reads this, then please remove gjb@bullit.void.oz.au (Greg Black) from the list and let me know at the address below. If somebody else reads this and knows that the list maintainer does not, please e-mail me at the address below with the details of what I need to do to unsubscribe. (I have an irate system administrator at an intermediate machine who wants the mail stopped.) Thanks in advance to all. P.S. For everybody who read this superficially and wants to tell me that I've done the wrong thing, I am not able to write from the addrsss that I want cancelled. -- Greg Black -- gjb%gba.oz.au@tmxmelb.mhs.oz.au 681 Park Street, Brunswick, Vic. 3056, Australia From rc-owner Fri Sep 24 11:14:47 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <2645>; Fri, 24 Sep 1993 11:11:45 -0400 Received: by mod.civil.su.oz.au id <28695>; Sat, 25 Sep 1993 01:08:20 +1000 From: John (Most modern computers would break if you stood on them) Mackin Date: Fri, 24 Sep 1993 11:05:01 -0400 To: Tom Culliton x2278 , rc@hawkwind.utcs.toronto.edu Subject: Re: List of known gotchas and patches In-Reply-To: <9309221341.aa26638@ceres.srg.af.mil> Message-ID: <199309250105.27728.rc.baloj@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ There's one known _bug_ with rc-1.4, and that's in its signal handling. Byron and I have tossed this back and forth several times; as far as I know, he hasn't fixed it, and I know I haven't. (Note that this bug was NOT present in pre-release versions of 1.4; it was in 1.3, I reported it to Byron and he fixed it, and then he broke it again in the 1.4 release version.) The bug is that rc doesn't wait correctly for backquoted commands to complete on signals, so that if you have a backquoted command running which traps interrupts and you type your interrupt character, you end up with a mess. OK, John. From rc-owner Fri Sep 24 12:54:54 1993 Received: by hawkwind.utcs.toronto.edu via suspension id <2699>; Fri, 24 Sep 19 93 12:54:29 -0400 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2645>; Fri, 24 Sep 1993 12:41:19 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA14894; Fri, 24 Sep 1993 11:40:59 -0500 Message-Id: <9309241640.AA14894@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: forking builtins Date: Fri, 24 Sep 1993 12:40:58 -0400 From: Alan Watson X-Mts: smtp Of the suggestions I have seen so far, Malte's `line is clearly the suggestion most in line with the rc philosophy. However, it isn't going to satisfy the performance demands (needs?) of many people. At first glance a builtin read will be no faster than line because of the way rc handles the redirection of builtins. However, all one needs to do is the following: exec ; Fri, 24 Sep 19 93 18:00:12 -0400 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2699>; Fri, 24 Sep 1993 17:46:17 -0400 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18512; Fri, 24 Sep 93 17:46:03 -0400 Received: from srg.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 174456.24956; Fri, 24 Sep 1993 17:44:56 EDT Received: from ceres.srg.af.mil by srg.srg.af.mil id aa01665; Fri, 24 Sep 93 17:19:30 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Re: forking builtins Date: Fri, 24 Sep 1993 17:19:41 -0400 Message-Id: <9309241719.aa13919@ceres.srg.af.mil> While this discussion about forking builtin's to do redirection is all well and good, it seems like a fairly odd way to use read. As I've said in the past, the reasons you would usually use read are to: 1) Get a single line of input from a user. In this case performance isn't an issue and the user is presumably talking to fd 0 and there's no problem. (There may be a case for using /dev/tty but performance still isn't going to be an issue.) For example: echo -n 'Where do you want logfile written? ' read logfilename 2) Chewing through a whole input stream or datafile. In this case performance is an issue but since the data is presented as a stream presumably on fd 0 and again there's no problem. For example: here = `pwd { find . -type d -print | while (read dirname) { if (cd $here/$dirname) ls -l >.contents }} I can only think of one case where you might do something like (get only the first line of a file): read bgcolor <.background and in that case you'd be crazy to do it more than once, so again performance shouldn't be an issue. Tom From rc-owner Mon Oct 4 09:20:18 1993 Received: from csadfa.cs.adfa.oz.au ([131.236.20.6]) by hawkwind.utcs.toronto.e du with SMTP id <2699>; Mon, 4 Oct 1993 09:16:49 -0400 Received: by csadfa.cs.adfa.oz.au (5.61/1.34) id AA09824; Mon, 4 Oct 93 22:20:27 +1000 Date: Mon, 4 Oct 1993 08:20:27 -0400 From: cjsv@csadfa.cs.adfa.oz.au (Christopher Vance) Message-Id: <9310041220.AA09824@csadfa.cs.adfa.oz.au> To: rc@hawkwind.utcs.toronto.edu Subject: patches to rc 1.4 Cc: cjsv@ccadfa.cc.adfa.oz.au The following patches are with respect to Tom Culliton's complete list, including the recent builtin read, although most of the changes revealed here were made to virgin 1.4 before any patches were posted. My patches were mostly made to enable identical source files to be compiled on several architectures. These sources now compile on Pyramid OSx 5.1a cc -Xa (has no stdarg.h) DomainOS 10.4 cc (both M68K and A88K) SunOS 4.1.3 gcc and closely related sources at one time did compile on ConvexOS 10.1 cc I can't remember if I also compiled the same sources on AIX 3.1; besides, my account on that machine doesn't have a home directory anymore... Since I made the original changes in November, our Convex has disappeared, so I can't verify that these sources still compile on ConvexOS. (A pity, since it had the best ANSI/POSIX environment I've used.) The details of which particular compiler required which change is now lost in history. Also, a number of OS upgrades since then may have made some of the patches unnecessary. The patches to trip.rc may fail on some versions of patch, but should be simple to apply by hand if have some version of gnu emacs. I can also provide these patches with respect to virgin 1.4 if requested. -- Christopher *** /tmp/,RCSt1008584 Mon Oct 4 21:58:48 1993 --- addon.c Mon Oct 4 21:58:22 1993 *************** *** 3,10 builtins. */ - #include "rc.h" /* for bool TRUE, FALSE, configuration options */ - #ifdef DWS /* --- 3,8 ----- builtins. */ #ifdef DWS /* *************** *** 15,20 #include #include #include "addon.h" #include "addon/access.c" --- 13,19 ----- #include #include + #include "rc.h" /* for bool TRUE, FALSE */ #include "addon.h" #include "addon/access.c" *************** *** 26,31 #ifndef DWS #include #include "addon.h" #endif --- 25,31 ----- #ifndef DWS #include + #include "rc.h" /* for bool TRUE, FALSE */ #include "addon.h" #endif *** /tmp/,RCSt1008584 Mon Oct 4 21:58:50 1993 --- config.h-dist Mon Oct 4 21:58:08 1993 *************** *** 108,132 #define NOJOB */ - /* - * Define the macro NEED_VARARGS if your C compiler doesn't have stdarg.h, - * but does have varargs.h. This macro assumes (as is true for the Pyramid) - * that va_alist can appear *after* other arguments in the argument list. - #define NEED_VARARGS - */ - - /* - * Define the macro NEED_STRINGS if your C compiler doesn't have string.h, - * but does have strings.h. - #define NEED_STRINGS - */ - - /* - * Define the macro NEED_ERRNO if your C compiler doesn't declare errno - * but does have strings.h. - #define NEED_STRINGS - */ - /* Beginning of defaults section: */ #ifndef CUSTOM --- 108,113 ----- #define NOJOB */ /* Beginning of defaults section: */ #ifndef CUSTOM *************** *** 153,159 #define PROTECT_ENV #undef DEFAULTPATH #define DEFAULTPATH "/usr/ucb", "/usr/bin", "." - #define DEFAULTINTERP "/bin/sh" #endif /* --- 134,139 ----- #define PROTECT_ENV #undef DEFAULTPATH #define DEFAULTPATH "/usr/ucb", "/usr/bin", "." #endif /* *************** *** 188,194 #if defined(host_mips) && defined(MIPSEB) && defined(SYSTYPE_BSD43) #define NODIRENT #define PROTECT_ENV - #define NEED_ERRNO #endif /* --- 168,173 ----- #if defined(host_mips) && defined(MIPSEB) && defined(SYSTYPE_BSD43) #define NODIRENT #define PROTECT_ENV #endif /* *************** *** 216,244 #define NOLIMITS #define word _word #define DEFAULTINTERP "/bin/sh" - #endif - - /* - * Suggested settings for DomainOS 10.4 - */ - - #ifdef apollo - #define DEFAULTINTERP "/bin/sh" - #define PROTECT_ENV - #define NODIRENT - #endif - - /* - * Suggested settings for OSx 5.1a - */ - - #ifdef pyr - #define DEFAULTINTERP "/bin/sh" - #define PROTECT_ENV - #define NODIRENT - #define NEED_ERRNO - #define NEED_STRINGS - #define NEED_VARARGS #endif #endif /* CUSTOM */ --- 195,200 ----- #define NOLIMITS #define word _word #define DEFAULTINTERP "/bin/sh" #endif #endif /* CUSTOM */ *** /tmp/,RCSt1008584 Mon Oct 4 21:58:52 1993 --- fn.c Mon Oct 4 21:58:10 1993 *************** *** 94,100 sigcommon: default: if (sighandlers[i] != SIG_DFL) { ! rc_signal(i, (sighandler*)SIG_DFL); delete_fn(signals[i].name); } } --- 94,100 ----- sigcommon: default: if (sighandlers[i] != SIG_DFL) { ! rc_signal(i, SIG_DFL); delete_fn(signals[i].name); } } *************** *** 167,173 if (streq(signals[i].name, name)) { handlers[i] = newdef; if (def == NULL) ! rc_signal(i, (sighandler*)SIG_IGN); else rc_signal(i, fn_handler); break; --- 167,173 ----- if (streq(signals[i].name, name)) { handlers[i] = newdef; if (def == NULL) ! rc_signal(i, SIG_IGN); else rc_signal(i, fn_handler); break; *************** *** 241,247 rc_signal(i, def_sigterm); break; default: ! rc_signal(i, (sighandler*)SIG_DFL); } } if (streq(name, "sigexit")) --- 241,247 ----- rc_signal(i, def_sigterm); break; default: ! rc_signal(i, SIG_DFL); } } if (streq(name, "sigexit")) *** /tmp/,RCSt1008584 Mon Oct 4 21:59:01 1993 --- list.c Mon Oct 4 21:58:13 1993 *************** *** 22,29 /* Copy list into malloc space (for storing a variable) */ ! /*extern List *listcpy(List *s, void *(*alloc)(SIZE_T)) {*/ ! extern List *listcpy(List *s, allocf *alloc) { List *top, *r; for (top = r = NULL; s != NULL; s = s->n) { if (top == NULL) --- 22,28 ----- /* Copy list into malloc space (for storing a variable) */ ! extern List *listcpy(List *s, void *(*alloc)(SIZE_T)) { List *top, *r; for (top = r = NULL; s != NULL; s = s->n) { if (top == NULL) *** /tmp/,RCSt1008584 Mon Oct 4 21:59:02 1993 --- main.c Mon Oct 4 21:58:27 1993 *************** *** 8,16 static bool dashoh; - #ifdef NEED_VARARGS - static void assigndefault(); - #else static void assigndefault(char *,...); #endif static void checkfd(int, redirtype); --- 8,13 ----- static bool dashoh; static void assigndefault(char *,...); static void checkfd(int, enum redirtype); *************** *** 12,19 static void assigndefault(); #else static void assigndefault(char *,...); ! #endif ! static void checkfd(int, redirtype); extern void main(int argc, char *argv[], char *envp[]) { char *dashsee[2], *dollarzero, *null[1]; --- 9,15 ----- static bool dashoh; static void assigndefault(char *,...); ! static void checkfd(int, enum redirtype); extern void main(int argc, char *argv[], char *envp[]) { char *dashsee[2], *dollarzero, *null[1]; *************** *** 104,112 rc_exit(getstatus()); } - #ifdef NEED_VARARGS - static void assigndefault(name, va_alist) char *name; va_dcl { - #else static void assigndefault(char *name,...) { #endif va_list ap; --- 100,105 ----- rc_exit(getstatus()); } static void assigndefault(char *name,...) { va_list ap; List *l; *************** *** 108,114 static void assigndefault(name, va_alist) char *name; va_dcl { #else static void assigndefault(char *name,...) { - #endif va_list ap; List *l; char *v; --- 101,106 ----- } static void assigndefault(char *name,...) { va_list ap; List *l; char *v; *************** *** 112,120 va_list ap; List *l; char *v; - #ifdef NEED_VARARGS - va_start(ap); - #else va_start(ap, name); #endif for (l = NULL; (v = va_arg(ap, char *)) != NULL;) --- 104,109 ----- va_list ap; List *l; char *v; va_start(ap, name); for (l = NULL; (v = va_arg(ap, char *)) != NULL;) l = append(l, word(v, NULL)); *************** *** 116,122 va_start(ap); #else va_start(ap, name); - #endif for (l = NULL; (v = va_arg(ap, char *)) != NULL;) l = append(l, word(v, NULL)); varassign(name, l, FALSE); --- 105,110 ----- List *l; char *v; va_start(ap, name); for (l = NULL; (v = va_arg(ap, char *)) != NULL;) l = append(l, word(v, NULL)); varassign(name, l, FALSE); *************** *** 127,133 /* open an fd on /dev/null if it is inherited closed */ ! static void checkfd(int fd, redirtype r) { int new = rc_open("/dev/null", r); if (new != fd && new != -1) close(new); --- 115,121 ----- /* open an fd on /dev/null if it is inherited closed */ ! static void checkfd(int fd, enum redirtype r) { int new = rc_open("/dev/null", r); if (new != fd && new != -1) close(new); *** /tmp/,RCSt1008584 Mon Oct 4 21:59:03 1993 --- mksignal Mon Oct 4 21:58:14 1993 *************** *** 7,14 echo echo 'Sigmsgs signals[] = {' ! sed ' s/\/\*[ ]*(P)[ ]*// ! s/\/\*[ ]*// s/[ ]*\*\/// s/([@*+!]) // s/[ ]*([a-zA-Z,->& ]*)[ ]*// --- 7,13 ----- echo echo 'Sigmsgs signals[] = {' ! sed ' s/\/\*[ ]*// s/[ ]*\*\/// s/([@*+!]) // s/[ ]*([a-zA-Z,->& ]*)[ ]*// *** /tmp/,RCSt1008584 Mon Oct 4 21:59:06 1993 --- print.c Mon Oct 4 21:58:16 1993 *************** *** 175,182 * conversion table management */ ! /*static Conv fmttab[MAXCONV];*/ ! static bool (*fmttab[MAXCONV])(Format *, int); static void inittab(void) { int i; --- 175,181 ----- * conversion table management */ ! static Conv fmttab[MAXCONV]; static void inittab(void) { int i; *************** *** 202,208 fmttab[i] = digitconv; } ! /*extern bool (*fmtinstall(int c, bool (*f)(Format *, int)))(Format *, int) { */ /*Conv fmtinstall(int c, Conv f) {*/ extern bool (*fmtinstall(c, f))() int c; bool f(); { /*Conv oldf;*/ --- 201,207 ----- fmttab[i] = digitconv; } ! extern bool (*fmtinstall(int c, bool (*f)(Format *, int)))(Format *, int) { /*Conv fmtinstall(int c, Conv f) {*/ Conv oldf; if (fmttab[0] == NULL) *************** *** 204,212 /*extern bool (*fmtinstall(int c, bool (*f)(Format *, int)))(Format *, int) { */ /*Conv fmtinstall(int c, Conv f) {*/ ! extern bool (*fmtinstall(c, f))() int c; bool f(); { ! /*Conv oldf;*/ ! bool (*oldf)(Format *, int); if (fmttab[0] == NULL) inittab(); c &= MAXCONV - 1; --- 203,209 ----- extern bool (*fmtinstall(int c, bool (*f)(Format *, int)))(Format *, int) { /*Conv fmtinstall(int c, Conv f) {*/ ! Conv oldf; if (fmttab[0] == NULL) inittab(); c &= MAXCONV - 1; *************** *** 271,279 * the public entry points */ - #ifdef NEED_VARARGS - extern int fmtprint(format, fmt, va_alist) Format *format; const char *fmt; v a_dcl { - #else extern int fmtprint(Format *format, const char *fmt,...) { #endif int n = -format->flushed; --- 268,273 ----- * the public entry points */ extern int fmtprint(Format *format, const char *fmt,...) { int n = -format->flushed; va_list saveargs = format->args; *************** *** 275,281 extern int fmtprint(format, fmt, va_alist) Format *format; const char *fmt; v a_dcl { #else extern int fmtprint(Format *format, const char *fmt,...) { - #endif int n = -format->flushed; va_list saveargs = format->args; --- 269,274 ----- */ extern int fmtprint(Format *format, const char *fmt,...) { int n = -format->flushed; va_list saveargs = format->args; *************** *** 279,287 int n = -format->flushed; va_list saveargs = format->args; - #ifdef NEED_VARARGS - va_start(format->args); - #else va_start(format->args, fmt); #endif n += printfmt(format, fmt); --- 272,277 ----- int n = -format->flushed; va_list saveargs = format->args; va_start(format->args, fmt); n += printfmt(format, fmt); va_end(format->args); *************** *** 283,289 va_start(format->args); #else va_start(format->args, fmt); - #endif n += printfmt(format, fmt); va_end(format->args); format->args = saveargs; --- 273,278 ----- va_list saveargs = format->args; va_start(format->args, fmt); n += printfmt(format, fmt); va_end(format->args); format->args = saveargs; *************** *** 300,308 writeall(format->u.n, buf, n); } - #ifdef NEED_VARARGS - extern int fprint(fd, fmt, va_alist) int fd; const char *fmt; va_dcl { - #else extern int fprint(int fd, const char *fmt,...) { #endif char buf[1024]; --- 289,294 ----- writeall(format->u.n, buf, n); } extern int fprint(int fd, const char *fmt,...) { char buf[1024]; Format format; *************** *** 304,310 extern int fprint(fd, fmt, va_alist) int fd; const char *fmt; va_dcl { #else extern int fprint(int fd, const char *fmt,...) { - #endif char buf[1024]; Format format; --- 290,295 ----- } extern int fprint(int fd, const char *fmt,...) { char buf[1024]; Format format; *************** *** 315,323 format.flushed = 0; format.u.n = fd; - #ifdef NEED_VARARGS - va_start(format.args); - #else va_start(format.args, fmt); #endif printfmt(&format, fmt); --- 300,305 ----- format.flushed = 0; format.u.n = fd; va_start(format.args, fmt); printfmt(&format, fmt); va_end(format.args); *************** *** 319,325 va_start(format.args); #else va_start(format.args, fmt); - #endif printfmt(&format, fmt); va_end(format.args); --- 301,306 ----- format.u.n = fd; va_start(format.args, fmt); printfmt(&format, fmt); va_end(format.args); *************** *** 356,364 return format->bufbegin; } - #ifdef NEED_VARARGS - extern char *mprint(fmt, va_alist) const char *fmt; va_dcl { - #else extern char *mprint(const char *fmt,...) { #endif Format format; --- 337,342 ----- return format->bufbegin; } extern char *mprint(const char *fmt,...) { Format format; char *result; *************** *** 360,366 extern char *mprint(fmt, va_alist) const char *fmt; va_dcl { #else extern char *mprint(const char *fmt,...) { - #endif Format format; char *result; format.u.n = 1; --- 338,343 ----- } extern char *mprint(const char *fmt,...) { Format format; char *result; format.u.n = 1; *************** *** 364,372 Format format; char *result; format.u.n = 1; - #ifdef NEED_VARARGS - va_start(format.args); - #else va_start(format.args, fmt); #endif result = memprint(&format, fmt, ealloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); --- 341,346 ----- Format format; char *result; format.u.n = 1; va_start(format.args, fmt); result = memprint(&format, fmt, ealloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); *************** *** 368,374 va_start(format.args); #else va_start(format.args, fmt); - #endif result = memprint(&format, fmt, ealloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); return result; --- 342,347 ----- char *result; format.u.n = 1; va_start(format.args, fmt); result = memprint(&format, fmt, ealloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); return result; *************** *** 374,382 return result; } - #ifdef NEED_VARARGS - extern char *nprint(fmt, va_alist) const char *fmt; va_dcl { - #else extern char *nprint(const char *fmt,...) { #endif Format format; --- 347,352 ----- return result; } extern char *nprint(const char *fmt,...) { Format format; char *result; *************** *** 378,384 extern char *nprint(fmt, va_alist) const char *fmt; va_dcl { #else extern char *nprint(const char *fmt,...) { - #endif Format format; char *result; format.u.n = 0; --- 348,353 ----- } extern char *nprint(const char *fmt,...) { Format format; char *result; format.u.n = 0; *************** *** 382,390 Format format; char *result; format.u.n = 0; - #ifdef NEED_VARARGS - va_start(format.args); - #else va_start(format.args, fmt); #endif result = memprint(&format, fmt, nalloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); --- 351,356 ----- Format format; char *result; format.u.n = 0; va_start(format.args, fmt); result = memprint(&format, fmt, nalloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); *************** *** 386,392 va_start(format.args); #else va_start(format.args, fmt); - #endif result = memprint(&format, fmt, nalloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); return result; --- 352,357 ----- char *result; format.u.n = 0; va_start(format.args, fmt); result = memprint(&format, fmt, nalloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); return result; *** /tmp/,RCSt1008584 Mon Oct 4 21:59:07 1993 --- proto.h Mon Oct 4 21:58:16 1993 *************** *** 14,24 of the same macros. */ - #ifdef NEED_STRINGS - #define strchr index - #define strrchr rindex - #endif - #ifndef ALIGN_T typedef long ALIGN_T; #endif --- 14,19 ----- of the same macros. */ #ifndef ALIGN_T typedef long ALIGN_T; #endif *************** *** 81,86 /* fake errno.h for mips (which doesn't declare errno in errno.h!?!?) */ ! #ifdef NEED_ERRNO extern int errno; #endif --- 76,81 ----- /* fake errno.h for mips (which doesn't declare errno in errno.h!?!?) */ ! #ifdef host_mips extern int errno; #endif *** /tmp/,RCSt1008584 Mon Oct 4 21:59:09 1993 --- rc.h Mon Oct 4 21:58:17 1993 *************** *** 7,15 #undef FALSE #undef TRUE - #ifdef NEED_VARARGS - #include - #else #include #endif --- 7,12 ----- #undef FALSE #undef TRUE #include typedef void builtin_t(char **); *************** *** 11,17 #include #else #include - #endif typedef void builtin_t(char **); typedef struct Block Block; --- 8,13 ----- #undef TRUE #include typedef void builtin_t(char **); typedef struct Block Block; *************** *** 166,177 #define streq(x, y) (*(x) == *(y) && strcmp(x, y) == 0) #define conststrlen(x) (sizeof (x) - 1) - /* function typedefs are more tricky */ - - typedef void *allocf(SIZE_T); - typedef void (sighandler)(int); - typedef void sigfunc(int); - /* rc prototypes */ /* main.c */ --- 162,167 ----- #define streq(x, y) (*(x) == *(y) && strcmp(x, y) == 0) #define conststrlen(x) (sizeof (x) - 1) /* rc prototypes */ /* main.c */ *************** *** 316,324 */ extern bool (*fmtinstall(int, bool (*)(Format *, int)))(Format *, int); extern int printfmt(Format *, const char *); - #ifdef NEED_VARARGS - extern int fmtprint(); - #else extern int fmtprint(Format *, const char *,...); #endif extern void fmtappend(Format *, const char *, SIZE_T); --- 306,311 ----- */ extern bool (*fmtinstall(int, bool (*)(Format *, int)))(Format *, int); extern int printfmt(Format *, const char *); extern int fmtprint(Format *, const char *,...); extern void fmtappend(Format *, const char *, SIZE_T); extern void fmtcat(Format *, const char *); *************** *** 320,326 extern int fmtprint(); #else extern int fmtprint(Format *, const char *,...); - #endif extern void fmtappend(Format *, const char *, SIZE_T); extern void fmtcat(Format *, const char *); #ifdef NEED_VARARGS --- 307,312 ----- extern bool (*fmtinstall(int, bool (*)(Format *, int)))(Format *, int); extern int printfmt(Format *, const char *); extern int fmtprint(Format *, const char *,...); extern void fmtappend(Format *, const char *, SIZE_T); extern void fmtcat(Format *, const char *); extern int fprint(int fd, const char *fmt,...); *************** *** 323,333 #endif extern void fmtappend(Format *, const char *, SIZE_T); extern void fmtcat(Format *, const char *); - #ifdef NEED_VARARGS - extern int fprint(); - extern char *mprint(); - extern char *nprint(); - #else extern int fprint(int fd, const char *fmt,...); extern char *mprint(const char *fmt,...); extern char *nprint(const char *fmt,...); --- 309,314 ----- extern int fmtprint(Format *, const char *,...); extern void fmtappend(Format *, const char *, SIZE_T); extern void fmtcat(Format *, const char *); extern int fprint(int fd, const char *fmt,...); extern char *mprint(const char *fmt,...); extern char *nprint(const char *fmt,...); *************** *** 331,337 extern int fprint(int fd, const char *fmt,...); extern char *mprint(const char *fmt,...); extern char *nprint(const char *fmt,...); - #endif /* the following macro should by rights be coded as an expression, not a statement, but certain compilers (notably DEC) have trouble with --- 312,317 ----- extern int fprint(int fd, const char *fmt,...); extern char *mprint(const char *fmt,...); extern char *nprint(const char *fmt,...); /* the following macro should by rights be coded as an expression, not a statement, but certain compilers (notably DEC) have trouble with *************** *** 356,363 extern void catcher(int); extern void sigchk(void); extern void (*rc_signal(int, void (*)(int)))(int); ! /*extern void (*sighandlers[])(int);*/ ! extern sighandler *sighandlers[]; extern volatile SIG_ATOMIC_T slow, interrupt_happened; #define SIGCHK sigchk() --- 336,342 ----- extern void catcher(int); extern void sigchk(void); extern void (*rc_signal(int, void (*)(int)))(int); ! extern void (*sighandlers[])(int); extern volatile SIG_ATOMIC_T slow, interrupt_happened; #define SIGCHK sigchk() *************** *** 372,380 extern void ssetstatus(char **); /* tree.c */ - #ifdef NEED_VARARGS - extern Node *mk(); - #else extern Node *mk(int /*nodetype*/,...); #endif extern Node *treecpy(Node *, void *(*)(SIZE_T)); --- 351,356 ----- extern void ssetstatus(char **); /* tree.c */ extern Node *mk(int /*nodetype*/,...); extern Node *treecpy(Node *, void *(*)(SIZE_T)); extern void treefree(Node *); *************** *** 376,382 extern Node *mk(); #else extern Node *mk(int /*nodetype*/,...); - #endif extern Node *treecpy(Node *, void *(*)(SIZE_T)); extern void treefree(Node *); --- 352,357 ----- /* tree.c */ extern Node *mk(int /*nodetype*/,...); extern Node *treecpy(Node *, void *(*)(SIZE_T)); extern void treefree(Node *); *** /tmp/,RCSt1008584 Mon Oct 4 21:59:11 1993 --- signal.c Mon Oct 4 21:58:18 1993 *************** *** 50,57 (*h)(s); } ! /*extern void (*rc_signal(int s, void (*h)(int)))(int) {*/ ! extern sigfunc *rc_signal(int s, sigfunc *h) { void (*old)(int); SIGCHK; old = sighandlers[s]; --- 50,56 ----- (*h)(s); } ! extern void (*rc_signal(int s, void (*h)(int)))(int) { void (*old)(int); SIGCHK; old = sighandlers[s]; *** /tmp/,RCSt1008584 Mon Oct 4 21:59:12 1993 --- tree.c Mon Oct 4 21:58:19 1993 *************** *** 4,12 /* make a new node, pass it back to yyparse. Used to generate the parsetree. */ - #ifdef NEED_VARARGS - extern Node *mk(t, va_alist) int t; va_dcl { - #else extern Node *mk(int /*nodetype*/ t,...) { #endif va_list ap; --- 4,9 ----- /* make a new node, pass it back to yyparse. Used to generate the parsetree. */ extern Node *mk(int /*nodetype*/ t,...) { va_list ap; Node *n; *************** *** 8,14 extern Node *mk(t, va_alist) int t; va_dcl { #else extern Node *mk(int /*nodetype*/ t,...) { - #endif va_list ap; Node *n; #ifdef NEED_VARARGS --- 5,10 ----- /* make a new node, pass it back to yyparse. Used to generate the parsetree. */ extern Node *mk(int /*nodetype*/ t,...) { va_list ap; Node *n; va_start(ap, t); *************** *** 11,19 #endif va_list ap; Node *n; - #ifdef NEED_VARARGS - va_start(ap); - #else va_start(ap, t); #endif switch (t) { --- 7,12 ----- extern Node *mk(int /*nodetype*/ t,...) { va_list ap; Node *n; va_start(ap, t); switch (t) { default: *************** *** 15,21 va_start(ap); #else va_start(ap, t); - #endif switch (t) { default: panic("unexpected node in mk"); --- 8,13 ----- va_list ap; Node *n; va_start(ap, t); switch (t) { default: panic("unexpected node in mk"); *************** *** 73,80 /* copy a tree to malloc space. Used when storing the definition of a functio n */ ! /*extern Node *treecpy(Node *s, void *(*alloc)(SIZE_T)) {*/ ! extern Node *treecpy(Node *s, allocf *alloc) { Node *n; if (s == NULL) return NULL; --- 65,71 ----- /* copy a tree to malloc space. Used when storing the definition of a functio n */ ! extern Node *treecpy(Node *s, void *(*alloc)(SIZE_T)) { Node *n; if (s == NULL) return NULL; *** /tmp/,RCSt1008584 Mon Oct 4 21:59:13 1993 --- trip.rc Mon Oct 4 21:58:30 1993 *************** *** 81,88 if (!~ `` '' {cat 2} foo) fail dup put wrong contents in file : `` '' {cat 2} rm -f 1 2 ! # cat doesn't seem to mind this on a Pyramid ! expect error from cat, closing stdin '('no error reported on Pyramid')' cat >[0=] submatch 'cat>(1 2 3)' 'multi-word filename in redirection' 'redirection erro r' --- 81,87 ----- if (!~ `` '' {cat 2} foo) fail dup put wrong contents in file : `` '' {cat 2} rm -f 1 2 ! expect error from cat, closing stdin cat >[0=] submatch 'cat>(1 2 3)' 'multi-word filename in redirection' 'redirection erro r' *************** *** 281,291 expect list of variables and functions whatis - - # during port to Pyramid (or was it Convex?), all elements seemed to - # be missing their first character - expect list of files in this directory - echo * submatch 'whatis -f' 'whatis: bad option: -f' 'bad option to whatis' --- 280,285 ----- expect list of variables and functions whatis submatch 'whatis -f' 'whatis: bad option: -f' 'bad option to whatis' *** /tmp/,RCSt1008584 Mon Oct 4 21:59:15 1993 --- walk.c Mon Oct 4 21:58:21 1993 *************** *** 44,52 if ((pid = rc_fork()) == 0) { #if !defined(NOJOB) && defined(SIGTTOU) && defined(SIGTTIN) && defined(SIGTST P) setsigdefaults(FALSE); ! rc_signal(SIGTTOU, (sighandler*)SIG_IGN); /* Berk eleyized version: put it in a new pgroup. */ ! rc_signal(SIGTTIN, (sighandler*)SIG_IGN); ! rc_signal(SIGTSTP, (sighandler*)SIG_IGN); setpgrp(0, getpid()); #else setsigdefaults(TRUE); /* ignore SIGINT, SIGQU IT, SIGTERM */ --- 44,52 ----- if ((pid = rc_fork()) == 0) { #if !defined(NOJOB) && defined(SIGTTOU) && defined(SIGTTIN) && defined(SIGTST P) setsigdefaults(FALSE); ! rc_signal(SIGTTOU, SIG_IGN); /* Berkeleyized version : put it in a new pgroup. */ ! rc_signal(SIGTTIN, SIG_IGN); ! rc_signal(SIGTSTP, SIG_IGN); setpgrp(0, getpid()); #else setsigdefaults(TRUE); /* ignore SIGINT, SIGQU IT, SIGTERM */ From rc-owner Tue Oct 5 22:15:17 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2707>; Tue, 5 Oct 1993 22:14:17 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA20130; Tue, 5 Oct 1993 21:14:10 -0500 Message-Id: <9310060214.AA20130@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: New rc FAQ Date: Tue, 5 Oct 1993 22:14:08 -0400 From: Alan Watson X-Mts: smtp There have been a couple of major changes between the first version posted, v2.10, and the current version, v2.12. Firstly, all of the stuff on using .profile or .login to exec rc has been deleted. There are just too many places where it does not work (like rsh and the X11 implementation under Ultrix). Secondly, all of the guff on getting quotes past rsh has been deleted. It was all based on a misunderstanding on my part of the interaction of vanilla rsh and a vanilla sh and so bore very little resemblence to reality. Thanks to Byron for pointing that one out. Other than that, there have been several typos corrected and a couple of minor bug fixes. I'm not inclined to post diffs (especially at this stage, when things are still settling down), but if you want to look at them they are available by anonymous ftp to oldp.astro.wisc.edu as pub/rc/rc-FAQ-diffs-v2.10-v2.12. Alan. From rc-owner Wed Oct 6 02:55:49 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2699>; Wed, 6 Oct 1993 02:55:27 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA27246; Wed, 6 Oct 1993 01:55:21 -0500 Message-Id: <9310060655.AA27246@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: ifs Date: Wed, 6 Oct 1993 02:55:20 -0400 From: Alan Watson X-Mts: smtp Whilst testing a read that performs ifs splitting, I discovered to my surprise that ifs is not exported into the environment and so is initialized to the standard space, tab, and newline whenever rc is run. One consequence of this is that the following two commands are different: ifs = ( : $nl ) rc -c 'line = `{ sed 1q /etc/passwd } ; echo $line' rc -c 'ifs = ( : $nl ) ; line = `{ sed 1q /etc/passwd } ; echo $line' Is this really the correct behaviour? I can understand this choice with regard to IFS and sh because of the IFS loophole, but this does not apply to rc. From rc-owner Wed Oct 6 03:50:10 1993 Received: from netcomsv.netcom.com ([163.179.1.7]) by hawkwind.utcs.toronto.edu with SMTP id <2699>; Wed, 6 Oct 1993 03:49:51 -0400 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA09416; Wed, 6 Oct 93 00:50:11 PDT Received: by netapp.com (4.1/SMI-4.1) id AA21040; Wed, 6 Oct 93 00:21:43 PDT Date: Wed, 6 Oct 1993 03:21:43 -0400 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9310060721.AA21040@netapp.com> To: alan@oldp.astro.wisc.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: ifs I remember talking this over with Paul when I wrote rc. I think we decided that ifs is akin to pid in that it is a per-shell rather than a per-environment quantity. We didn't want to force script writers to initialize ifs to prevent a trojan horse ifs, for example. So, to answer your question, yes this was a deliberate choice and is in our opinion correct. From rc-owner Wed Oct 6 04:50:37 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <2683>; Wed, 6 Oct 1993 04:48:27 -0400 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA29158; Wed, 6 Oct 1993 03:48:22 -0500 Message-Id: <9310060848.AA29158@oldp.astro.wisc.edu> To: byron@netapp.com (Byron Rakitzis), rc@hawkwind.utcs.toronto.edu Subject: Re: ifs Date: Wed, 6 Oct 1993 04:48:22 -0400 From: Alan Watson X-Mts: smtp Yes, this all hangs on whether one sees ifs as a per shell or per environment property. It depends on whether you expect: rc -c $cmd to be (roughly) identical to: @ eval $cmd or not. (Yes, I know about the magic $pid variable, but its odd behaviour is dictated by reasons firmly rooted in pragmatism.) I tend to think that the current behaviour is wrong, and would like you to reconsider this. If you still feel it's right, please add something to the man page. I'm not entirely convinced by the trojan horse argument -- is certainly doesn't exist to the same degree than it did in sh. By your argument, why not disable the export of functions to save people from using builtin to prevent trojan horse commands? I'm more in favour of flexibility. I tend towards prefering to allow the programmer to explicitly over-ride functions and ifs (by using builtin and setting ifs) or to inherit the user's preference from the environment. We are all used to setting path and using builtin, why is setting ifs so different? Besides, I wouldn't trust Paul's view -- he's on record as being prejudiced against innocent state variables. :-) From rc-owner Wed Oct 6 15:15:43 1993 Received: from colossus.apple.com ([130.43.2.6]) by hawkwind.utcs.toronto.edu w ith SMTP id <2683>; Wed, 6 Oct 1993 15:14:51 -0400 Received: from talisman.kaleida.com by colossus.apple.com with SMTP (5.65/22-Ju n-1993-eef) id AA09458; Wed, 6 Oct 93 12:00:16 -0700 for Received: from [130.43.11.214] (kip-24.kaleida.com) by talisman.kaleida.com (4. 1/SMI-4.1) id AA10923; Wed, 6 Oct 93 11:56:51 PDT Date: Wed, 6 Oct 1993 14:56:49 -0400 Message-Id: <9310061856.AA10923@talisman.kaleida.com> To: Alan Watson From: haahr@kaleida.com (Paul Haahr) X-Sender: haahr@talisman.kaleida.com Subject: Re: ifs Cc: rc@hawkwind.utcs.toronto.edu >Yes, this all hangs on whether one sees ifs as a per shell or per >environment property. It depends on whether you expect: > rc -c $cmd >to be (roughly) identical to: > @ eval $cmd >or not. they are different. why not? what is there that says they should be the same? they express two distinct operations; in the case where the first rc in the path is not rc the shell, they are very different. (how many of you have had that problem when /etc was in your path?) >I tend >to think that the current behaviour is wrong, and would like you to >reconsider this. If you still feel it's right, please add something to >the man page. i'm very certain i like the current behavior, and thought it was mentioned on the man page, but would agree that -- if they're not there -- the non-exported variables should be listed explicitly. i believe ifs, pid, *, and 0 are it, but perusing the source would make it certain. >I'm not entirely convinced by the trojan horse argument -- is certainly >doesn't exist to the same degree than it did in sh. By your argument, >why not disable the export of functions to save people from using >builtin to prevent trojan horse commands? this is all very vague in my memory, but i think it's because ifs was otherwise automatically inherited by the commands inside the backquotes, which was almost certainly the wrong thing for the default case. for example, ifs = ':' { passwd = `foobar /etc/passwd` } where foobar is an rc script that does lots of things, and then finally prints a line of its input file. among the things that it does, foobar uses backquotes at one point. the non-exporting of ifs was done so that the author of the above command wouldn't have to worry about how foo is written. similarly, i think it is reasonable that the author of foobar doesn't have to set foobar >I'm more in favour of flexibility. I tend towards prefering to allow >the programmer to explicitly over-ride functions and ifs (by using >builtin and setting ifs) or to inherit the user's preference from the >environment. i think this is where we disagree. i don't consider ifs a user preference setting. it's a parameter to backquote. as far as i'm concerned it's an internal piece of a shell script. but remember, i'm responsible for the `` monstrosity. >We are all used to setting path and using builtin, why is >setting ifs so different? i don't set path or use builtin in functions very often, because i want to defer to the user's choices. these i do consider preferences. >Besides, I wouldn't trust Paul's view -- he's on record as being >prejudiced against innocent state variables. :-) i have nothing against innocent state variables, it's just that i presume them guilty until proven otherwise. paul From rc-owner Sat Oct 9 05:43:57 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <2720>; Sat, 9 Oct 1993 05:42:23 -0400 Received: from moscvax.demos.su by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27513; Sat, 9 Oct 93 05:41:14 -0400 Received: by moscvax.demos.su id AA01062 (5.65c/IDA-1.4.4 for rc@hawkwind.utcs.toronto.edu); Fri, 8 Oct 1993 21:15:54 +0300 Received: by kremvax.hq.demos.su; Fri, 8 Oct 1993 20:45:27 +0300 Received: by phreak.ex952.demos.su; Fri, 8 Oct 1993 18:43:57 +0300 Received: by ibs.msk.su (UUPC/@ v5.09gamma, 14Mar93); Fri, 8 Oct 1993 15:43:35 +0300 To: rc@hawkwind.utcs.toronto.edu Message-Id: Organization: Intermicro BS From: DDW@ibs.msk.su (Dmitry Doronin) Date: Fri, 8 Oct 1993 07:43:35 -0400 Return-Receipt-To: ddw@ibs.msk.su X-Mailer: dMail (Demos Mail v1.13a) Subject: unsubscribe me! Lines: 2 Please delete me from this list! -ddw From rc-owner Mon Oct 25 14:28:44 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2734>; Mon, 25 Oct 1993 14:24:25 -0400 Return-Path: immd3.informatik.uni-erlangen.de!dalibor Received: from faui45.informatik.uni-erlangen.de ([131.188.1.45]) by hawkwind.u tcs.toronto.edu with SMTP id <2726>; Fri, 15 Oct 1993 07:31:19 -0400 Received: from faui30.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA18816 (5.65c-5/7.3v-FAU); Fri, 15 Oct 1993 12:30:42 +0100 Received: from faui30a.informatik.uni-erlangen.de by immd3.informatik.uni-erlan gen.de with SMTP; id AA03082 (5.65c-5/7.3v-FAU); Fri, 15 Oct 1993 12:30:38 +0100 From: Stefan Dalibor Message-Id: <199310151130.AA03082@faui30.informatik.uni-erlangen.de> Date: Fri, 15 Oct 1993 07:30:39 -0400 To: rc-owner Subject: Interrupts in backquotes Reply-To: Stefan.Dalibor@informatik.uni-erlangen.de Resent-To: rc Resent-Date: Mon, 25 Oct 1993 14:23:59 -0400 Resent-From: Chris Siebenmann Resent-Message-Id: <93Oct25.142425edt.2734@hawkwind.utcs.toronto.edu> Hi, I want to execute a command via rsh on several hosts in a script; some of the remote hosts are ill-behaving in a way that makes them answer ping-requests but hanging forever once the rsh-command is started :(. I tried to implement a timeout with a handler for SIGALRM - this handler is called, but then the script aborts with the error message backquote read: Interrupted system call What is the correct way to perform such actions? Or should there perhaps be special treatment for EINTR when occuring in bqinput() (as this is done in fdgchar())? Thanks, Stefan This is rc-1.4 on SunOS 4.1.3 (gcc) and IRIX 4.0.5H (cc), snippets from script: . . . . . . timeout=10 fn sigalrm { echo timeout timedout=yeah } for(hanghost in $hostlist) { if(/usr/etc/ping $hanghost 4 >/dev/null >[2=1]) { timedout=no {sleep $timeout; kill -ALRM $pid} & # timer started timerpid=$apid echo -n $hanghost^': ' res=`{rsh $hanghost '$HOME/bin/m88k/osv'; echo $status} if(~ $timedout no) { # rsh succeeded kill -INT $timerpid >[2]/dev/null . . . . . . } else # timer expired . . . . . . } echo Done Output from script: ; ./src/rc-1.4/rc-1.4-g bin/mstat m41: SYSV88 m42: SYSV88 m43: timeout backquote read: Interrupted system call From rc-owner Mon Oct 25 19:12:57 1993 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2732>; Mon, 25 Oct 1993 19:12:21 -0400 To: rc Subject: where to get rc by ftp Date: Mon, 25 Oct 1993 19:12:18 -0400 From: Chris Siebenmann Message-Id: <93Oct25.191221edt.2732@hawkwind.utcs.toronto.edu> archone.tamu.edu's ftp service appears to have gone on vacation more or less permanently, and queries to people there have gone unaswered. I've put up the crucial bits of archone's ftp area on ftp.sys.utoronto.ca, in /pub/rc/archone, based on a mirror I made around May 29 1992. Please update the ftp location in documentation and stuff you tell people, and someone let me know if archone comes back. Contributions for the ftp area can, of course, be sent to me. - cks From rc-owner Tue Oct 26 23:20:52 1993 Received: from viz ([128.194.53.1]) by hawkwind.utcs.toronto.edu with SMTP id < 2731>; Tue, 26 Oct 1993 23:19:28 -0400 Received: from dragon by viz.tamu.edu id <13073>; Tue, 26 Oct 1993 22:16:33 -05 00 From: Steve Rikli To: rc@hawkwind.utcs.toronto.edu Subject: anon ftp to archone.tamu.edu moved to viz.tamu.edu Message-Id: <93Oct26.221633cdt.13073@viz.tamu.edu> Date: Tue, 26 Oct 1993 23:16:32 -0400 The anonymous ftp archives at archone.tamu.edu (128.194.53.42) (i.e. the home of 'rc') have moved to: viz.tamu.edu (128.194.53.1) The directory, as before, is /pub/rc . Email root@viz.tamu.edu if you encounter problems. cheers, sr. --- || Steve Rikli ||| Visualization Lab || || steve@viz.tamu.edu ||| Texas A&M University || || work: 409-845-3465 ||| College Station, TX 77843-3137 || From rc-owner Mon Nov 1 13:39:57 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <32813>; Mon, 1 Nov 1993 13:36:05 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA25777; Mon, 1 Nov 1993 12:35:42 -0600 Message-Id: <9311011835.AA25777@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: -c arguents Date: Mon, 1 Nov 1993 13:35:41 -0500 From: Alan Watson X-Mts: smtp I've just discovered a minor incompatibility between rc and sh: sh -ce foo # execute foo and exit on any error rc -ce foo # execute e with an argument of foo rc is behaving according to the manual page, so this is not a bug, however, I wonder if the behaviour should be changed to follow that of sh? I came across this using make on our new SGI machine -- it executes commands with $SHELL -ce ... and I had forgotten to explicity set SHELL to sh within the Makefile. Alan. From rc-owner Mon Nov 1 13:48:50 1993 Received: from mod.civil.su.OZ.AU ([129.78.142.6]) by hawkwind.utcs.toronto.edu with SMTP id <32814>; Mon, 1 Nov 1993 13:48:22 -0500 Received: by mod.civil.su.oz.au id <28693>; Tue, 2 Nov 1993 05:48:10 +1100 From: John (I lived alone, but I was only / Coming back to you) Mackin Date: Mon, 1 Nov 1993 13:47:11 -0500 To: rc@hawkwind.utcs.toronto.edu Subject: Re: -c arguents In-Reply-To: <9311011835.AA25777@oldp.astro.wisc.edu> Message-ID: <199311020547.5527.rc.babad@civil.su.oz.au> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ I wonder if the behaviour should be changed to follow that of sh? It absolutely and definitely should be so changed. OK, John. From rc-owner Mon Nov 1 13:51:34 1993 Received: from charon.cwi.nl ([192.16.184.142]) by hawkwind.utcs.toronto.edu wi th SMTP id <32815>; Mon, 1 Nov 1993 13:51:13 -0500 Received: from paling.cwi.nl by charon.cwi.nl with SMTP id AA14099 (5.65b/%I%/CWI-Amsterdam); Mon, 1 Nov 1993 19:50:57 +0100 Received: by paling.cwi.nl with SMTP id AA16277 (930416.SGI/3.8/CWI-Amsterdam); Mon, 1 Nov 93 19:50:55 +0100 Message-Id: <9311011850.AA16277=robertl@paling.cwi.nl> To: Alan Watson Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: -c arguents In-Reply-To: Your message of "Mon, 01 Nov 1993 13:35:41 GMT." <9311011835.AA25777@oldp.astro.wisc.edu> From: Robert van Liere X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands X-Phone: tel: +31-20-592-4118 | fax: +31-20-592-4199 Date: Mon, 1 Nov 1993 13:50:54 -0500 Sender: Robert.van.Liere@cwi.nl > I wonder if the behaviour should be changed to follow that of sh? I've reported this to Byron more than a year ago. This was his reply. -- Robert > 2) make on the sgi has a bug: it executes its shell with "$SHELL -ce command" > and since rc uses getopt(3) to process its arguments (hardly nonstandard, > imho) rc sees the single command "e" followed by a bunch of arguments which > it places in $*. One fix is to place a copy of make in a different directory, > edit it with, say, emacs, and transpose the order of the letters "ce". That > will make it invoke rc correctly. > > One caveat: many makefiles out there break when you use rc as a shell. It is > a bug, imo, that sgi's make does not default to sh unless explicitly override n > via SHELL. I believe other makes operate in that fashion. From rc-owner Mon Nov 1 15:06:32 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <32817>; Mon, 1 Nov 1993 15:05:42 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21825; Mon, 1 Nov 93 15:04:58 -0500 Received: from srg.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 144505.12270; Mon, 1 Nov 1993 14:45:05 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa10745; Mon, 1 Nov 93 14:14:51 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: alan@oldp.astro.wisc.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: -c arguents Date: Mon, 1 Nov 1993 14:16:07 -0500 Message-Id: <9311011416.aa10877@ceres.srg.af.mil> This is a stupid bug in make if you ask me. I encountered the same problem with SCO Unix, and fixed make on our base system tape to do the right thing by flipping -ce to -ec. Tom From rc-owner Mon Nov 15 19:03:52 1993 Received: from duvel.cs.colorado.edu ([128.138.242.12]) by hawkwind.utcs.toront o.edu with SMTP id <35222>; Mon, 15 Nov 1993 19:00:12 -0500 Received: by duvel.cs.colorado.edu id AA26576 (5.65c/IDA-1.4.4 for rc@hawkwind.utcs.toronto.edu); Mon, 15 Nov 1993 16:59:58 -0700 Date: Mon, 15 Nov 1993 18:59:58 -0500 From: Philippe Meunier Message-Id: <199311152359.AA26576@duvel.cs.colorado.edu> To: rc@hawkwind.utcs.toronto.edu Subject: ^z Hi everybody, i have always used tcsh, but i am fed up with all the quoting problems, so rigth now i am playing with rc to see how good it is. But i have the following problem, which makes me a bit nervous about having rc as my permanent shell (i have already looked at the archives about this and fount some related mails, but nothing clearly explaining what happens, so...) : ; stty susp '^z' ; sleep 5 ^Z^Z^Z^Z; [why is it ignored ?] ; fn sigtstp {echo hello} ; sleep 5 ^Zkilled [why is it killed ?] hello ; fn sigtstp {} ; sleep 5 ^Z^Z^Z^Z; [the behavior i was waiting] ; fn sigtstp ; sleep 5 [^z and shell dies] [???] According to signal(3), the default behavior for SIGTSTP it to stop the process, so i really do not understand what is happening... What i would like to do is something like the following : fn sigtstp { proc_pid = `{ps ux|grep sleep|awk '{print $2}'} rc -i kill -19 $proc_pid } ie, i would like to be able to temporarily stop a running process, to do another task, and then restart the first process. Look at this as a very basic kind of job-control (no flame, please). BTW, i have two related questions: - is there a nice way to set proc_pid to the pid of the process that has received the SIGTSTP signal ? (i know the way i have done it in my exemple is horrible and is not working, but it was just to give you an idea of what i want to do...). - what do you do when you forget to add an & at the end of the command line ? Do you just kill the process and start a new one in the background ? If it matters, i have compiled rc with gcc 2.5.0 on a Sparc SLC, running SunOS 4.1.4, with the following options (i give them all, just in case): #define CUSTOM #define DEFAULTPATH "/usr/ucb", "/usr/bin", "/bin" #define TMPDIR "/home/bigtime/meunierp/tmp" #define DEFAULTINTERP "/bin/sh" #define PROTECT_ENV and that'all, no READLINE, no SVSIGS, so i think the problem is coming from rc itself (in fact, i think there is no problem, just something that i do not understand :-). I am starting rc by doing an "exec ./rc" from a tcsh, so it is not a login shell. So would somebody be kind enough to explain me what's happening ? (and remember, i have never used sh...). Thanks in advance, Philippe _______________________________________________________________________ Philippe Meunier meunierp@anchor.cs.colorado.edu From rc-owner Thu Dec 2 05:59:57 1993 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <23989>; Thu, 2 Dec 1993 05:57:13 -0500 Received: from pharao.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA07583; Thu, 2 Dec 1993 11:56:3 3 +0100 Received: by pharao.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA09324; Thu, 2 Dec 93 11:56:32 +0100 Date: Thu, 2 Dec 1993 05:56:32 -0500 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9312021056.AA09324@pharao.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: possible bug in rc 1.4 Content-Length: 981 Hello fellow rc users, I'm afraid that I've found a bug in rc that I can easily reproduce on Sparcs running Solaris 2.[2] and RS6000 running AIX 3.2.5, but not on Sparcs running SunOS 4, DEC Alphas running OSF/1 1.3 and SGIs running IRIX 4.0.5. On all machines, gcc 2.5.3 was used to compile the shell. Consider running the following script: #!/vol/local/bin/rc fn sigint sighup { echo something >[1=2]; exit 1 } while(){} ; script [ run run run ] ^Csomething ; Now I add sighup to the list of caught signals, rerun the script and hit ^C again, the output is either "something" or rc panic: unexpected node in doredirs! or "something" followed by some blanks and newlines. and is not reproducible. Adding another signal consistently causes an rc panic. I believe that either r or r->r in doredirs gets corrupted but have no idea why. If I replace the invocation of echo with a call to another function echo'ing the message with redirection, everything is fine. Malte From rc-owner Mon Dec 6 16:54:25 1993 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <23998>; Mon, 6 Dec 1993 16:51:01 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA08072; Mon, 6 Dec 1993 15:50:52 -0600 Message-Id: <9312062150.AA08072@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Patches and FAQ Date: Mon, 6 Dec 1993 16:50:51 -0500 From: Alan Watson X-Mts: smtp For my own use, I recently collected the various patches posted to the list and catalogued by Tom. I have put these up for anonymous FTP as oldp.astro.wisc.edu:/pub/rc/patches.tar.Z to save others the same work. BTW, I have just reposted v2.13 of the rc FAQ list. The major changes in this versions were: replacing references to archone.tamu.edu with the new site viz.tamu.edu; mention of the patches; mention of Paul Haahr's /dev/fd port for NeXT OS; a minor bug fix in the `at' function (it previously failed to give an error message if invoked with no arguments); a large number of minor changes of phrasing. Thanks once again to those of you who have pointed out errors in the FAQ. Alan. From rc-owner Tue Dec 7 21:14:38 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24001>; Tue, 7 Dec 1993 21:13:25 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10556; Tue, 7 Dec 93 21:13:12 -0500 Received: from srg.UUCP by uucp5.uu.net with UUCP/RMAIL (queueing-rmail) id 211116.10370; Tue, 7 Dec 1993 21:11:16 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa13961; Tue, 7 Dec 93 20:45:17 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Raising the flag Date: Tue, 7 Dec 1993 20:45:18 -0500 Message-Id: <9312072045.aa11960@ceres.srg.af.mil> Things here on the mailing list have been quiet for far too long. It seems like time to stir them up a bit before the holidays. So since I've never been one to leave well enough alone, I'll take Byron Claus at his word about 1.5: ;-) ;-) ;-) > From: Byron Rakitzis > Date: Sun, 19 Sep 1993 16:48:19 -0400 > > ... once the smoke clears I will possibly have some time to > concentrate on rc. Bug me in a few weeks again.. So how are things going? Still busier than a one legged man in a butt kicking contest? Any chance for 1.5 in the new year? Anything we can do to help? Of course 1.4 continues to perform flawlessly and unobtrusively, day in and day out, quietly making short work of the ugliest shell problems. For other "Doctor Who" fans, it reminds me of the laser probe that could "remove the atoms from a molecule one by one, or punch a fist size hole through six inch armor plate". (I'm sure someone will be able to correct me and even name the episode the quote is from.) Tom ObRC - When you wrap a builtin like cd with a function, be sure that you remember to propagate the result. I gave myself a nasty fright when: if (cd $invalid_directory) { ... } thought that the cd had succeeded, because my cd function didn't save $status before updating $prompt and return the saved value. Luckily, testing the script caught this. Caveat Utor! From rc-owner Wed Dec 8 01:15:10 1993 Received: from netcomsv.netcom.com ([163.179.1.8]) by hawkwind.utcs.toronto.edu with SMTP id <24003>; Wed, 8 Dec 1993 01:14:30 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id WAA21415; Tue, 7 Dec 1993 22:11:42 -0800 Received: from ghoti.netapp.com by netapp.com (4.1/SMI-4.1) id AA14757; Tue, 7 Dec 93 22:12:15 PST Received: by ghoti.netapp.com (4.1/SMI-4.1) id AA00991; Tue, 7 Dec 93 22:12:11 PST Date: Wed, 8 Dec 1993 01:12:11 -0500 From: byron@ghoti.netapp.com (Byron Rakitzis) Message-Id: <9312080612.AA00991@ghoti.netapp.com> To: culliton@srg.af.mil, rc@hawkwind.utcs.toronto.edu Subject: Re: Raising the flag Hello again. Code freeze for NAC v1.1 ("FASware") is tomorrow, so I anticipate some gear changing in the next day or two. Thanks for reminding me; I haven't forgotten, I just need to schedule some time where I can fault all of rc back into my head and work on fixing all the nitty gritty problems. Part of my reluctance to work on rc-1.5 stems from precisely what Tom mentions: the fact that 1.4 is working so well. The old "if it ain't broke" principle. To this end I have also felt compelled to release something completely polished, and this has acted as an inhibitor on my actions. However, I do realize that there some valuable fixes which need to get out there, and I will do my best at getting them out soon. If that doesn't happen then I will try to be more realistic about what I can actually accomplish with my time --- i.e., maybe I will try to solicit someone's help as Tom suggested. I thought I'd raise this since I would like to have a reasonable beta period for any changes, given that there is no way that I as an individual can test rc in the way that it will surely be stressed when released to hundreds of users on n different OSes. Byron. From rc-owner Wed Dec 8 19:43:07 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24003>; Wed, 8 Dec 1993 19:42:11 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA06341; Wed, 8 Dec 93 19:42:03 -0500 Received: from srg.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 194100.16340; Wed, 8 Dec 1993 19:41:00 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa10927; Wed, 8 Dec 93 19:20:12 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Translating question Date: Wed, 8 Dec 1993 19:20:16 -0500 Message-Id: <9312081920.aa20477@ceres.srg.af.mil> The following fragment was easy to prototype in rc: prog1 |[3] prog2 # output of fd 3 is piped to stdin but trying to convert it to Bourne shell is making me nuts! I want stdout and stderr to go to "the usual place" with just "special stuff" being piped into the second program. Could someone give me a clue before I have to embarrass myself in comp.unix.shell? Thanks! Tom (with yet another reason too love rc and hate the rest) From rc-owner Wed Dec 8 20:38:09 1993 Received: from merlin.resmel.bhp.com.au ([134.18.1.6]) by hawkwind.utcs.toronto .edu with SMTP id <24003>; Wed, 8 Dec 1993 20:37:36 -0500 Received: from cerberus.bhpese.oz.au by merlin.resmel.bhp.com.au with SMTP id A A02392 (5.65c/IDA-1.4.4 for ); Thu, 9 Dec 1993 12:36:2 6 +1100 Received: from localhost by cerberus.bhpese.oz.au with SMTP id AA00252; Thu, 9 Dec 1993 12:36:40 +1100; sendmail 5.67a/Sm3.8RMPSU (from Sm@cerberus.bhpese.oz.au for rc@hawkwind.utcs.toronto.edu) Message-Id: <199312090136.AA00252@cerberus.bhpese.oz.au> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Translating question In-Reply-To: Your message of "Wed, 08 Dec 93 19:20:16 EST." <9312081920.aa20477@ceres.srg.af.mil> X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" >The following fragment was easy to prototype in rc: > > prog1 |[3] prog2 # output of fd 3 is piped to stdin > >but trying to convert it to Bourne shell is making me nuts! I want >stdout and stderr to go to "the usual place" with just "special stuff" >being piped into the second program. Could someone give me a clue >before I have to embarrass myself in comp.unix.shell? This is probably not optimal, but it seems to work: (exec 4>&1;((echo a; echo b>&2; echo c>&3))>&4 3>&1 | cat > 1); cat 1; rm 1 so you could probably use: (exec 4>&1;prog2 >&4 3>&1 | prog2) Sm From rc-owner Wed Dec 8 20:49:28 1993 Received: from merlin.resmel.bhp.com.au ([134.18.1.6]) by hawkwind.utcs.toronto .edu with SMTP id <24003>; Wed, 8 Dec 1993 20:49:01 -0500 Received: from cerberus.bhpese.oz.au by merlin.resmel.bhp.com.au with SMTP id A A02503 (5.65c/IDA-1.4.4 for ); Thu, 9 Dec 1993 12:47:3 3 +1100 Received: from localhost by cerberus.bhpese.oz.au with SMTP id AA00784; Thu, 9 Dec 1993 12:47:56 +1100; sendmail 5.67a/Sm3.8RMPSU (from Sm@cerberus.bhpese.oz.au for rc@hawkwind.utcs.toronto.edu) Message-Id: <199312090147.AA00784@cerberus.bhpese.oz.au> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Translating question In-Reply-To: Your message of "Wed, 08 Dec 93 20:36:38 EST." <199312090136.AA00252@cerberus.bhpese.oz.au> X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" I knew I should have tested that final optimization! Instead, use: (exec 4>&1;(((echo a; echo b>&2; echo c>&3))>&4) 3>&1 | cat > 1); cat 1; rm 1 # ^ note extra paranthesis! ^ so you could probably use: (exec 4>&1;(prog2 >&4) 3>&1 | prog2) # ^ ^ Sm From rc-owner Fri Dec 10 12:22:17 1993 Received: from Arizona.edu ([128.196.128.234]) by hawkwind.utcs.toronto.edu wit h SMTP id <24006>; Fri, 10 Dec 1993 12:18:57 -0500 Return-path: jew@Arizona.edu Received: from convx1.ccit.arizona.edu by Arizona.EDU (PMDF V4.2-13 #2381) id <01H6B7KQ38CW9JFMVM@Arizona.EDU>; Fri, 10 Dec 1993 10:18:37 MST Received: from localhost by convx1.ccit.arizona.edu; Fri, 10 Dec 1993 10:16:41 -0700 Date: Fri, 10 Dec 1993 12:16:41 -0500 From: jew@convx1.ccit.arizona.edu (James E Ward) Subject: rc on a Convex handling interrupts correctly? To: rc@hawkwind.utcs.toronto.edu Message-id: <199312101716.KAA07798@convx1.ccit.arizona.edu> Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Full-Name: James E Ward I'm running rc under: ConvexOS convx1.ccit.arizona.edu C240 11.0 and am having a problem with interrupt handling. Sometimes, rc -l will exit when I hit ^C. Additionally, programs running under rc may not be seeing ^C since they don't stop in a reasonable time. I scanned the mailing list archive, but didn't see this discussed. Sorry if I missed it. Can anyone help me out here? I haven't used rc in a year or so... From rc-owner Fri Dec 10 13:59:05 1993 Received: from ucsd.edu ([132.239.254.201]) by hawkwind.utcs.toronto.edu with S MTP id <24006>; Fri, 10 Dec 1993 13:58:33 -0500 Received: from sdnp1.UCSD.EDU by ucsd.edu; id KAA17922 sendmail 8.6.4/UCSD-2.2-sun via SMTP Fri, 10 Dec 1993 10:58:24 -0800 Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA10413 for rc@hawkwind.utcs.toronto.edu; Fri, 10 Dec 93 10:58:04 ps t Date: Fri, 10 Dec 1993 13:58:04 -0500 From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9312101858.AA10413@sdnp1.UCSD.EDU> To: jew@convx1.ccit.arizona.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: rc on a Convex handling interrupts correctly? On a 486 running BSDI I see a different problem with ^C. If I start up an sh script which does a 'someprog &' and exits, if I hit ^c in my rc after the script is finished then 'someprog' dies having seen a SIGINT. This does not occur if I start csh or sh and start the script from within them. This problem took me a long time to notice, and kept a few people trying to figure out why our server process would get SIGINTs at apparently random times. Otherwise, don't have any problems with rc, having been using it for almost 3 years. Now if only I could get it to work on my A/UX machine. My environment is too large for it with all my functions. -- David Moore - SysAdmin/Programmer __o UCSD | Dept. of Anesthesiology | V-151 | La Jolla, CA 92093-9151 _ \<,_ Work Phone: (619) 552-8585 x7091 (_)/ (_) "God does not play dice." - A. Einstein "Yes, I do." - D. Moore From rc-owner Mon Dec 20 03:05:32 1993 Received: from mailgate.ericsson.se ([130.100.2.2]) by hawkwind.utcs.toronto.ed u with SMTP id <24032>; Mon, 20 Dec 1993 03:01:35 -0500 Received: from eua.ericsson.se by mailgate.ericsson.se (4.1/SMI-4.1-MAILGATE1.1 4) id AA25662; Mon, 20 Dec 93 09:01:30 +0100 Received: from ms.eua.ericsson.se by eua.ericsson.se (4.1/EUA-2.1) id AA26167; Mon, 20 Dec 93 09:01:27 +0100 Received: from euas69c13.eua.ericsson.se by ms.eua.ericsson.se (4.1/MS-2.1) id AA17814; Mon, 20 Dec 93 09:01:20 +0100 From: Bengt.Kleberg@eua.ericsson.se (Bengt Kleberg) Received: by euas69c13.eua.ericsson.se (4.1/client-1.3) id AA11894; Mon, 20 Dec 93 09:01:20 +0100 Date: Mon, 20 Dec 1993 03:01:20 -0500 Message-Id: <9312200801.AA11894@euas69c13.eua.ericsson.se> To: rc@hawkwind.utcs.toronto.edu Subject: problem with rc and tr Greetings, I'm doing something wrong and would appreciate any pointers to what it is and how to get my desired result. My version of rc, I've been unable to get the rc version# (should be 1.3 or 1.4), is compiled with gcc under SunOS 4.1.3 (currently running under SunOs4.1.2). This is what I want (and I get it with csh): euas69c13% tr ÿ \012 < audit > tmp euas69c13% This is what I get: ; tr ÿ \012 < audit > tmp ^C ; \012 not found ; Best Wishes, Bengt From rc-owner Mon Dec 20 03:46:15 1993 Received: from mailgate.ericsson.se ([130.100.2.2]) by hawkwind.utcs.toronto.ed u with SMTP id <24033>; Mon, 20 Dec 1993 03:43:37 -0500 Received: from eua.ericsson.se by mailgate.ericsson.se (4.1/SMI-4.1-MAILGATE1.1 4) id AA27441; Mon, 20 Dec 93 09:43:36 +0100 Received: from ms.eua.ericsson.se by eua.ericsson.se (4.1/EUA-2.1) id AA28113; Mon, 20 Dec 93 09:43:34 +0100 Received: from euas69c13.eua.ericsson.se by ms.eua.ericsson.se (4.1/MS-2.1) id AA21253; Mon, 20 Dec 93 09:43:33 +0100 From: Bengt.Kleberg@eua.ericsson.se (Bengt Kleberg) Received: by euas69c13.eua.ericsson.se (4.1/client-1.3) id AA11948; Mon, 20 Dec 93 09:43:33 +0100 Date: Mon, 20 Dec 1993 03:43:33 -0500 Message-Id: <9312200843.AA11948@euas69c13.eua.ericsson.se> To: rc@hawkwind.utcs.toronto.edu Subject: Re: problem with rc and tr Let me add something. When I received my message from the rc-list I noticed that the " over the y where gone (dissipered(sp?)). The command is (on a sun type-5 keyboard): tr \012 < audit > tmp Hope this helps, Bengt From rc-owner Wed Dec 22 17:19:20 1993 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24035>; Wed, 22 Dec 1993 17:17:47 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09247; Wed, 22 Dec 93 17:17:10 -0500 Received: from srg.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 171522.29952; Wed, 22 Dec 1993 17:15:22 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa12460; Wed, 22 Dec 93 17:02:57 EST From: culliton@srg.srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: A Xmas toy Date: Wed, 22 Dec 1993 17:03:01 -0500 Message-Id: <9312221703.aa18393@ceres.srg.af.mil> # This is my Xmas present to the mailing list. It's a version of cd that # keeps track of all the directories that you've visited and lets you easily # return to any of them. I wrote it because I often find myself bouncing # back and forth between 3 or 4 different places, cd - just didn't cut it, # and pushd/popd/swapd were inconvenient. Hopefully you'll find this # useful or at least entertaining. # # Tom # The variable dirs holds the MRU directory queue fn dirs { echo $dirs } fn cd { if (! ~ $#* [01]) { echo too many arguments return 1 } switch ($1) { case - # shorthand for -1 cd $dirs(1) # recursion case -[1-9] -[1-9][0-9] # 1 -> 99 are valid cd $dirs(`{echo $1 | cut -c2-}) # recursion case -[0-9]* # catch dumb stuff echo bad numeric argument return 1 case * # also handles no args case d = $1 { # save arg (if any) '*' = $dirs # shift only works on * dirs = `{/bin/pwd} # MRU moves to front while (! ~ $* ()) # and eliminate duplicates { if (! ~ $dirs $1) dirs = ($dirs $1) shift } builtin cd $d # actually go there # and possibly fix your prompt, etc. } } } From rc-owner Wed Dec 22 18:20:25 1993 Received: from relay2.UU.NET ([192.48.96.7]) by hawkwind.utcs.toronto.edu with SMTP id <24034>; Wed, 22 Dec 1993 18:20:03 -0500 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17520; Wed, 22 Dec 93 18:20:09 -0500 Received: from srg.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 181824.11867; Wed, 22 Dec 1993 18:18:24 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa13196; Wed, 22 Dec 93 17:49:00 EST From: culliton@srg.srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: A (new and improved) Xmas toy Date: Wed, 22 Dec 1993 17:49:06 -0500 Message-Id: <9312221749.aa18791@ceres.srg.af.mil> # Amazing what an extra half hour of thought will do to improve a piece # of code. I was fretting about the size of the function, because SCO # Unix has limited environment space and managed to shave its size a bit # and make it a little cleaner. fn dirs { echo $D } fn cd { if (! ~ $#* [01]) { echo too many arguments return 1 } switch ($1) { case - # shorthand for -1 cd $D(1) # recursion case -[1-9] -[1-9][0-9] # 1 -> 99 are valid cd $D(`{echo $1 | cut -c2-}) # recursion case -[0-9]* # catch dumb stuff echo bad numeric argument return 1 case * # also handles no args case d=$D i=() { D = `{/bin/pwd} # MRU moves to front for (i in $d) # and eliminate duplicates if (! ~ $D $i) D = ($D $i) builtin cd $1 # actually go there # and fix the prompt } } } From rc-owner Wed Dec 29 21:33:43 1993 Received: from vlsi.cs.caltech.edu ([131.215.131.129]) by hawkwind.utcs.toronto .edu with SMTP id <24047>; Wed, 29 Dec 1993 21:32:21 -0500 Received: from ariadne.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1) id AA00241; Wed, 29 Dec 93 18:34:08 PST Date: Wed, 29 Dec 1993 21:34:08 -0500 From: drazen@vlsi.cs.caltech.edu (drazen) Message-Id: <9312300234.AA00241@vlsi.cs.caltech.edu> To: rc@hawkwind.utcs.toronto.edu Subject: `{prog args} versus `(prog args) Happy New Year to everyone! Is there a "real" difference between ; x = `{prog args ...} and ; x = `(prog args ...) The only difference in the text of the commands is braces versus parenthesis. Both conform to the syntax, and I cannot get them to produce different results. Does anyone have any opinions when one is preferable to another? Drazen From rc-owner Wed Dec 29 23:08:14 1993 Received: from kaleida.com ([130.43.11.35]) by hawkwind.utcs.toronto.edu with S MTP id <24048>; Wed, 29 Dec 1993 23:07:48 -0500 Received: from [130.43.11.209] (kip-19.kaleida.com) by kaleida.com (4.1/Spike-2 .1-(Kaleida)) id AA26911; Wed, 29 Dec 93 19:43:01 PST Message-Id: <9312300343.AA26911@kaleida.com> Date: Wed, 29 Dec 1993 22:42:16 -0500 To: drazen@vlsi.cs.caltech.edu (drazen) From: haahr@kaleida.com (Paul Haahr) X-Sender: haahr@talisman.kaleida.com Subject: Re: `{prog args} versus `(prog args) Cc: rc@hawkwind.utcs.toronto.edu > Is there a "real" difference between > ; x = `{prog args ...} >and > ; x = `(prog args ...) yes. `() can contain only words, not things like redirections and pipes, whereas `{} can contain any rc commands. that `() works is just a happy accident of the orthogonality of rc. paul From rc-owner Mon Jan 10 02:42:34 1994 Received: from netcomsv.netcom.com ([163.179.1.8]) by hawkwind.utcs.toronto.edu with SMTP id <24073>; Mon, 10 Jan 1994 02:28:41 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id XAA13352; Sun, 9 Jan 1994 23:26:54 -0800 Received: by netapp.com (4.1/SMI-4.1) id AA20806; Sun, 9 Jan 94 23:20:01 PST Date: Mon, 10 Jan 1994 02:20:01 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9401100720.AA20806@netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: rc-1.5betadev-1 trip.rc begin 644 trip.rc.Z M'YV0(T#0D9,&C@LY8T"T:"$PS)HR(,((?%-'#H@W9D @5! PB1L[;QY&G -" M!)PP=-"TH/.FA9LR=UH@!,%#($&#"$4H4("P!PD8"LJ,0?/&9D$X:=R< 4%B MHP(S;D"8"9.@]"A(()0K"QY88/61T,0IG8LB((.[(>:-48$4W.IBJR"JG MC<*,).BT@9.U#)XT=$#$4-#G:52_<(0&QJIU:%&O8,4J/(PG\9C )+RH\'(B M[@G"AD',J2.F#7/HTF*YRU>^GX=&-U-8C6K\& 84K]:M.$+=(D)!'#JXP>,;KT82JC M=H+;5*V2F $:JN@T9_P"OG\F:> Y^,51QWX GC%'&6?8$5J!^BW6EV-D@<#; M7FR404<9H.D%1P\O:-CA32Z0@!09/-G5 EX:*D!=#Y]]QA%'&H$WQHL*6(?" M=PHE9%X7+Y!1AATON%$'&VRD(%5\()PP4PL)D9$&&6Z<<$)@O\'16V 2B1$& M&2 T*!H=*-4QQV=X] #&'C@RF>161?W$'FPJG("6&!*"P"5$9A1FXU1L'&CD M'N\%&M 504CA1!).'!%72FF0Y*099I0A!TEF0"=:* 0@Y%A&(F; M54LF5.65))WPDYR[]?;;96SD,1*GGKJGZ6LD=-J>A*(B6:I&95@I!QVIDB # MJV[PYIMBL;VZZG#%CL"LLJ^2D>S89!4;6WKE=$G M1(S=2NNG3"&4+:DR BLLL4FN&ERXS,I:[KNV3HNKKD:*,6^,.=J+:K['[NMJ MO\X2+.UUU'9JK0T';QOLPJI^Z_"RL/IKKL7H[C0"C'68-L<:-*9<[AH@ .4# M4RF6>6:?"LFGH9X" YRD3#')$71,)QSL\LHQ@_#<&V34,4897+8*,I5EC,8& M'7$]^VF)=]&\EP)'PPR###7^=AYAXXMZ#S7CQ3C&L>M?XLM$P+Y5WT MD;F%'3/92J_5]--1)_OP95)554;6=&]=5]=H\^4N&'Z/?8/1*L/,[85<:LFE M'6&P4^4[*F48':B?X[;F<)W@.0MBPRTZ[ JDSEZ3?+5A>^Y:S9_X[ ME[?GOCH:NV<.0@[,-S]\\"\_7SQIJK/N-QII"(2&I&7 SE)1IKGAKQQGI%R& M&_BR!/W*L/L=!OD24H2^BY-73O;!MBL_5!A*0;T^S* 3'4349[J7F0Q&OW&2 MN(SCACG0R#YBR,.%2+('J?3F.FDPDLWV<(=ZD2 -Z8*0UHQ4c\#$G[ H( MM"2'&O7L3!&MAP8VQ*$.$YB&!1YG#$#D7%K6TA8 Z<%_3:Q07& H M02JRL#"/.U$*61@4"+FD*S'HRA;$(@,]1F8L9GC#&Q2 !Q#TH'3;D=)5B!.8 M&,0-.[ I9 WY9I6FE06,90@BEX;HAB(>L4N?3"/IM),D.>V!D8)YY*9(J2:'/,H@YT@ M!CB26HM%*O4&NS"2!1)BPQL 5$8Z.,D-"D"E5V#0@RZ@CGJZ.P$C?> I6,XF M!;!KPY#HD(86W*$W7!*E&\+0!H@(DXM>C%*2 -K#XT2S-Y\Q'NO6B0)X)DE( M1!KF^?CISZ@0]#(,A-U%Z6E0WR#T@ ')X1ONH+V*XO(_8!H#RT[V1$AB+XI! M"6"79/JCT,W4IC6U2DYOJE.:^A2G/^VI3;D04Z :5:A(Y:E2=\K4H"Y5ID1M MZE&?.E6I)M6J5+5*5)V*U:YR]:M5A6I1KPI6LH;UK&;5ZEBSRE:OHK6M8G5K M6N'Z5KF"8*MU+2M=YXI5O/)5KW8-;%P!2]B\&E:M@CWL7I<*(>P1QCVC @$: MZI ?GH)4LMR[X1A(PC\N;>\WC M@.<:EW_2A1IU/S,Y8UZ%!SS80@W&4H0G&$%"KPPO.<>[GJ8P]VI&SPUD/>).4I*PH 0[ 6]X+60U2L@"!39H"DB4^ 8IIL M@9PD[L.,T4N'%$26#>^KK'U#2Q"E.%##=_VOBBNTDSCB9,F#D MOR0(RI77HZJB9:7"=:#O:/.%K.PB&'?H/%Z2&%EEC,".O\-Q&(4LU+TDM6K. M%S+S"G:$1#1$XC\%%"D6>.O_, Q18.2.7 M=N@)+MT"T\CA(189(I;NHQ0=L@$PDK+I/>5 AN!K6+3A:0"OV%.%;A M7^CR " 'LO29B+O#^]PP6@4 P)F-Y=X7&O6%,'P!B$3*PQ>TJ90OK)H,+D@" M';Z AG)]X0ST_0)+OB"&,DR;EY(2=[?=\(48W!8&7]B?',)P&4G-X0N!E(.Z MS6UK\82NV?N,U1DG1>XZ0"K=XWZ#'21E!FW>H>#;3@E*OC 'H@R)#%\0-;G- M_;TO/*J)8YBGN-_@\3>X@ D6^D(_*0ZF85F;(/2L]ARJ:6Z4WX'90WC?6HCD M BH(^]YB( B1\ -PC*?$W',X=4JDS9*%SX$%1'C2M_/PFZ)_.PUMR*&YD[)O M:_^V#"X( I%4CO4Y2/L.RCXZN7OS!G [G05!<(/1MZ=RFLL$)6BX-T7H<(9Y ME]L%0H#)^SA.=R7\MMQ"&\X:5"[MF;N!!52@NQK"<(=[2WS;IKT0"]0^!B!7 M7MT39^10 "_XJJM=":1I@1I(0^XNDH$%G:7X9-D=>7-7*F7&$=,7A-!9>^_S M>"Y L<%N7CLW1LD]VO9P(OQ8UUPIL[?'B@.;[?8&ZZSYRR M:* #"Z9 YU'=?YP(JU"%[\0(B\B0NP 9W@&Q<<0+V MM6SWYFS0%BOG5FW7EFT)Z&W@%G$D5V[WF!_Z)G'LYFZW%6_=-F_U1G#YUG7] MAFL MVL#!W0$B' D!XQRT' C!7&@MVT51Q%L@'$:!Y =]W'B(7+C=D,GEW(K M%UKOLVUJ 1BC17':9W,XIW-OP'.S"'1"=XM(Z'U*YXLC]W91AW'$6'7'B'5: MMW]JUXQ@)W;+%XV,.(VF5XULAXU/IXUJQXW]='??N('AZ'=@%WC"5I7F]H 1 MJ'B,1Y./UX"3]WF7UWJ:QWF>9WG=MFVBAP:D5Y;6YX"IMWIBT'JLEHL85W%U M0'MT=WO1R(F[UWN3\GNCUX;?4WS,YH3_-@?-YXJ=Q0+2=X+5MXW\DWTK%TC= MAW1**'[D]VQ5($9J'=FT($4!8(496TDV' SF80JJ'8L MZ(+6!H/:.(-R4(/"N6QXJ8,\*(1O (0]2 =#J)5H8(1+&'O>>81-V!M/F$-; M8FYH]X9:*!Z@EH5;N 9=.&U?&(;;-H;W1W_1B8;HMX9M&*#;=@9QN!=T> ;D M1F\(JHUZ&'$6UX=4P6Z "(&"J'B%>(@DYXB+V(C25FZ0:("36(F7B&]^MXFZ MYXF@*(K:] :E&#JGF*"J."Y0LW^O&(L]]W/DUI/X09A=QXM+-Y3!6)13AY3T MAXQ+N8P ^G7/&)72.(5FN7;7"(Q9J8MTQY5EX)5Y!Y9\)Y8N("HY*?IB&UL$ =] %E( FQB1&U+061CUED@ M *EI@4\3L4+^Y"/HXV]L(&4@L$$=E#"&>J>!"@(#4S?NA@,XP*BYX:C^8ZG7 MEJGE)A@PP*HKU$8.I"FANC:CJB:E"JB*BJH^LZJM^F6-6AF*$:N\! (6-D!% M4:O&FJL3U&1V$:R(VHZ/@ZUX>D[+H6:;UEC9PP=[!#NPRB52PB)RB$->P);\+!)[40(B788ZX8$1S.&F9B)*E*@;8J2S]F, ?JFAHP!D7PJ!MR>BQ"<$2.#NP>%6[IC0%0(D;KOL;H>VKJ1"Q.4^[KR"KS" M"P+$:[GT!A&^M'"3PKG(NRGPR 5IT+S/*UGL2[V+:Q6L"V2N*TQ'!VM/0@8Z M%+?7UKGJBSQ<(+A1]+X"K!OR&UF54IM9""9R-V;U"[F@ :IIDA G$!"7)K<3 MTD_SXZHZ%;?"M,' U"5_(49F"+YL,7!%X9+NYT P,D&!D;]FASYA4$@J&SC^ M(2D[L331T;<.1@+=@2:ELAKF@1[JD23;&P.>$2=I>T$O\3ZZ809>-K\XC#ZB MD07,7_@<5@HL72=%DS M6!4QYVL[81^SY+>_X7YR$!4%8@:),<&S)&6XPL)BPA^"7 9MW,=OL4(#2K2Z'!5*,LQ_?!&Y9,P0,]"&S!39$RU4?- 0 MO=#)/,WI)&S[,4NPL\?7546;E#*(5SMME\A!9CY6K#XN'= ME1W.2[KK\0-M M_+PCS4JF5+@MT%[4<=1VU ([? =D8"8O8%IN\ )P0-420@8GD1(<8_=>!W=F$?0*&G1N(7E(]B>'45[;<&Q3=B ;=NG MG=H0!I*LC=GJ$W++8L4\=!F]D0.2M/@:],ZG 5MQJ! M4 *GJD 7B%@ MN!(M01"_.<&VS2<'LE8F8 *4=-T1M5.@92'Y@LACHJ M7=G"18Z"/>-I<9?&51?K8=MUTP M\^9S$!>R\P9*Q$!Q$>?/@^?/G*ET#FE])FET'MC4) :_IP>P\P*'GNB*;4&' MV6HGFTD(@3RKS.AK@>@HH>@N?AU"7>BG%HV!L2,]\B-!,B1LL!YU+,EN\"=9 M$>K[H2Q0(X=F!!% L=E1!.N+W1NSOA>U3D,JH+@*'!_^HSX'LNL)1.MI<$:9 MJL*T34H-=16Z'C_)[NO+7@:"NAW1SC98!QA\T'?!0NV]#@>_+NQ(,NVZ7MZ# MCL3=WMV"!#M#)!I.@SRZ_CSU3LA1P=@L#:Z8G242 L_@,\_AS=/WW-6PT^_^ M/-Z?4<%KYM5X)^.MC>EOH.ETH.AZ)!:E#B00914C7N)][=J-ONGR/@9/ S50 MP^3JO% .#]8/*R>8'?(5?_#"?>2+W=A% ?,6__'J@_,C7_(^0@8HOQ,GL!HG MT ,/D0>SRA@ +\_B,_!L#>A4\;-)$F3Q ] +_RMO MG_>"(:=[Q",^HO&H#@(='UEP/QBX4R'A7@,F$!3@G5^N94*6_R1IGO>=C@+9 MX5TED56VPLQ1+S'M@>HE^M]22P?XX0. :S3R)ML 8* M5/MUJD"Y[_L]4A"Y7UT4@1I^"OR'^@)>@ +^/@9&DOS$O_S-__RU,=(Q8-\@ ML 5^@ ==\ ,WU@(DUL85.]+1'NS!;!5$&[<;7ZF-HDN]F"1Q$M37820J8 ?H M3\7KGQ'M_^5I$?\GX/XQL=% \FK3SS-_>RR5Z8'W8?]4@ -4 7K@ 3I \J<[ M)MK[RU47X24H#90@LJ 9L2,1M.PZ)$ HM@#E@/T; _G/>G&)\N0F AV0)YH ?.P!J8 M']9?+C%G3!!#&,%09=1FX/>@>[)"WM ;D55/\O)6!!T6"_ML>NZAEH,! .OQ^0^]"@;(B$YZ@,*K\180G%0 I$ M$H=P#L8_;O0;&"'DPH.\"@B<$K\&V%Z#"G@!?3#XQ3X50+TB2RC48!7A-R"W M+J(8EEL>]! _ +C\0=4B# ^5#T0-<>OV!;\P@*&*66 8<"= ]K5!97BHBH:+ MV%:QKQB.".%'#5U+',E(PF\3TC[I9Q .U669!*/XNF!BV?X3%W[6WQ(X@0<"'Z(//)6 M&#Q^R,-/#1&_(!2*WU#@1EPB#,0YX3<1\4!%-(< T4-TQ(^X#4G=X=-Z'(_$ M11:)R'T\(B&D?<8ED$0Z)LTGBKRR)Q/E MCKVB=*C!(3(8'!?M;%MN*UC[ 0:@-C=8XGX+2:ALX>N$Z<-CEZDVWF7QL07D%A0P MB $C@ Q.13;1R,"#@E![ M=H*^T(@0J-1 #GZ 9\P-[2_&U($6"?Q(*K$ MA+@@XY9$X"3Z(;2,,%$R:V!$:/DFT_'%F1"L!1RGEV3)(#,0*2"%;O)-,I53 MH#5FSI0U$&PBYM:BXNL2'Z&+L 5[I@X50F;< _GFHJ6 ,'"T9D 7$ ,^P >, M 1&S:4Z "3 # K+S%;KGD,,^0E?(>ANO-+JZ!$ F?\E'Z %M\D)\!,+0)=9% M%+L.A>Y\"$B9N6F$LBD+(SYT-\1!,A-L_,6"X$+.%+!Y$ <,4>VY=4 M\<<,!YM2+M0:D^R7<@%\K:: >>X&9JYAB_AAK8TPQ_;@/L-M$"2,,@$\-^6" M,$G 'HMVUE)@HC4? 2]/6<>4#2#S#5J%LV932&8H.PX4<_XQ2Z8P BU"R/05 MJXG7F;-02#"A%LNT"GV'(O %7"$;4MG-%&:XJ10*N(K)O2S"S]R4*6AH%C"7 M6!IW0)H@C$E"7C:4J7@"M*9#.9I682.:D##W/H*7UGF7+Q.<& 9\8P98Q!Z0 M$_;QBT$14B+&%*.,@!0"DMUI0"4F_^3$#7MB%N'2_$JK$#MR&J5 9U%!F.A) M)2DQY\/B'@,]+P !%EACDQ+K4*27,G,D.':DNDH(_(0D#873L M.W^5.V&:00,>+(YF[0A>]9 M'_THQ-.-:<(_AD@_6?CZY-9CGR4ND/K1T& ?+XOQ80ER( _0B$NZW.):G;JD MP2]N*A(3 H_>7R?=FIHRD6I/H5:H/ 0H/51$:,/+8Q ,>O,T(&9;D!W=M+< end From rc-owner Mon Jan 10 02:44:01 1994 Received: from netcomsv.netcom.com ([163.179.1.8]) by hawkwind.utcs.toronto.edu with SMTP id <24074>; Mon, 10 Jan 1994 02:42:31 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id XAA12946; Sun, 9 Jan 1994 23:24:32 -0800 Received: by netapp.com (4.1/SMI-4.1) id AA20782; Sun, 9 Jan 94 23:19:13 PST Date: Mon, 10 Jan 1994 02:19:13 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9401100719.AA20782@netapp.com> To: rc@hawkwind.utcs.toronto.edu Subject: rc patches halfway to 1.5 Here are a set of rc patches I have applied to rc-1.4. They reflect the current state of my rc-1.5 development directory, and I am pushing them out of the door since I do not know when I will be able to hack in all the features I want for 1.5. This "release" is called "rc-1.5betadev-1", which means that 1.5 is still nominally under development. Any futher patches before a freeze in features will be called "betadev-2", and so forth. Things that are notably missing from this patch set: support for builtin read, support for /dev/fd-like functionality via /tmp files. Also, the man pages are possibly not quite up-to-date; I still need to coordinate the feature changes with the man pages. Please read the changes to the CHANGES file to see what has changed, that should be an authoritative list. Thanks, Byron. PS "patch" seems to fail on trip.rc, so I am reposting the new trip.rc; it follows in the next message. I will ask cks if he can apply all the patches and leave the resulting archive for ftp on a toronto machine. *** /tmp/T0a19009 Sun Jan 9 14:43:20 1994 --- history/history.c Wed Dec 8 21:52:25 1993 *************** *** 246,252 **** /* * if the command contains the "me" character at the start of the line ! * or after any of [`{|()] then try again */ for (t = s; *t != '\0'; t++) --- 246,252 ---- /* * if the command contains the "me" character at the start of the line ! * or after any of [`{|()@] then try again */ for (t = s; *t != '\0'; t++) *************** *** 254,261 **** char *u = t - 1; while (u >= s && (*u == ' ' || *u == '\t')) --u; ! if (u < s || *u == '`' || *u == '{' || *u == '|' || *u == '(' || *u == ')') goto again; } return s; } --- 254,269 ---- char *u = t - 1; while (u >= s && (*u == ' ' || *u == '\t')) --u; ! if (u < s) goto again; + switch (*u) { + case '`': case '@': + case '(': case ')': + case '{': case '|': + goto again; + default: + break; + } } return s; } *** /tmp/T0a19638 Sun Jan 9 15:21:04 1994 --- CHANGES Sun Jan 9 15:20:53 1994 *************** *** 169,171 **** --- 169,263 ---- A memory leak in treefree() was plugged up --- the root node of a function was not getting freed. + + Changes since rc-1.4: + + General changes: + + Some small memory leaks/uninit references revealed by Purify. + + $bqstatus for querying the exit status of a backquote. + + Globbing through unreadable directories. + + More options to whatis. + + History append which always re-opens the file (avoids + inconsistencies over multiple NFS-mounted accesses to + $history). + + Support "rc -s". + + --------- + + Makefile: Added comment referring to README for yacc/malloc problem. + + uiltins.c: Added more options to whatis, protected rlimit prototypes + with #ifndef SYSVR4, renamed SIGCHK to sigchk. + + except.c: Patched nl_on_intr printing to happen only in interactive + shells. + + exec.c: Added comment explaining nl_on_intr variable, renamed S IGCHK + to sigchk. + + fn.c: Replaced by-hand consing of exception stack etc. for signal + handler execution with call to funcall(). Replaced fun2str + call with call on print routines. + + footobar.c: Got rid of memory leak in get_name(), parenthesize count, + flat and var nodes for correctness in unparsing, removed + list2str, made get_name use nalloc space, merge in a + better parse_var from es. + + glob.c: Split out a test so that closedir is called correctly, renamed + SIGCHK to sigchk. + + glom.c: Added bqstatus, renamed SIGCHK to sigchk, removed spuri ous + setsigdefaults, patched uninit memory reference, rename + "clear" to "memzero", wait for bq subproc to finish on EINTR. + + hash.c: Added options to function/variable print code. + + history/history.c: Added '@' to the list of chars which can precede an + ignored '-'. + + input.c: Got rid of tiny memory leak in closefds, got rid of uninit + memory reference in popinput, moved nul ignored check into + realgchar(), changed history append to always reopen the + history file, replaced SIGCHK with sigchk. Freed memory + returned by call to readline(). + + lex.c: Corrected typo in comment, moved nul character ignore c ode + to input routines. + + main.c: Added -s flag. + + nalloc.c: Added convenience feature to erealloc. (Allow NULL parameter) + + print.c: Changed use of va_start so broken compilers can compile + print code. + + proto.h: Added fake memset. + + rc.h: Replaced clear() function prototype with a macro call on + memset(), removed SIGCHK, fixed prototypes. + + signal.c: Removed unconditional exit in catcher code, renamed SIGCHK + to sigchk. + + status.c: Rewrite sgetstatus breaking out strstatus so that bqstatus + can be set from glom routines. + + utils.c: Got rid of clear() (use memset from C library), rename SIGCHK + to sigchk. + + var.c: Got rid of memory leak in listassign(), converted list2 str() + call to something using the print routines. + + version.c: New version string. + + wait.c: Got rid of memory leak in rc_fork, renamed SIGCHK to si gchk. + + walk.c: Fixed pre-redirection bug, removed spurious setsigdefau lts(), + renamed SIGCHK to sigchk. *** /tmp/T0a19127 Sun Jan 9 14:45:35 1994 --- Makefile Wed Dec 8 21:52:27 1993 *************** *** 21,27 **** LDFLAGS= # You may substitute "bison -y" for yacc. (You want to choose the one that ! # makes a smaller y.tab.c.) YACC=yacc OBJS=$(ADDON) builtins.o except.o exec.o $(EXECVE) fn.o footobar.o getopt.o \ --- 21,27 ---- LDFLAGS= # You may substitute "bison -y" for yacc. (You want to choose the one that ! # makes a smaller y.tab.c. Also see the README about Sun's yacc.) YACC=yacc OBJS=$(ADDON) builtins.o except.o exec.o $(EXECVE) fn.o footobar.o getopt.o \ *** /tmp/T0a19127 Sun Jan 9 14:45:36 1994 --- README Wed Dec 8 21:52:29 1993 *************** *** 1,4 **** ! This is release 1.4 of rc. Read COPYRIGHT for copying information. All files are --- 1,4 ---- ! This is release 1.5 of rc. Read COPYRIGHT for copying information. All files are *************** *** 62,67 **** --- 62,78 ---- to get rc to work in a reasonable fashion on a real (i.e., commercial, non-Labs) UNIX system; a few were changes motivated by concern about some inadequacies in the original design. + + YACC + + The yacc that Sun ships with SunOS 4.1.1 calls malloc() to allocate + space for the state stack, and requires a call to YYACCEPT or YYABORT + to free this memory. This means that if rc takes an interrupt while + parsing a command (say, if ^C is typed), yacc will leak away this + memory. The solution is to use a yacc which statically allocates + this array, such as the yacc in the BSD distribution. Berkeley yacc- + generated y.tab.c and y.tab.h are shipped with rc in case you cannot + get hold of Berkeley yacc. OLD C *** /tmp/T0a19127 Sun Jan 9 14:45:36 1994 --- builtins.c Wed Dec 8 21:52:27 1993 *************** *** 12,17 **** --- 12,18 ---- #include #include "rc.h" #include "jbwrap.h" + #include "sigmsgs.h" #ifndef NOLIMITS #include #include *************** *** 266,272 **** setstatus(pid, stat); else set(FALSE); ! SIGCHK; } /* --- 267,273 ---- setstatus(pid, stat); else set(FALSE); ! sigchk(); } /* *************** *** 274,282 **** is defined as a variable, function or pathname. */ static void b_whatis(char **av) { bool f, found; - bool ess = FALSE; int i, ac, c; List *s; Node *n; --- 275,294 ---- is defined as a variable, function or pathname. */ + #define not(b) ((b)^TRUE) + #define show(b) (not(eff|vee|pee|bee|ess)|(b)) + + static bool issig(char *s) { + int i; + for (i = 0; i < NUMOFSIGNALS; i++) + if (streq(s, signals[i].name)) + return TRUE; + return FALSE; + } + static void b_whatis(char **av) { + bool ess, eff, vee, pee, bee; bool f, found; int i, ac, c; List *s; Node *n; *************** *** 283,319 **** char *e; for (rc_optind = ac = 0; av[ac] != NULL; ac++) ; /* count the arguments for getopt */ ! while ((c = rc_getopt(ac, av, "s")) == 's') ! ess = TRUE; ! if (c != -1) { ! set(FALSE); ! return; ! } av += rc_optind; ! if (*av == NULL && !ess) { ! whatare_all_vars(); set(TRUE); return; } - if (ess) - whatare_all_signals(); found = TRUE; for (i = 0; av[i] != NULL; i++) { f = FALSE; errno = ENOENT; ! if ((s = varlookup(av[i])) != NULL) { f = TRUE; prettyprint_var(1, av[i], s); } ! if ((n = fnlookup(av[i])) != NULL) { f = TRUE; prettyprint_fn(1, av[i], n); ! } else if (isbuiltin(av[i]) != NULL) { f = TRUE; fprint(1, "builtin %s\n", av[i]); ! } else if ((e = which(av[i], FALSE)) != NULL) { f = TRUE; ! fprint(1, "%s\n", e); } if (!f) { found = FALSE; --- 295,343 ---- char *e; for (rc_optind = ac = 0; av[ac] != NULL; ac++) ; /* count the arguments for getopt */ ! ess = eff = vee = pee = bee = FALSE; ! while ((c = rc_getopt(ac, av, "sfvpb")) != -1) ! switch (c) { ! default: set(FALSE); return; ! case 's': ess = TRUE; break; ! case 'f': eff = TRUE; break; ! case 'v': vee = TRUE; break; ! case 'p': pee = TRUE; break; ! case 'b': bee = TRUE; break; ! } av += rc_optind; ! if (*av == NULL) { ! if (vee|eff) ! whatare_all_vars(eff, vee); ! if (ess) ! whatare_all_signals(); ! if (bee) ! for (i = 0; i < arraysize(builtins); i++) ! fprint(1, "builtin %s\n", builtins[i].name); ! if (pee) ! fprint(2, "whatis -p: must specify argument\n"); ! if (show(FALSE)) /* no options? */ ! whatare_all_vars(TRUE, TRUE); set(TRUE); return; } found = TRUE; for (i = 0; av[i] != NULL; i++) { f = FALSE; errno = ENOENT; ! if (show(vee) && (s = varlookup(av[i])) != NULL) { f = TRUE; prettyprint_var(1, av[i], s); } ! if (((show(ess)&&issig(av[i])) || show(eff)) && (n = fnlookup(a v[i])) != NULL) { f = TRUE; prettyprint_fn(1, av[i], n); ! } else if (show(bee) && isbuiltin(av[i]) != NULL) { f = TRUE; fprint(1, "builtin %s\n", av[i]); ! } else if (show(pee) && (e = which(av[i], FALSE)) != NULL) { f = TRUE; ! fprint(1, "%S\n", e); } if (!f) { found = FALSE; *************** *** 440,447 **** --- 464,473 ---- { NULL, 0, NULL } }; + #ifndef SYSVR4 extern int getrlimit(int, struct rlimit *); extern int setrlimit(int, struct rlimit *); + #endif static void printlimit(const Limit *limit, bool hard) { struct rlimit rlim; *** /tmp/T0a19127 Sun Jan 9 14:45:38 1994 --- except.c Fri Dec 10 20:25:37 1993 *************** *** 131,137 **** if (s != SIGINT) panic("s != SIGINT in sigint catcher"); /* this is the newline you see when you hit ^C while typing a command * / ! if (nl_on_intr) fprint(2, "\n"); nl_on_intr = TRUE; redirq = NULL; --- 131,137 ---- if (s != SIGINT) panic("s != SIGINT in sigint catcher"); /* this is the newline you see when you hit ^C while typing a command * / ! if (interactive && nl_on_intr) fprint(2, "\n"); nl_on_intr = TRUE; redirq = NULL; *** /tmp/T0a19127 Sun Jan 9 14:45:38 1994 --- exec.c Wed Dec 8 21:59:43 1993 *************** *** 110,118 **** redirq = NULL; rc_wait4(pid, &stat, TRUE); setstatus(-1, stat); if ((stat & 0xff) == 0) nl_on_intr = FALSE; ! SIGCHK; nl_on_intr = TRUE; pop_cmdarg(TRUE); } --- 110,129 ---- redirq = NULL; rc_wait4(pid, &stat, TRUE); setstatus(-1, stat); + /* + There is a very good reason for having this weird + nl_on_intr variable: when rc and its child both + process a SIGINT, (i.e., the child has a SIGINT + catcher installed) then you don't want rc to print + a newline when the child finally exits. Here's an + example: ed, , . rc does not + and should not print a newline before the next + prompt, even though there's a SIGINT in its signal + vector. + */ if ((stat & 0xff) == 0) nl_on_intr = FALSE; ! sigchk(); nl_on_intr = TRUE; pop_cmdarg(TRUE); } *** /tmp/T0a19127 Sun Jan 9 14:45:38 1994 --- fn.c Wed Dec 8 21:52:27 1993 *************** *** 12,20 **** static bool runexit = FALSE; static Node *handlers[NUMOFSIGNALS], null; ! static void (*def_sigint)(int) = SIG_DFL, ! (*def_sigquit)(int) = SIG_DFL, ! (*def_sigterm)(int) = SIG_DFL; /* Set signals to default values for rc. This means that interactive --- 12,20 ---- static bool runexit = FALSE; static Node *handlers[NUMOFSIGNALS], null; ! static void (*def_sigint)(int) = SIG_DFL; ! static void (*def_sigquit)(int) = SIG_DFL; ! static void (*def_sigterm)(int) = SIG_DFL; /* Set signals to default values for rc. This means that interactive *************** *** 106,118 **** /* rc's exit. if runexit is set, run the sigexit function. */ extern void rc_exit(int stat) { - static char *sigexit[2] = { - "sigexit", - NULL - }; if (runexit) { runexit = FALSE; ! funcall(sigexit); stat = getstatus(); } exit(stat); --- 106,117 ---- /* rc's exit. if runexit is set, run the sigexit function. */ extern void rc_exit(int stat) { if (runexit) { + char *sig[2]; + sig[0] = "sigexit"; + sig[1] = NULL; runexit = FALSE; ! funcall(sig); stat = getstatus(); } exit(stat); *************** *** 121,142 **** /* The signal handler for all functions. calls walk() */ static void fn_handler(int s) { ! List *dollarzero; ! Estack e; ! Edata star; int olderrno; if (s < 1 || s >= NUMOFSIGNALS) panic("unknown signal"); olderrno = errno; ! dollarzero = nnew(List); ! dollarzero->w = signals[s].name; ! dollarzero->n = NULL; ! varassign("*", dollarzero, TRUE); ! star.name = "*"; ! except(eVarstack, star, &e); ! walk(handlers[s], TRUE); ! varrm("*", TRUE); ! unexcept(); /* eVarstack */ errno = olderrno; } --- 120,133 ---- /* The signal handler for all functions. calls walk() */ static void fn_handler(int s) { ! char *sig[2]; int olderrno; if (s < 1 || s >= NUMOFSIGNALS) panic("unknown signal"); olderrno = errno; ! sig[0] = signals[s].name; ! sig[1] = NULL; ! funcall(sig); errno = olderrno; } *************** *** 217,223 **** return NULL; if (look->extdef != NULL) return look->extdef; ! return look->extdef = fun2str(name, look->def); } /* --- 208,214 ---- return NULL; if (look->extdef != NULL) return look->extdef; ! return look->extdef = mprint("fn_%F={%T}", name, look->def); } /* *** /tmp/T0a19127 Sun Jan 9 14:45:39 1994 --- footobar.c Wed Dec 8 21:52:29 1993 *************** *** 5,19 **** #include "rc.h" ! #define FSCHAR '\1' ! #define FSSTRING "\1" - static char *getenvw(char *, bool); - #ifdef PROTECT_ENV ! static bool Fconv(Format *f, int ignore) { /* protect an exported name fro m brain-dead shells */ ! int c; unsigned const char *s = va_arg(f->args, unsigned const char *); while ((c = *s++) != '\0') if (dnw[c] || c == '*' || (c == '_' && *s == '_')) --- 5,16 ---- #include "rc.h" ! /* protect an exported name from brain-dead shells */ #ifdef PROTECT_ENV ! static bool Fconv(Format *f, int ignore) { unsigned const char *s = va_arg(f->args, unsigned const char *); + int c; while ((c = *s++) != '\0') if (dnw[c] || c == '*' || (c == '_' && *s == '_')) *************** *** 24,35 **** } #endif - /* used to turn a function in Node * form into something we can export to the environment */ - - extern char *fun2str(char *name, Node *n) { - return mprint("fn_%F={%T}", name, n); - } - /* convert a redirection to a printable form */ static bool Dconv(Format *f, int ignore) { --- 21,26 ---- *************** *** 63,76 **** switch (n->type) { case nWord: fmtprint(f, "%S", n->u[0].s); break; case nQword: fmtprint(f, "%#S", n->u[0].s); break; ! case nBang: fmtprint(f, "! %T", n->u[0].p); break; case nCase: fmtprint(f, "case %T", n->u[0].p); break; case nNowait: fmtprint(f, "%T&", n->u[0].p); break; - case nCount: fmtprint(f, "$#%T", n->u[0].p); break; - case nFlat: fmtprint(f, "$^%T", n->u[0].p); break; case nRmfn: fmtprint(f, "fn %T", n->u[0].p); break; case nSubshell: fmtprint(f, "@ %T", n->u[0].p); break; - case nVar: fmtprint(f, "$%T", n->u[0].p); break; case nAndalso: fmtprint(f, "%T&&%T", n->u[0].p, n->u[1].p); break; case nAssign: fmtprint(f, "%T=%T", n->u[0].p, n->u[1].p); break; case nConcat: fmtprint(f, "%T^%T", n->u[0].p, n->u[1].p); break; --- 54,64 ---- switch (n->type) { case nWord: fmtprint(f, "%S", n->u[0].s); break; case nQword: fmtprint(f, "%#S", n->u[0].s); break; ! case nBang: fmtprint(f, "!%T", n->u[0].p); break; case nCase: fmtprint(f, "case %T", n->u[0].p); break; case nNowait: fmtprint(f, "%T&", n->u[0].p); break; case nRmfn: fmtprint(f, "fn %T", n->u[0].p); break; case nSubshell: fmtprint(f, "@ %T", n->u[0].p); break; case nAndalso: fmtprint(f, "%T&&%T", n->u[0].p, n->u[1].p); break; case nAssign: fmtprint(f, "%T=%T", n->u[0].p, n->u[1].p); break; case nConcat: fmtprint(f, "%T^%T", n->u[0].p, n->u[1].p); break; *************** *** 81,90 **** case nArgs: fmtprint(f, "%T %T", n->u[0].p, n->u[1].p); break; case nSwitch: fmtprint(f, "switch(%T){%T}", n->u[0].p, n->u[1].p); break; case nMatch: fmtprint(f, "~ %T %T", n->u[0].p, n->u[1].p); break; - case nVarsub: fmtprint(f, "$%T(%T)", n->u[0].p, n->u[1].p); break; case nWhile: fmtprint(f, "while(%T)%T", n->u[0].p, n->u[1].p); break; case nLappend: fmtprint(f, "(%T %T)", n->u[0].p, n->u[1].p); break; case nForin: fmtprint(f, "for(%T in %T)%T", n->u[0].p, n->u[1].p, n- >u[2].p); break; case nDup: if (n->u[2].i != -1) fmtprint(f, "%D[%d=%d]", n->u[0].i, n->u[1].i, n->u[2]. i); --- 69,93 ---- case nArgs: fmtprint(f, "%T %T", n->u[0].p, n->u[1].p); break; case nSwitch: fmtprint(f, "switch(%T){%T}", n->u[0].p, n->u[1].p); break; case nMatch: fmtprint(f, "~ %T %T", n->u[0].p, n->u[1].p); break; case nWhile: fmtprint(f, "while(%T)%T", n->u[0].p, n->u[1].p); break; case nLappend: fmtprint(f, "(%T %T)", n->u[0].p, n->u[1].p); break; case nForin: fmtprint(f, "for(%T in %T)%T", n->u[0].p, n->u[1].p, n- >u[2].p); break; + case nVarsub: fmtprint(f, "$%T(%T)", n->u[0].p, n->u[1].p); break; + case nCount: case nFlat: case nVar: { + char *lp = "", *rp = ""; + Node *n0 = n->u[0].p; + + if (n0->type != nWord && n0->type != nQword) + lp = "(", rp = ")"; + + switch (n->type) { + default: panic("this can't happen"); break; + case nCount: fmtprint(f, "$#%s%T%s", lp, n0, rp); break; + case nFlat: fmtprint(f, "$^%s%T%s", lp, n0, rp); break; + case nVar: fmtprint(f, "$%s%T%s", lp, n0, rp); break; + } + break; + } case nDup: if (n->u[2].i != -1) fmtprint(f, "%D[%d=%d]", n->u[0].i, n->u[1].i, n->u[2]. i); *************** *** 154,218 **** return FALSE; } - /* convert a List to a string, separating it with ^A characters. Used for exp orting variables to the environment */ - - extern char *list2str(char *name, List *s) { - SIZE_T size, step; - List *t; - char *w, *x; - name = nprint("%F", name); - size = strlen(name) + listlen(s); - w = ealloc(size + 2); - t = s; - x = w; - strcpy(x, name); - strcpy(x += strlen(name), "="); - strcpy(x += conststrlen("="), t->w); - for (x += strlen(t->w), s = s->n; s != NULL; s = s->n) { - memcpy(x, FSSTRING, step = conststrlen(FSSTRING)); - x += step; - memcpy(x, s->w, step = strlen(s->w)); - x += step; - } - *x = '\0'; - return w; - } - /* convert a List to an array, for execve() */ extern char **list2array(List *s, bool print) { ! char **av; ! int i; - /* 4 == 1 for the null terminator + 2 for the fake execve() + 1 for def aulting to sh */ - av = nalloc((listnel(s) + 4) * sizeof (char *)); - av += 3; /* hide the two free spots from rc (two for #! emulation, one for defaulting to sh) */ if (print) fprint(2, "%L\n", s, " "); ! for (i = 0; s != NULL; i++) { ! av[i] = s->w; s = s->n; } ! av[i] = NULL; ! return av; } ! /* figure out the name of a variable given an environment string. copy this i nto malloc space */ extern char *get_name(char *s) { int c; ! SIZE_T i; ! char *r, *namebuf; ! for (i = 0; s[i] != '\0' && s[i] != '='; i++) ! ; ! if (s[i] == '\0') return NULL; ! r = namebuf = ealloc(i + 1); while (1) switch (c = *s++) { case '=': *r++ = '\0'; ! return namebuf; #ifdef PROTECT_ENV case '_': if (*s == '_') { --- 157,197 ---- return FALSE; } /* convert a List to an array, for execve() */ extern char **list2array(List *s, bool print) { ! char **argv, **av; if (print) fprint(2, "%L\n", s, " "); ! /* ! Allocate 3 extra spots (2 for the fake execve & 1 for defaulting to ! sh) and hide these from exec(). ! */ ! argv = av = (char **) nalloc((listnel(s) + 4) * sizeof *av) + 3; ! while (s != NULL) { ! *av++ = s->w; s = s->n; } ! *av = NULL; ! return argv; } ! /* figure out the name of a variable given an environment string. */ extern char *get_name(char *s) { + char *eq = strchr(s, '='); + char *r, *result; int c; ! ! if (eq == NULL) return NULL; ! r = result = nalloc(eq - s + 1); while (1) switch (c = *s++) { case '=': *r++ = '\0'; ! return result; #ifdef PROTECT_ENV case '_': if (*s == '_') { *************** *** 233,287 **** } } ! /* get the next word from a variable's value as represented in the environmen t. */ ! static char *getenvw(char *s, bool saw_alpha) { ! SIZE_T i; ! char *r; ! for (i = 0; s[i] != '\0' && s[i] != FSCHAR; i++) ! ; ! if (i == 0) { ! if (s[i] == '\0' && !saw_alpha) ! return NULL; ! else ! return clear(enew(char), (SIZE_T) 1); ! } ! r = strncpy(ealloc(i + 1), s, i); ! r[i] = '\0'; ! return r; ! } - /* take an environment entry for a variable (elements ^A separated) and turn it into a List */ - extern List *parse_var(char *name, char *extdef) { ! List *r, *top; ! char *f; ! bool saw_alpha; ! top = r = enew(List); ! extdef = strchr(extdef, '=') + 1; ! if ((f = getenvw(extdef, FALSE)) == NULL) { ! r->w = ""; ! r->m = NULL; ! r->n = NULL; ! } else { ! while (1) { ! r->w = f; ! r->m = NULL; ! extdef += strlen(f); ! if (*extdef == FSCHAR) { ! extdef++; ! saw_alpha = TRUE; ! } else { ! saw_alpha = FALSE; ! } ! if ((f = getenvw(extdef, saw_alpha)) == NULL) { ! r->n = NULL; ! break; ! } ! r = r->n = enew(List); ! } } ! return top; } /* get an environment entry for a function and have rc parse it. */ --- 212,256 ---- } } ! /* ! Hacky routine to split a ^A-separated environment variable. Scans ! backwards. Be VERY CAREFUL with the loop boundary conditions. e.g., ! notice what happens when there is no ^A in the extdef. (It does ! the right thing, of course :-) ! */ ! #define skipleft(p) do --p; while (*p != '\0' && *p != '\001'); extern List *parse_var(char *name, char *extdef) { ! char *endp, *realend, *sepp; ! List *tailp, *new; ! ! extdef = strchr(extdef, '='); ! *extdef++ = '\0'; /* null "initiate" the string for rtol scanning */ ! ! sepp = realend = strchr(extdef, '\0'); ! tailp = NULL; ! ! while (1) { ! endp = sepp; /* set endp to end of current mebmer */ ! skipleft(sepp); /* advance sepp to the previous \1, */ ! *endp = '\0'; /* and null terminate the member. */ ! ! new = enew(List); ! new->w = ecpy(sepp+1); ! new->m = NULL; ! new->n = tailp; ! tailp = new; ! ! if (sepp < extdef) /* break when sepp hits the null "initi ator" */ ! break; ! if (endp != realend) /* else restore the \1 in between membe rs */ ! *endp = '\001'; } ! if (endp != realend) ! *endp = '\001'; ! *--extdef = '='; /* restore extdef '=' */ ! return tailp; } /* get an environment entry for a function and have rc parse it. */ *** /tmp/T0a19127 Sun Jan 9 14:45:39 1994 --- glob.c Sun Dec 12 17:01:20 1993 *************** *** 94,104 **** extern DIR *opendir(const char *); extern struct dirent *readdir(DIR *); /*extern int closedir(DIR *);*/ top = r = NULL; /* opendir succeeds on regular files on some systems, so the stat() cal l is necessary (sigh) */ ! if (stat(d, &s) < 0 || (s.st_mode & S_IFMT) != S_IFDIR || (dirp = opend ir(d)) == NULL) return NULL; while ((dp = readdir(dirp)) != NULL) if ((*dp->d_name != '.' || *p == '.') && match(p, m, dp->d_name )) { /* match ^. explicitly */ matched = TRUE; --- 94,132 ---- extern DIR *opendir(const char *); extern struct dirent *readdir(DIR *); /*extern int closedir(DIR *);*/ + int i; + /* + return a match if there are no metacharacters; allows globbing throu gh + directories with no read permission. make sure the file exists, thou gh. + */ + matched = TRUE; + if (m != NULL) + for (i = 0; p[i] != '\0'; i++) + if (m[i]) { + matched = FALSE; + break; + } + + if (matched) { + char *path = nprint("%s/%s", d, p); + if (stat(path, &s) < 0) + return NULL; + r = nnew(List); + r->w = ncpy(p); + r->m = NULL; + r->n = NULL; + return r; + } + top = r = NULL; + if ((dirp = opendir(d)) == NULL) + return NULL; /* opendir succeeds on regular files on some systems, so the stat() cal l is necessary (sigh) */ ! if (stat(d, &s) < 0 || (s.st_mode & S_IFMT) != S_IFDIR) { ! closedir(dirp); return NULL; + } while ((dp = readdir(dirp)) != NULL) if ((*dp->d_name != '.' || *p == '.') && match(p, m, dp->d_name )) { /* match ^. explicitly */ matched = TRUE; *************** *** 125,139 **** static List *lglob(List *s, char *p, char *m, SIZE_T slashcount) { List *q, *r, *top, foo; ! static List slash; ! static SIZE_T slashsize = 0; ! if (slashcount + 1 > slashsize) { ! slash.w = ealloc(slashcount + 1); ! slashsize = slashcount; } ! slash.w[slashcount] = '\0'; while (slashcount > 0) ! slash.w[--slashcount] = '/'; for (top = r = NULL; s != NULL; s = s->n) { q = dmatch(s->w, p, m); if (q != NULL) { --- 153,169 ---- static List *lglob(List *s, char *p, char *m, SIZE_T slashcount) { List *q, *r, *top, foo; ! static struct { ! List l; ! SIZE_T size; ! } slash; ! if (slashcount+1 > slash.size) { ! slash.size = 2*(slashcount+1); ! slash.l.w = erealloc(slash.l.w, slash.size); } ! slash.l.w[slashcount] = '\0'; while (slashcount > 0) ! slash.l.w[--slashcount] = '/'; for (top = r = NULL; s != NULL; s = s->n) { q = dmatch(s->w, p, m); if (q != NULL) { *************** *** 141,147 **** foo.m = NULL; foo.n = NULL; if (!(s->w[0] == '/' && s->w[1] == '\0')) /* need to se parate */ ! q = concat(&slash, q); /* dir/name w ith slash */ q = concat(&foo, q); if (r == NULL) top = r = q; --- 171,177 ---- foo.m = NULL; foo.n = NULL; if (!(s->w[0] == '/' && s->w[1] == '\0')) /* need to se parate */ ! q = concat(&slash.l, q); /* dir/name w ith slash */ q = concat(&foo, q); if (r == NULL) top = r = q; *************** *** 209,215 **** } do { SIZE_T slashcount; ! SIGCHK; for (slashcount = 0; *s == '/'; s++, m++) slashcount++; /* skip slashes */ while (*s != '/' && *s != '\0') --- 239,245 ---- } do { SIZE_T slashcount; ! sigchk(); for (slashcount = 0; *s == '/'; s++, m++) slashcount++; /* skip slashes */ while (*s != '/' && *s != '\0') *** /tmp/T0a19127 Sun Jan 9 14:45:40 1994 --- glom.c Fri Dec 10 20:20:31 1993 *************** *** 3,8 **** --- 3,9 ---- #include #include #include + #include #include "rc.h" #if !defined(S_IFIFO) && !defined(DEVFD) #define NOCMDARG *************** *** 68,78 **** } else { r->m = nalloc(z); if (s1->m == NULL) ! clear(r->m, x); else memcpy(r->m, s1->m, x); if (s2->m == NULL) ! clear(&r->m[x], y); else memcpy(&r->m[x], s2->m, y); r->m[z] = 0; --- 69,79 ---- } else { r->m = nalloc(z); if (s1->m == NULL) ! memzero(r->m, x); else memcpy(r->m, s1->m, x); if (s2->m == NULL) ! memzero(&r->m[x], y); else memcpy(&r->m[x], s2->m, y); r->m[z] = 0; *************** *** 183,189 **** char isifs[256]; int n, state; /* a simple FSA is used to read in data */ ! clear(isifs, sizeof isifs); for (isifs['\0'] = TRUE; ifs != NULL; ifs = ifs->n) for (s = ifs->w; *s != '\0'; s++) isifs[*(unsigned char *)s] = TRUE; --- 184,190 ---- char isifs[256]; int n, state; /* a simple FSA is used to read in data */ ! memzero(isifs, sizeof isifs); for (isifs['\0'] = TRUE; ifs != NULL; ifs = ifs->n) for (s = ifs->w; *s != '\0'; s++) isifs[*(unsigned char *)s] = TRUE; *************** *** 209,216 **** if ((n = rc_read(fd, end, remain)) <= 0) { if (n == 0) /* break */ break; ! uerror("backquote read"); ! rc_error(NULL); } remain -= n; for (bufend = &end[n]; end < bufend; end++) --- 210,221 ---- if ((n = rc_read(fd, end, remain)) <= 0) { if (n == 0) /* break */ break; ! else if (errno == EINTR) ! return NULL; /* interrupted, wait for subproc * / ! else { ! uerror("backquote read"); ! rc_error(NULL); ! } } remain -= n; for (bufend = &end[n]; end < bufend; end++) *************** *** 218,223 **** --- 223,229 ---- if (!isifs[*(unsigned char *)end]) { state = 1; r->w = end; + r->m = NULL; } } else { if (isifs[*(unsigned char *)end]) { *************** *** 252,258 **** rc_error(NULL); } if ((pid = rc_fork()) == 0) { - setsigdefaults(FALSE); mvfd(p[1], 1); close(p[0]); redirq = NULL; --- 258,263 ---- *************** *** 264,270 **** close(p[0]); rc_wait4(pid, &sp, TRUE); statprint(-1, sp); ! SIGCHK; return bq; } --- 269,276 ---- close(p[0]); rc_wait4(pid, &sp, TRUE); statprint(-1, sp); ! varassign("bqstatus", word(strstatus(sp), NULL), FALSE); ! sigchk(); return bq; } *** /tmp/T0a19127 Sun Jan 9 14:45:40 1994 --- hash.c Wed Dec 8 21:52:28 1993 *************** *** 279,293 **** return env; } ! extern void whatare_all_vars() { int i; List *s; ! for (i = 0; i < vsize; i++) ! if (vp[i].name != NULL && (s = varlookup(vp[i].name)) != NULL) ! prettyprint_var(1, vp[i].name, s); ! for (i = 0; i < fsize; i++) ! if (fp[i].name != NULL && fp[i].name != dead) ! prettyprint_fn(1, fp[i].name, fnlookup(fp[i].name)); } /* fake getenv() for readline() follows: */ --- 279,295 ---- return env; } ! extern void whatare_all_vars(bool showfn, bool showvar) { int i; List *s; ! if (showvar) ! for (i = 0; i < vsize; i++) ! if (vp[i].name != NULL && (s = varlookup(vp[i].name)) ! = NULL) ! prettyprint_var(1, vp[i].name, s); ! if (showfn) ! for (i = 0; i < fsize; i++) ! if (fp[i].name != NULL && fp[i].name != dead) ! prettyprint_fn(1, fp[i].name, fnlookup(fp[i].na me)); } /* fake getenv() for readline() follows: */ *** /tmp/T0a19127 Sun Jan 9 14:45:41 1994 --- input.c Sun Jan 9 13:51:20 1994 *************** *** 40,47 **** static SIZE_T istacksize, chars_out, chars_in; static bool eofread = FALSE, save_lineno = TRUE; static Input *istack, *itop; - static char *histstr; - static int histfd; static int (*realgchar)(void); static void (*realugchar)(int); --- 40,45 ---- *************** *** 49,59 **** int last; extern int gchar() { if (eofread) { eofread = FALSE; return last = EOF; } ! return (*realgchar)(); } extern void ugchar(int c) { --- 47,63 ---- int last; extern int gchar() { + int c; + if (eofread) { eofread = FALSE; return last = EOF; } ! ! while ((c = (*realgchar)()) == '\0') ! pr_error("warning: null character ignored"); ! ! return c; } extern void ugchar(int c) { *************** *** 99,105 **** slow = FALSE; if (r == NULL) errno = EINTR; ! SIGCHK; return r; } #else --- 103,109 ---- slow = FALSE; if (r == NULL) errno = EINTR; ! sigchk(); return r; } #else *************** *** 128,141 **** inbuf = ealloc(chars_in + 3); strcpy(inbuf+2, rlinebuf); strcat(inbuf+2, "\n"); } } else #endif { long /*ssize_t*/ r = rc_read(istack->fd, inbuf + 2, BUFSIZE); if (r < 0) { - if (errno == EINTR) - continue; /* Suppose it was int errupted by a signal */ uerror("read"); rc_exit(1); } --- 132,145 ---- inbuf = ealloc(chars_in + 3); strcpy(inbuf+2, rlinebuf); strcat(inbuf+2, "\n"); + efree(rlinebuf); } } else #endif { long /*ssize_t*/ r = rc_read(istack->fd, inbuf + 2, BUFSIZE); + sigchk(); if (r < 0) { uerror("read"); rc_exit(1); } *************** *** 214,220 **** efree(inbuf); --istack; realgchar = (istack->t == iString ? stringgchar : fdgchar); ! if (istack->fd == -1) { /* top of input stack */ realgchar = dead; realugchar = ugdead; } --- 218,224 ---- efree(inbuf); --istack; realgchar = (istack->t == iString ? stringgchar : fdgchar); ! if (istack->t == iFd && istack->fd == -1) { /* top of input stack */ realgchar = dead; realugchar = ugdead; } *************** *** 258,264 **** Edata block; block.b = newblock(); except(eArena, block, &e2); ! SIGCHK; if (dashell) { char *fname[3]; fname[1] = concat(varlookup("home"), word("/.rcrc", NUL L))->w; --- 262,268 ---- Edata block; block.b = newblock(); except(eArena, block, &e2); ! sigchk(); if (dashell) { char *fname[3]; fname[1] = concat(varlookup("home"), word("/.rcrc", NUL L))->w; *************** *** 314,360 **** return fun; } ! /* write last command out to a file. Check to see if $history has changed, al so */ static void history() { ! List *histlist; SIZE_T a; ! if (!interactive) return; ! if ((histlist = varlookup("history")) == NULL) { ! if (histstr != NULL) { ! efree(histstr); ! close(histfd); ! histstr = NULL; } - return; } - if (histstr == NULL || !streq(histstr, histlist->w)) { /* open new file */ - if (histstr != NULL) { - efree(histstr); - close(histfd); - } - histstr = ecpy(histlist->w); - histfd = rc_open(histstr, rAppend); - if (histfd < 0) { - uerror(histstr); - efree(histstr); - histstr = NULL; - varrm("history", FALSE); - } - } - /* - Small unix hack: since read() reads only up to a newline - from a terminal, then presumably this write() will write at - most only one input line at a time. - */ - for (a = 2; a < chars_in + 2; a++) { /* skip empty lines and comments i n history. */ - if (inbuf[a] == '#' || inbuf[a] == '\n') - return; - if (inbuf[a] != ' ' && inbuf[a] != '\t') - break; - } - writeall(histfd, inbuf + 2, chars_in); } /* close file descriptors after a fork() */ --- 318,353 ---- return fun; } ! /* write last command out to a file if interactive && $history is set */ static void history() { ! List *hist; SIZE_T a; ! ! if (!interactive || (hist = varlookup("history")) == NULL) return; ! ! for (a = 0; a < chars_in; a++) { ! char c = inbuf[a+2]; ! ! /* skip empty lines and comments */ ! if (c == '#' || c == '\n') ! break; ! ! /* line matches [ \t]*[^#\n] so it's ok to write out */ ! if (c != ' ' && c != '\t') { ! char *name = hist->w; ! int fd = rc_open(name, rAppend); ! if (fd < 0) { ! uerror(name); ! varrm(name, TRUE); ! } else { ! writeall(fd, inbuf + 2, chars_in); ! close(fd); ! } ! break; } } } /* close file descriptors after a fork() */ *************** *** 361,370 **** extern void closefds() { Input *i; - if (histstr != NULL) { /* Close an open history file * / - close(histfd); - histstr = NULL; /* But prevent re-closing of th e same file-descriptor */ - } for (i = istack; i != itop; --i) /* close open scripts */ if (i->t == iFd && i->fd > 2) { close(i->fd); --- 354,359 ---- *** /tmp/T0a19127 Sun Jan 9 14:45:42 1994 --- lex.c Wed Dec 8 21:52:29 1993 *************** *** 10,16 **** The lexical analyzer is fairly straightforward. The only really unclean part concerns backslash continuation and "double backslashes". A backslash followed by a newline is treated as a ! space, otherwise backslash is not a special characeter (i.e., it can be part of a word). This introduces a host of unwanted special cases. In our case, \ cannot be a word character, since we wish to read in all word characters in a tight loop. --- 10,16 ---- The lexical analyzer is fairly straightforward. The only really unclean part concerns backslash continuation and "double backslashes". A backslash followed by a newline is treated as a ! space, otherwise backslash is not a special character (i.e., it can be part of a word). This introduces a host of unwanted special cases. In our case, \ cannot be a word character, since we wish to read in all word characters in a tight loop. *************** *** 155,163 **** w = KW; } switch (c) { - case '\0': - pr_error("warning: null character ignored"); - goto top; case '!': return BANG; case '@': --- 155,160 ---- *** /tmp/T0a19127 Sun Jan 9 14:45:43 1994 --- main.c Wed Dec 8 21:52:28 1993 *************** *** 3,9 **** #include "rc.h" bool dashdee, dashee, dashvee, dashex, dashell, dasheye, ! dashen, dashpee, interactive; int rc_pid; static bool dashoh; --- 3,9 ---- #include "rc.h" bool dashdee, dashee, dashvee, dashex, dashell, dasheye, ! dashen, dashpee, dashess, interactive; int rc_pid; static bool dashoh; *************** *** 19,25 **** dollarzero = argv[0]; rc_pid = getpid(); dashell = (*argv[0] == '-'); /* Unix tradition */ ! while ((c = rc_getopt(argc, argv, "nolpeivdxc:")) != -1) switch (c) { case 'l': dashell = TRUE; --- 19,25 ---- dollarzero = argv[0]; rc_pid = getpid(); dashell = (*argv[0] == '-'); /* Unix tradition */ ! while ((c = rc_getopt(argc, argv, "nolpeivdxsc:")) != -1) switch (c) { case 'l': dashell = TRUE; *************** *** 39,44 **** --- 39,47 ---- case 'd': dashdee = TRUE; break; + case 's': + dashess = dasheye = interactive = TRUE; + break; case 'c': dashsee[0] = rc_optarg; goto quitopts; *************** *** 56,63 **** } quitopts: argv += rc_optind; ! /* use isatty() iff -i is not set, and iff the input is not from a scri pt or -c flag */ ! if (!dasheye && dashsee[0] == NULL && *argv == NULL) interactive = isatty(0); if (!dashoh) { checkfd(0, rFrom); --- 59,66 ---- } quitopts: argv += rc_optind; ! /* use isatty() iff -i is not set, and iff the input is not from a scri pt or -c or -s flags */ ! if (!dasheye && !dashess && dashsee[0] == NULL && *argv == NULL) interactive = isatty(0); if (!dashoh) { checkfd(0, rFrom); *************** *** 78,87 **** null[0] = NULL; starassign(dollarzero, null, FALSE); /* assign $0 to $* */ inithandler(); ! if (dashsee[0] != NULL) { /* input from the -c flag? */ if (*argv != NULL) starassign(dollarzero, argv, FALSE); ! pushstring(dashsee, TRUE); } else if (*argv != NULL) { /* else from a file? */ b_dot(--argv); rc_exit(getstatus()); --- 81,93 ---- null[0] = NULL; starassign(dollarzero, null, FALSE); /* assign $0 to $* */ inithandler(); ! if (dashsee[0] != NULL || dashess) { /* input from -c or -s? */ if (*argv != NULL) starassign(dollarzero, argv, FALSE); ! if (dashess) ! pushfd(0); ! else ! pushstring(dashsee, TRUE); } else if (*argv != NULL) { /* else from a file? */ b_dot(--argv); rc_exit(getstatus()); *** /tmp/T0a19127 Sun Jan 9 14:45:44 1994 --- nalloc.c Wed Dec 8 21:52:28 1993 *************** *** 122,127 **** --- 122,129 ---- extern void *erealloc(void *p, SIZE_T n) { extern void *realloc(void *, SIZE_T); + if (p == NULL) /* convenience feature */ + return ealloc(n); if ((p = realloc(p, n)) == NULL) { uerror("realloc"); rc_exit(1); *** /tmp/T0a19127 Sun Jan 9 14:45:45 1994 --- print.c Wed Dec 8 21:52:29 1993 *************** *** 270,278 **** extern int fmtprint(Format *format, const char *fmt,...) { int n = -format->flushed; ! va_list saveargs = format->args; ! va_start(format->args, fmt); n += printfmt(format, fmt); va_end(format->args); format->args = saveargs; --- 270,280 ---- extern int fmtprint(Format *format, const char *fmt,...) { int n = -format->flushed; ! va_list ap, saveargs; ! va_start(ap, fmt); ! saveargs = format->args; ! format->args = ap; n += printfmt(format, fmt); va_end(format->args); format->args = saveargs; *************** *** 292,297 **** --- 294,300 ---- extern int fprint(int fd, const char *fmt,...) { char buf[1024]; Format format; + va_list ap; format.buf = buf; format.bufbegin = buf; *************** *** 300,306 **** format.flushed = 0; format.u.n = fd; ! va_start(format.args, fmt); printfmt(&format, fmt); va_end(format.args); --- 303,310 ---- format.flushed = 0; format.u.n = fd; ! va_start(ap, fmt); ! format.args = ap; printfmt(&format, fmt); va_end(format.args); *************** *** 340,347 **** extern char *mprint(const char *fmt,...) { Format format; char *result; format.u.n = 1; ! va_start(format.args, fmt); result = memprint(&format, fmt, ealloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); return result; --- 344,354 ---- extern char *mprint(const char *fmt,...) { Format format; char *result; + va_list ap; + format.u.n = 1; ! va_start(ap, fmt); ! format.args = ap; result = memprint(&format, fmt, ealloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); return result; *************** *** 350,357 **** extern char *nprint(const char *fmt,...) { Format format; char *result; format.u.n = 0; ! va_start(format.args, fmt); result = memprint(&format, fmt, nalloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); return result; --- 357,367 ---- extern char *nprint(const char *fmt,...) { Format format; char *result; + va_list ap; + format.u.n = 0; ! va_start(ap, fmt); ! format.args = ap; result = memprint(&format, fmt, nalloc(PRINT_ALLOCSIZE), PRINT_ALLOCSIZ E); va_end(format.args); return result; *** /tmp/T0a19127 Sun Jan 9 14:45:45 1994 --- proto.h Wed Dec 8 21:52:27 1993 *************** *** 47,52 **** --- 47,53 ---- extern char *strcat(char *, const char *); extern char *strncat(char *, const char *, SIZE_T); extern void *memcpy(void *, const void *, SIZE_T); + extern void *memset(void *, int, SIZE_T); /* fake unistd.h */ *** /tmp/T0a19127 Sun Jan 9 14:45:45 1994 --- rc.1 Wed Dec 8 21:52:28 1993 *************** *** 490,495 **** --- 490,496 ---- .Ds .Cr $variable^follow .De + .PP To include a literal .Cr $ in a here document when an unquoted end-of-file marker is being used, *************** *** 683,690 **** .Cr "command || command" .De .PP ! executes the first command executing the second command if and only if ! the second command exits with a nonzero exit status (``false'' in Unix). .Ds .Cr "! command" .De --- 684,691 ---- .Cr "command || command" .De .PP ! executes the first command and then executes the second command if and only i f ! the first command exits with a nonzero exit status (``false'' in Unix). .Ds .Cr "! command" .De *************** *** 1625,1631 **** .I pid is specified, .I rc ! waits for any child process to exit. .TP \fBwhatis \fR[\fB\-s\fR] [\fB\-\|\-\fR] [\fIname ...\fR] Prints a definition of the named objects. --- 1626,1632 ---- .I pid is specified, .I rc ! waits for all child processes to exit. .TP \fBwhatis \fR[\fB\-s\fR] [\fB\-\|\-\fR] [\fIname ...\fR] Prints a definition of the named objects. *** /tmp/T0a19127 Sun Jan 9 14:45:46 1994 --- rc.h Fri Dec 10 20:26:11 1993 *************** *** 150,155 **** --- 150,156 ---- #define a2u(x) n2u(x, 10) #define o2u(x) n2u(x, 8) #define arraysize(a) ((int)(sizeof(a)/sizeof(*a))) + #define memzero(s, n) memset(s, 0, n) #define enew(x) ((x *) ealloc(sizeof(x))) #define ecpy(x) strcpy((char *) ealloc(strlen(x) + 1), x) #define lookup_fn(s) ((Function *) lookup(s, fp)) *************** *** 192,199 **** extern void doredirs(void); /* footobar.c */ - extern char *fun2str(char *, Node *); - extern char *list2str(char *, List *); extern char **list2array(List *, bool); extern char *get_name(char *); extern List *parse_var(char *, char *); --- 193,198 ---- *************** *** 245,251 **** extern void inithandler(void); extern void varassign(char *, List *, bool); extern void varrm(char *, bool); ! extern void whatare_all_vars(void); extern void whatare_all_signals(void); extern void prettyprint_var(int, char *, List *); extern void prettyprint_fn(int, char *, Node *); --- 244,250 ---- extern void inithandler(void); extern void varassign(char *, List *, bool); extern void varrm(char *, bool); ! extern void whatare_all_vars(bool, bool); extern void whatare_all_signals(void); extern void prettyprint_var(int, char *, List *); extern void prettyprint_fn(int, char *, Node *); *************** *** 338,344 **** extern void (*rc_signal(int, void (*)(int)))(int); extern void (*sighandlers[])(int); extern volatile SIG_ATOMIC_T slow, interrupt_happened; - #define SIGCHK sigchk() /* status.c */ extern int istrue(void); --- 337,342 ---- *************** *** 349,354 **** --- 347,353 ---- extern void setpipestatus(int [], int); extern void statprint(int, int); extern void ssetstatus(char **); + extern char *strstatus(int s); /* tree.c */ extern Node *mk(int /*nodetype*/,...); *************** *** 362,368 **** extern int mvfd(int, int); extern int starstrcmp(const void *, const void *); extern void pr_error(char *); - extern char *clear(char *, SIZE_T); extern void panic(char *); extern void uerror(char *); extern void writeall(int, char *, SIZE_T); --- 361,366 ---- *** /tmp/T0a19127 Sun Jan 9 14:45:47 1994 --- signal.c Wed Dec 8 21:52:29 1993 *************** *** 13,20 **** static volatile SIG_ATOMIC_T sigcount, caught[NUMOFSIGNALS]; extern void catcher(int s) { - if (forked) - exit(1); /* exit unconditionally on a signal in a child process */ if (caught[s] == 0) { sigcount++; caught[s] = 1; --- 13,18 ---- *************** *** 52,58 **** extern void (*rc_signal(int s, void (*h)(int)))(int) { void (*old)(int); ! SIGCHK; old = sighandlers[s]; if (h == SIG_DFL || h == SIG_IGN) { signal(s, h); --- 50,56 ---- extern void (*rc_signal(int s, void (*h)(int)))(int) { void (*old)(int); ! sigchk(); old = sighandlers[s]; if (h == SIG_DFL || h == SIG_IGN) { signal(s, h); *** /tmp/T0a19127 Sun Jan 9 14:45:47 1994 --- status.c Wed Dec 8 21:52:28 1993 *************** *** 80,104 **** /* prepare a list to be passed back. Used whenever $status is dereferenced */ extern List *sgetstatus() { ! List *r; int i; ! for (r = NULL, i = 0; i < pipelength; i++) { List *q = nnew(List); ! int s = statuses[i]; ! int t; q->n = r; r = q; - if ((t = s & 0x7f) != 0) { - const char *core = (s & 0x80) ? "+core" : ""; - if (t < NUMOFSIGNALS && *signals[t].name != '\0') - r->w = nprint("%s%s", signals[t].name, core); - else - r->w = nprint("-%d%s", t, core); /* unknown sig nals are negated */ - } else - r->w = nprint("%d", (s >> 8) & 0xff); - r->m = NULL; } return r; } extern void ssetstatus(char **av) { --- 80,112 ---- /* prepare a list to be passed back. Used whenever $status is dereferenced */ extern List *sgetstatus() { ! List *r = NULL; int i; ! ! for (i = 0; i < pipelength; i++) { List *q = nnew(List); ! q->w = strstatus(statuses[i]); ! q->m = NULL; q->n = r; r = q; } + return r; + } + + /* return status as a string (used above and for bqstatus) */ + + extern char *strstatus(int s) { + int t = s & 0x7f; + + if (t != 0) { + const char *core = (s & 0x80) ? "+core" : ""; + if (t < NUMOFSIGNALS && *signals[t].name != '\0') + return nprint("%s%s", signals[t].name, core); + else + return nprint("-%d%s", t, core); /* unknown signals are negated */ + } else + return nprint("%d", (s >> 8) & 0xff); } extern void ssetstatus(char **av) { *** /tmp/T0a19127 Sun Jan 9 14:45:48 1994 --- utils.c Wed Dec 8 23:56:04 1993 *************** *** 82,88 **** slow = FALSE; } slow = FALSE; ! SIGCHK; } extern int rc_read(int fd, char *buf, SIZE_T n) { --- 82,88 ---- slow = FALSE; } slow = FALSE; ! sigchk(); } extern int rc_read(int fd, char *buf, SIZE_T n) { *************** *** 101,116 **** errno = EINTR; r = -1; } - SIGCHK; return r; - } - - /* clear out z bytes from character string s */ - - extern char *clear(char *s, SIZE_T z) { - while (z != 0) - s[--z] = 0; - return s; } /* duplicate a fd and close the old one only if necessary */ --- 101,107 ---- *** /tmp/T0a19127 Sun Jan 9 14:45:49 1994 --- var.c Wed Dec 8 21:52:27 1993 *************** *** 104,110 **** return look->extdef; if (look->def == NULL) return NULL; ! return look->extdef = list2str(name, look->def); } /* remove a variable from the symtab. "stack" determines whether a level of s coping is popped or not */ --- 104,110 ---- return look->extdef; if (look->def == NULL) return NULL; ! return look->extdef = mprint("%F=%-L", name, look->def, "\001"); } /* remove a variable from the symtab. "stack" determines whether a level of s coping is popped or not */ *************** *** 166,181 **** return; } v = def->w; ! r = val = enew(List); while ((w = strchr(v, ':')) != NULL) { *w = '\0'; ! r->w = ecpy(v); *w = ':'; v = w + 1; ! r->n = enew(List); ! r = r->n; } ! r->w = ecpy(v); r->n = NULL; varassign(name, val, stack); } --- 166,180 ---- return; } v = def->w; ! r = val = nnew(List); while ((w = strchr(v, ':')) != NULL) { *w = '\0'; ! r->w = ncpy(v); *w = ':'; v = w + 1; ! r = r->n = nnew(List); } ! r->w = ncpy(v); r->n = NULL; varassign(name, val, stack); } *** /tmp/T0a19127 Sun Jan 9 14:45:49 1994 --- version.c Wed Dec 8 23:02:38 1993 *************** *** 1 **** ! const char id[] = "@(#)rc version 1.4, 5/26/92."; --- 1 ---- ! const char id[] = "@(#)rc version 1.5betadev-1, 1/9/94."; *** /tmp/T0a19127 Sun Jan 9 14:45:49 1994 --- wait.c Wed Dec 8 21:52:29 1993 *************** *** 16,22 **** } *plist = NULL; extern int rc_fork() { ! Pid *new = enew(Pid); int pid = fork(); switch (pid) { case -1: --- 16,22 ---- } *plist = NULL; extern int rc_fork() { ! Pid *new; int pid = fork(); switch (pid) { case -1: *************** *** 25,33 **** /* NOTREACHED */ case 0: forked = TRUE; ! SIGCHK; return 0; default: new->pid = pid; new->alive = TRUE; new->n = plist; --- 25,34 ---- /* NOTREACHED */ case 0: forked = TRUE; ! sigchk(); return 0; default: + new = enew(Pid); new->pid = pid; new->alive = TRUE; new->n = plist; *************** *** 98,104 **** setstatus(pid, stat); else set(FALSE); ! SIGCHK; } } --- 99,105 ---- setstatus(pid, stat); else set(FALSE); ! sigchk(); } } *** /tmp/T0a19127 Sun Jan 9 14:45:49 1994 --- walk.c Wed Dec 8 21:52:29 1993 *************** *** 11,16 **** --- 11,17 ---- */ bool cond = FALSE; + static bool haspreredir(Node *); static bool isallpre(Node *); static bool dofork(bool); static void dopipe(Node *); *************** *** 22,28 **** /* walk the parse-tree. "obvious". */ extern bool walk(Node *n, bool parent) { ! top: SIGCHK; if (n == NULL) { if (!parent) exit(0); --- 23,29 ---- /* walk the parse-tree. "obvious". */ extern bool walk(Node *n, bool parent) { ! top: sigchk(); if (n == NULL) { if (!parent) exit(0); *************** *** 147,153 **** } case nSubshell: if (dofork(TRUE)) { - setsigdefaults(FALSE); walk(n->u[0].p, FALSE); rc_exit(getstatus()); } --- 148,153 ---- *************** *** 214,221 **** case nPre: { List *v; if (n->u[0].p->type == nRedir || n->u[0].p->type == nDup) { qredir(n->u[0].p); ! walk(n->u[1].p, parent); } else if (n->u[0].p->type == nAssign) { if (isallpre(n->u[1].p)) { walk(n->u[0].p, TRUE); --- 214,227 ---- case nPre: { List *v; if (n->u[0].p->type == nRedir || n->u[0].p->type == nDup) { + if (redirq == NULL && !dofork(parent)) /* subshell on f irst preredir */ + break; qredir(n->u[0].p); ! if (!haspreredir(n->u[1].p)) ! doredirs(); /* no more preredirs, empty queue * / ! walk(n->u[1].p, FALSE); ! rc_exit(getstatus()); ! /* NOTREACHED */ } else if (n->u[0].p->type == nAssign) { if (isallpre(n->u[1].p)) { walk(n->u[0].p, TRUE); *************** *** 239,245 **** if (n->u[1].p == NULL) { WALK(n->u[0].p, parent); } else if (dofork(parent)) { - setsigdefaults(FALSE); walk(n->u[1].p, TRUE); /* Do redirections */ redirq = NULL; /* Reset redirection queue */ walk(n->u[0].p, FALSE); /* Do commands */ --- 245,250 ---- *************** *** 265,270 **** --- 270,286 ---- return istrue(); } + /* checks to see whether there are any pre-redirections left in the tree */ + + static bool haspreredir(Node *n) { + while (n != NULL && n->type == nPre) { + if (n->u[0].p->type == nDup || n->u[0].p->type == nRedir) + return TRUE; + n = n->u[1].p; + } + return FALSE; + } + /* checks to see whether a subtree is all pre-command directives, i.e., assig nments and redirs only */ static bool isallpre(Node *n) { *************** *** 286,292 **** redirq = NULL; /* clear out the pre-redirection queue in the parent */ rc_wait4(pid, &sp, TRUE); setstatus(-1, sp); ! SIGCHK; return FALSE; } --- 302,308 ---- redirq = NULL; /* clear out the pre-redirection queue in the parent */ rc_wait4(pid, &sp, TRUE); setstatus(-1, sp); ! sigchk(); return FALSE; } *************** *** 304,310 **** rc_error(NULL); } if ((pid = rc_fork()) == 0) { - setsigdefaults(FALSE); redirq = NULL; /* clear preredir queue */ mvfd(p[0], r->u[1].i); if (fd_prev != 1) --- 320,325 ---- *************** *** 321,327 **** close(p[0]); } if ((pid = rc_fork()) == 0) { - setsigdefaults(FALSE); mvfd(fd_prev, fd_out); walk(r, FALSE); exit(getstatus()); --- 336,341 ---- *************** *** 340,344 **** intr |= (sp == SIGINT); } setpipestatus(stats, i); ! SIGCHK; } --- 354,358 ---- intr |= (sp == SIGINT); } setpipestatus(stats, i); ! sigchk(); } From rc-owner Mon Jan 10 13:16:05 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24072>; Mon, 10 Jan 1994 13:15:26 -0500 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04656; Mon, 10 Jan 94 13:15:04 -0500 Received: from srg.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 131359.5286; Mon, 10 Jan 1994 13:13:59 EST Received: from ceres.srg.af.mil by srg.srg.af.mil id aa27074; Mon, 10 Jan 94 12:50:25 EST From: culliton@srg.srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: byron@netapp.com, rc@hawkwind.utcs.toronto.edu Subject: Re: rc patches halfway to 1.5 Date: Mon, 10 Jan 1994 12:50:23 -0500 Message-Id: <9401101250.aa01315@ceres.srg.af.mil> Just quickly looking these patches over it looks like there are a couple of things that slipped by. 1) In main.c -s implies -i, memory says the consensus was that this isn't right. 2) Some of the fixes for correct readline handling are missing. Tom From rc-owner Wed Jan 19 03:54:20 1994 Received: from mail.swip.net ([192.71.220.11]) by hawkwind.utcs.toronto.edu wit h SMTP id <24092>; Wed, 19 Jan 1994 03:52:28 -0500 Received: from localhost by mail.swip.net (8.6.4/2.01) id JAA07655; Wed, 19 Jan 1994 09:52:14 +0100 Received: from dragos.UUCP by enea.se (4.1/SMI-4.0) id AA05722; Wed, 19 Jan 94 08:30:16 +0100 Received: from dragos.UUCP by pallas.enea.se (4.1/SMI-4.0) id AA12527; Wed, 19 Jan 94 08:25:54 +0100 Received: from dragos.UUCP by walker. (4.1/SMI-4.1) id AA26877; Wed, 19 Jan 94 08:31:06 +0100 Received: by ose.enea.se (4.1/SMI-4.1) id AA29324; Wed, 19 Jan 94 08:25:46 +0100 Date: Wed, 19 Jan 1994 02:25:46 -0500 From: bekl@ose.enea.se (Bengt Kleberg) Message-Id: <9401190725.AA29324@ose.enea.se> To: rc@hawkwind.utcs.toronto.edu Subject: rc and 9term on Sunos4.1.x Greetings, Is there anybody that uses rc with 9term on Sunos 4.1.X (9term from matty@cs.su.oz.au (James Matthew Farrow))? When I try to start rc directly (9term -e rc) I get no echo of what I type and I need to press 4 times to get 4 prompts. They are all on one line, like this ; ; ; ; . If I type a short command, say ls, I only need to type 2 's to get output , followed by 2 prompts. Long comands makes 4 once. The standard shell here, tcsh, almost works. It gives an extra after each line, but otherwise fine. It echo'es and only needs one touch. If I start rc from tcsh rc works too. In fact it is even better then tcsh since the extra character is gone. As I said in the beginning, this is only for 9term/rc users on Sunos 4.1.X. Anybody out there? More minds are better then one. Bengt From rc-owner Thu Feb 3 02:21:08 1994 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.toronto.ed u with SMTP id <24121>; Thu, 3 Feb 1994 02:20:04 -0500 Received: from localhost by groucho.cse.psu.edu with SMTP id <3005>; Thu, 3 Feb 1994 02:19:46 -0500 To: rc@hawkwind.utcs.toronto.edu Subject: - vs " Date: Thu, 3 Feb 1994 02:19:39 -0500 From: Scott Schwartz Message-Id: <94Feb3.021946est.3005@groucho.cse.psu.edu> You know, it's kind of odd to use ``-'' as the name of the history program when ``"'' is a common symbol for ``ditto''. From rc-owner Thu Feb 3 03:56:36 1994 Received: from netcomsv.netcom.com ([163.179.1.8]) by hawkwind.utcs.toronto.edu with SMTP id <24122>; Thu, 3 Feb 1994 03:56:12 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id AAA18359; Thu, 3 Feb 1994 00:47:37 -0800 Received: by netapp.com (4.1/SMI-4.1) id AA12382; Thu, 3 Feb 94 00:03:58 PST Date: Thu, 3 Feb 1994 03:03:58 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9402030803.AA12382@netapp.com> To: rc@hawkwind.utcs.toronto.edu, schwartz@groucho.cse.psu.edu Subject: Re: - vs " "-" doesn't require SHIFT. I think the labs folks use ":" for rc instead of "=", but that requires using the shift key. Go figure. Of course you are free to name the program whatever you want... From rc-owner Thu Feb 3 13:03:57 1994 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.toronto.ed u with SMTP id <24124>; Thu, 3 Feb 1994 13:02:49 -0500 Received: from localhost by groucho.cse.psu.edu with SMTP id <3005>; Thu, 3 Feb 1994 13:01:53 -0500 To: byron@netapp.com (Byron Rakitzis) cc: rc@hawkwind.utcs.toronto.edu Subject: Re: - vs " In-reply-to: Your message of "Thu, 03 Feb 1994 03:03:58 EST." <9402030803.AA12382@netapp.com> X-Face: /:c""]'pLDG"M1[[aEFnkj?8sKTY0V4gnpT.D;CY]!sUJ*+uJ02!OX?zLxM_cn`#G`H,|2L \?RsN=DhXG9*!ZMr#.S=c>[ Message-Id: <94Feb3.130153est.3005@groucho.cse.psu.edu> I know I could change it, but that would be nonconformist. :-) Colon is plausible by analogy with the bourne shell colon, I suppose. And anyone who uses emacs is conditioned to accept bucky bits, so shift is less problematic. :-) From rc-owner Sun Feb 6 19:00:12 1994 Received: from quux.es.su.oz.au ([129.78.145.8]) by hawkwind.utcs.toronto.edu w ith SMTP id <24129>; Sun, 6 Feb 1994 18:57:54 -0500 Received: by quux.es.su.oz.au id <313>; Mon, 7 Feb 1994 10:57:38 +1100 From: Noel Hunt Date: Sun, 6 Feb 1994 18:47:25 -0500 to: Rc List Subject: rc -c cmd hangs in SunOS5.3 Message-ID: <199402071047.20601.rc.babef@es.su.oz.au> i have build rc on a sparc10, sunos5.3 and i have noticed that when i rsh from another machine to the sparc (where rc is my login shell), the `rc -c cmd' forked by in.rshd hangs on the sparc, in a cpu loop and the rsh command on the other machine doesn't return. any suggestions? From rc-owner Mon Mar 7 14:06:38 1994 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <24153>; Mon , 7 Mar 1994 14:01:48 -0500 To: rc Subject: /pub/rc/rc-1.5betadev-1.tar.gz now on ftp.sys.utoronto.ca Date: Mon, 7 Mar 1994 14:01:33 -0500 From: Chris Siebenmann Message-Id: <94Mar7.140148est.24153@hawkwind.utcs.toronto.edu> After a long delay, I've made a gzipped tarfile of 1.4 + Byron's rc 1.5 betadev-1 patches and put it on ftp.sys.utoronto.ca for your ftp'ing pleasure. - cks From rc-owner Mon Mar 7 14:48:09 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24167>; Mon, 7 Mar 1994 14:47:21 -0500 Received: from uucp2.uu.net by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwgfv12929; Mon, 7 Mar 94 14:46:44 -0 500 Received: from srg.UUCP by uucp2.uu.net with UUCP/RMAIL ; Mon, 7 Mar 1994 14:46:48 -0500 Received: from ceres.srg.af.mil by srg.srg.af.mil id aa28423; Mon, 7 Mar 94 14:40:06 EST From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: /pub/rc/rc-1.5betadev-1.tar.gz now on ftp.sys.utoronto.ca Date: Mon, 7 Mar 1994 14:40:00 -0500 Message-Id: <9403071440.aa07845@ceres.srg.af.mil> I forwarded these patches for the readline support to Byron two months ago but never heard back. (Possibly an email glitch, or merely that Byron fell (or was pushed) off the face of the planet again ;-) ) If you link in readline without these patches, 1) readline doesn't handle certain signals (e.g. SIGINT) gracefully, 2) trip.rc will fail to complete successfully. From culliton Wed Jan 12 16:36:18 1994 From: culliton@srg.af.mil (Tom Culliton x2278) To: byron@ghoti.netapp.com Subject: Re: rc patches halfway to 1.5 Date: Wed, 12 Jan 94 16:36:18 EST Status: RO > Hm. I don't know about (1), I will have to look through my mail. > With regard to (2), could you please let me know which patches > are missing so I could put them in? Sorry this took so long, too many balls in the air and something tends to get dropped, as you probably know. Here's at least one patch that was missing. Without the patch and with readline linked in trip will fail when it checks prompting. Tom *** input.c~ Mon Jan 10 11:37:57 1994 --- input.c Wed Jan 12 16:18:30 1994 *************** *** 121,127 **** while (1) { #ifdef READLINE if (interactive && istack->fd == 0) { ! rlinebuf = readline(prompt); if (rlinebuf == NULL) { chars_in = 0; } else { --- 121,127 ---- while (1) { #ifdef READLINE if (interactive && istack->fd == 0) { ! rlinebuf = rc_readline(prompt); if (rlinebuf == NULL) { chars_in = 0; } else { *************** *** 279,288 **** } if ((s = varlookup("prompt")) != NULL) { #ifdef READLINE ! prompt = s->w; ! #else ! fprint(2, "%s", s->w); #endif prompt2 = (s->n == NULL ? "" : s->n->w) ; } } --- 279,289 ---- } if ((s = varlookup("prompt")) != NULL) { #ifdef READLINE ! if (istack->fd == 0) ! prompt = s->w; ! else #endif + fprint(2, "%s", s->w); prompt2 = (s->n == NULL ? "" : s->n->w) ; } } *************** *** 302,307 **** --- 303,321 ---- unexcept(); /* eError */ return parsetree; } + + extern void print_prompt2() { + lineno++; + if (interactive) + { + #ifdef READLINE + if (istack->fd == 0) + prompt = prompt2; + else + #endif + fprint(2, "%s", prompt2); + } + } /* parse a function imported from the environment */ *** lex.c~ Mon Jan 10 11:37:58 1994 --- lex.c Wed Jan 12 16:18:19 1994 *************** *** 336,351 **** realbuf = ealloc(bufsize); } - extern void print_prompt2() { - lineno++; - #ifdef READLINE - prompt = prompt2; - #else - if (interactive) - fprint(2, "%s", prompt2); - #endif - } - /* Scan in a pair of integers for redirections like >[2=1]. CLOSED re presents a closed file descriptor (i.e., >[2=]) and UNSET represents an undesignated file descriptor (e.g., --- 336,341 ---- From rc-owner Mon Mar 14 15:43:31 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24169>; Mon, 14 Mar 1994 15:40:31 -0500 Received: from uucp3.uu.net (via uucp3-le1.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhfu12975; Mon, 14 Mar 94 15:40:10 - 0500 Received: from srg.UUCP by uucp3.uu.net with UUCP/RMAIL ; Mon, 14 Mar 1994 15:40:10 -0500 Received: from ceres.srg.af.mil by srg.srg.af.mil id aa01443; Mon, 14 Mar 94 15:16:17 EST From: culliton@srg.srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Signal weirdness Date: Mon, 14 Mar 1994 15:17:05 -0500 Message-Id: <9403141517.aa11662@ceres.srg.af.mil> I just got a nasty suprise with signal handlers. While trying to test: fn sigwinch {eval `{/usr/bin/X11/resize}} I discovered that rc (1.5beta1 with GNU readline linked in, under SunOs (4.1.3) and SCO-ODT (1.1 and 3.0)) dies after running the handler for a signal that isn't ignored. For example setting the following: fn sighup {echo 'got sighup';sleep 10} and then sending the shell a sighup (kill -1 11532) from another window causes it to print the message, wait, and the shell to exit. If the signal handler ends with a return command you get an error message but the shell doesn't die. This is really ugly, anyone have a clue? I'd test this without readline and even dig through code if work wasn't so piled up on my desk. Maybe in a week or so. In the mean time, can anyone else verify this? Tom From rc-owner Mon Mar 14 15:53:37 1994 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <24170>; Mon , 14 Mar 1994 15:53:05 -0500 To: rc Subject: Re: Signal weirdness In-reply-to: culliton's message of Mon, 14 Mar 1994 15:17:05 -0500. <9403141517.aa11662@ceres.srg.af.mil> Date: Mon, 14 Mar 1994 15:52:52 -0500 From: Chris Siebenmann Message-Id: <94Mar14.155305est.24170@hawkwind.utcs.toronto.edu> When I try this on a rc 1.5 betadev-1 without readline, I get a 'read: Interrupted system call' error and rc exits. - cks From rc-owner Mon Mar 14 17:07:05 1994 Received: from netcomsv.netcom.com ([163.179.3.2]) by hawkwind.utcs.toronto.edu with SMTP id <24169>; Mon, 14 Mar 1994 17:06:11 -0500 Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id NAA06451; Mon, 14 Mar 1994 13:53:34 -0800 Received: from ghoti.netapp.com by netapp.com (4.1/SMI-4.1) id AA27940; Mon, 14 Mar 94 13:47:05 PST Received: by ghoti.netapp.com (4.1/SMI-4.1) id AA08042; Mon, 14 Mar 94 13:46:44 PST Date: Mon, 14 Mar 1994 16:46:44 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9403142146.AA08042@ghoti.netapp.com> To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Signal weirdness Aigh. I will take a look at this. Thanks for letting me know. From rc-owner Mon Mar 14 18:41:05 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24170>; Mon, 14 Mar 1994 18:40:13 -0500 Received: from uucp6.UU.NET by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhgg05866; Mon, 14 Mar 94 18:40:06 - 0500 Received: from srg.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 14 Mar 1994 18:40:10 -0500 Received: from ceres.srg.af.mil by srg.srg.af.mil id aa04967; Mon, 14 Mar 94 18:12:42 EST From: culliton@srg.srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: byron@netapp.com, cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: Signal weirdness Date: Mon, 14 Mar 1994 18:13:23 -0500 Message-Id: <9403141813.aa13127@ceres.srg.af.mil> I just did some more testing, and the signal problem occurs in: - 1.5beta1 with and without readline with and without SVSIGS defined - patched versions of 1.4 BUT not in vanilla 1.4! It looks like the question is, "what's changed in the signal handling from 1.4 to 1.5beta1?" Tom From rc-owner Mon Mar 14 19:17:13 1994 Received: from trout.nosc.mil ([128.49.16.7]) by hawkwind.utcs.toronto.edu with SMTP id <24173>; Mon, 14 Mar 1994 19:16:40 -0500 Received: from Np.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA02548; Mon, 14 Mar 94 16:16:24 PST Received: by Np.nosc.mil (4.1/SMI-4.1) id AA00697; Mon, 14 Mar 94 16:12:20 PST Date: Mon, 14 Mar 1994 19:12:20 -0500 From: broman@Np.nosc.mil (Vincent Broman) Message-Id: <9403150012.AA00697@Np.nosc.mil> To: culliton@srg.srg.af.mil Cc: rc@hawkwind.utcs.toronto.edu In-Reply-To: <9403141813.aa13127@ceres.srg.af.mil> (culliton@srg.srg.af.mil) Subject: Re: Signal weirdness Reply-To: broman@nosc.mil I get the symptom you describe with my rc1.4 + readline on sunos4.1.3 . Vincent Broman, code 572 Bayside Phone: +1 619 553 1641 Naval Command Control and Ocean Surveillance Center, RDT&E Div. San Diego, CA 92152-6147, USA Email: broman@nosc.mil From rc-owner Tue Mar 15 03:56:26 1994 Received: from techfac.TechFak.Uni-Bielefeld.DE ([129.70.132.100]) by hawkwind. utcs.toronto.edu with SMTP id <24173>; Tue, 15 Mar 1994 03:52:33 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA27986; Tue, 15 Mar 1994 09:52: 07 +0100 Received: by dahlie.techfak.uni-bielefeld.de (5.0/tp.29.0890) id AA05571; Tue, 15 Mar 1994 09:52:04 --100 Date: Tue, 15 Mar 1994 05:52:04 -0500 From: malte@TechFak.Uni-Bielefeld.DE Message-Id: <9403150852.AA05571@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Signal weirdness Content-Length: 490 I just tried your example on Solaris 2.3 and found a different though still wrong behaviour: fn sighup { echo 'caught sighup'; sleep 10 } rc-1.5b1 + readline from bash-1.13.1 The signal gets caught but the handler is not executed until is pressed. The shell keeps running. rc-1.5b1 without readline Signal gets caught, the handler executed but then the shell exits with exit code 1 and "read: Interrupted system call" message. rc-1.4 without readline works fine. Malte From rc-owner Tue Mar 15 10:18:31 1994 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <24177>; Tue, 15 Mar 1994 10:16:43 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA16450; Tue, 15 Mar 1994 09:15:24 -0600 Message-Id: <9403151515.AA16450@oldp.astro.wisc.edu> To: rc@hawkwind.utcs.toronto.edu Subject: Re: Signal weirdness Date: Tue, 15 Mar 1994 10:15:23 -0500 From: Alan Watson X-Mts: smtp My patched version of v1.4 without readline does NOT display this bug under any of Ultrix v4.3, OSF/1 v1.3, or IRIX v5.1.1.1. Alan. From rc-owner Tue Mar 22 10:28:42 1994 Received: from bnr.ca ([192.58.194.73]) by hawkwind.utcs.toronto.edu with SMTP id <24184>; Tue, 22 Mar 1994 10:26:02 -0500 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 22 Mar 199 4 10:06:21 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 22 Mar 1994 10:04:35 -05 00 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 22 Mar 1994 05:04:00 -05 00 Date: Tue, 22 Mar 1994 05:04:00 -0500 X400-Originator: /dd.id=1581776/g=jeff/i=jd/s=sparkes/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.535:22.02.94.15.04.35] X400-Content-Type: P2-1984 (2) Content-Identifier: want code for... From: "jeff (j.d.) sparkes" Sender: "jeff (j.d.) sparkes" Message-ID: <"6593 Tue Mar 22 10:04:59 1994"@bnr.ca> To: rc@hawkwind.utcs.toronto.edu Subject: want code for b_access I'd like to use the builtin access for path building across various architectures, where I have a *lot* of directories, many non-existent to search. For various reasons, I'd like to have the extra efficiency of not calling test about a hundred times. It's mentioned in addon.[ch], but I can't find any pointers to the code in the mailing list archives. -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa, Ontario, Canada From rc-owner Tue Mar 22 10:39:58 1994 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <24186>; Tue, 22 Mar 1994 10:39:19 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA11048; Tue, 22 Mar 1994 09:37:48 -0600 Message-Id: <9403221537.AA11048@oldp.astro.wisc.edu> To: "jeff (j.d.) sparkes" Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: want code for b_access Date: Tue, 22 Mar 1994 10:37:47 -0500 From: Alan Watson X-Mts: smtp For path building, it is probably easiest to use the hack in the rc FAQ list -- attempt to cd to each directory. It's not perfect, but it works for me. See question 5.7. Alan. From rc-owner Mon Mar 28 21:34:44 1994 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <24189>; Mon, 28 Mar 1994 21:31:49 -0500 Received: from merlin.resmel.bhp.com.au ([134.18.1.6]) by archone.tamu.edu with SMTP id <11415>; Mon, 28 Mar 1994 20:30:13 -0600 Received: from cerberus.bhpese.oz.au by merlin.resmel.bhp.com.au with SMTP id A A18533 (5.67b/IDA-1.5 for ); Tue, 29 Mar 1994 12:29:11 +1000 Received: from localhost by cerberus.bhpese.oz.au with SMTP id AA01584; Tue, 29 Mar 1994 12:29:15 +1000; sendmail 5.67a/Sm3.12RMPSU (from Sm@cerberus.bhpese.oz.au for rc@archone.tamu.edu) Message-Id: <199403290229.AA01584@cerberus.bhpese.oz.au> To: The rc Mailing List Subject: solaris 2.2 & rshd & rc X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" When doing a rsh command to a solaris 2.2 box, I find that the rc started by rshd hangs in a cpu loop after the command has terminated. Interestingly, SIGCLD is ingored in both rshd & rc. Has anyone else fixed this problem ? Sm -- Scott Merrilees, BHP Information Technology, Newcastle, Australia Internet: Sm@bhpese.oz.au Phone: +61 49 40 1687 Fax: ... 2165 From rc-owner Mon Mar 28 22:01:23 1994 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <24189>; Mon, 28 Mar 1994 22:00:58 -0500 Received: from quux.es.su.oz.au ([129.78.145.8]) by archone.tamu.edu with SMTP id <11415>; Mon, 28 Mar 1994 20:59:24 -0600 Received: by quux.es.su.oz.au id <401>; Tue, 29 Mar 1994 12:59:48 +1000 From: noel@es.su.oz.au Date: Mon, 28 Mar 1994 21:54:26 -0500 to: Scott Merrilees , The rc Mailing List Subject: Re: solaris 2.2 & rshd & rc In-Reply-To: <199403290229.AA01584@cerberus.bhpese.oz.au> Message-ID: <199403291254.26792.out.bajem@es.su.oz.au> From: Scott Merrilees Subject: solaris 2.2 & rshd & rc When doing a rsh command to a solaris 2.2 box, I find that the rc started by rshd hangs in a cpu loop after the command has terminated. Interestingly, SIGCLD is ingored in both rshd & rc. Has anyone else fixed this problem ? it's not that rc _ignores_ SIGCLD, it just doesn't touch it. when rc is started by login and forks a program, you will notice that SIGCLD is SIG_DFL. but when rc is started by rshd, it must be set to SIG_IGN. bad shit happens in sysvr4 when this is done, namely, a parent is not notified of the death of a child, so rc just sits in that wait loop waiting to pick up the status of the child it just forked, a status it will never get. i noticed the cpu in a tight loop when this happened. anyway, i just hacked the code to make sure SIGCLD is _always_ SIG_DFL. this seems to fix the problem. From rc-owner Mon Mar 28 22:15:33 1994 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.toronto.edu with SMTP id <24189>; Mon, 28 Mar 1994 22:15:05 -0500 Received: from merlin.resmel.bhp.com.au ([134.18.1.6]) by archone.tamu.edu with SMTP id <11416>; Mon, 28 Mar 1994 21:13:47 -0600 Received: from cerberus.bhpese.oz.au by merlin.resmel.bhp.com.au with SMTP id A A19648 (5.67b/IDA-1.5 for ); Tue, 29 Mar 1994 13:13:29 +1000 Received: from localhost by cerberus.bhpese.oz.au with SMTP id AA04481; Tue, 29 Mar 1994 13:13:31 +1000; sendmail 5.67a/Sm3.12RMPSU (from Sm@cerberus.bhpese.oz.au for rc@archone.tamu.edu) Message-Id: <199403290313.AA04481@cerberus.bhpese.oz.au> To: noel@es.su.oz.au Cc: The rc Mailing List Subject: Re: solaris 2.2 & rshd & rc In-Reply-To: Your message of "Mon, 28 Mar 94 21:54:26 EST." <199403291254.26792.out.bajem@es.su.oz.au> X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" From: Scott Merrilees When doing a rsh command to a solaris 2.2 box, I find that the rc started by rshd hangs in a cpu loop after the command has terminated. Interestingly, SIGCLD is ingored in both rshd & rc. Has anyone else fixed this problem ? >From: noel@es.su.oz.au >it's not that rc _ignores_ SIGCLD, it just doesn't touch it. when rc >is started by login and forks a program, you will notice that SIGCLD >is SIG_DFL. but when rc is started by rshd, it must be set to SIG_IGN. >bad shit happens in sysvr4 when this is done, namely, a parent is not >notified of the death of a child, so rc just sits in that wait loop >waiting to pick up the status of the child it just forked, a status >it will never get. i noticed the cpu in a tight loop when this happened. > >anyway, i just hacked the code to make sure SIGCLD is _always_ SIG_DFL. >this seems to fix the problem. That was my guess, I figure that rshd must be doing a process id specific wait, such as waitpid(), and doesn't want to get hit with SIGCLD signals. After looking in fn.c:setsigdefaults(), I came up with the following patch to fn.c:inithandlers(). This seems to work. The patch is relative to rc-1.4. Sm -- *** fn.c.orig Tue Mar 29 12:37:04 1994 --- fn.c Tue Mar 29 12:39:16 1994 *************** *** 45,50 **** --- 45,54 ---- fnrm("sigterm"); /* ditto for SIGTERM */ } } + #ifdef NOSIGCLD + rc_signal(SIGCLD, SIG_DFL); + delete_fn(signals[SIGCLD].name); + #endif } /* only run this in a child process! resets signals to their default values * / From rc-owner Wed Mar 30 15:21:52 1994 Received: from mail.swip.net ([192.71.220.11]) by hawkwind.utcs.toronto.edu wit h SMTP id <24197>; Wed, 30 Mar 1994 15:19:24 -0500 Received: by mail.swip.net (8.6.8/2.01) id WAA13708; Wed, 30 Mar 1994 22:19:04 +0200 Received: from walker.UUCP by enea.se (4.1/SMI-4.0) id AA09085; Wed, 30 Mar 94 21:00:13 +0200 Received: from walker.UUCP by pallas.enea.se (4.1/SMI-4.0) id AA00673; Wed, 30 Mar 94 20:52:09 +0200 Received: from dragos.enea.se by ose.enea.se (5.0/SMI-SVR4) id AA07299; Wed, 30 Mar 1994 21:01:18 --100 Received: from llongo.enea.se by dragos.enea.se (4.1/SMI-4.1) id AA03596; Wed, 30 Mar 94 20:54:40 +0200 Date: Wed, 30 Mar 1994 13:54:40 -0500 From: bekl@dragos.ose.enea.se (Bengt Kleberg) Message-Id: <9403301854.AA03596@dragos.enea.se> To: rc@hawkwind.utcs.toronto.edu Subject: FAQ? Content-Length: 206 I need the FAQ. Where can I find it? (if somebody also would tell me how to loop over each line in a file that would be nice. the equiv of: for ( i in `{cat file}) , but with file beeing very long) Bengt From rc-owner Wed Mar 30 15:34:42 1994 Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.e du with SMTP id <24198>; Wed, 30 Mar 1994 15:34:17 -0500 Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3) id AA12582; Wed, 30 Mar 1994 14:33:30 -0600 Message-Id: <9403302033.AA12582@oldp.astro.wisc.edu> To: bekl@dragos.ose.enea.se (Bengt Kleberg) Subject: Re: FAQ? Cc: rc@hawkwind.utcs.toronto.edu Date: Wed, 30 Mar 1994 15:33:29 -0500 From: Alan Watson X-Mts: smtp >I need the FAQ. Where can I find it? I post it every month to comp.unix.shell and it is also available by anonymous ftp as rtfm.mit.edu:/pub/usenet/comp.unix.shell/rc-FAQ. >(if somebody also would tell me how to loop over each line in a file >that would be nice. the equiv of: for ( i in `{cat file}) >, but with file beeing very long) Use the read function in the FAQ list with a while loop or try something like: ifs = $nl for ( line in `{ cat file } ) { ... } From rc-owner Mon Apr 11 13:41:55 1994 Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <24211>; Mon , 11 Apr 1994 13:39:31 -0400 Return-Path: immd3.informatik.uni-erlangen.de!dalibor Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by hawkwind.u tcs.toronto.edu with SMTP id <24211>; Mon, 11 Apr 1994 13:17:02 -0400 Received: from faui30.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA18714 (5.65c-6/7.3v-FAU); Mon, 11 Apr 1994 19:15:55 +0200 Received: from faui30c.informatik.uni-erlangen.de by immd3.informatik.uni-erlan gen.de with SMTP; id AA04911 (5.65c-5/7.3v-FAU); Mon, 11 Apr 1994 19:15:53 +0200 From: Stefan Dalibor Message-Id: <199404111715.AA04911@faui30.informatik.uni-erlangen.de> Date: Mon, 11 Apr 1994 13:15:55 -0400 To: rc-owner Subject: Some questions ref. process substitution Reply-To: Stefan.Dalibor@informatik.uni-erlangen.de Resent-To: rc Resent-Date: Mon, 11 Apr 1994 13:39:29 -0400 Resent-From: Chris Siebenmann Resent-Message-Id: <94Apr11.133931edt.24211@hawkwind.utcs.toronto.edu> Hi, lately I played around a bit with rc's process substitution facility (which I think is a very nice feature - thanks, Byron!); this unvealed one buglette and a few questions when executing: ; exec echo<{echo XXX} 1. Purify says that the memory allocated for the eFd/eFifo exception stack entry in mkcmdarg() is leaking. I patched this by freeing the memory in except.c, but it makes the code IMHO look a bit fuzzy. Is there any objection against allocating the stack entry in mkcmdarg() with nnew() instead of enew() ? 2. The exec is simply ignored - as far as I understand, this is necessary if process substitution is implemented with FIFOS to get rid of the FIFO file in TMPDIR, but couldn't rc just execve the command for those lucky enough to have /dev/fd? BTW, just in case I'm not the last one to notice: The /dev/fd patch available from emx.cc.utexas.edu mentioned in the FAQ works fine with 4.1.3(_U1, too) and also with minimal changes for the sun4m archi- tecture. Another question is wether the parent rc should exit after deleting the FIFO files to maintain manual-compatibility as far as possible (`Replaces rc with the given command.')... 3. I have sigexit set up to do some cleanup; to get this done if the exec builtin is called, I redefined exec to explicitly call sigexit - but this provokes an error message `sigexit not found' with the command above because the function's definition is deleted in setsigdefaults(). Is it really necessary to delete the signal handling functions - wouldn't it be enough to deinstall them as handlers so they could be called just as ordinary, but unexportable functions)? Bye, Stefan From rc-owner Mon Apr 11 14:05:41 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.toronto.edu with SMTP id <24213>; Mon, 11 Apr 1994 14:05:16 -0400 Received: from uucp6.UU.NET by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwleu18455; Mon, 11 Apr 94 14:04:04 - 0400 Received: from srg.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 11 Apr 1994 14:04:15 -0400 Received: from ceres.srg.af.mil by srg.srg.af.mil id aa25504; Mon, 11 Apr 94 13:46:50 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: Redirection and builtin commands Date: Mon, 11 Apr 1994 13:47:13 -0400 Message-Id: <9404111347.aa01197@ceres.srg.af.mil> This has come up in the past, but I just encountered it again and figured it might be worth nudging Byron about. Someone mentioned that es has code to redirect the i/o for builtin commnads without spawning a subshell. It might be nice to transplant that capability back into rc. What inspires this was seeing the comp.unix.shell FAQ, "how do you change the parents environment from a child process", rehashed yet again. It occured to me that, ". <{gen-settings}" would be a very clever rc solution, if only the redirection didn't force it into a subshell. Just a thought... Tom BTW - Anything new on that signal handler problem in 1.5beta1 that we talked about back in March? From rc-owner Fri May 6 17:49:08 1994 Received: from relay1.UU.NET ([192.48.96.5]) by hawkwind.utcs.utoronto.ca with SMTP id <24245>; Fri, 6 May 1994 17:46:59 -0400 Received: from uucp6.UU.NET by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwotr14742; Fri, 6 May 94 17:46:44 -0 400 Received: from srg.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 6 May 1994 17:46:49 -0400 Received: from ceres.srg.af.mil by srg.srg.af.mil id aa16802; Fri, 6 May 94 13:37:36 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: rc on linux Date: Fri, 6 May 1994 13:37:32 -0400 Message-Id: <9405061337.aa27148@ceres.srg.af.mil> I built rc on my new Linux machine :-) the other night, and basically it was just as easy as you'd expect. Running trip didn't show any obvious problems, but there is definitely something funny going on with signals and signal handlers. Clues? In other news, Byron seems to have fallen off the face of the planet again. ;-) Any further news or fixes for the problems with 1.5beta1 that we discussed a while back? Will there ever be a "real" 1.5? ;-) Tom From rc-owner Fri May 6 18:10:07 1994 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.c a with SMTP id <24245>; Fri, 6 May 1994 18:09:48 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <3009>; Fri, 6 May 1994 18:09:15 -0400 To: rc@hawkwind.utcs.toronto.edu Subject: signals and stuff Date: Fri, 6 May 1994 18:09:03 -0400 From: Scott Schwartz Message-Id: <94May6.180915edt.3009@groucho.cse.psu.edu> A while back Byron sent me this patch for 1.5beta. I don't know if it was sent to the list, but just in case, here it is. ------- Forwarded Message =================================================================== RCS file: RCS/input.c,v retrieving revision 1.4 diff -c -r1.4 input.c *** /tmp/T0a00581 Tue Apr 5 01:12:45 1994 - --- input.c Tue Apr 5 01:11:01 1994 *************** *** 140,145 **** - --- 140,147 ---- long /*ssize_t*/ r = rc_read(istack->fd, inbuf + 2, BUFSIZE); sigchk(); if (r < 0) { + if (errno == EINTR) /* retry interrupte d read */ + continue; uerror("read"); rc_exit(1); } (snarfed and pasted from one xterm to another, I don't know how many of the blanks got hosed...) ------- End of Forwarded Message From rc-owner Tue May 10 14:21:08 1994 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <23981>; Tue, 10 May 1994 14:18:24 -0400 Received: from uucp3.uu.net by relay3.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25680; Tue, 10 May 94 14:18:19 -0400 Received: from srg.UUCP by uucp3.uu.net with UUCP/RMAIL ; Tue, 10 May 1994 14:18:19 -0400 Received: from ceres.srg.af.mil by srg.srg.af.mil id aa04209; Tue, 10 May 94 13:58:59 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu, schwartz@groucho.cse.psu.edu Subject: Re: signals and stuff Date: Tue, 10 May 1994 13:58:36 -0400 Message-Id: <9405101358.aa24953@ceres.srg.af.mil> Well, the patch to rc-1.5beta1 in Scott's message gave me the clue I needed. It fixes the problem (for rc without readline) by ensuring that interrupted reads aren't treated as an EOF. Here is a patch to do the same thing when using readline. Both patches should be applied if you use readline. If you don't, at least apply the patch from Byron that Scott passed along so that your signal handlers work right. Tom ------------------------------------------------------------------------------ *** input.c Tue May 10 13:38:19 1994 --- input.cn Tue May 10 13:26:13 1994 *************** *** 96,108 **** slow = TRUE; if (!interrupt_happened) r = readline(prompt); ! else r = NULL; ! } else r = NULL; - slow = FALSE; - if (r == NULL) errno = EINTR; sigchk(); return r; } --- 96,110 ---- slow = TRUE; if (!interrupt_happened) r = readline(prompt); ! else { r = NULL; ! errno = EINTR; ! } ! } else { r = NULL; errno = EINTR; + } + slow = FALSE; sigchk(); return r; } *************** *** 123,128 **** --- 125,132 ---- if (interactive && istack->fd == 0) { rlinebuf = rc_readline(prompt); if (rlinebuf == NULL) { + if (errno == EINTR) /* retry interrupte d read */ + continue; chars_in = 0; } else { if (*rlinebuf != '\0') From rc-owner Tue May 10 17:38:29 1994 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <23981>; Tue, 10 May 1994 17:37:05 -0400 Received: from uucp6.UU.NET by relay3.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA08153; Tue, 10 May 94 16:09:33 -0400 Received: from srg.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Tue, 10 May 1994 16:09:36 -0400 Received: from ceres.srg.af.mil by srg.srg.af.mil id aa06538; Tue, 10 May 94 15:54:13 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: culliton@uunet.UU.NET, rc@hawkwind.utcs.toronto.edu, schwartz@groucho.cse.psu.edu Subject: Re: signals and stuff Date: Tue, 10 May 1994 15:53:29 -0400 Message-Id: <9405101553.aa27072@ceres.srg.af.mil> Well that patch is an improvement, but it's not perfect yet. Testing on my friendly neighborhood Sparc-station with: fn sigwinch {eval `/usr/bin/X11/resize; stty sane; echo} The next command entered after the signal handler is executed complains about a "parse error". It also fails to clear errno the next time through rc_readline so that ^D doesn't work unless another command is executed first. 8-P Blech! (This doesn't happen under SCO Unix...) From rc-owner Fri Jul 8 15:26:36 1994 Received: from plg.uwaterloo.ca ([129.97.140.10]) by hawkwind.utcs.utoronto.ca with SMTP id <24036>; Fri, 8 Jul 1994 15:24:02 -0400 Received: by plg.uwaterloo.ca id <185321>; Fri, 8 Jul 1994 15:23:51 -0400 From: Dave Mason To: rc@hawkwind.utcs.toronto.edu Subject: rc as a login shell, and Solaris X-Face: %Q_F^9R-:'3MM7eZ6@E.x@f\*bgatzGv-8d%I~L[p^.F)3QF{kq\UTsu|e#?)3FPwJNvPPB !s*He|-*M^p*~bh"Nywm5NLL\\Rl3r(hWHY*F:$/RdKV*bS";n&#\Ov@*=]mu\}6tP Date: Fri, 8 Jul 1994 15:23:42 -0400 I have been using rc as my (virtual) login shell for several years, however I actually had itcsh in /etc/passwd because it has a feature where it will pass the -c string to the shell.... I took that string and exec'd rc to do the real work. Well we've moved to Solaris and itcsh (apparently) doesn't work, so I was forced to change. So what I did was added 2 lines to main.c that make -c imply -l, so I get a chance to set environments, etc. before executing the command, and put the -c string into the variable ``Command''. Then the start of my .rcrc says: ------ home=`/bin/pwd # get *real* home directory name (less symbolic links) if (! ~ $#Command 0) { ~ $#prepath 0 && { . ./.rc/rcmin fn prompt { reenv;refn ~ $TERM emacs && prompt = ('; ' '') && history=() && PAGER=cat fn prompt }} eval `` () {echo 'fn _C_ {'^$Command'}'|sed -e 's/(/{/g' -e 's/)/}/g'} Command= () _C_ exit } ------ The cost of this is that anything that does a ``rc -c ....'' incurs the overhead of rc opening .rcrc, but this seems pretty insignificant, given the resulting flexibility. As in my example above, initialization cost can be minimized to this level by such things as checking if ``prepath'' is already set. The remaining patches were required to make everything work properly on solaris. The only significant problem was that SIGCHLD when set to SIG_IGN causes exiting processes to *not* return their pid's to wait(2)! Because of a bug in wait.c, this caused rc to loop when run directly from rshd (which sets SIGCHLD to SIG_IGN). There is a patch to signal.c to always force SIGCHLD to SIG_IGN (conditionalized on NOSIGCLDIGN) and a patch to wait.c to fix the behaviour. The remaining patches simply get protypes to match the system ones. This now works very nicely. ../Dave *** rc-1.4/main.c Sun May 24 16:39:04 1992 --- rc-1.4-dvm/main.c Fri Jul 8 13:34:47 1994 *************** *** 40,45 **** --- 40,48 ---- dashdee = TRUE; break; case 'c': + #ifdef DASHC + dashell = TRUE; + #endif dashsee[0] = rc_optarg; goto quitopts; case 'n': *************** *** 79,84 **** --- 82,90 ---- starassign(dollarzero, null, FALSE); /* assign $0 to $* */ inithandler(); if (dashsee[0] != NULL) { /* input from the -c flag? */ + #ifdef DASHC + assigndefault("Command", dashsee[0], (void *)0); + #endif if (*argv != NULL) starassign(dollarzero, argv, FALSE); pushstring(dashsee, TRUE); *** rc-1.4/signal.c Wed Apr 15 16:47:00 1992 --- rc-1.4-dvm/signal.c Fri Jul 8 13:33:55 1994 *************** *** 69,74 **** --- 69,79 ---- int i; for (i = 1; i < NUMOFSIGNALS; i++) { if ((h = signal(i, SIG_DFL)) != SIG_DFL) + #ifdef NOSIGCLDIGN + if (i==SIGCHLD && h==SIG_IGN) + h=SIG_DFL; + else + #endif signal(i, h); sighandlers[i] = h; } *** rc-1.4/wait.c Fri Apr 17 19:26:25 1992 --- rc-1.4-dvm/wait.c Fri Jul 8 13:35:11 1994 *************** *** 53,59 **** while (pid != (ret = rc_wait(stat))) { Pid *q; if (ret < 0) { ! if (nointr) goto again; return ret; } --- 53,59 ---- while (pid != (ret = rc_wait(stat))) { Pid *q; if (ret < 0) { ! if (nointr && errno==EINTR) goto again; return ret; } *** rc-1.4/builtins.c Tue May 26 00:42:58 1992 --- rc-1.4-dvm/builtins.c Thu Jul 7 15:09:55 1994 *************** *** 441,447 **** }; extern int getrlimit(int, struct rlimit *); ! extern int setrlimit(int, struct rlimit *); static void printlimit(const Limit *limit, bool hard) { struct rlimit rlim; --- 441,447 ---- }; extern int getrlimit(int, struct rlimit *); ! extern int setrlimit(int, const struct rlimit *); static void printlimit(const Limit *limit, bool hard) { struct rlimit rlim; *** rc-1.4/config.h Fri Sep 11 22:56:16 1992 --- rc-1.4-dvm/config.h Fri Jul 8 15:18:12 1994 *************** *** 25,30 **** --- 25,37 ---- */ /* + * Define the macro DASHC if you want the -c string put into the + * environment variable Command and to force -l so that the .rcrc file + * can control the environment for the command execution. + #define DASHC + */ + + /* * Define the macro SVSIGS if your system has System V signal semantics, * i.e., if "slow" system calls are interrupted rather than resumed * after returning from an interrupt handler. (If you are not sure what *************** *** 64,69 **** --- 71,83 ---- */ /* + * Define the macro NOSIGCLDIGN if your system uses SIGCLD set to SIG_IGN + * to mean that it should reap child processes as they exit. This probably + * only matters if you use rc as your login shell and want rsh to work. + #define NOSIGCLDIGN + */ + + /* * Define the macro READLINE if you want rc to call GNU readline * instead of read(2) on interactive shells. #define READLINE *************** *** 108,113 **** --- 122,132 ---- #define NOJOB */ + /* + * Define the macro SYSVR4 if your system has System V include prototypes + #define SYSVR4 + */ + /* Beginning of defaults section: */ #ifndef CUSTOM *************** *** 131,139 **** --- 150,168 ---- #endif #ifdef sun /* Used on SunOS 4.1.1 */ + #ifdef __svr4__ + #define SVSIGS + #define NOSIGCLD + #define NOSIGCLDIGN + #define SYSVR4 #define PROTECT_ENV #undef DEFAULTPATH + #define DEFAULTPATH "/usr/bin", "/bin", "." + #else + #define PROTECT_ENV + #undef DEFAULTPATH #define DEFAULTPATH "/usr/ucb", "/usr/bin", "." + #endif #endif /* From rc-owner Tue Aug 2 15:59:46 1994 Received: from localhost by hawkwind.utcs.utoronto.ca with SMTP id <24077>; Tue , 2 Aug 1994 15:55:48 -0400 To: rc Subject: A general desire for rc 1.5/1.6 Date: Tue, 2 Aug 1994 15:55:44 -0400 From: Chris Siebenmann Message-Id: <94Aug2.155548edt.24077@hawkwind.utcs.utoronto.ca> It would be nice if all the scattered prototypes for various system functions could be centralized in one header file; it seems that lots of systems have conflicting definitions for some or all of them, and it's annoying to have to touch four or five rc source files to get rc to compile. - cks [The latest one is the Cray EL92 under Unicos, which complains about opendir() in glob.c and stat() in which.c.] From rc-owner Tue Aug 2 17:24:32 1994 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.c a with SMTP id <24077>; Tue, 2 Aug 1994 17:23:36 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <2542>; Tue, 2 Aug 1994 17:22:17 -0400 To: Chris Siebenmann cc: rc@hawkwind.utcs.toronto.edu Subject: Re: A general desire for rc 1.5/1.6 In-reply-to: Your message of "Tue, 02 Aug 1994 15:55:44 EDT." <94Aug2.155548edt.24077@hawkwind.utcs.utoronto.ca> Date: Tue, 2 Aug 1994 17:21:59 -0400 From: Scott Schwartz Message-Id: <94Aug2.172217edt.2542@groucho.cse.psu.edu> | It would be nice if all the scattered prototypes for various system | functions could be centralized in one header file; it seems that lots | of systems have conflicting definitions for some or all of them, and | it's annoying to have to touch four or five rc source files to get rc | to compile. One thing I'd like to see for 1.6 is some utility routines abstracted out into libraries. I've already taken Paul's print routines and rewhacked them into libprint.a, fixing a number of bugs in the process (which were benign since rc didn't exercise them.) It's a little bigger (5K vs 2K) but it does lots more (famous last words, I know). If anyone wants to check it out, you can ftp it from ftp://groucho.cse.psu.edu/pub/scott/print.shar If similar things were done to the globber and glomer you could get shell globbing in other programs (in opposition to the unix tradition of not reusing code.) From rc-owner Wed Aug 3 03:25:51 1994 Received: from ben.britain.eu.net ([192.91.199.254]) by hawkwind.utcs.utoronto. ca with SMTP id <24079>; Wed, 3 Aug 1994 03:24:59 -0400 Received: from a.gec-epl.co.uk by ben.britain.eu.net via PSS with NIFTP (PP) id ; Wed, 3 Aug 1994 08:15:07 +0100 Received: from zombie.gec-epl.co.uk (zombie.limbo.gec-epl.co.uk) by vampire.gec-epl.co.uk (5.0/SMI-SVR4) id AA24042; Wed, 3 Aug 1994 08:19:15 +0000 Received: by zombie.gec-epl.co.uk (5.0/SMI-SVR4) id AA29124; Wed, 3 Aug 1994 08:12:41 +0000 Date: Wed, 3 Aug 1994 04:12:41 -0400 From: steve@cegelecproj.co.uk (Steve_Kilbane) Message-Id: <9408030712.AA29124@zombie.gec-epl.co.uk> To: rc@hawkwind.utcs.toronto.edu Subject: Re: A general desire for rc 1.5/1.6 X-Sun-Charset: US-ASCII X-Face: Iqsa(US9p?)Y^W+6Ff[Z] rM"uFE) lFDjag1e]\/#2 Content-Length: 780 > From: Scott Schwartz > One thing I'd like to see for 1.6 is some utility routines abstracted > out into libraries. [...] > If similar things were done to the globber and glomer you could get > shell globbing in other programs (in opposition to the unix tradition > of not reusing code.) Hmm. sounds a bit like tcl to me. Still, I had considered a while back that it would be useful to write a shell (Bourne, I was thinking, specifically), library by library for this very reason. Variable expansion was going to be the first thing to do, since that's more generally useful than wildcard expansion ("Why *can't* I enter $HOME/my_file in this text field?"). But of course, real work intruded. Now I'll just use tcl. :-) steve From rc-owner Wed Aug 3 16:03:58 1994 Received: from alpha.xerox.com ([13.1.64.93]) by hawkwind.utcs.utoronto.ca with SMTP id <24079>; Wed, 3 Aug 1994 15:59:48 -0400 Received: from gemini.sdsp.mc.xerox.com ([13.252.21.73]) by alpha.xerox.com wit h SMTP id <14501(2)>; Wed, 3 Aug 1994 12:59:18 PDT Received: from gasface.mc.xerox.com (gasface.sdsp.mc.xerox.com) by gemini.sdsp. mc.xerox.com (4.1/SMI-4.1) id AA27740; Wed, 3 Aug 94 15:59:15 EDT Received: by gasface.mc.xerox.com (4.1/SMI-4.1) id AA06119; Wed, 3 Aug 94 15:59:09 EDT Message-Id: <9408031959.AA06119@gasface.mc.xerox.com> To: rc@hawkwind.utcs.toronto.edu Subject: RC on Dos... Date: Wed, 3 Aug 1994 15:59:08 -0400 From: "Marty Leisner" I'm not a member of this list (please answer me directly). Would it be worthwhile to get rc to run on Dos (has it been done?) I can get a non-multitasking fork working, but need to implement pipes as files... marty Member of the League of Programming Freedom leisner@sdsp.mc.xerox.com leisner@eso.mc.xerox.com From rc-owner Thu Aug 4 16:18:20 1994 Received: from relay3.UU.NET ([192.48.96.8]) by hawkwind.utcs.utoronto.ca with SMTP id <24080>; Thu, 4 Aug 1994 16:14:38 -0400 Received: from uucp7.UU.NET by relay3.UU.NET with SMTP id QQxbns11113; Thu, 4 Aug 1994 16:14:23 -0400 Received: from srg.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Thu, 4 Aug 1994 16:14:32 -0400 Received: from ceres.srg.af.mil by srg.srg.af.mil id aa17674; Thu, 4 Aug 94 15:14:14 EDT From: culliton@srg.af.mil (Tom Culliton x2278) X-Mailer: SCO System V Mail (version 3.2) To: rc@hawkwind.utcs.toronto.edu Subject: 1.6? lets get 1.5 first! Date: Thu, 4 Aug 1994 15:15:14 -0400 Message-ID: <9408041515.aa06650@ceres.srg.af.mil> Last I heard we were still on 1.5beta1, and unless something slipped by me, waiting for a real 1.5 release... Whats the word from Byron? I still have signal handler problems with 1.5beta1 + readline + patches. BTW - What really prompts this message is another question. Has anyone thought to set up a RC home page on the WWW? We've got tons of stuff which could be tied together rather nicely this way, Duff's paper, the man page, the FAQ, the mail archives, source code, patches, examples, ... Tom From rc-owner Mon Aug 8 05:33:38 1994 Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by hawkwind.u tcs.utoronto.ca with SMTP id <24081>; Mon, 8 Aug 1994 05:27:50 -0400 Received: from faui01.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA09473 (5.65c-6/7.3w-FAU); Mon, 8 Aug 1994 11:27:23 +0200 Received: from faui06d.informatik.uni-erlangen.de by cip.informatik.uni-erlange n.de with SMTP; id AA00512 (5.65c-6/7.3m-FAU); Mon, 8 Aug 1994 11:27:20 +0200 From: "Markus Friedl (CIP 92)" Message-Id: <199408080927.AA00512@faui01.informatik.uni-erlangen.de> Subject: readline & history To: rc@hawkwind.utcs.toronto.edu (rc-mailing-list) Date: Mon, 8 Aug 1994 05:27:18 -0400 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1271 Hi! With the current version of rc I am not able to use the $history- file with the readline-interface (i.e. CTRL-p, CTRL-r, ...). The following patch forces rc to add the contents of the file to the history list. any comments? cu --markus =================================================================== RCS file: RCS/input.c,v retrieving revision 1.3 diff -u -r1.3 input.c --- 1.3 1994/06/22 08:31:07 +++ input.c 1994/08/07 21:39:33 @@ -23,6 +23,8 @@ #ifdef READLINE extern char *readline(char *); extern void add_history(char *); +extern int read_history(char *); +extern void using_history(void); static char *rlinebuf; #endif @@ -256,6 +258,9 @@ extern Node *doit(bool execit) { bool eof; +#ifdef READLINE + bool doinithist = TRUE; +#endif Jbwrap j; Estack e1, e2; Edata jerror; @@ -277,6 +282,18 @@ dashell = FALSE; b_dot(fname); } +#ifdef READLINE + if (doinithist && interactive) { + List *hist; + if (hist = varlookup("history")){ + using_history(); + read_history(hist->w); + } else { + fprint(2, "history not defined\n"); + } + doinithist = FALSE; + } +#endif if (interactive) { List *s; if (!dashen && fnlookup("prompt") != NULL) { -- Markus Friedl msfriedl@cip.informatik.uni-erlangen.de From rc-owner Mon Aug 8 14:58:58 1994 Received: from groucho.cse.psu.edu ([130.203.2.12]) by hawkwind.utcs.utoronto.c a with SMTP id <24082>; Mon, 8 Aug 1994 14:58:11 -0400 Received: from localhost by groucho.cse.psu.edu with SMTP id <3045>; Mon, 8 Aug 1994 14:57:36 -0400 To: rc@hawkwind.utcs.toronto.edu Subject: Re: A general desire for rc 1.5/1.6 In-reply-to: Your message of "Tue, 02 Aug 1994 17:21:59 EDT." <94Aug2.172217edt.2542@groucho.cse.psu.edu> Date: Mon, 8 Aug 1994 14:57:13 -0400 From: Scott Schwartz Message-Id: <94Aug8.145736edt.3045@groucho.cse.psu.edu> I wrote: > ftp://groucho.cse.psu.edu/pub/scott/print.shar If anyone does check this out, please send me whatever feedback you have. From rc-owner Sat Aug 13 01:51:12 1994 Received: from postman.osf.org ([130.105.1.152]) by hawkwind.utcs.utoronto.ca w ith SMTP id <24087>; Sat, 13 Aug 1994 01:49:30 -0400 Received: from sulphur.osf.org (sulphur.osf.org [130.105.5.36]) by postman.osf. org (8.6.9/8.6.x) with SMTP id BAA07685; Sat, 13 Aug 1994 01:49:26 -0400 From: Rich Salz Received: by sulphur.osf.org (1.37.109.4/4.7) id AA22028; Sat, 13 Aug 94 01:46: 53 -0400 Date: Sat, 13 Aug 1994 01:46:53 -0400 Message-Id: <9408130546.AA22028@sulphur.osf.org> To: rc-owner@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: readline & history >With the current version of rc I am not able to use the $history- >file with the readline-interface (i.e. CTRL-p, CTRL-r, ...). >The following patch forces rc to add the contents of the file >to the history list. > >any comments? If you do this then you cannot use the small editline library since it does not have the using_history() and read_history() functions. Do you really want to suck your whole history file into your shell's address space? Ick. /r$ From rc-owner Sat Aug 13 08:07:02 1994 Received: from kazatz.dtek.chalmers.se ([129.16.30.14]) by hawkwind.utcs.utoron to.ca with SMTP id <24088>; Sat, 13 Aug 1994 08:06:05 -0400 Received: (from d0asta@localhost) by kazatz.dtek.chalmers.se (8.6.9/8.6.9) id O AA23713; Sat, 13 Aug 1994 14:04:06 +0200 Date: Sat, 13 Aug 1994 08:04:06 -0400 From: Magnus Homann Message-Id: <199408131204.OAA23713@kazatz.dtek.chalmers.se> To: rc@hawkwind.utcs.toronto.edu Subject: rc 1.4 and Solaris 2.3... I have compiled rc with readline, and it works. The only problem I've got is when using rc as a script running from NCSA httpd 1.3. It hangs... Other shells work alright, and rc worked before moving to Solaris. Question: What are the correct setup in config.h for Solaris? I've tried a few combinations, but the problem wouldn't go away! :-) Anyone? Homann -- Magnus Homann Email: d0asta@dtek.chalmers.se URL : http://www.dtek.chalmers.se/DCIG/d0asta.html The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html From rc-owner Fri Sep 9 11:00:38 1994 Received: from mail.swip.net ([192.71.220.11]) by hawkwind.utcs.utoronto.ca wit h SMTP id <24118>; Fri, 9 Sep 1994 10:58:45 -0400 Received: by mail.swip.net (8.6.8/2.01) id QAA25087; Fri, 9 Sep 1994 16:58:27 +0200 Received: from walker.UUCP by enea.se (4.1/SMI-4.0) id AA15835; Fri, 9 Sep 94 15:30:24 +0200 Received: from walker.UUCP by pallas.enea.se (4.1/SMI-4.0) id AA15923; Fri, 9 Sep 94 15:29:59 +0200 Received: from dragos.enea.se by ose.enea.se (5.0/SMI-SVR4) id AA07431; Fri, 9 Sep 1994 15:32:00 --100 Received: from wambasi.enea.se by dragos.enea.se (4.1/SMI-4.1) id AA18325; Fri, 9 Sep 94 15:29:15 +0200 Date: Fri, 9 Sep 1994 09:29:15 -0400 From: bekl@dragos.ose.enea.se (Bengt Kleberg) Message-Id: <9409091329.AA18325@dragos.enea.se> To: rc@hawkwind.utcs.toronto.edu Subject: I have mislaid the manul, you may IGNORE this Content-Length: 174 I will find the manual, RSN, but in the meantime: Isn't it possible to do this, ie refer to ${var}: ; asd = 123 ; echo ${asd} syntax error ; Bengt, with much apologising. From rc-owner Fri Sep 30 13:05:06 1994 Received: from Sun.COM ([192.9.9.1]) by hawkwind.utcs.utoronto.ca with SMTP id <24136>; Fri, 30 Sep 1994 13:01:40 -0400 Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA22869; Fri, 30 Sep 94 10:01:11 PDT Received: from geko.Corp.Sun.COM by Corp.Sun.COM (4.1(1/24/94)/elliemay (corpma il1 inbound)) id AA08764; Fri, 30 Sep 94 10:01:05 PDT Received: by geko.Corp.Sun.COM (5.x/SMI-SVR4) id AA02594; Fri, 30 Sep 1994 10:01:04 -0700 Message-Id: <9409301701.AA02594@geko.Corp.Sun.COM> From: John.Benninghoff@Corp.Sun.COM (John Benninghoff) Date: Fri, 30 Sep 1994 13:01:03 -0400 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rc@hawkwind.utcs.toronto.edu Subject: Where's the rc FAQ? Where can I ftp or otherwise get a copy of the rc FAQ? I'm not on the list so please Cc: my address. /jb From rc-owner Mon Oct 3 20:16:42 1994 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.utoronto.ca with SMTP id <24139>; Mon, 3 Oct 1994 20:12:57 -0400 Received: from cooper.edu ([199.98.16.5]) by archone.tamu.edu with SMTP id <114 81>; Mon, 3 Oct 1994 19:10:20 -0500 From: To: rc@archone.tamu.edu Subject: rc archive on www Content-Length: 329 Message-Id: <94Oct3.191020cdt.11481@archone.tamu.edu> Date: Mon, 3 Oct 1994 20:10:10 -0400 Mon Oct 3 19:59:49 EDT 1994 the rc and sam mail archives can be accessed at URL: http://cooper.edu:9000/~rp/plan9/plan9-info.html from here, you can go to the appropiate lists. PS this machine is officially up during the following hours - M-F 8:45 to 22:00 EST Sat 13:00 to 18:00 EST Sun 15:00 to 21:00 EST micro From rc-owner Thu Oct 6 06:21:42 1994 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.utoronto.ca with SMTP id <24141>; Thu, 6 Oct 1994 06:19:53 -0400 Received: from gateway.sequent.com ([138.95.18.1]) by archone.tamu.edu with SMT P id <11481>; Thu, 6 Oct 1994 05:17:23 -0500 Received: from sequent.sequent.com by gateway.sequent.com (5.61/1.34) id AA00427; Thu, 6 Oct 94 03:19:36 -0700 Received: by sequent.sequent.com (5.65/1.34) id AA20534; Thu, 6 Oct 94 03:19:32 -0700 Received: by sequent via UUCP from amsqnt; Thu Oct 6 11:16:27 1994 Received: by amsqnt.nl.sequent.com (5.65/1.34) id AA06655; Thu, 6 Oct 94 11:16:27 +0100 From: Hans van de Looy Message-Id: <9410061016.AA06655@amsqnt.nl.sequent.com> Subject: subscribe To: archone.tamu.edu!rc@sequent.com Date: Thu, 6 Oct 1994 06:16:26 -0400 Organization: Sequent Computer Systems B.V. Country: the Netherlands Phone: +31-3406-66070 Fax: +31-3406-66054 X-Mailer: ELM [version 2.3 PL0] subscribe From rc-owner Thu Oct 6 06:32:44 1994 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.utoronto.ca with SMTP id <24142>; Thu, 6 Oct 1994 06:32:26 -0400 Received: from gateway.sequent.com ([138.95.18.1]) by archone.tamu.edu with SMT P id <11481>; Thu, 6 Oct 1994 05:29:55 -0500 Received: from sequent.sequent.com by gateway.sequent.com (5.61/1.34) id AA00737; Thu, 6 Oct 94 03:32:09 -0700 Received: by sequent.sequent.com (5.65/1.34) id AA20915; Thu, 6 Oct 94 03:32:07 -0700 Received: by sequent via UUCP from amsqnt; Thu Oct 6 11:29:07 1994 Received: by amsqnt.nl.sequent.com (5.65/1.34) id AA06939; Thu, 6 Oct 94 11:29:07 +0100 From: Hans van de Looy Message-Id: <9410061029.AA06939@amsqnt.nl.sequent.com> Subject: Re: subscribe (fwd) To: archone.tamu.edu!rc@sequent.com Date: Thu, 6 Oct 1994 06:29:06 -0400 Priority: *URGT* Organization: Sequent Computer Systems B.V. Country: the Netherlands Phone: +31-3406-66070 Fax: +31-3406-66054 X-Mailer: ELM [version 2.3 PL0] Chris Siebenmann wrote: ! From sequent!cse.psu.edu!plan9-fa Wed Oct 5 00:35 MET 1994 ! To: plan9-fans@cse.psu.edu ! Subject: Re: subscribe info for sam & rc ! In-Reply-To: micro's message of Tue, 04 Oct 1994 17:31:12 -0400. ! <94Oct4.173143edt.291949@psuvax1.cse.psu.edu> ! Date: Tue, 4 Oct 1994 19:05:32 -0400 ! From: Chris Siebenmann ! Message-Id: <94Oct4.190547edt.24140@hawkwind.utcs.utoronto.ca> ! Sender: sequent!cse.psu.edu!owner-plan9-fans ! Precedence: bulk ! Reply-To: sequent!cse.psu.edu!plan9-fans ! ! The subscription address for the rc mailing list is *NOT* ! 'rc@archone.tamu.edu'; that is an obsolete address for the ! list itself. The subscription address for the rc mailing list ! is 'rc-request@hawkwind.utcs.toronto.edu'. ! ! I am unhappy about this mistake. ! ! - cks ! Excuse me for the subscribe message; I am as unhappy as Chris :) -- Kind Regards, ============================================================================ dBP dBP dBP dP dBBBBb dBP .-----. Rijnzathe 7a-2 dB' | # | 3454 PV de Meern dBBBBBP dB .BP dBP dB' dBP | | The Netherlands dBP dBP BB.BP dBP dB' dBP `-----' Tel:+31 3406-66070 Car:06-52879921 dBP dBP BBBP dBBBBB' dBBBBBP SEQUENT Fax:+31 3406-66054 Pgr:06-57540981 ---------------------------------------------------------------------------- GCS d++(--) p-(--) c++(++++) l u++ e- m++ s-/+ n+(---) h-- f !g w t+ r y+(*) ============================================================================ From rc-owner Wed Nov 2 13:25:07 1994 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.utoronto.ca with SMTP id <24183>; Wed, 2 Nov 1994 13:22:00 -0500 Received: from pong.nas.nasa.gov ([129.99.50.8]) by archone.tamu.edu with SMTP id <11483>; Wed, 2 Nov 1994 12:19:09 -0600 Received: (from gray@localhost) by pong.nas.nasa.gov (8.6.8.1/NAS.5.b) id KAA18881; Wed, 2 Nov 1994 10: 21:37 -0800 Date: Wed, 2 Nov 1994 13:21:36 -0500 From: "Scott C. Gray" To: rc@archone.tamu.edu Subject: Re: rc archive on www In-Reply-To: <94Oct3.191020cdt.11481@archone.tamu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Has anyone out there gotten rc 1.5 to work under HP-UX 9.05 under VUE 3.0? I got it to compile without too many problems, however if I log in through VUE, it immediatly kicks me back out without even showing me the massive copyright page. (side note: I realize that you aren't supposed to be able to run VUE with anything other than /bin/sh, /bin/csh, or /bin/ksh, however I am succesfully running it right now using /bin/bash--it complains a little, but it lets me do it). I can log in from other machines via telnet, rsh, etc., however I have noticed that I do have problems performing some tasks. For example, if I use man, I get: 'sh: exec: restricted'. Any suggestions? -scott _/ _/ _/_/_/ _/_/_/_/ _/_/_/ Scott C. Gray _/_/ _/ _/ _/ _/_/ _/ _/ gray@nas.nasa.gov _/ _/_/ _/_/_/_/ _/_/ _/_/_/_/ NASA Ames Research M/S 258-6 _/ _/ _/ _/ _/_/_/_/ _/ _/ Moffett Field, CA 93035 From rc-owner Wed Nov 2 14:06:44 1994 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.utoronto.ca with SMTP id <24184>; Wed, 2 Nov 1994 14:06:06 -0500 Received: from postman.osf.org ([130.105.1.152]) by archone.tamu.edu with SMTP id <11483>; Wed, 2 Nov 1994 13:03:15 -0600 Received: from sulphur.osf.org (sulphur.osf.org [130.105.5.36]) by postman.osf. org (8.6.9/8.6.x) with SMTP id PAA05790; Wed, 2 Nov 1994 15:05:44 -0400 From: Rich Salz Received: by sulphur.osf.org (1.37.109.4/4.7) id AA03888; Wed, 2 Nov 94 14:02:3 6 -0500 Date: Wed, 2 Nov 1994 14:02:36 -0500 Message-Id: <9411021902.AA03888@sulphur.osf.org> To: rc-owner@hawkwind.utcs.toronto.edu, rc@archone.tamu.edu Subject: Re: rc archive on www The HP is very very stupid. If there is an "r" anywhewre in the shell name then it gets treated as restricted. For this reason, I have ln /bin/rc /bin/p9sh and run p9sh as my login shell. (Actually I threw out vuew altogether; my .vueprofile just exec's my .xsession) From rc-owner Wed Nov 2 16:08:30 1994 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.utoronto.ca with SMTP id <24186>; Wed, 2 Nov 1994 16:07:24 -0500 Received: from pong.nas.nasa.gov ([129.99.50.8]) by archone.tamu.edu with SMTP id <11483>; Wed, 2 Nov 1994 15:04:29 -0600 Received: (from gray@localhost) by pong.nas.nasa.gov (8.6.8.1/NAS.5.b) id NAA19191; Wed, 2 Nov 1994 13: 06:54 -0800 Date: Wed, 2 Nov 1994 16:06:53 -0500 From: "Scott C. Gray" To: Rich Salz cc: rc-owner@hawkwind.utcs.toronto.edu, rc@archone.tamu.edu Subject: rc, HP-UX, VUE, and me In-Reply-To: <9411021902.AA03888@sulphur.osf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 2 Nov 1994, Rich Salz wrote: > The HP is very very stupid. If there is an "r" anywhewre in the shell > name then it gets treated as restricted. For this reason, I have > ln /bin/rc /bin/p9sh > and run p9sh as my login shell. > > (Actually I threw out vuew altogether; my .vueprofile just > exec's my .xsession) Yeah, I already got feedback about the 'r' from somewhat else. Changing the name of rc fixes the problem with 'man', but I still can't log into VUE. It just sits there for about 10 seconds with a blank screen and kicks me back into the login. Any other suggestions? -scott P.S. Sorry about the old subject line--I was using an old piece of mail to get the e-mail address for the group, and I forgot to change the subject line. From rc-owner Wed Nov 2 21:00:26 1994 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.utoronto.ca with SMTP id <23979>; Wed, 2 Nov 1994 20:59:02 -0500 Received: from postman.osf.org ([130.105.1.152]) by archone.tamu.edu with SMTP id <11554>; Wed, 2 Nov 1994 19:56:03 -0600 Received: from sulphur.osf.org (sulphur.osf.org [130.105.5.36]) by postman.osf. org (8.6.9/8.6.x) with SMTP id VAA25029; Wed, 2 Nov 1994 21:58:26 -0400 From: Rich Salz Received: by sulphur.osf.org (1.37.109.4/4.7) id AA04337; Wed, 2 Nov 94 20:55:1 7 -0500 Date: Wed, 2 Nov 1994 20:55:17 -0500 Message-Id: <9411030155.AA04337@sulphur.osf.org> To: gray@nas.nasa.gov, rsalz@osf.org Subject: Re: rc, HP-UX, VUE, and me Cc: rc-owner@hawkwind.utcs.toronto.edu, rc@archone.tamu.edu I took a closer look. I have /bin/csh in /etc/passwd but my .vueprofile is #! /bin/sh exec rc -l $HOME/.xsession-vue From rc-owner Thu Nov 3 09:22:09 1994 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.utoronto.ca with SMTP id <23979>; Thu, 3 Nov 1994 09:20:41 -0500 Received: from postman.osf.org ([130.105.1.152]) by archone.tamu.edu with SMTP id <11554>; Thu, 3 Nov 1994 08:17:52 -0600 Received: from coltsfoot.osf.org (coltsfoot.osf.org [130.105.2.105]) by postman .osf.org (8.6.9/8.6.x) with SMTP id KAA20096; Thu, 3 Nov 1994 10:19:41 -0400 Message-Id: <199411031419.KAA20096@postman.osf.org> To: Rich Salz Cc: gray@nas.nasa.gov, rc@archone.tamu.edu Subject: Re: rc, HP-UX, VUE, and me In-reply-to: Message from Rich Salz <9411030155.AA04337@sulphur.osf.org> . X-Face: a;}E)>U4sE9,,b@uM+#q\=,S)_go^*pb@M[' In message <9411030155.AA04337@sulphur.osf.org> you write: > I took a closer look. I have /bin/csh in /etc/passwd but my .vueprofile One problem with that approach is that you still end up running vuelogin, which sits around consuming a few Mbs of your swap area. You are best off turning it off and just using normal xdm. With this approach, I deleted my .vueprofile, which is the best solution! John From rc-owner Thu Nov 3 12:35:14 1994 Received: from archone.tamu.edu ([128.194.53.42]) by hawkwind.utcs.utoronto.ca with SMTP id <23980>; Thu, 3 Nov 1994 12:34:06 -0500 Received: from hp08.nas.nasa.gov ([129.99.50.32]) by archone.tamu.edu with SMTP id <11554>; Thu, 3 Nov 1994 11:31:10 -0600 Received: (from gray@localhost) by hp08.nas.nasa.gov (8.6.8.2/NAS.6) id JAA13672; Thu, 3 Nov 1994 09:26 :47 -0800 Date: Thu, 3 Nov 1994 12:26:47 -0500 From: "Scott C. Gray" To: rc-owner@hawkwind.utcs.toronto.edu, rc@archone.tamu.edu Subject: Re: rc, HP-UX, VUE, and me In-Reply-To: <9411030155.AA04337@sulphur.osf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 2 Nov 1994, Rich Salz wrote: > I took a closer look. I have /bin/csh in /etc/passwd but my .vueprofile > is > #! /bin/sh > exec rc -l $HOME/.xsession-vue > I just gave that a try, however, it still wouldn't let me log in through vuelogin. However, this time it at least gets to the copyright screen, then it goes blank and kicks me back out to vuelogin. Just to make sure, I placed "echo start >> /tmp/rc.test" at the beginning of my .rcrc, and "echo done >> /tmp/rc.test" at the end of it. My .rcrc is getting succesfully run, but somewhere after that, things are choking up. I have also made sure that I set SHELL=/bin/RC (I have a hard link between RC and rc), so that sh won't think that it is being called from a restricted shell. Any *more* suggestions? (*sigh* -- I miss rc) Thanks, -scott From rc-owner Thu Dec 1 18:11:16 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoront o.ca with SMTP id <24123>; Thu, 1 Dec 1994 18:07:40 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.2 49]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id SAA21417; Thu, 1 Dec 1994 18:07:30 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id SAA 29418; Thu, 1 Dec 1994 18:07:28 -0500 Date: Thu, 1 Dec 1994 18:07:28 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199412012307.SAA29418@penfold.cc.gatech.edu> To: es@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: rc, es, and 9term under Linux? Hi. I apologize in advance for the triple posting, since I know there's a lot of membership overlap, but I wanted to not miss anyone. I'm writing an article on sam/9term/9wm/rc/es for Linux Journal, and have hit the Linux specific part. Unfortunately (and ironically) I don't have a Linux system. So I need some help. 1. Does rc compile out of the box under Linux? If not, what has to be done to make it work? 1. Does es compile out of the box under Linux? If not, what has to be done to make it work? 3. Does 9term work under Linux? I know that it takes some work to get it to compile, but does it run ok, or are there problems? Thanks! Arnold From rc-owner Fri Dec 2 11:20:38 1994 Received: from burdell.cc.gatech.edu ([130.207.3.207]) by hawkwind.utcs.utoront o.ca with SMTP id <24123>; Fri, 2 Dec 1994 11:15:24 -0500 Received: from penfold.cc.gatech.edu (arnold@penfold.cc.gatech.edu [130.207.3.2 49]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id LAA29657; Fri, 2 Dec 1994 11:15:14 -0500 Received: (from arnold@localhost) by penfold.cc.gatech.edu (8.6.9/8.6.9) id LAA 29901; Fri, 2 Dec 1994 11:15:12 -0500 From: arnold@cc.gatech.edu (Arnold Robbins) Message-Id: <199412021615.LAA29901@penfold.cc.gatech.edu> Date: Fri, 2 Dec 1994 11:15:12 -0500 In-Reply-To: Arnold Robbins's 35-line message on Dec 1, 6:07pm X-Ultrix: Just Say NO! X-Important-Saying: Premature Optimization Is The Root Of All Evil. X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: es@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu, sam-fans@hawkwind.utcs.toronto.edu Subject: Re: rc, es, and 9term under Linux? (summary) Again, apologies for the triple post. I'll try not to do it again, except perhaps to announce the availability of the article when it's done. Thanks to everyone who replied. The upshot is that rc compiles with little problem, requiring minor changes to generate the sigmsgs.c file. es is similar, but this is noted in a comment in the Makefile. 9term can be made to compile under Linux, but apparently does not work quite right yet. At least one person is working on it but has not released his port yet. For those of you who asked "What is 9wm, and where can I get it?". The answer is that 9wm is an X11 window manager that completes the sam+9term+rc picture, emulating the window management policies of 8-1/2 (8½ for you unicode folks ⺠:-), hiding windows instead of iconifying them, click to type, thick border on the current window, etc. As to the second part of the question, you can't get it, yet. I've been beta-testing it. It is due for release REALLY REALLY REALLY SOON NOW, but as I'm not the author, I can't say when. (My article has around a two-month lead time before it's published, so by then 9wm should be out.) Rob, Bobf, Byron, Paul, Matty, and David, I would like to send you a copy to review when it's done. If you're not interested, please let me know. Thanks, Arnold Robbins "What's GNU" columnist for Linux Journal (Yet Another Alternate Identity) From rc-owner Thu Dec 8 13:26:51 1994 Received: from fester.cim.cdc.com ([129.179.44.89]) by hawkwind.utcs.utoronto.c a with SMTP id <24138>; Thu, 8 Dec 1994 13:24:17 -0500 Received: by fester.cim.cdc.com (920330.SGI/920502.SGI) for rc@hawkwind.utcs.toronto.edu id AA06809; Thu, 8 Dec 94 12:17:03 -06 00 Date: Thu, 8 Dec 1994 13:17:03 -0500 From: quanstro@fester.cim.cdc.com (goon) Message-Id: <9412081817.AA06809@fester.cim.cdc.com> To: Subject: fn sigint -> read: interrupted system call Apparently-To: rc@hawkwind.utcs.toronto.edu i've been having the following problem with rc on sgi irix 4. ; exec /bin/csh -f % rc ; fn sigint {echo fu} # ; fu read: Interrupted system call % the important thing to note is that the fact that the print routines are called by echo is key and that i think that this may be because sigchk() is called there. but my experimentation with the code didn't fix the problem; so perhaps there's something else going on here. any ideas? erik From rc-owner Thu Dec 8 13:32:07 1994 Received: from weaver-gw.netapp.com ([198.95.224.2]) by hawkwind.utcs.utoronto. ca with SMTP id <24139>; Thu, 8 Dec 1994 13:30:35 -0500 Received: from netapp.com ([192.9.200.1]) by weaver.netapp.com with SMTP id <15 927>; Thu, 8 Dec 1994 10:30:33 -0000 Received: from ghoti.netapp.com by netapp.com (4.1/SMI-4.1) id AA23181; Thu, 8 Dec 94 10:31:49 PST Received: by ghoti.netapp.com (4.1/SMI-4.1) id AA08444; Thu, 8 Dec 94 10:29:02 PST Date: Thu, 8 Dec 1994 13:29:02 -0500 From: byron@netapp.com (Byron Rakitzis) Message-Id: <9412081829.AA08444@ghoti.netapp.com> To: quanstro@fester.cim.cdc.com, rc@hawkwind.utcs.toronto.edu Subject: Re: fn sigint -> read: interrupted system call Yeah, this is a bug in the latest bundle (bungle?) of rc. Scott Schwartz had a fix which I have not got handy at my fingertips. Scott, if you have it do you want to repost?