brsmith@umn-cs.cs.umn.edu (Brian R. Smith) (07/19/90)
During the normal login sequence, /bin/login will dump /etc/motd to the terminal, say whether or not you have mail, then start up the shell. (Ok, I've omitted a couple details...) But, when one of our novice users logs in through xdm and starts up a login xterm, (s)he will never see /etc/motd. (The default setup is a single large login xterm, so even folks with x-phobia can make some use of them as terminals...) So, would it be reasonable to augment xterm (yet again) to dump /etc/motd (among other things) into its window before starting a login shell? Anyone have a patch for it? I've got a crude hack set up in /etc/.login (sourced before ~/.cshrc and ~/.login) right now - if "WINDOWID" is set it cats /etc/motd. Any better ideas? Brian brsmith@cs.umn.edu
jf@ap.co.umist.ac.uk (John Forrest) (07/19/90)
In article <1990Jul18.200754.13129@cs.umn.edu>, brsmith@umn-cs.cs.umn.edu (Brian R. Smith) writes: |> ... would it be reasonable to augment xterm (yet again) to dump |> /etc/motd (among other things) into its window before starting a login |> shell? Anyone have a patch for it? |> |> I've got a crude hack set up in /etc/.login (sourced before ~/.cshrc |> and ~/.login) right now - if "WINDOWID" is set it cats /etc/motd. |> I fully agree that the /etc/motd ought to get out somehow. We run an Apollo ring, and normally users start X if they want after logging in (or we have set ups that do this automatically). However, we have one node running xdm and the nett effect is that you don't see the motd! However, I'm not sure that getting this to come out in xterm is the best idea - can the system easily differentiate between the first and subsequent xterms? I expect a better idea would be to pop up some sort of window with the motd init, which could then be killed when the user has read the stuff. Has anyone tried this? John Forrest Dept of Computation UMIST.
baur@venice.SEDD.TRW.COM (Steven L. Baur) (07/20/90)
I have the same problem. From article <1990Jul18.200754.13129@cs.umn.edu>, by brsmith@umn-cs.cs.umn.edu (Brian R. Smith): > But, when one of our novice users logs in through xdm and starts up a > login xterm, (s)he will never see /etc/motd. > So, would it be reasonable to augment xterm (yet again) to dump > /etc/motd (among other things) into its window before starting a login > shell? Absolutely not. There is a perfectly good place to put this, and that is in the Xsession file run by xdm prior to login. > I've got a crude hack set up in /etc/.login (sourced before ~/.cshrc > and ~/.login) right now - if "WINDOWID" is set it cats /etc/motd. That works only if your users don't use more modern shells :-). What I'd like to see is a program that can take a text file (determine a minimum amount of screen space) and just display it with a button to click on when the user is done reading it. Xmessage is almost the program to use. However, it does not automatically resize above one line correctly. Essentially I have to have a program that does just this (yesterday, sigh). What I'd like to see is a (possibly scrollable) window come up with the message of the day. Unlike Xmessage, I would like the default to show a number of (reasonable) lines. Xmessage does that when you know in advance the geometry in pixels and specify on the command line a -geometry flag. A temporary solution is to put up the motd in an Xmessage sized for some fixed number of lines, and then force the user to scroll to see anything else, but this is a system that will be displaying X windows over modems running at 19.2kbaud, and scrolling is painful at best. Is there anything better? -- steve baur@venice.SEDD.TRW.COM
garyc@hobbes.wv.tek.com (Gary Combs) (07/20/90)
Here is how I do it. I call a shell script 'checkmotd' from my .x11start
file. This in turn calls another shell script 'Motd'.
------------------------------------------------------------------------
-----------
checkmotd:
#!/bin/sh
if [ ! -f $HOME/.motd ]
then
touch $HOME/.motd
xterm -geometry 70x24+110+120 -title "Message Of The Day" -fn
LucidaV2RT
14 -e /usr/local/bin/Motd &
else
whic="`ls -lt /etc/motd $HOME/.motd`"
file="`echo $whic | awk ' { print $9 } '`"
if [ "$file" = "/etc/motd" ]
then
touch $HOME/.motd
xterm -geometry 70x24+110+120 -title "Message Of The
Day" -fn Lu
cidaV2RT14 -e /usr/local/bin/Motd &
fi
fi
------------------------------------------------------------------------
-----------
Motd:
#!/bin/sh
cat /etc/motd
echo "Press return when done reading ..."
read ans
-------------------------------------------------------------------------------
Gary Combs
Tektronix, Inc
VSG Technical Marketing Support
(503)685-2072
garyc@shamu.wv.tek.com
-------------------------------------------------------------------------------brsmith@cs.umn.edu (Brian R. Smith) (07/21/90)
baur@venice.SEDD.TRW.COM (Steven L. Baur) writes: >From article <1990Jul18.200754.13129@cs.umn.edu>, by brsmith@umn-cs.cs.umn.edu (Brian R. Smith): >> So, would it be reasonable to augment xterm (yet again) to dump >> /etc/motd (among other things) into its window before starting a login >> shell? >Absolutely not. There is a perfectly good place to put this, and that is >in the Xsession file run by xdm prior to login. What about when user "george" does and "rcmd [or xrsh] foo xterm -ls". He's now logged into foo, but he has NOT seen /etc/motd. xterm has half of /bin/login in it already - it can update /etc/utmp and /usr/adm/wtmp, chown the pty, etc. Why not throw the rest in? It would make things much less confusing for our novice users - xterm logins would appear nearly identical to normal terminal logins. >> I've got a crude hack set up in /etc/.login (sourced before ~/.cshrc >> and ~/.login) right now - if "WINDOWID" is set it cats /etc/motd. > That works only if your users don't use more modern shells :-). Ah, but *I* am the one to install the more modern shells, so I can hack them as I please... (evil laughter) >What I'd like to see is a program that can take a text file >(determine a minimum amount of screen space) and just display it with >a button to click on when the user is done reading it. That would be a nice solution, for xdm logins, at least. But it still wouldn't take care of those people using xterm to login, rather than rlogin or telnet. Probably the *BEST* solution came from Edward Wang (edward@ucbarpa.berkeley.edu) - have xterm run /bin/login itself, and not even try to update /etc/utmp and /usr/adm/wtmp. This is essentially what rlogind and telnetd do, so there's even precedent. Unfortunately, this means that you must have an xterm and /bin/login that can agree with each other. If your login supports "-f" (which SunOS doesn't), you can just do: xterm +ls -e /bin/login -fp $USER On our Sequent (Dynix 3.0.17) this works just great - it is *identical* to an rlogin. But no go for suns. BUT: the 4.3bsd /bin/login supports "-f", and it IS publicly available, so it is a workable solution. Now the question is: Would it be reasonable to change xterm to run "/bin/login -fp ..." for login shells? (If you'll excuse me, I'll go bash on the xterm source for a while... :-)) Brian brsmith@cs.umn.edu
rlk@THINK.COM (Robert L Krawitz) (07/21/90)
Funny, this issue just came up here. My own proposal (for those who don't like xterm -e rlogin) is rsh -n host "xterm -display $DISPLAY -e login -p $USER </dev/null >&/dev/null&" or something of that general flavor.
jg@crl.dec.com (Jim Gettys) (07/23/90)
> xterm has half of /bin/login in it already - it can update /etc/utmp > and /usr/adm/wtmp, chown the pty, etc. Why not throw the rest in? It > would make things much less confusing for our novice users - xterm > logins would appear nearly identical to normal terminal logins. xterm has all this junk in it for historical (hysterical) reasons. This doesn't mean it is a good idea to add hacks on hacks; therein lies long term madness. xdm did not exist at the time the hacks were going into xterm. - Jim
J.K.Wight@newcastle.ac.UK (Jim Wight) (07/23/90)
In article <678@venice.SEDD.TRW.COM> Steven L. Baur writes: > What I'd like to see is a program that can take a text file (determine > a minimum amount of screen space) and just display it with a button > to click on when the user is done reading it. Xmessage is almost the > program to use. However, it does not automatically resize above one line > correctly. Essentially I have to have a program that does just this > (yesterday, sigh). I have almost the very program. Without knowing about xmessage at the time I came up with a similar interface. The number and names of the buttons, and the codes they return are command line options. > What I'd like to see is a (possibly scrollable) window come up with the > message of the day. Unlike Xmessage, I would like the default to show > a number of (reasonable) lines. > > A temporary solution is to put up the motd in an Xmessage sized for some > fixed number of lines, and then force the user to scroll to see anything > else, but this is a system that will be displaying X windows over > modems running at 19.2kbaud, and scrolling is painful at best. As it currently stands my program displays the whole file in a window of the correct size. Although some generalisation has been incorporated it was principally written in order to display the message of the day file under xdm, and I don't expect that to be more than a screenful. It would not be a tremendous task to add scrolling but I didn't use a complicated text widget because I wanted to keep the program reasonably small given the limited objective. The program is not in a polished enough state to be released for general consumption but if anyone feels they would like to give it a try then I am willing to mail it to them. It requires C++ and version 2.6 of the InterViews toolkit. Jim Wight --------- J.K.Wight@newcastle.ac.uk Computing Laboratory, University of Newcastle upon Tyne Newcastle upon Tyne, NE1 7RU, United Kingdom. Tel: +44 91 222 8238
brsmith@cs.umn.edu (Brian R. Smith) (07/24/90)
jg@crl.dec.com (Jim Gettys) writes: >> xterm has half of /bin/login in it already - it can update /etc/utmp >> and /usr/adm/wtmp, chown the pty, etc. Why not throw the rest in? It >> would make things much less confusing for our novice users - xterm >> logins would appear nearly identical to normal terminal logins. >xterm has all this junk in it for historical (hysterical) reasons. >This doesn't mean it is a good idea to add hacks on hacks; therein >lies long term madness. xdm did not exist at the time the hacks were >going into xterm. Ok - so the best fix would be to: Have xterm NOT do the utmp/wtmp stuff. (Quick Imakefile hack.) Have "login" xterms run "/bin/login -h $DISPLAY -fp $USER" as root. The one itty-bitty teeny-tiny problem with this is that not all /bin/login's support "-f". So some folks (me included) may have to grab the 4.3bsd login (on uunet, among others) and put it someplace like /usr/bin/X11/login... Could support for this be worked into xterm? Could the 4.3 login be included in the X release? (I'd assume the situation would be similar to that of compress.) Or is this too much work for too little gain? The end result would be an xterm login identical to a normal terminal/rlogin/telnet connection. I doubt too many of my users would actually notice, but that was the whole idea - seamless. Well, back to work... Brian brsmith@cs.umn.edu
edward@ucbarpa.Berkeley.EDU (Edward Wang) (07/24/90)
In article <1990Jul23.201745.11646@cs.umn.edu> brsmith@cs.umn.edu (Brian R. Smith) writes: >Ok - so the best fix would be to: > Have xterm NOT do the utmp/wtmp stuff. (Quick Imakefile hack.) > Have "login" xterms run "/bin/login -h $DISPLAY -fp $USER" as root. Actually, even with the right version of login, this isn't a solution, because there's nobody to do the logout part of utmp and wtmp fixing. Currently, this is done whatever programs that invoke login: init, rlogind, and so on. (Brian: I know I suggested using login -f, but with a caution.) The correct solution seems to be a server-based pty server. There seem to be people working on this here at Berkeley. The original Unix login design is outliving its usefulness.
barmar@think.com (Barry Margolin) (07/24/90)
In article <5877@crltrx.crl.dec.com> jg@crl.dec.com (Jim Gettys) writes: >xterm has all this junk in it for historical (hysterical) reasons. >This doesn't mean it is a good idea to add hacks on hacks; therein >lies long term madness. xdm did not exist at the time the hacks were >going into xterm. XDM is fine for the initial login to a local host. But it doesn't help in the case that prompted out question. One of our users frequently needs to access a host in Sweden. He'd like to use "rsh sweden-host xterm -ls -display his-x-terminal", but this doesn't display the Swedish host's motd. And "rsh sweden-host xterm -display his-x-terminal -e login $USER" asks him for a password, which he'd like to bypass (he has hosts.equiv and ~/.rhosts set up to allow the rsh, so login's password prompt doesn't add any security). Someone else mentioned "login -f -p". Our SunOS 4.0.3 /bin/login appears to support the "-f" option, but it's undocumented. What does it do? -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
jdaly@ATHENA.MIT.EDU (07/24/90)
The following is information regarding the real-time messaging system here at Athena (zephyr) and GMS (Global Messaging System). Should you have any further questions, you may direct them to info-athena@athena.mit.edu. Janet Daly Information Officer, Project Athena /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ X X X X Zephyr notification service, applications, & libraries X X Zephyr is a wide area, multicast, subscription based messag- X X ing system. It supports arbitrary typecasting on messages, X X thereby permitting Zephyr to be used as a common carrier to X X messages of whatever type yet without central registration X X of those types. The practical applications of this system X X include operational control as well as rendevous applica- X X tions such as OLC (vide infra). X X X X X GMS global message system X X The traditional Unix login-time announcement mechanism of X X displaying the contents of the file /etc/motd is not main- X X tainable in a wide area workstation environment. In addi- X X tion, the contents of that file may change on a schedule X X dynamically different from that of the rest of the software X X suite, necessitating maintenance and writeability con- X X straints on the whole software suite unsuitable on behalf of X X that one file. Instead, the Athena environment includes a X X global message service (GMS) that permits the retrieval of X X the message of the day from a server, comparison of the mes- X X sage retrieved with messages already viewed by the user, and X X display of the relevant or the explicitly requested message. X X In this way, the GMS facility is a mix of the functionality X X provided by the /etc/motd and mesg mechainsms. X X X XX
tim@appenzell.cs.wisc.edu (Tim Theisen) (07/25/90)
In article <1990Jul18.200754.13129@cs.umn.edu> brsmith@umn-cs.cs.umn.edu (Brian R. Smith) writes: >I've got a crude hack set up in /etc/.login (sourced before ~/.cshrc >and ~/.login) right now - if "WINDOWID" is set it cats /etc/motd. > >Any better ideas? Try out the xlogin program. I was posted to comp.sources.x recently. You can also pick it up via anonymous ftp from expo.lcs.mit.edu. xlogin handles /etc/motd, among other things. Hope this helps, ...Tim -- Tim Theisen Department of Computer Sciences tim@cs.wisc.edu University of Wisconsin-Madison uwvax!tim 1210 West Dayton Street (608)262-0438 Madison, WI 53706
brsmith@cs.umn.edu (Brian R. Smith) (07/25/90)
edward@ucbarpa.Berkeley.EDU (Edward Wang) writes: >In article <1990Jul23.201745.11646@cs.umn.edu> brsmith@cs.umn.edu (Brian R. Smith) writes: >>Ok - so the best fix would be to: >> Have xterm NOT do the utmp/wtmp stuff. (Quick Imakefile hack.) >> Have "login" xterms run "/bin/login -h $DISPLAY -fp $USER" as root. I hate to sound like a complete moron... but after looking through the xterm source, the solution gets even simpler. "-DUSE_LOGIN_DASH_P" No hacking necessary... ["Use the Source, Luke."] >Actually, even with the right version of login, this isn't a >solution, because there's nobody to do the logout part of utmp and >wtmp fixing. Currently, this is done whatever programs that invoke >login: init, rlogind, and so on. (Brian: I know I suggested using >login -f, but with a caution.) The correct solution seems to be a >server-based pty server. There seem to be people working on this >here at Berkeley. Xterm can clean up the utmp/wtmp stuff - it already does. I'll have to hack it a little - to let /bin/login add the utmp/wtmp entries, but remove them itself. (Or maybe hack login to *not* add the utmp/wtmp entries.) It could work. >The original Unix login design is outliving its usefulness. Probably... but I'm not going to try to fix THAT myself... :-) Brian brsmith@cs.umn.edu
brsmith@cs.umn.edu (Brian R. Smith) (07/26/90)
barmar@think.com (Barry Margolin) writes: >Someone else mentioned "login -f -p". Our SunOS 4.0.3 /bin/login appears >to support the "-f" option, but it's undocumented. What does it do? I'm not exactly sure - It works on our Sequent (Dynix 3.0.17.9), and isn't documented there either... From what I gather, it just means to bypass the normal user authentication, if you're root or the user specified. The 4.3 (tahoe) rlogind uses it, rather than "-r". Brian brsmith@cs.umn.edu
dan@scooter.rosemount.com (Dan Messinger) (07/26/90)
In article <678@venice.SEDD.TRW.COM>, baur@venice.SEDD.TRW.COM (Steven L. Baur) writes: |> What I'd like to see is a program that can take a text file (determine |> a minimum amount of screen space) and just display it with a button |> to click on when the user is done reading it. Have you looked at xlogin? I believe it handles everything that you have mentioned.