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 m