kim@uts.amdahl.com (Kim DeVaughn) (06/10/90)
In article <12396@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes: > > Command lines should be able to be longer as used by System and > Execute. This hasn't been extensively tested as of yet, but it was a Thanks for the good news, and a BIG *Thank You* for fixing this! People with directories having hundreds of files (like usr:spool/news/comp/sys/amiga) will appreciate this ability alot! > factor in design. Path lengths are still constrained by the 255 character > limit to BSTRs, due to the packet formats. At some later date I have plans > to eliminate that as well (no time for 2.0). 255 *seems* reasonable for this, but it would be nice to get the fix "In there" for 2.1 ... I assume filenames proper are still limited to 30 chars? > The console may be able to handle longer than 255 character lines > now, I'm not sure (but I suspect it still has some hard limit). Hardcoded limits should be exorcised whenever possible (IMO), in favor of dynamic allocation. However, if the "hard limit" is on the order of 64K, I'll shut up for now ... :-) > Wildcard expansion is much easier to do now, due to matchfirst/ > matchnext. Will these work with "*" and "?" In a previous posting it was mentioned that there would be a flag of some sort in 2.0 to finally allow "*" as a wildcard. /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
jesup@cbmvax.commodore.com (Randell Jesup) (06/10/90)
In article <38zy02j0ae2P01@amdahl.uts.amdahl.com> kim@uts.amdahl.com (Kim DeVaughn) writes: >> factor in design. Path lengths are still constrained by the 255 character >> limit to BSTRs, due to the packet formats. At some later date I have plans >> to eliminate that as well (no time for 2.0). > >255 *seems* reasonable for this, but it would be nice to get the fix "In there" >for 2.1 ... Warning, it's a big one, so don't hold your breath yet. >I assume filenames proper are still limited to 30 chars? The filesystem determines that, and the current filesystems (ram and the rom FS) use 30, but a FS could allow more. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
kim@uts.amdahl.com (Kim DeVaughn) (06/11/90)
In article <12517@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes: > > >> factor in design. Path lengths are still constrained by the 255 character > > > >255 *seems* reasonable for this, but it would be nice to get the fix "In there" > >for 2.1 ... > > Warning, it's a big one, so don't hold your breath yet. > > >I assume filenames proper are still limited to 30 chars? > > The filesystem determines that, and the current filesystems (ram and > the rom FS) use 30, but a FS could allow more. OK, I won't. The reason I mentioned the FS name-length limitation was more to verify it than anything else, as the 255/30 ratio still guarantees a minimum tree depth of 7 (if you include the vol name), as seen at the CLI/Exec() inter- face. Typically, of course, it can be much deeper (with a maximum of around 146). Sound quite reasonable (not that I plan on counting on such "limits" for anything). So, if a real fix for the path-length is extensive/ugly/etc, I see no reason not to put it on the back-burner. Thanks again for taking care of the major headache! BTW, will all these new hooks for the improved shell interface (System(), matchfirst/next, wildcard flags, etc) be documented in the DevCon notes, or are some things still not "firm"? I get the impression that the latter's the case. /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
koren@hpfelg.HP.COM (Steve Koren) (06/13/90)
> I much prefer the Amiga's pattern matching abilities over the > traditional * route, But what I think is sorely missed in the Amiga Shell > is file completion. I think the most valuable thing about the shells I use > on Unix is File Completion! That feature... There are two ways to achieve file name completion in AmigaDos. (Or rather, there are at least two; I suppose there might be others). One solution is that a utility by Bill Hawes (supplied with WShell I believe) will provide filename completion for you. I don't have Wshell so I can't comment on how it works and what features it has. WShell is pretty cheap though, you might consider it. The second choice (advertisement-mode on :-) ) is to use SKsh. It is free, and provides a few different filename completion features. You can use <esc><esc> or <tab> to do normal filename completion. <esc>-* will insert all file names which match the previously typed pattern, and <esc>-= will list matching filenames and then re-display the command line as it was letting you continue typing. In 1.4 there is a new feature called a "complist" which lets to perform completion on any arbitrary series of strings. For example, ones that you define yourself, files inside of a .zoo archive, or a buffered list of files on a floppy disk for rapid access, etc. Completion will get a little better yet in 1.5 (RSN :-)) when a few new features will be added (such as automatically indicating whether the thing you completed was a directory or a file name), and you will be able to map any keys you wish to perform completion. I'm even considering context sensitive string completion for 1.6, but that is a ways off yet. Context sensitive completion will be able to, for example, look at only .c files and ignore .o files in certain situations, etc. Hope this helps. WShell is available pretty much anyplace which sells Amiga software, and SKsh 1.4 is on one of the recent Fish disks. - steve