koren@hpfelg.HP.COM (Steve Koren) (11/22/89)
Message to SKsh (was Ash) users:
------------------------------------------------------------------
Now that SKsh version 1.2 is out (the release version, which might
not have appeared in c.b.a quite yet), I have fixed most of the major
problems, and I have some time think about what would be useful in
the future. I have gotten a whole bunch of mail from people with
useful ideas, so I thought I'd post some of the ideas here, roughly
in order of the number of people who seem to want them. Also, there
are a few of my own. If anyone has anything to add to this list,
please contact me. I'll probably do these things based on some combination
of their difficulty and the number of people who want them. I won't
include in this list the things people have asked for which made it
into version 1.2 (there were alot of those).
* ARexx support (coming as soon as I can do it; I ordered ARexx this
week) [ around 20 requests ]
* Ability to use resident programs (coming as soon as I figure out
how - unless its as *ugly* as the normal method to execute
programs when you have a seglist pointer, in which case I
won't do it until the interface gets better)
Also, SKsh is already pure in 1.1 and later.
[ 9 requests ]
* Hidden bit support ( trivial - definitely coming in SKsh 1.3 )
[ 3 requests]
* Filenote support (not hard - maybe coming in 1.3)
[ 2 requests ]
* Don't search unmounted volumes in path (as soon as I figure out how)
[ 2 requests ]
* vi style editing (not soon - harder to do than emacs editing, and
would make the binary much bigger (maybe 10K))
[ 1 request ]
* "here documents" (under investigation; useful for shar archives)
[ 1 request ]
* stderr redirection (not possible on Amiga, or at least not reasonably)
[ 1 request ]
* A command to change the priority of other tasks (probably coming soon)
[ 3 requests ]
* Case insensitive pattern matching flag (probably coming)
[ 4 requests ]
* tiny-sksh (would anyone be interested? I can reduce memory usage
by hacking out some not-often used features, making
hash table sizes smaller, etc - it would not support the
full functionality of SKsh, of course - what should go
and what should stay?? )
[ no requests - my idea ]
* a command to move and windows from a script (anybody want it?)
[ no requests - my idea ]
Anything else???
- stevepeter@sugar.hackercorp.com (Peter da Silva) (11/25/89)
In article <13920018@hpfelg.HP.COM> koren@hpfelg.HP.COM (Steve Koren) writes: > * Filenote support (not hard - maybe coming in 1.3) Why would the shell need to know about filenotes? * csh style editing. > * "here documents" (under investigation; useful for shar archives) This is pretty important to me. > * tiny-sksh Just remove most of the builtins (test, etc) and make them seperate programs. Like the bourne shell. That should help a bunch. > * a command to move and windows from a script (anybody want it?) This should be another external program. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "Really, a video game is nothing more than a Skinner box." -- Peter Merel <pete@basser.oz>
stephen@hpdml93.HP.COM (Stephen Holmstead) (11/28/89)
Peter da Silva writes: >In article <13920018@hpfelg.HP.COM> koren@hpfelg.HP.COM (Steve Koren) writes: >> * tiny-sksh > >Just remove most of the builtins (test, etc) and make them seperate >programs. Like the bourne shell. That should help a bunch. I second this. Steve Koren wanted to know of additional features wanted: On the filename expansion, if an exact match is not available, then expand as much as possible. For example, in a directory with the filenames "foobar" and "foobat", when you type the expand key, it should expand to "fooba" and beep to tell you that an exact match wasn't made. At this point, you can manually type the "r" or the "t" yourself. Also, could you put the '-F' flag on your 'ls' program? This flag will let you tell the difference between files and directories. It puts a '/' after files that are directories, '@' after files that are links, '*' after files that are executables, and nothing after everything else. The PD 'ls' program I am using currently will write the names of the directory in a different color (this would also be acceptable). Either that, or allow us a way to replace your built-in 'ls' with one of our own. Overall, I am *VERY* happy with the shell that you have written. Keep up the good work. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Stephen Holmstead ...!hplabs!hpdmlge!stephen // Hewlett Packard Disk Memory Division \X/ Amiga Forever! "I remind you that humans are only a tiny minority in this galaxy." -- Spock, "The Apple," stardate 3715.6.
koren@hpfelg.HP.COM (Steve Koren) (11/29/89)
> On the filename expansion, if an exact match is not available, then > expand as much as possible. For example, in a directory with the > filenames "foobar" and "foobat", when you type the expand key, it > should expand to "fooba" and beep to tell you that an exact match > wasn't made. At this point, you can manually type the "r" or the "t" > yourself. Try it, it works. It has always done as much of the expansion as it can do. > Also, could you put the '-F' flag on your 'ls' program? This flag will > let you tell the difference between files and directories. It puts a > '/' after files that are directories, '@' after files that are links, > '*' after files that are executables, and nothing after everything else. There is a -F option on the 'ls' command in SKsh 1.2, although it works slightly differently than in Un*x (you can change colors, for example). > that, or allow us a way to replace your built-in 'ls' with one of our You can do that, too. Use something like: alias ls='$(which ls)' or alias ls='sys:bin/ls' - steve
peter@sugar.hackercorp.com (Peter da Silva) (11/30/89)
In article <13920021@hpfelg.HP.COM> koren@hpfelg.HP.COM (Steve Koren) writes: > You can do that, too. Use something like: > alias ls='$(which ls)' I hope this is a typo. Please tell me you don't to variable expansion inside single-quotes. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "Really, a video game is nothing more than a Skinner box." -- Peter Merel <pete@basser.oz>
coco@cbnewsl.ATT.COM (felix.a.lugo) (12/01/89)
>> In article <13920021@hpfelg.HP.COM> koren@hpfelg.HP.COM (Steve Koren) writes: >> > You can do that, too. Use something like: >> >> > alias ls='$(which ls)' >> >> I hope this is a typo. Please tell me you don't to variable expansion inside >> single-quotes. >> -- >> Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> >> `-_-' >> 'U` "Really, a video game is nothing more than a Skinner box." >> -- Peter Merel <pete@basser.oz> >> .... Earth to Peter ... Earth to Peter ... 8^) First, I create an alias: alias test='$(which ls)' Let's see!!! I type "alias (set -a)" (quotes not included) and I get . . . test = $(which ls) . . . (No variable expansion, as was expected). Now, if I type "which ls" (again, quotes not included), I get sys:bin/ls [ sys:bin is where I keep "ls" ] If I type "$(which ls) -a", I get a Usage message from the "ls" command under sys:bin. With me so far???!! Now I type "test -a". I got the same Usage message!!! What could all this mean? That Steve Koren knows his stuff!!! 8^) Good job Steve!!!!!!!! ______________ Felix A. Lugo coco@ihlpy.att.com att!ihlpy!coco
peter@sugar.hackercorp.com (Peter da Silva) (12/01/89)
???> alias ls='$(which ls)'
Me> I hope this is a typo. Please tell me you don't to variable expansion inside
Felix> .... Earth to Peter ... Earth to Peter ... 8^)
Right. It still works. Personally I'd rather call 'which' at "compile time"
when the alias was defined, rather than when it's used. Which is why it looked
like he was doing variable expansion inside ''.
Or... don't tell me... which is another built-in?
Hey, Steve. You want to cut a whole bunch of stuff out of sksh? Get rid of all
the builtins!
--
Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com>
`-_-'
'U` "Really, a video game is nothing more than a Skinner box."
-- Peter Merel <pete@basser.oz>andrewt@watsnew.waterloo.edu (Andrew Thomas) (12/02/89)
In article <13920021@hpfelg.HP.COM> koren@hpfelg.HP.COM (Steve Koren) writes: > that, or allow us a way to replace your built-in 'ls' with one of our You can do that, too. Use something like: alias ls='$(which ls)' or alias ls='sys:bin/ls' - steve You mean 'which' will not inform me that I'm actually using a shell builtin???? I would have reported this as a BUG. -- Andrew Thomas andrewt@watsnew.waterloo.edu Systems Design Eng. University of Waterloo "If a million people do a stupid thing, it's still a stupid thing." - Opus
koren@hpfelg.HP.COM (Steve Koren) (12/04/89)
>I hope this is a typo. Please tell me you don't to variable expansion inside >single-quotes. No, it is not a typo. In following with the Un*x convention, variables are only expanded inside double quotes. There are a number of reasons why this is necessary. - steve
koren@hpfelg.HP.COM (Steve Koren) (12/05/89)
> Or... don't tell me... which is another built-in? > Hey, Steve. You want to cut a whole bunch of stuff out of sksh? Get rid of all > the builtins! I like this idea, though I think the best route is to supply two binaries, one with the builtins and one without. Hard drive users tell me "get rid of the builtins" and floppy users tell me "add more builtins". I don't think I can get rid of *all* the builtins (like the exit command, for example), but certainly many of them. Anyhow, I will probably be doing this; perhaps for the 1.4 release of SKsh. There is alot more work than just trimming stuff out; have to create another set of install docs, more test scripts, make sure that large-sksh users know they don't have to install the external "which" command, etc. This is just a guess, but I think I may be able to save perhaps 30K or so with a small-sksh. - steve
gerry@pencilbox.uucp (Gerry Lachac) (12/08/89)
Since I only have ASH (haven't been able to find SKsh yet, where is
it?) I found two things (so far) I would like to see SKsh do. It might
already do it, but like I said, I haven't seen the latest yet.
1) In sh/ksh I can do this:
FILES=(one.txt two.txt three.txt)
for i in $FILES
And i will be each one of the files defined in the first line. I
tried it, and it didn't work with my version of ASH. This of course,
also should work with wildcards:
FILES=(dh0:man/*)
2) This is something that I use in tcsh that I would like to see in
SKsh since it already does filename completetion. I can best describe
it by example. My directory has:
amiga.txt.1 amy.list fred.txt
I am at the prompt and I type:
PROMPT> am<TAB>
The shell should beep indicating I have multiple choices. In addition
if I hit <CTRL-D> it should list my possible choices as:
amiga.txt.1 amy.list
Forgive my rambling, but this is my wishlist.
uunet!dialogic!gerry | "Even a dead plant turns | Dialogic Corporation
OR | over a new leaf | 300 Littleton Rd
gerry@dialogic.UUCP | when the wind blows." | Parsippany, NJ 07054
| | (201)334-8450bader+@andrew.cmu.edu (Miles Bader) (12/09/89)
koren@hpfelg.HP.COM (Steve Koren) writes: > > Or... don't tell me... which is another built-in? > > > Hey, Steve. You want to cut a whole bunch of stuff out of sksh? Get rid > > of all the builtins! > > I like this idea, though I think the best route is to supply two binaries, > one with the builtins and one without. Hard drive users tell me "get rid of > the builtins" and floppy users tell me "add more builtins". I don't think > I can get rid of *all* the builtins (like the exit command, for example), > but certainly many of them. Why exactly do you need builtins at all, even on a floppy disk, given the existance of REZ? [Which has the large advantage of letting the USER decide which commands take up memory space...] -Miles
jac@muslix.llnl.gov (James Crotinger) (12/09/89)
Why not do this: put the builtins into a library. Then sksh could look for the library and use it if it's there, not use it if it ain't. Depending on how sksh works, this might make better use of memory too. Also, you could release the specs for the library so others could extend it if they liked. Jim
kim@uts.amdahl.com (Kim DeVaughn) (12/10/89)
In article <AZTz25K00Uka8Bt052@andrew.cmu.edu>, bader+@andrew.cmu.edu (Miles Bader) writes: > > Why exactly do you need builtins at all, even on a floppy disk, given the > existance of REZ? [Which has the large advantage of letting the USER decide > which commands take up memory space...] I am all for leaving it up to the user to decide which commands, or specific implementations thereof, to use. Absolutely. However, there is a fundemental problem that exists that builtin's allow you to get around. That is the braindamaged limitation on the length of the command line that AmigaDOS can handle. Something like 256 bytes. Ridiculous! Sure, that is long enough for most things, but it is a real pain to try and deal with directories that may have, oh, say 1200 files in them (such as root0:spool/news/comp/sys/amiga frequently has on my machine). Is it possible this limitation will be removed under 1.4? How about 1.5? 1.6? How about going so far as to make it *dynamic* ... or allowing the *user* to decide how much buffer area to burn? Arbitrary, hard-coded limits like this really turn me off (and yes, I know there are a bunch of them in UN*X, too)! Grrrrrrr .... /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
peter@sugar.hackercorp.com (Peter da Silva) (12/11/89)
In article <bfea02ID72lX01@amdahl.uts.amdahl.com> kim@uts.amdahl.com (Kim DeVaughn) writes: > I am all for leaving it up to the user to decide which commands, or specific > implementations thereof, to use. Absolutely. Here's an idea... it requires (a) having a special flag on a file somewhere, and (b) adding a new case to the startup module. If the flag is set, then make SKSH do a workbench-style start with a modified struct WBStartup. Maybe make sm_NumArgs negative to flag that it's new and replace: char *sm_ToolWindow; struct WBArg *sm_ArgList; } with something like: LONG sm_ReturnCode; BPTR sm_StandardInput; BPTR sm_StandardOutput; char **sm_ArgV; } Then make the new modules use this structure. When they finish they set sm_ReturnCode to the value of exit(), and bounce it back to the parent. This method of launching programs is much cleaner than the CLI's, and if an innovative must-have new tool like SKSH started using it it'd really take off. > Is it possible this limitation will be removed under 1.4? It can be removed under 1.3, and *we* can do it! > Arbitrary, hard-coded limits like this really turn me off (and yes, I know > there are a bunch of them in UN*X, too)! Grrrrrrr .... Yeh, weren't we just speaking about arbitrary hard-coded limits? -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"
mwm@violet.berkeley.edu (Mike (With friends like these, who needs hallucinations) Meyer) (12/11/89)
In article <bfea02ID72lX01@amdahl.uts.amdahl.com> kim@uts.amdahl.com (Kim DeVaughn) writes:
<I am all for leaving it up to the user to decide which commands, or specific
<implementations thereof, to use. Absolutely.
Yes indeed!
<However, there is a fundemental problem that exists that builtin's allow you
<to get around. That is the braindamaged limitation on the length of the
<command line that AmigaDOS can handle. Something like 256 bytes. Ridiculous!
It's 25[56] bytes. The problem is really with BCPL, though. It can't
handle string longer than that because it encodes the length of the
string in a byte.
Since 1.4 is now in C (or so everyone assures me), this should now be
fixable. Bill Hawes has a patch for Execute that allows the strings to
be arbitrarily long - after all, the caller has allocated the space,
so bother limiting it? He also has versions of WShell and ARexx
(inhouse test only, unfortunately) which allow arbitrarily long
strings. Long lines break a lot of things (I think he said "most of
ARP", but it's been a while), including some of his code (now fixed).
That looks like a reasonable route to me for ksh, though. Push
everything out to res, or a shared library.
The shared library approach is particulary appealing if the libraries
use the WSHell format. That would allow for WShell users to import the
sksh libraries, and sksh users who own WShell to use the WShell
libraries.
To add a real request: I'd like the () notation form anonymous
pipelines that Unix ksh has. A string delimited by () is run as a
command pipeline, with it's standard output going to an anonymous
pipe. That pipe's name is substituted in the command line. So you can
diff the sorted versions of two unsorted files by:
diff (sort file1) (sort file2)
I don't know of anyway to do this without some form of temporary file
(AmigaDOS gets to put them in PIPE:, of course) without such a
feature.
<mike
--
My feet are set for dancing, Mike Meyer
Won't you turn your music on. mwm@berkeley.edu
My heart is like a loaded gun, ucbvax!mwm
Won't you let the water run. mwm@ucbjade.BITNETkoren@hpfelg.HP.COM (Steve Koren) (12/11/89)
> Since I only have ASH (haven't been able to find SKsh yet, where is > it?) I found two things (so far) I would like to see SKsh do. It might Yup, 1.2 is very much more stable than either of the Ash versions. 1.3 will probably be appearing in around a month or so (sometime after the holiday season winds down) and it has the largest list of enhancements and fixes yet. > 1) In sh/ksh I can do this: > FILES=(one.txt two.txt three.txt) > for i in $FILES Well, you can can do it in Sksh, but you have to use quotes instead of parens: FILES='one.txt two.txt three.txt' for i in $FILES That will work, although it depends on the setting of $IFS. > FILES=(dh0:man/*) try: for i in dh0:man/* or, FILES=$(echo dh0:man/*) for i in FILES > The shell should beep indicating I have multiple choices. In addition > if I hit <CTRL-D> it should list my possible choices as: > > amiga.txt.1 amy.list In Sksh (1.2), you can list the possible choices by using <esc>-=. (This is the same keystroke that ksh uses). Also, <esc>-* is supported. > Forgive my rambling, but this is my wishlist. Most of it is accomplishable(??) in 1.2. - steve
koren@hpfelg.HP.COM (Steve Koren) (12/11/89)
> > I like this idea, though I think the best route is to supply two binaries, > > one with the builtins and one without. Hard drive users tell me "get rid of > > the builtins" and floppy users tell me "add more builtins". I don't think ... > Why exactly do you need builtins at all, even on a floppy disk, given the ^^^^^^ > existance of REZ? [Which has the large advantage of letting the USER decide Well, there are a few reasons: 1) First of all, if you REZ (or resident) everything, you will consume *much* more space than by building it into the shell. For example, the 'basename' command probably consumes but 80 or so bytes (just a guess), but in compiled C it would probably be 4 or 5 K (again, a guess). If you add this up over the course of all the builtins, you get a huge amount of stuff resident. You can partially solve this by only making resident a few of the builtins, but if the whole shell is made resident, you only pay this price once anyhow. 2) As Kim points out, AmigaDos limits external command lines to a very small length (something like 256 chars). This causes a problem for things like 'externcmd *', where '*' matches a large number of files (or a few files with long names). I run into this all the time with things like 'zoo -add foo.zoo *'. 3) People are asking me for it. 4) Some builtins (such as 'exit') cannot easily be provided as an external command. I haven't yet identified exactly which ones can be yanked, but I think that there will be a core set in there anyhow. As another example, some commands are provided as a 'keyword', and they have to be. Consider: time { dir; sleep 3; my_cmd } It would not be possible to make 'time' an external command in this case, since it can time *any* complex command, not just a single external binary. It has to be part of the syntax. 5) Not all external commands are pure. Granted, REZ fixes this, but I'd like to avoid depending on another freeware program that might up and go away at any time. FYI, some future release of SKsh (past 1.3) will provide a shell with only the necessary builtins (like 'exit' and 'set'). I still feel that two versions (minSksh and maxSksh) would be the best route, since there are a large number of people who want both types. (What's that saying about pleasing all the people some of the time, or some of the people all the time... :-) - steve
rick@anasaz.UUCP (Rick Coupland) (12/14/89)
In article <bfea02ID72lX01@amdahl.uts.amdahl.com> kim@uts.amdahl.com (Kim DeVaughn) writes: >In article <AZTz25K00Uka8Bt052@andrew.cmu.edu>, bader+@andrew.cmu.edu (Miles Bader) writes: >> >> Why exactly do you need builtins at all, even on a floppy disk, given the >> existance of REZ? [Which has the large advantage of letting the USER decide >> which commands take up memory space...] > >I am all for leaving it up to the user to decide which commands, or specific >implementations thereof, to use. Absolutely. > >However, there is a fundemental problem that exists that builtin's allow you >to get around. That is the braindamaged limitation on the length of the >command line that AmigaDOS can handle. Something like 256 bytes. Ridiculous! > >Sure, that is long enough for most things, but it is a real pain to try and >deal with directories that may have, oh, say 1200 files in them (such as >root0:spool/news/comp/sys/amiga frequently has on my machine). I have also run into this problem and have come up with a solution. I use "make" (my own version) for maintaining libraries of my own routines. Over a period of time I have added more and more routines to the library and now have about 50 modules in the library. Everything appeared to be working fine untill I made a change to a header file which caused most of the source files to be recompiled. I then discovered that the last several files didn't get updated in the library. After some investigation I discovered that the reason for this was that the command line to "oml" (the Lattice library maintenance program) was getting truncated to about 256 bytes. My solution to this was to write my own routines to execute a program which did not limit the length of the command line. I then modified my make program to use these new routines. After doing this I discovered that the Lattice startup routines also place limits on command command line arguments (max of 32 arguments). So, I coded my own startup routines which also place no limits on the length or number of command line arguments. This of course did not directly solve the problem with "oml" since all of the Lattice utilities were linked with the Lattice startup routines. However, all of my own utilities, as well as public domain utilities which I build from the sources, do not have a maximum command line length and do not have a limit on the number of command line arguments. I was then able to solve the problem with "oml" by changint the Makefile to use my own "echo" command to create a temp file and then reference this file on the "oml" command line using the "@" construct. I realize that I could have solved my particular problem more simply by other means. For example I could have changed the Makefile to rebuild the entire library on every update and maintained a seperate file containing a list of all of the object file names. However, I felt that this was a more general problem and a general solution should be applied if possible. Otherwise, I would keep running into the same problem again and again. I would be willing to place this code in the public domain if it could be used to remove command line length limitations for Amiga utilities in general. I don't know whether or not the Manx startup routines have similar limitations to Lattice. Maybe someone else can answer this. However, it does no good to have shells which can generate long command lines if the programs being run by the shell cannot accept them. -- Rick Coupland ...!{noao!asuvax | mcdphx}!anasaz!rick (602) 870-3330
peter@sugar.hackercorp.com (Peter da Silva) (12/17/89)
In article <13920030@hpfelg.HP.COM> koren@hpfelg.HP.COM (Steve Koren) writes: > FYI, some future release of SKsh (past 1.3) will provide a shell with > only the necessary builtins (like 'exit' and 'set'). Good. > I still feel that > two versions (minSksh and maxSksh) would be the best route, since there > are a large number of people who want both types. (What's that saying > about pleasing all the people some of the time, or some of the people > all the time... :-) This is the best way to do it. And after all, it's a cheap optimisation. But... how about the superworkbenchshell idea? -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"