New Messages
From: Guido Beijderwellen <q8.nl!beijder@uunet.uu.net> Status: RO
Robert, I am trying to connect to your system in order to download the last month's listings file. But I cannot get in contact with the number 1-900-468-7727. Is this a wrong number?
Regards, Guido Beijderwellen The number is correct but is apparently not accessible to some international callers. We are working on alternate code distribution possibilities, but have not yet found a suitable solution. We are considering posting the Sys Admin code on CompuServe -- would our readers like to see that?
To: saletter@rdpub.com
Dear Editor: Keep up the good "practical" work, SA!
Donald C. Stone Thanks for your kind words.
From: Mark Dadgar <mdadgar@wma.com> Editor, SysAdmin, This is in response to Larry Reznick's response to Christopher Calabrese's letter. Larry states that: "As for directory names containing a space, that sin is not easy to commit by the average user. If I ever saw that actually happen, I'd track down the owner, find out why and what depends on it, and rename the offending directory as soon as I can." Well, Larry, in our environment here (360 NeXT workstations), our users create hundreds of files like this every day. We have exclusively non-technical people on our system, and the NEXTSTEP environment does not forbid file naming with spaces. And I don't see why it should. This is a modern system we're talking about here. We've left 8+3 DOS naming behind, let's leave as many old UNIX file restrictions as we can, too. True, it makes system administration a little more difficult (by making shell scripts more complex), but the most useful utilities (gnutar, etc.) have no problem with filenames of this kind. And if we're going to move these non-technical people into the future of computing, we need to adapt the system (as much as is possible) to THEIR way of thinking, and not them to ours.
Mark Dadgar, NeXT SysAdmin Larry Reznick responds: I didn't bring MSDOS into the conversation. As it happens, MSDOS doesn't restrict spaces in filenames, command.com does. However, in all of the UNIX shells, the only way to put a space into a filename on the command line is to enclose it in quotes. That isn't commonly done by the average user. Within an application, though, anyone might enter a space in response to a filename prompt. The application simply passes the name on to the operating system when creating or opening the file. The underlying OS file functions have no problem with any characters including the various shell metacharacters, redirection symbols, and any other symbols special to the shells. Those characters simply aren't important to the underlying functions. They are important to the shells, though, and most day-to-day system administration is done from one shell or another. Those characters are troublesome. If all maintenance of those files is restricted to application-specific maintenance, they present no important problem for an aware administrator. For instance, SVR4 and BSD filenames are limited to 255 characters. Not much of a limit. One company I worked for several years ago took advantage of that with applications that created and worked with automatically generated filenames that might be as long as 100 characters. Those files were destined for CDROM. The names bore indexing and origin information for an audit trail. Those filenames were a bear to type, and contained many unusual characters, although no characters conflicted with shell metacharacters. On the rare occasions we had to deal with those files manually, we usually used wildcards. All of the applications I wrote to deal with them made UNIX tell the program their names. The applications rarely dealt with the names except as arbitrary strings. No restrictions, although we did avoid characters meaningful to the shells.
Editor, My program (see Listing 1: E-Media Production Manager's note: Listings referenced within the New Messages/Letters can be found by scrolling to the bottom of the current page.) does not exactly match yours in function because I wanted to match our old wh functions.
Sincerely, A slightly different approach -- thanks for sharing it.
Dear Editor, Within VMS, the operating system can be set up so that when a user logs onto the VAX across the network, he is given two terminals, a physical and a virtual terminal. If for some reason he loses his session across the network, his physical terminal is destroyed; however, the virtual terminal is left intact, and, on logging in again, the user can reconnect to his previous session via the virtual terminal and carry on as though nothing has happened. My question is: does anyone know of a product that would give us the above functionality under UNIX? We are running NCR SVR4 and IBM AIX. The nearest I can get so far is Double Vision from MaxTech, which may allow users to connect to a lost session and log it out, but would like the process to be automatic.
Simon D. Ralfs Can any of our readers help?
Listing 1: Rory Hammond's wh
#! /bin
:
#ident "@(#) Rory Hammond -PN1 - /usr/lbin/wh"
# 07-11-93 replaced C program with this shell
#
# wh
#
# Examine the path for a command & tell which dir has it. Stop with
# the 1st dir that has it.
#
#
if [ $# -eq 0 ]
then
echo "usage:\t$0 prognam ...." >>&2
exit 1
fi
dirs=F51>`F255>echo $PATH |
sed -e 's/^:/.:/' -e 's/:$/:./' -e 's/::/:.:/' -e 's/:/ /g'F51>`F255>
notfound=
for ffile in $*
do
found=0
for dir in $dirs
do
if [ -x ${dir}/${ffile} -a ! -d "${dir}/$1" ]
then
echo ${dir}/${ffile}
found=1
break
fi
done
if [ ${found} -eq 0 ]
then
notfound="${notfound} $1"
fi
shift
done
#report the not found
for arg in $notfound
do
echo "${arg} not found"
done
exit 0
|