drew@cgofs.dec.com (Steve Drew) (01/23/88)
First of all there is no Shell 2.08M, yet.
And there wont be for a little while, (as least from me).
Since I'm pretty tied up, for a couple of weeks. And then
on holidays (florida) for a couple more.
What I would like include in version 2.08M:
1. $_titlebar variable,
--------------------
- ability to set title bar via variable.
eg. alias cd "%q \\cd $q; set _titlebar $_cwd"
Problem, when quiting shell, the memory allocated for the titlebar
variable is free'd, and next time someone clicks on the title it
blanks out. What would be the best way to handle this? maybe
AllocMem() the few bytes for the string, and never free it?
2. Iconify,
-------
Turn in to an icon via command, or funtion key ect..
Problem,
I could use Leo's subroutine for this, except, since the window
actually gets closed, and a new one reopen'd; how do you tell
the console handler that your window ptr has changed. Other wise
when you quit out of shell and endcli, the console handler, I
assume, will try to use close the window using the original
window ptr.
Any advice for problems mentioned above?
3. Dir command,
------------
Add more options, as per suggestions I have received.
4. File comment support,
--------------------
Allow to set file comment, and ability to have the comment
copied, when copying.
Anymore reasonable suggestions welcome.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Drew at ENET: CGFSV1::DREW
ARPA: drew%cfgsv1.dec.com@decwrl.dec.com
USENET: {decvax!decwrl}!cgfsv1.dec.com!drew
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~richard@gryphon.CTS.COM (Richard Sexton) (01/24/88)
Steve Drew writes: > > First of all there is no Shell 2.08M, yet. > > And there wont be for a little while, (as least from me). > Since I'm pretty tied up, for a couple of weeks. And then > on holidays (florida) for a couple more. > > What I would like include in version 2.08M: > > 1. $_titlebar variable, > 2. Iconify, > 3. Dir command, > 4. File comment support, > Anymore reasonable suggestions welcome. Geez, I dunno, what do you call reasonable ? :-) I have two things I'd like to see. 5. "Screen history". Incorperate the idea in the _rollback_ program to save all that text that just scrolled off the top of your screen. Have a user sizable local memory buffer and page off to the disk. 6. "Seperate input and output windows". Like Apollo's. The bottom line is the input window, and there is a horizontal line painted above it. All output goes to the window above the input line. Input is typed into the input window and the commands "stack up" as the horizontal line is moved up: | <-- crude simulation of diagram | dir of the lower left portion of | Directory of: foo your screen. | .login ---------------------- | > date +--------------------- Now, at this point, on an amiga, hitting the 'd' key in date stops the output from the directory listing and waits for you to terminate the input with a <CR> or some such. What the you gain with a seperate input window is not mixing text from input and output. In the above example if the still hadnt processed the date command on the apollo, it would have stacked up: | | dir | Directory of: foo | .login foo1 foo2 | .now .then .never | 6 very silly files in this directory +----------------------------------------- | date | > cat foo1 ------------------------------------------ The input window expands to two lines, the input is held there safely, out of output stream and incomprehensability. As the system processes the input, the input window contracts. | | | | .login foo1 foo2 | dir | .now .then .never | Directory of: foo | 6 very silly files in this | .login foo1 foo2 | date | .now .then .never | Right now t's 10:45. That' | 6 very silly files in this directory | cat foo1 | date | 1 of 2 lines of foo1. | Right now it's 10:45. That's $0.10. | 2 of 2 lines of foo1. +------------------------------------ +------------------------ | > cat foo1 | > +------------------------------------ +------------------------- Just an idea. -- "...and before too long I might, see those flashing red lights" richard@gryphon.CTS.COM {ihnp4!scgvaxd!cadovax, philabs!cadovax, codas!ddsw1} gryphon!richard
spencer@eris (Randal m. Spencer [RmS]) (01/24/88)
Recently on *comp.sys.amiga* richard@gryphon.CTS.COM (Richard Sexton) wrote: ... ...I have two things I'd like to see. ... ... 6. "Seperate input and output windows". Like Apollo's. ... The bottom line is the input window, and there is a horizontal ... line painted above it. All output goes to the window above ... the input line. Input is typed into the input window ... and the commands "stack up" as the horizontal line ... is moved up: I am sure that Pete Goodeve will comment on his Sili(con:) program, that has a very similar user interface so the one you discribe. It opens a window in the upper right the bottom line of which is the current command, above that (seperated by a line) are all the previous commands, and then the original CLI window takes care of output in almost exactly the way you mentioned. Additional advantages include the ability to click on commands in the history list to re-execute them, and clicking and editing commands. The thing I don't like, which must apply to yours also, is how do you stop scrolling. On the single command line I can type a space and boom! no more output until *I* say. What does the Apollo do? ... ...Just an idea. ... richard@gryphon.CTS.COM -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)222-7595 spencer@mica.berkeley.edu I N F I N I T Y BBS: (415)222-9416 ..ucbvax!mica!spencer s o f t w a r e AAA-WH1M -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
jw@sics.se (Johan Widen) (01/25/88)
In article <8801221705.AA20640@decwrl.dec.com> drew@cgofs.dec.com (Steve Drew) writes: > What I would like include in version 2.08M: ... > Anymore reasonable suggestions welcome. One feature that I would like to see is file name completion: You type part of a file name. If you then hit the "completion key" the shell will try to complete the file name for you. This feature is available in GNU Emacs, in tcsh and in csh (under 4.3BSD). This might be a bit slow in a large directory on a disk but should work well in a small directory or on a ram disk. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Steve Drew at ENET: CGFSV1::DREW > ARPA: drew%cfgsv1.dec.com@decwrl.dec.com > USENET: {decvax!decwrl}!cgfsv1.dec.com!drew >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Johan Widen SICS, PO Box 1263, S-164 28 KISTA, SWEDEN Tel: +46 8 752 15 32 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30 Internet: jw@sics.se or {mcvax,munnari,ukc,unido}!enea!sics.se!jw
richc@vaxwaller.UUCP (Rich Commins) (01/28/88)
In article <8801221705.AA20640@decwrl.dec.com>, drew@cgofs.dec.com (Steve Drew) writes: > > First of all there is no Shell 2.08M, yet. I've been using your shell and think it's great. Looks just like my Unix environment at work. At work, I customize my prompt so the prompt increments with my history variable. It looks like this.... (1) > command 1 (2) > command 2 (3) > command 3 (4) > etc. I use this information from my prompt to reference the history file. My question is "can I customize the prompt in the shell to do the same thing"? In Matt's version of the shell he executed a command script. Any help with this would be appreciated. Also it doesn't seem obvious to me how the variables work with the alias commands. Could you elaborate on their usage (Yes I've read the readme.doc's) Thanks, -- -- Rich Commins (415)939-2400 \ /\ Varian Instruments, 2700 Mitchell Drive, Walnut Creek, CA 94598 \/--\ {ptsfa,lll-crg,zehntel,dual,amd,fortune,ista,rtech,csi,normac}varian!richc
cks@radio.toronto.edu (Chris Siebenmann) (01/31/88)
In article <8801221705.AA20640@decwrl.dec.com> drew@cgofs.dec.com (Steve Drew) writes:
...
: 1. $_titlebar variable,
: --------------------
: - ability to set title bar via variable.
: eg. alias cd "%q \\cd $q; set _titlebar $_cwd"
:
: Problem, when quiting shell, the memory allocated for the titlebar
: variable is free'd, and next time someone clicks on the title it
: blanks out. What would be the best way to handle this? maybe
: AllocMem() the few bytes for the string, and never free it?
I noticed this problem myself about two days after I posted my
modification to Hobie's patch. What I did was to save the old window
title on startup, and restore it on exit. I think doing that is better
than swiping some memory permanently for a title; I tend to run
recursive shells and shells from withing makefiles a lot, and would
hate to lose some memory each time. I agree that a _titlebar variable
is a cleaner way to do title bar changing than the cd/pwd hack.
--
"I shall clasp my hands together and bow to the corners of the world."
Number Ten Ox, "Bridge of Birds"
Chris Siebenmann {allegra,mnetor,decvax,pyramid}!utgpu!radio!cks
cks@radio.toronto.edu or ...!utgpu!{chp!hak!ziebmef,ontmoh}!cksugmiker@sunybcs.uucp (Michael Reilly) (02/04/88)
In article <1698@sics.se> jw@sics.se (Johan Widen) writes: >In article <8801221705.AA20640@decwrl.dec.com> drew@cgofs.dec.com (Steve Drew) writes: >> What I would like include in version 2.08M: >... >> Anymore reasonable suggestions welcome. > >One feature that I would like to see is file name completion: >.... >This might be a bit slow in a large directory on a disk but should work well >in a small directory or on a ram disk. > >> Steve Drew at ENET: CGFSV1::DREW >Johan Widen But if you had a cache just holding a directory system of the mounted disks (maybe in a specially designed format for easy traversing), you could go through the available commands (files) quicker. I don't have my Facc II yet (have yet to send my facc in for updating), but perry said it would have the ability of talking to other programs, could this be used to get changed files names ?? maybe?? just an idea.. File completion is cool, and there has to be some way of implementing it fast. Michael Reilly University of Buffalo Computer Science CSNET: ugmiker@buffalo.CSNET BITNET: ugmiker@sunybcs.BITNET INTERNET: ugmiker@{joey,marvin}.cs.buffalo.edu UUCP: ..!{nike|watmath,alegra,decvax}!sunybcs!ugmiker
ejkst@cisunx.UUCP (Eric J. Kennedy) (02/05/88)
Here's what I would like to see in Shell 2.08M: I would like it to respond correctly to 'volume xxx has a read/write error' requesters. When I'm copying a file to a disk and encounter an error, I can hit cancel all day, and do nothing but wear my drive out. If I take the disk out, I get 'you MUST replace volume xxx in drive n!!!' Shell should give up after one or two 'cancel's on the first requester, and tell you it can't open the file, or something. I crashed twice the other day because of this one. (ever notice that the longer you use your amiga, the more expensive crashes become? 'cause you keep adding utilities, using multitasking more, etc...) Eric Kennedy ejkst@cisunx.UUCP
pds@quintus.UUCP (Peter Schachte) (02/05/88)
In article <1698@sics.se>, jw@sics.se (Johan Widen) writes: > > What I would like include in version 2.08M: > One feature that I would like to see is file name completion: > You type part of a file name. If you then hit the "completion key" > the shell will try to complete the file name for you. Amen. I use filename completion all the time under Unix, and would love to have it on my Amiga. Two other things: It would be nice if you could catch ^C,D, etc. I sometimes hit this accidentally, and get bounced out of the shell altogether. Since there's another way to get out, it would be nice if this didn't bounce you. (I'm using an older version of the shell, so maybe this is already fixed.) Also it would be nice if I could bind my own control characters to edit as I like. It's hard for me to remember the shell's control codes, since I'm an emacs user. To me, ^A means beginning-of-line, and ^D means delete-next-character (which is why I keep bouncing myself out of the shell). I'd modify the sources, but I don't have Aztec C, just Lattice. And thanks, Steve and Matt, for a shell well done! -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
sdk@CS.UCLA.EDU (02/05/88)
I also would be very interested in file name completion for shell 2.08M. I think with faccII it might work quite well. If it is rather slow a user can just not use it. I would also like to see a way of binding the command line editing keys without having to recompile the shell. I also hacked the shell to put in a very simple version of dirs, pushd, and popd. I don't know if this is a feature that others would make much use of. -Scott
mrr@amanpt1.UUCP (Mark Rinfret) (02/08/88)
In article <6701@cisunx.UUCP>, ejkst@cisunx.UUCP (Eric J. Kennedy) writes: > > Here's what I would like to see in Shell 2.08M: I would like it to > respond correctly to 'volume xxx has a read/write error' requesters. > When I'm copying a file to a disk and encounter an error, I can hit > cancel all day, and do nothing but wear my drive out. If I take the > disk out, I get 'you MUST replace volume xxx in drive n!!!' > ... Eric - you're describing the same symptoms that I have encountered. I recently posted an article with a short program that demonstrates this (and runs stand- alone). I believe the problem to be in AmigaDOS and not the Shell. > Eric Kennedy > ejkst@cisunx.UUCP Mark -- < Mark R. Rinfret, mrr@amanpt1.ZONE1.COM | ...rayssd!galaxia!amanpt1!mrr > < Aquidneck Management Associates Home: 401-846-7639 > < 6 John Clarke Road Work: 401-849-8900 x56 > < Middletown, RI 02840 "If I just had a little more time...">
steveb@cbmvax.UUCP (Steve Beats) (02/09/88)
In article <408@amanpt1.UUCP> mrr@amanpt1.UUCP (Mark Rinfret) writes: >In article <6701@cisunx.UUCP>, ejkst@cisunx.UUCP (Eric J. Kennedy) writes: >> >> Here's what I would like to see in Shell 2.08M: I would like it to >> respond correctly to 'volume xxx has a read/write error' requesters. >> When I'm copying a file to a disk and encounter an error, I can hit >> cancel all day, and do nothing but wear my drive out. If I take the >> disk out, I get 'you MUST replace volume xxx in drive n!!!' >> ... > >Eric - you're describing the same symptoms that I have encountered. I recently >posted an article with a short program that demonstrates this (and runs stand- >alone). I believe the problem to be in AmigaDOS and not the Shell. > >> Eric Kennedy >> ejkst@cisunx.UUCP > >Mark > I haven't been following this thread, but this article caught my eye. I think the problem is in AMigaDOS and is related to the dreaded 3 second timeout. DOS is trying to write the bitmap back to disk because it has been altered but the blocks allocated for the bitmap are bad. Since the FS doesn't take this possibility into consideration, it constantly loops. Fixed in FFS. Steve
anthes@geocub.UUCP (Franklin Anthes) (02/09/88)
While we're on the subject of shell 2.08, how about fixing a bug ( think) in 2.07: I have a set f4 "dir -s !*.info^M" in my shell startup file which works just dandy. But I also had an alias lf "dir -s !*.info^M", which didn't work. That is to say that the .info files showed up anyway! Now it took me a while to notice that the "^M" at the end of the alias was supefluous, and that it was the culrit! Now can't the parser ignore this extra carriage return at the end of the alias? I know it's a small gripe, but it took me quite a long time to figure out what was going on... So maybe it can get fixed? -- Frank Anthes-Harper Usenet: ....!ucbvax!decvax!uunet!mcvax!inria!geocub!anthes
ejkst@cisunx.UUCP (Eric J. Kennedy) (02/10/88)
In article <408@amanpt1.UUCP>, mrr@amanpt1.UUCP (Mark Rinfret) writes: > In article <6701@cisunx.UUCP>, ejkst@cisunx.UUCP (Eric J. Kennedy) writes: > > respond correctly to 'volume xxx has a read/write error' requesters. > > When I'm copying a file to a disk and encounter an error, I can hit > > cancel all day, and do nothing but wear my drive out. If I take the > > Eric - you're describing the same symptoms that I have encountered. I recently > posted an article with a short program that demonstrates this (and runs stand- > alone). I believe the problem to be in AmigaDOS and not the Shell. > > > Eric Kennedy > > ejkst@cisunx.UUCP > > Mark > Yes, I saw your post after I left mine. I can see why you're saying it's an AmigaDOS problem, but if that's the case, why are there some programs that handle a read/write error correctly? i.e. stop trying to write to the the disk and tell you it can't open the file or something. I wish I could give you an example of such a program, but I don't remember. I may be remembering wrong, anyway, it's been a while since I've had a bad disk using anything but Shell. Anybody else confirm or deny this? More specifically, the question is when you encounter a read/write error, does every program you use fail to handle it correctly, or do some programs actually detect the error and stop? -- ------------ Eric Kennedy ejkst@cisunx.UUCP