[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] last?




On Mon, 11 Dec 2000, Guido Flohr wrote:

> On Mon, Dec 11, 2000 at 07:59:35PM +0100, Tomas Berndtsson wrote:
> > Andreas Schwab <schwab@suse.de> writes:
> > 
> > > Maurits van de Kamp <maurits@bassment.nu> writes:
> > > 
> > > |> 1. Shouldn't utmp be in /var or /var/tmp/ or something similar? :)
> > > 
> > > On Linux, it is in /var/run.
> > 
> > Doesn't `last' use wtmp? On Linux, wtmp is in /var/log.
> > 

Sorry, that is correct.  At any rate, the file it is looking for is there,
as if does have some history, just not recent history.  It appears that
"last" is working, but that login isn't logging to the wtmp/utmp file.

> > utmp contains currently logged in sessions, and wtmp contains the
> > history or logins, logouts and system reboots..
> 
> And there is currently some confusion with utmp/wtmp.
> 
> These logging facilities were (IMHO) more or less broken in older MiNT
> systems (like KGMD).

The system I am using is essentially an upgraded kgmd.  (I didn't have
much luck with the debian-linux ;<).

>  The file format didn't allow to store the
> information that was needed for modern interfaces to these
> facilities.  Furthermore the location of both files was non-standard (with
> respect to the filesystem hierarchy standard FHS).

well that can be changed.
 
> As a consequence I have changed the MiNTLib (for Noah: MiNT's libc) to
> support utmp/wtmp handling in exactly the same manner that Linux
> does (I think the Linux interface is pretty standard, hope so, at
> least).

If you need verification, I have also a fair amount of Solaris experience,
and also I think NetBSD is a little closer to "unix" than linux is in some
ways.  (all depends on your position I suppose).

> But in the absence of a shared libc (all programs are statically
> linked in MiNT) these changes will only show an effect after recompilation
> of the programs that read/write entries in these files.
> 
> Hence some programs log in the new files (at the new locations in the new
> format), others still follow the old ways (notably TosWin).

BTW, how can I make TOSWIN return "vt52" or "vt100" instead of it's
"tw52".  Why did they decide to return "tw5@", when no normal machine on
earth is going to recognize that.  For example:

(from tw2):

monolith# telnet queen.mcs.drexel.edu
Unix (r) system V Sun OS 5.2 (queen)

Login: testuser
password:

welcome to queen

blah blah blah

Unknown terminal type "tw52".

queen(1)$pine

ncurses: cannot open window on unknown display type "tw52".

etc.  I can do a manual "export TERM = vt100" each time, but why didn't
they just make it "vt100"?  Is anything gained by it having it's own ID?

> Besides, the
> utmp file must be initialized by the init daemon.  The one that is shipped
> with KGMD is out of date and a new one still waits to be finished.  A
> system V compatible init suite is available on Sparemint but in the
> current state it is plain crap and non functional (I can say that because
> I am the author ...).

The system I am using has both installed but the KGMD one is active.

> This confusion is mostly my fault because I had introduced these
> incompatible changes too early in the MiNTLib, hoping that I would be able
> to provide the missing parts in reasonable time, thus allowing a complete
> migration to the new standards.  Unfortunately it turned out that I wasn't
> able to do so because my hardware wreaked havoc and the replacement I
> have got has technical problems.
> 
> A temporary solution: A daemon that scans the old files for changes and
> updates the new files accordingly.  This daemon needs to be written
> though.  AFAIR the GNU libc has a similar tool.

interesting, though I say just recompile the old programs. ;)

> 
> BTW, the MiNTLib knows some defines that allow you to use the old
> utmp/wtmp interface in your own programs if you feel it is better to stick
> with them for a while.
> 
> Ciao
> 
> Guido


thanks,
   noah silva