[linux_logo] Problemen met /etc/issue

Pagina: 1
Acties:

  • geertb
  • Registratie: Juli 2001
  • Laatst online: 15-11-2025
Ik zit nu al 1,5 uur te kloten met linux_logo en ik ben het een beetje zat :|

Het probleem is dat linux_logo de outputs gooit van o.a. de load en de uptime, maar als je
code:
1
linux_logo -u -s -y >> /etc/issue


Doet, slaat 'ie natuurlijk maar 1x de gegevens van de load en uptime op.

Omdat ik in getty geen variabelen kan vinden voor load/uptime en nog wat dingetjes, wilde ik eigenlijk /etc/issue elke keer dat 'ie aangeroepen wordt gewoon linux_logo -u -s -y laat uitvoeren.

Echter, /etc/issue wordt erg als tekst benaderd. Als je al iets doet zoals:

code:
1
2
3
4
5
#!/bin/sh

#Let it start

/usr/bin/linux_logo -u -s -y


spuugt 'ie dit als pure tekst uit.. Het lukt me dus maar niet..

Iemand tips? Ik ben even beswel de weg kwijt nu...

  • igmar
  • Registratie: April 2000
  • Nu online

igmar

ISO20022

geertb schreef op 16 december 2003 @ 17:03:
Ik zit nu al 1,5 uur te kloten met linux_logo en ik ben het een beetje zat :|

Het probleem is dat linux_logo de outputs gooit van o.a. de load en de uptime, maar als je
code:
1
linux_logo -u -s -y >> /etc/issue


Doet, slaat 'ie natuurlijk maar 1x de gegevens van de load en uptime op.
Sja. Ik zie het nut niet zo van een constant veranderende /etc/issue, behalve voor grappen zoals uptime ed, en dat gebruikt zowat niemand.
Omdat ik in getty geen variabelen kan vinden voor load/uptime en nog wat dingetjes, wilde ik eigenlijk /etc/issue elke keer dat 'ie aangeroepen wordt gewoon linux_logo -u -s -y laat uitvoeren.

Echter, /etc/issue wordt erg als tekst benaderd.
Het is tekst, niet meer, niet minder. Het ding wordt ingelezen, de en wordt wat substitutie op toegepast, en naar de terminal geschreven.
Iemand tips? Ik ben even beswel de weg kwijt nu...
Een crontabje, of een andere getty gebruiken die het wel kan.

  • geertb
  • Registratie: Juli 2001
  • Laatst online: 15-11-2025
Mja.. crontab zou idd kunnen, ik had eigenlijk gehoopt op een escapecode in getty die de uptime deed, maar getty wil dat niet ;) Tijd & Datum wel, uptime&load dus niet.. En ik vind de load iig wel fijn eigenlijk:)

[ Voor 14% gewijzigd door geertb op 16-12-2003 17:20 ]


  • igmar
  • Registratie: April 2000
  • Nu online

igmar

ISO20022

geertb schreef op 16 december 2003 @ 17:19:
Mja.. crontab zou idd kunnen, ik had eigenlijk gehoopt op een escapecode in getty die de uptime deed, maar getty wil dat niet ;
Die bestaat echt niet :)
) Tijd & Datum wel, uptime&load dus niet.. En ik vind de load iig wel fijn eigenlijk:)
Ik zou zeggen : Hack het in mingetty. Zowel uptime als loadavarage zijn in Linux extreem simpel te implementeren.

  • tech-no-logical
  • Registratie: December 2000
  • Laatst online: 19-02 15:13
dat kan (misschien) met een named pipe. google voor een uitleg van het fenomeen. een scriptje dat zou kunnen werken (niet getest, aangepast van een random .signature script !):

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#!/usr/bin/perl

use strict;

my $NAMED_PIPE = "/etc/motd";

### Make sure the named pipe exists.  If not, set it up.
unless (-p $NAMED_PIPE) {
  system("rm $NAMED_PIPE") if -e $NAMED_PIPE;
  if (system("mkfifo $NAMED_PIPE")) {
    die "Couldn't make named pipe ($NAMED_PIPE)n";
  }
}


### Loop forever
while(1) {
  open(MOTD,">/etc/motd") || die "Can't write to named pipe.n";

  ### Create motd dynamically
  my $motd = `linux_logo`;

  ### Send it to the named pipe
  print MOTD $motd;

  ### Close the named pipe (the current program will think it has read the
  ### entire file.
  close(MOTD);

  ### Prevent the next pipe we open from catching the end of the current
  ### request.
  sleep 1;

}


edit:
even vergeten

scriptje opslaan als $scriptnaam, chmod ugo+x $scriptnaam, opstarten als "$scriptnaam &". de user die dit opstart heeft schrijfrechten nodig in /etc...
als een "cat /etc/motd" steeds courante info geeft, dan werkt 't :)

edit:
foutje

vervang /etc/motd door /etc/issue. had ff verkeerd gelezen. mijn bsd heeft geen /etc/issue.

[ Voor 27% gewijzigd door tech-no-logical op 16-12-2003 22:26 ]