Archive-Date: XXX, 17 Apr 1996 11:51:26 +0700 Subject: NSH - NETWORK SHELL for UNIX Message-ID: <317500670.acb@curly.ftc.ru> From: fun@ftc.nsk.su Date: 17 Apr 1996 11:51:26 +0700 Reply-To: fun@ftc.nsk.su Sender: newsserv@fagot.turbo.nsk.su Hello, World !! There is something new for you ... NSH - The Network SHell for UNIX, Version 1.0 NSH gives you EASY, FULL and SECURE control over remote UNIX hosts and their resources. With NSH you can do so many nice things in a very elegant manner! NSH uses client-server scheme, works via TCP/IP and consists of 3 main components: 1. The client (we call it nsh); 2. The server (we call it nshd); 3. The authenticator (we call it nshman). A nsh connects to a remote host where nshman is supposedly running, nshman accepts the connection and checks the client's credentials. If the authentication is successful, nshman passes the connection to the server (if the server didn't exist, it is spawned). After that the client and server are ready to work with each other in two main modes: (1) File I/O mode; (2) Terminal I/O mode. To better see what NSH is, it is a good idea to go into comparison with the world-wide known programs: 1. NC - The Norton Commander for DOS; 2. FTP, TELNET/RLOGIN, REXEC, RCP for UNIX. NSH uses neither of them but can be treated as all or just any of them at the same time. NSH presents NC-like interface to a user but with remote UNIX hosts instead of DOS drives. With NSH the remote UNIX hosts as easily accessible as DOS drives via NC and in similar way. You are able to have connections to as many hosts as you wish. In mode (1) you can perform numerous file I/O operations (including recursive directory processing). For example, you can copy/move files or the whole directory trees among hosts, or just delete files or the whole directory trees from a host, and all of these is as simple as in NC with respect to DOS drives. In mode (2) you can work in remote terminal sessions as you normaly do with TELNET-like utilities. Being in mode (1) you, as if you are in NC, can put the cursor over an executable and press Enter and nsh will automatically get into mode (2) and the program will be run by nshd on the remote host. While the program is running you can go to mode (1), work in modes (1) or/and (2) with the same or other hosts, then return to previous terminal session on the host where the executable was run, since modes (1) and (2) function in parallel. NSH-client has fast built-in viewer to view and powerful built-in editor (having REXEC feature) to edit remote files and there is an option to select additional external remote editors for each host. NSH has a side effect to work in mode (1) with NetWare if there is a UnixWare machine in the network, so this may prevent you from having NFS channel between NetWare and, say, SCO - all you need is having NSH-servers running on these UnixWare and SCO. Further, NSH can be used as ordinary NC-like shell for UNIX, since it is very fast and does not care if it were used locally or remotely - it gives you perfect and uniform access to local and remote resources. If you run several instances of nsh, connecting to the same remote host, then all of them will work with single copy of nshd unlike FTP- or TELNET- like servers. NSH is more secure than either of utilities mentioned here. NSH passwords and normal Unix ones have nothing in common. NSH is fully implemented on different UNIX platforms and the client part is being completed for DOS, OS/2, Windows and X-Windows. NSH seems to be very useful for all wanting to have pretty good and easy to use the network tool in their everyday life under UNIX. We do hope that users, programmers and administrators of UNIX will enjoy our NSH! We can send you demo-versions of NSH (one operates in fully automatic mode by simulating user's input, other is interactive) and documentation for free. Russia, 630090, Novosibirsk St. Shaturskya, 2 Tel: (3832) 39-92-42 E-mail: fun@ftc.nsk.su Name: Konstantin Kuznetsov ================================================================================ Archive-Date: XXX, 20 Apr 1996 22:40:10 -0400 Subject: Re: Work around TCPWARE 5.0 bug Message-ID: <1996Apr20.224010@process.com> From: tchen@process.com (Weimin Tchen - Process Software 800-722-7770 x280) Date: 20 Apr 96 22:40:10 -0400 References: <4eoqll$vhs@hera.cuci.nl> <4f5d8j$qq@theben.kapsch.co.at> Hello, We expect that the forthcoming TCPware 5.1 will fix these 3 problems. In article <4f5d8j$qq@theben.kapsch.co.at>, eplan@kapsch.co.at (Peter LANGSTOEGER) writes: 1. > Every time I invoke DECW_FTP it crashes with an ACCVIO shortly after > getting the initial directory listing from the remote FTP server. > (we are using vanilla OpenVMS Alpha V6.2 with TCPware V5.0-4) Once we could replicate the problem using a particular FTP server that reported filenames without a version (i.i. no ";"), DECW_FTP was corrected. 2. > PS: Normal FTP client crashes sometimes with "%TCPWARE_FTP-F-ERRDURWRI", too. This was also corrected once we were able to reproduce the problem by using FTP> SET HASH on an AXP. To enhance performance the AXP VMS runtime libraries no longer use shareable output devices, thus leading to the ERRDURWRI when outputing "#" at the same time as outputing FTP info to the terminal. 3. > PPS: Use of RFC1006 (eg. DECnet/OSI over IP) crashes our VAXes and Alphas > (again OpenVMS V6.2 w/ or w/o patches, TCPware V5.0-4, DECnet/OSI V6.2 ECO 4) > with DOUBLEDEALLO or BADDALRQSZ bugchecks in PWIPDRIVER. It appears that DECnet/OSI is not deallocating a chain of buffer as expected. TCPware's PWIPdriver was modified to deallocate one buffer at a time. Hope this help, -Weimin Tchen