From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: Bengt Kleberg Message-ID: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit References: , <406C1811.5030306@swtch.com> Subject: Re: [9fans] acme, rio workalike available in plan 9 ports Date: Fri, 2 Apr 2004 09:29:49 +0000 Topicbox-Message-UUID: 4ebcac90-eacd-11e9-9e20-41e7f4b1d025 Russ Cox wrote: > Bengt Kleberg wrote: ...deleted >> is it correct to assume that this unportableness of rc scripts is the >> reason for using /bin/sh all over the place? including in mk, which is >> not entirely to my liking. > > > > the reason mk uses sh is that it came before rc. > i'm not sure what to do here. i'm not convinced > rc is quite stable enough to be used in mk. i would conjecture that we have not one, but two ''mk''. one from mk-20040301.tgz that is of interest to a unix user that wants a new ''make'', but is not interested in plan9. this mk does not need to use ''rc''. the other ''mk'' is the one in plan9-20040321.tar.gz. this mk will be used by someone interested in plan9. i belive that this mk should use rc. if rc is not stable enough it should be made stable enough. a _starting point_ for testing plan9 rc could be the ''trip'' test that comes with byrons rc. since it is never a good idea to have different commands with the same name (provided we have the same context. in this case unix) i suggest that one of the two mk are renamed. the one to rename, imho, is the one that uses sh. possible names would be: smk, umk (or mks, mku). ...deleted >> >> how about ignoring those that have the same home directory on several >> architectures? this leaves ''only'' the simpler problem of installing >> different files into $PLAN9/bin depending upon architecture. > > > > how does this differ from what i am currently doing? in plan9-20040321.tar.gz the ''ps'' command installed in $PLAN9/bin did not work on SunOS. i think it was working on another architecture. my solution was to choose/build the correct ''ps'' during install. i see that ''ps'' in plan9-20040330.tar.gz has solved the problem by detecting SunOS at runtime instead. about the new ''ps''. (a warning here. i am using openbsd man pages to interpret ''-axww''. this could very well be wrong since you presumably did now create ''ps'' on openbsd. however, openbsd seems to have the best man pages available online. please correct me if i am mistaken.) the ''x'' flag on openbsd means "Display information about processes without controlling terminals." the ''a'' flag on SunOS means "Lists information about all processes most frequently requested: all those except process group leaders and processes not associated with a terminal." i am not a native english speaker but my interpretation is that ''a'' does not include processes without controlling terminals. i therefore suggest that it is removed. ''A'' on its own should work. bengt