jhc@vax5.CIT.CORNELL.EDU (02/14/89)
I just read thru the csh man pages on the NeXT. It looks like they have added functionality similar to tcsh's into csh. Specifically, if you set the variable editmode to emacs, you will be able to use emacs-like syntax to edit the current input line as well as the history. Whether a vi mode exists (yet?) wasn't specified, but it wouldn't hurt to try. (man csh for details.) I would like to add that a command to list the current bindings should be added. (If I missed it in the man pages, my appologies.) On another tangent, I would like to execute some commands on login iff I've loged in remotely, but don't know how to check this in .login. I have the following basic form: if (remote-login) then [execute some commands here] if (no-one-else-on) [execute some more commands here] endif endif where remote-login is true if I've rlogged in or telneted in, and no-one-else-on is true if anyone else who is logged in has also logged in via rlogin or telnet. (Ie, the [execute some more commands here] line(s) should not run if someone is logged in at the machine itself.) Is there any way to determine these from w/in a csh script? Thanks for any help. -JimC -- James H. Cloos, Jr. "Entropy isn't what it used to be." jhc@Crnlvax5.BITNET --c/o Fortune @ batcomputer.UUCP jhc@Vax5.CIT.Cornell.EDU #include <std_disclaimers.h> cornell!vax1!vax5.cit.cornell.edu!jhc@rochester.UUCP B-7 Upson Hall, Cornell Univ., Ithaca, NY 14853 +1 607 272 4519
feldman@umd5.umd.edu (Mark Feldman) (02/15/89)
In article <17953@vax5.CIT.CORNELL.EDU> jhc@Vax5.CIT.Cornell.EDU (James H. Cloos, Jr.) writes: > >On another tangent, I would like to execute some commands on login iff I've >loged in remotely, but don't know how to check this in .login. I have the >following basic form: >if (remote-login) then > [execute some commands here] > if (no-one-else-on) > [execute some more commands here] > endif >endif > >where remote-login is true if I've rlogged in or telneted in, and >no-one-else-on is true if anyone else who is logged in has also logged in >via rlogin or telnet. (Ie, the [execute some more commands here] line(s) >should not run if someone is logged in at the machine itself.) Is there any >way to determine these from w/in a csh script? > >Thanks for any help. > >-JimC One of our NeXTs is available for faculty to evaluate. In order to make it easy to log into, we placed a guest account on it w/o a password. Unfortunately, there are some maladjusted individuals that like to attack computers -- especially those with guest accounts w/o passwords -- over the net. In order to prevent people from using telnet/rlogin/rsh to sign on the guest account and still allow guest at the console to bring up a terminal/csh, I use the following as guest's shell: VVVVVVVVVVVVVVVVVVVVVVV /usr/local/lib/securecsh VVVVVVVVVVVVVVVVVVVVVVVVV #!/bin/csh -f # # get the user name of the parent of this process # set ppid=`ps -l $$ | awk '{ if ($3 == "'$$'") print $4}'` set parent=`ps -u $ppid | awk '{ if ($2 == "'$ppid'") print $1}'` # # see if the user brought up the shell (OK) or if it was created by # the system (telnetd/rlogind -- not OK) # if ($parent == $USER) then setenv SHELL /bin/csh setenv PATH /usr/local/lib exec -csh else echo Network access to the $USER account is not allowed. echo Access to this machine is for authorized users only. sleep 4 endif ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It checks the user name of the parent process and if it the parent is the same as the user, then the user started the shell after already logging in (at the console) and everything is ok. If the user name and the parent process' name are different, then the parent process is probably a root process (telnetd, rlogind, ...) and I don't want them around. -csh is actually a symbolic link in /usr/local/lib that points to /bin/csh. In order for csh to run your .login, it (argv[0]) must be called as -csh. Yes, it's a kludge. No question about it. Jim, I'm sure that this could be modified to do whatever you want. If this is part of a .login or .cshrc and not a shell, then the exec stuff can be tossed. The part about checking if anyone else is on can be implemented by using wc or awk on the output of users or who. Net, If you've get a better solution, I'm interested. I would have simply modified the NeXT login, 'cept I don't have the source (sorry about that). Mark
lkw@csun.edu (Larry Wake) (02/16/89)
In article <17953@vax5.CIT.CORNELL.EDU> jhc@Vax5.CIT.Cornell.EDU (James H. Cloos, Jr.) writes: >On another tangent, I would like to execute some commands on login iff I've >loged in remotely, but don't know how to check this in .login. Here's what I do to get the opposite effect, which you should be able to alter to suit your needs. I have certain commands that I *don't* want to be executed for remote logins. So, I have the following lines at the top of .login: # Find out if this is an rlogin: tty | egrep /dev/ttyp > /dev/null set NOTNET = $status $NOTNET is true if it's not an rlogin. I use its value in subsequent 'if' statements in .login; I even check it in .logout to skip things like fortune when I'm just closing an rlogin session. -- Larry Wake lkw@csun.edu CSUN Computer Center uucp: {hplabs,rdlvax}!csun!lkw Northridge, CA 91330 BITnet: LKW@CALSTATE "...it's not as good as Whip 'n' Chill, but it does have a very nice flavor."
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/17/89)
Another interesting thing to do is write a program of the form:
main()
{
<stuff to do before the workspace runs>
if (!fork())
execl("/bootdisk/NeXT/Apps/Workspace","-LoginProgram","YES",0);
else
{
wait(&junk);
<stuff to do after the workspace runs>
}
}
You then use dwrite to tell the login process you want to run this
instead of Workspace when you log in to the console:
dwrite loginwindow Workspace /usr/local/bin/foo
Now, you get control BEFORE and AFTER the Workspace runs. I use a program
of this type on our public access machines, to reset the files in the
guest account to a friendly state (all the right things on the dock, etc.).
There is also a "LoginHook" switch you can add to the console entry in
/etc/ttys to give control before the Workspace is run; this one I haven't
yet tried.
--
Steve Dorner, U of Illinois Computing Services Office
Internet: dorner@garcon.cso.uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner
IfUMust: (217) 244-1765abe@mace.cc.purdue.edu (Vic Abell) (02/18/89)
In article <451@garcon.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu
(Steve Dorner) writes about a way to create a program that will be
launched at login time instead of the Workspace manager. That program
can initialize, call the WM, and do wrapup functions.
Steve's approach works nicely. Coupled with Christopher Lane's bright
program, it enables one to have a poor man's screen dimmer/brightener
at logoff/logon time.
There's one "gotcha": the Workspace manager that the program runs loses
contact with the console and you cannot use the Console item of its Utilities
submenu. I'm a bit surprised, since that WM process is started by a
fork/execl and should inherit the file descriptors of the program that
started it.
How does the WM access the console?
Vic Abell