pmt@sbcs.UUCP (04/09/87)
Yes, it's no April Fool joke. The PD C compiler exists and I've used
it. Someone mentioned that he has the lastest version, and has (by now)
posted it to James Turner.
Last night, I finally logged onto the Atari BBS, and downloaded a
public domain shell (called ash). If people are interested, I'll send it
to Turner.
I've been using PCOMMAND for a while now, but I just switched to the new
shell. Its commands are very similar to Csh, eg ls , rm , mv, mkdir, etc.
It also support a history mechanism, and previous command(s) line editing,
which is something NOT supported by PCOMMAND. Ash also has df, cat, grep.
It takes up about 70-80 K of memory.
Now the bad part. The cp command is very slow. Doing a rm *.* always
generate an error message saying "Can't remove .", and it quits. No
option for wide directory listing.
Actually, these flaws are very annoying that I'm considering getting
Beckermeyer's Cshell. Can someone tell me how much memory the
Beckermeyer Csh takes up? How good is it previous command line editing
facilities?
--
CSNET:pmt@sbcs.csnet
UUCP :{allegra, hocsd, philabs, ogcvax}!sbcs!pmt
In the path of our happiness shall we find the learning for which
we have choosen this lifetime.nowlin@ihuxy.UUCP (04/13/87)
In article <387@sbcs.UUCP>, pmt@sbcs.UUCP (Phil Tromovitch) writes: > > Last night, I finally logged onto the Atari BBS, and downloaded a > public domain shell (called ash). If people are interested, I'll send it > to Turner. > > I've been using PCOMMAND for a while now, but I just switched to the new > shell. Its commands are very similar to Csh, eg ls , rm , mv, mkdir, etc. > It also support a history mechanism, and previous command(s) line editing, > which is something NOT supported by PCOMMAND. Ash also has df, cat, grep. > It takes up about 70-80 K of memory. > > Now the bad part. The cp command is very slow. Doing a rm *.* always > generate an error message saying "Can't remove .", and it quits. No > option for wide directory listing. > > Actually, these flaws are very annoying that I'm considering getting > Beckermeyer's Cshell. Can someone tell me how much memory the > Beckermeyer Csh takes up? How good is it previous command line editing > facilities? > > -- > > CSNET:pmt@sbcs.csnet > UUCP :{allegra, hocsd, philabs, ogcvax}!sbcs!pmt > > In the path of our happiness shall we find the learning for which > we have choosen this lifetime. This is the first I've heard of ash (A SHell) on the net. I wrote it because I can't hack too much pointing and clicking. Fortunately I'm spoiled by UN*X and ksh so I stuck some history editing capabilities in that mimic the vi interface to ksh and most of the UN*X style commands. Ash has a few short comings but I'm working on some improvements now and I'll look into that rm problem. I'm taking suggestions for the cp problem (it's also a mv problem when files aren't on the same drive). I've tried lots of things to make it faster but nothing I know about can make it as fast as a desktop drag copy. I just bought Megamax C, mainly because it's supposed to do disk I/O faster and generate smaller code. I'm currently working on compiling ash with Megamax and while I'm at it I'll try to fix any of the little problems and nagging things that are bugging you. I also plan to make the memory allocation dynamic so ash runs leaner. If I can do it without too much rewriting I'm going to implement I/O redirection for the built-in commands while I'm at it. PLEASE send me any suggestions you have. I'm planning to post the thing to the net with an actual document instead of the HELP file in a few weeks. I have to make sure the port to Megamax is solid first. Just for information, ash was the shell used to port the Icon Programming Language to the ST so it has proved useful. Thanks. Jerry Nowlin (...!ihnp4!ihuxy!nowlin)
john@viper.UUCP (John Stanley) (04/17/87)
In article <1935@ihuxy.ATT.COM> nowlin@ihuxy.ATT.COM (Jerry Nowlin) writes: >In article <387@sbcs.UUCP>, pmt@sbcs.UUCP (Phil Tromovitch) writes: >> >> Now the bad part. The cp command is very slow. Doing a rm *.* always >> generate an error message saying "Can't remove .", and it quits. No >> option for wide directory listing. >> > >I'm taking suggestions for the cp problem (it's also a mv problem when >files aren't on the same drive). I've tried lots of things to make it >faster but nothing I know about can make it as fast as a desktop drag copy. >I just bought Megamax C, mainly because it's supposed to do disk I/O faster >and generate smaller code. I'm currently working on compiling ash with >Megamax and while I'm at it I'll try to fix any of the little problems and >nagging things that are bugging you. I also plan to make the memory >allocation dynamic so ash runs leaner. If I can do it without too much >rewriting I'm going to implement I/O redirection for the built-in commands >while I'm at it. > >PLEASE send me any suggestions you have. I'm planning to post the thing to >the net with an actual document instead of the HELP file in a few weeks. I >have to make sure the port to Megamax is solid first. Just for >information, ash was the shell used to port the Icon Programming Language >to the ST so it has proved useful. Thanks. > The slowest way to copy a file is character by character... Speed increases as the block size increases. You'll also get significantly faster disk i/o if you use the Fopen/Fread/Fcreate functions instead of the fopen/fread/fwrite. A friend and I wrote a shell which we installed in the version of Emacs we use, and later extracted it for use as a seperate shell. We Malloc (not malloc) the largest chunk of memory we can find, then Fread and Fwrite in monster sized chunks. It copys so fast it make the desktop look like it's transfering a -bit- at a time... :) [ Shell Writers, Please Read ---> One important thing I'd like to see -all- shell writers do is to get the old date and time properly transfered to the new file. It's not very complicated (takes about 5 lines of C) and makes the copy function -much- more useful... (Ever try using MAKE in a system where copying your files flakes out the date and time info? It doesn't work...! :( --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
bob@wiley.UUCP (Bob Amstadt) (04/19/87)
Posting-Front-End: GNU Emacs 18.36.2 of Mon Feb 23 1987 on orville (berkeley-unix) In article <859@viper.UUCP> john@viper.UUCP (John Stanley) writes: > One important thing I'd like to see -all- shell writers do is to get > the old date and time properly transfered to the new file. It's not > very complicated (takes about 5 lines of C) and makes the copy function > -much- more useful... (Ever try using MAKE in a system where copying > your files flakes out the date and time info? It doesn't work...! :( I disagree. It is very important copy updates the date to the current date and time. Example: I make some changes to a file which later proves to be damaging or useless. I get back the original source from a backup. This constitutes a change and therefore should affect the last modified date. If you are using MAKE, then you shouldn't move your files (at least not very often). Bob Amstadt bob@wiley.uucp (UUCP) trwrb.uucp!wiley!bob (Alternate UUCP) csvax.caltech.edu!wiley!bob (Alternate UUCP or ARPA)