This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Greg, re: > OK - I added the .mcenv file which was missing and made sure group write > privs were set for $MCDATA. Excellent! re: > Upon further investigation, the above edit > error looked to be caused by our server failing to have the "ed" editor > installed. I totally forgot that this became an issue since 'ed' is not installed by default in some Linux distributions; sorry! re: > We did a yum install of that and got a bit further. We are now > getting: > > [root@typhoon mcidas]# ./mcinet2017.sh install mcadde > Redirecting to /bin/systemctl status xinetd.service > mcinet2017: /etc/services: mcidas: adding service lines > mcinet2017: xinet: Using xinetd.d to set up services > mcinet2017: /etc/hosts.allow: mcidas: adding service lines > mcinet2017: /etc/xinetd.d/mcidas: modifying file > ./mcinet2017.sh: line 713: [: too many arguments > mcinet2017: WARNING: xinetd not listening > Try running the script again in a few minutes. OK, I ran into this also. My solution was (and is likely to be in the actual release) to change the shell used in mcinet2017.sh from 'sh' to 'bash'. Give this a try and see if the script doesn't run to the end with no errors. re: > This server is running CentOS7 and this error looks like it could be OS > related. Line 713 is an if statement related to a part of the code that > seems to be checking what kind of OS is running. Let us know what the next > step should be. If you need access to our server we could set that up as > well if that would help. The issue is that 'sh' (which, by the way, is actually running run as 'bash' with some flags) has a problem with line lengths that are "too" long. Changing the script to run as 'bash' should eliminate this problem altogether. In the distant past, this would likely have been a problem since 'bash' was not as omnipresent as 'sh', but now 'sh' is actually 'bash'. Check this listing of 'sh' and 'bash' on my CentOS 6.8 Linux development system: /home/mcidas% ls -alt `which bash` -rwxr-xr-x 1 root root 941944 Jan 11 11:29 /bin/bash* /home/mcidas% ls -alt /bin/sh lrwxrwxrwx 1 root root 4 Jan 12 16:02 /bin/sh -> bash* Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: WPD-667222 Department: Support McIDAS Priority: Normal Status: Closed =================== NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.