davis@MASIG2.OCEAN.FSU.EDU (Alan Davis) (03/22/91)
We have a NeXT machine, v2.0, nfs mounted to our 320 VGX, 3.3.1, that I have
been having an ongoing problem that I origionally attributed to an nfs
incompatability, but have just discovered that it is a problem with csh. When
I try to access a file on the NeXT machine and use the * or ? characters, csh
returns an error message "No match". sh will properly handle this filename
substitution and csh will work from a 3000 machine. I am wondering if this is
a problem on other machines or limited to the NeXT? Also does anybody (SGI?)
have an explanation/workaround (besides using sh) for this problem?
--
-------------------------------------------------------------------------------
Alan Davis |
MS B-174, Love 008A |
Mesoscale Air-Sea Interaction Group | INTERNET davis@masig1.ocean.fsu.edu
Florida State University | SPAN fsu1::davis
Tallahassee, FL 32306-3041 |
(904) 644-3798 |
_______________________________________________________________________________davis@MASIG2.OCEAN.FSU.EDU (Alan Davis) (03/22/91)
Mark Ferneau replies: >In article <9103211941.AA28942@masig2.ocean.fsu.edu> you write: >>We have a NeXT machine, v2.0, nfs mounted to our 320 VGX, 3.3.1, that I have >>been having an ongoing problem that I origionally attributed to an nfs >> ... >You may look at your variables set from inside the csh on the NeXT. >If you have a variable set called "noglob", then all pattern matching >will be ignored. To find out if the variable is set, just type: > set >csh will respond with a list of variables. If "noglob" is at the >beginning of one of the lines, then do the following to use pattern >matching: > unset noglob >It's likely that when you login to the NeXT, either your .login or >your .cshrc is setting noglob when trying to set your terminal >type. You may have a line like "eval `tset -s -Q`" which actually >will expand to a set of commands, one of which is a set noglob. >Usually this will only be a problem if the entire command is not >successful, as the sequence terminates with an unset noglob. Unfortunately, Mark that is not my problem at all. When I log into the IRIS ls * works as expected on any disk that I access that is connected to one of our IRISes, so my problem is not with set noglob. Also, if I log into the NeXT machine, I am able to use the * and ? chars. when trying to access a file on an IRIS disk that is nfs mounted on the NeXT. The problem occurs when I am logged into the IRIS not the NeXT machine, when trying to access a file on a NeXT disk that is nfs mounted on the IRIS. -- ------------------------------------------------------------------------------- Alan Davis | MS B-174, Love 008A | Mesoscale Air-Sea Interaction Group | INTERNET davis@masig1.ocean.fsu.edu Florida State University | SPAN fsu1::davis Tallahassee, FL 32306-3041 | (904) 644-3798 | _______________________________________________________________________________
slevy@poincare.geom.umn.edu (Stuart Levy) (03/23/91)
In article <9103211941.AA28942@masig2.ocean.fsu.edu> davis@MASIG2.OCEAN.FSU.EDU (Alan Davis) writes: >We have a NeXT machine, v2.0, nfs mounted to our 320 VGX, 3.3.1, that I have >been having an ongoing problem that I origionally attributed to an nfs >incompatability, but have just discovered that it is a problem with csh. When >I try to access a file on the NeXT machine and use the * or ? characters, csh >returns an error message "No match". ... We see the same problem w/NeXT 1.0. The fault's in the BSDreaddir() code which csh uses -- it does directory reads into a 512-byte buffer, which the NeXT NFS server could probably handle but doesn't. It's disappointing NeXT didn't fix this in 2.0. SGI's normal readdir(), used by sh, ls, etc. has a larger buffer (4K?) and succeeds. I'm told by a helpful SGI person that the next major release will have a BSDreaddir() with larger buffer, but meanwhile we're stuck. One thing you might try in the mean time: use tcsh instead of csh. I think there are a handful of tcsh binaries up for anonymous FTP on tesla.ee.cornell.edu and/or ftp.brl.mil. We have "tcsh.iris4d-irix3.3.1"; it *does* successfully glob with the NeXT. Stuart Levy, Geometry Group, University of Minnesota slevy@geom.umn.edu
brendan@illyria.wpd.sgi.com (Brendan Eich) (03/23/91)
In article <1991Mar22.190717.27233@cs.umn.edu>, slevy@poincare.geom.umn.edu (Stuart Levy) writes: > We see the same problem w/NeXT 1.0. The fault's in the BSDreaddir() code which > csh uses -- it does directory reads into a 512-byte buffer, which the NeXT NFS > server could probably handle but doesn't. It's disappointing NeXT didn't fix > this in 2.0. SGI's normal readdir(), used by sh, ls, etc. has a larger buffer > (4K?) and succeeds. I'm told by a helpful SGI person that the next major > release will have a BSDreaddir() with larger buffer, but meanwhile we're stuck > > One thing you might try in the mean time: use tcsh instead of csh. > I think there are a handful of tcsh binaries up for anonymous FTP on > tesla.ee.cornell.edu and/or ftp.brl.mil. We have "tcsh.iris4d-irix3.3.1"; > it *does* successfully glob with the NeXT. Thanks for summarizing this lingering SGI/NeXT bug. Those who aren't ready for tcsh can ftp a fixed csh from sgi.sgi.com:~ftp/sgi/csh. There's a README file; you must be running 4D1-3.3 or later. /be