# less nervt, denn es zeigt /var/log/messages hexadezimal an.

## Randy Andy

Da more und andere Pager/ Editoren das nicht tun gilt für mich:

less bugs more than more  :Wink: 

Interessanter Weise schlägt dieses Problem seit geraumer Zeit bei mir, mit sämtlichen Versionen von less und auf den verschiedensten Rechnern zu.

Nervt mich also wirklich schon geraume Zeit.

Leider wüsste ich auch nicht wie man mittels einer Tastenkombination less von der Hex-Anzeige auf ASCII-Anzeige umstellt. das wär ja schon mal ein Workaround für mich, denn ansonsten mag ich less viel lieber also z.B. more. Hier gilt schließlich: less is more  :Wink: 

Irgenwann hab ich dann festgestellt dass in meinen /var/log messages Zeichenkombination auftreten, die less anscheined von less als Magic number interpretiert werden und es zum Wechsel in den Hex-Modus veranlasst.

Diese verflixten Zeichen sehen so aus:

In ASCII:

```
Dec 16 14:34:32 ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^

@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ kernel: [    0.000000] Initializing cgroup subsys cpu

```

In Hex-Darstellung dann so:

```
Dec 16 14:34:32|

0037f520  20 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  | ...............|

0037f530  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

*

0037f620  20 6b 65 72 6e 65 6c 3a  20 5b 20 20 20 20 30 2e  | kernel: [    0.|

0037f630  30 30 30 30 30 30 5d 20  49 6e 69 74 69 61 6c 69  |000000] Initiali|

0037f640  7a 69 6e 67 20 63 67 72  6f 75 70 20 73 75 62 73  |zing cgroup subs|

0037f650  79 73 20 63 70 75 0a 44  65 63 20 31 36 20 31 34  |ys cpu.
```

Also Jeweils alles zwischen dem Datum und dem Wort kernel.

Lösche ich besagte Zeichenkombinationen/Zeilen aus der Datei, zeigt less sie gleich wieder korrekt an, solange bis der kernel mal wieder diese Zeichen neu hinein schreibt und dieses nervige Verhalten wieder von vorne los geht.

Die Frage für mich ist daher: Wer macht hier was falsch (kernel, less oder more) und wie bekomme ich das für less gelöst oder umschifft?

Bin mal gespannt wo die Reise hingeht.

Gruß, Andy.

----------

## franzf

Interessant - ich bin so an vim und dessen Bedienung/Syntax Highlighting/... gewöhnt, dass ich mir sogar nen alias less="/usr/bin/vimpager" angelegt hab  :Wink: 

Kannst du mal schaun ob "less -r /var/log/messages" geht?

Ansonsten

```
LC_MESSAGES="" man less
```

und nach "control" (sequence), hex o.Ä. durchsuchen und entsprechende Optionen testen.

----------

## Yamakuzure

Das ist nicht less, das ist lesspipe. Wenn in der Datei auch nur ein nicht druckbares zeichen drin ist, schiebt lesspipe die Datei durch hexdump (oder hd). (Siehe /usr/bin/lesspipe.sh)

Du kannst das mit 

```
 $ cat foo.bin | less
```

 umgehen.

Oder du passt deine Umgebung an:

```
 ~ $ cat /etc/env.d/70less

LESSOPEN="|lesspipe %s"

LESS="-R -M --shift 5"
```

(Notiz: da lesspipe.sh zu sys-apps/less gehört, ists natürlich in der Tat "less", das nervt.  :Wink:  )

----------

## Genone

Keine Ahnung wer die da reinschreibt (Kernel, Treiber, syslog, ...), aber NULL-Bytes haben in einer Textdatei nichts verloren. Die können halt nicht einfach als Text angezeigt werden, daher wechselt less in den Hex-Modus, andere Pager ignorieren sie einfach, kann man beides als logisches Verhalten ansehen.

----------

## Yamakuzure

 *Genone wrote:*   

> Keine Ahnung wer die da reinschreibt (Kernel, Treiber, syslog, ...), aber NULL-Bytes haben in einer Textdatei nichts verloren. Die können halt nicht einfach als Text angezeigt werden, daher wechselt less in den Hex-Modus, andere Pager ignorieren sie einfach, kann man beides als logisches Verhalten ansehen.

 Naja, nicht ganz. Wenn die Datei *nicht* mittels lesspipe durch hexdump geschoben wird, zeigt less in der Tat "^@" für jedes Nullbyte an.

----------

## Randy Andy

Hui Leute, da wart ihr aber fix.

Schon mal vielen Dank für die rege Beteiligung. Ich hatte es zwar Gestern noch gelesen, kam dann aber nicht mehr zum Antworten, nun aber der Reihe nach.

franzf

"less -r /var/log/messages" ändert leider nichts. Die man page hatte ich schon einige male durchsucht, fand aber zuvor nie etwas verwertbares oder verstand nicht die vielen angebotenen Optionen (den Wald vor lauter Bäumen nicht sehend). 

Yamakuzure's Tipp "cat foo.bin | less"  zu verwenden war dann schon mal ein funktionierender workaround, den ich noch nicht kannte.

Aber bei deinem Tipp die Umgebung anzupassen viel mir folgendes auf. Offensichtlich wird bei der Installation von less genau diese Anpassung bereits vorgenommen, denn sie ist auf all meinen Kisten schon vorhanden und wurde nicht von mir erstellt, genau so wie du sie schriebst, also:

```
 ~ $ cat /etc/env.d/70less

LESSOPEN="|lesspipe %s"

LESS="-R -M --shift 5"
```

Und sorge ich damit nicht genau dafür, dass alles durch lesspipe geschoben wird? Sorry, bin in bash noch nicht so firm.

Jedenfalls wollte ich zu testzwecken, um zu sehen ob das etwas ändert, das mal deaktivieren, also die zwei Zeilen der 70less  mal fix auskommentiert, Umgebung aktualisiert mit:

```
env-update && source /etc/profile
```

aber die export variable liefert mir immer noch:

```
export | grep less

declare -x LESSOPEN="|lesspipe %s"

declare -x PAGER="/usr/bin/less"
```

selbst nach einem Neustart mit auskommentierter /etc/env.d/70less noch das gleiche. Warum ist das so und wo kommt diese persistente Einstellung noch her?

Genone

Ja, ich dachte mir schon, dass es Auslegungssache oder ein Frage der Betrachtungsweise ist.   :Wink: 

Yamakuzure

Durch deine Anmerkungen dass ohne den Weg über lesspipe die Zeichen korrekt angezeigt werden, kam mir eine weitere Idee in Sachen Parameter aus der (hallo franzf)   :Wink:   man page.

Da gibts dann noch den -L Parameter:

 *Quote:*   

>  -L or --no-lessopen
> 
>               Ignore  the LESSOPEN environment variable (see the INPUT PREPROCESSOR section below).  This option can be
> 
>               set from within less, but it will apply only to files opened subsequently, not to the file which is  cur‐
> ...

 

mit dem gehts dann syntaktisch noch etwas einfacher statt mit cat pipe. Versuche mir erst mal den zu merken, als workaround.

Interessant wärs aber schon, less das dauerhaft abzugewöhnen, seid ihr dabei?

Bis hierhin jedenfalls schon mal vielen Dank, für die interessanten Erkenntnisse, die das hervor gebracht hat.

Griß, Andy.

----------

## Christian99

lesspipe kann man auch durch anhängen von ":" an den dateinamen deaktivieren. müsste auch in der allerersten zeile stehen, wenn du eine datie mit less/lesspipe öffnest.

----------

## Randy Andy

Hi Christian99.

Hmm, funktioniert bei mir nicht, vielleicht verstehe ich Dich aber nicht ganz richtig und verwende die falsche Syntax.

Kannst Du mir mal ein Beispiel nennen anhand von:

```
less /var/log/messages
```

 wie das mit einem Doppelpunkt bei Dir funktioniert.

----------

## cryptosteve

Den Tip mit dem Doppelpunkt habe ich auch gefunden, aber es funktioniert hier auch nicht. Zuerst dachte ich, die zsh würde mir da einen Strich durch die Rechnung machen, aber auch unter sh und bash führt das nicht zum Erfolg.

----------

## Christian99

hast dus mal mit escapen probiert? dann kannst du ausschließen, dass die shell was mit dem doppelpunkt anstellt. also

```
less <file>\:
```

----------

## Randy Andy

Wie schaut's bei Euch aus,

bei mir brngt weder escapen noch hochkommata noch sonst was, etwas.

nehme daher erst mal, wie schon erwähnt:

```
less -L /var/log/messages
```

Interessant wäre aber noch wieso die export variable von less gesetzt bleibt und wieso auskommentieren innerhalb von /etc/env.d/70less nichts bewirkt???

----------

## firefly

hast du nach der Änderung ein env-update + relogin gemacht?

AFAIK werden Änderungen in Dateien unter /etc/env.d nur übernommen, wenn env-update danach aufgerufen wurde.

----------

## Randy Andy

Türlich firefly,

schrieb ich doch etwas weiter oben, such mal nach  *Quote:*   

> env-update && source /etc/profile

 

dann findest Du's.

Dort schrieb ich auch, dass sogar ein reboot nix half.

Mache ich allerdings ein 

```
unset LESSOPEN
```

 (Danke Cryptosteve) dann gehts auch ohne tricksereien.

Fürchte nur das auch das nicht update persistent sein wird, kann aber gerade nicht rebooten, da libreoffice rekompiliert.   :Wink: 

Wo könnte "LESSOPEN="|lesspipe %s" noch zusätzlich gesetzt sein. Wie suche ich mit find mit dem string LESSOPEN="|lesspipe %s über die ganze platte bzw. erst mal durch rekursiv durch /etc.

----------

## Yamakuzure

Sorry, da war ich etwas undeutlich. Ich habe lediglich den Ist-zustand zitiert.

Wenn du lesspipe grundsätzlich abschalten möchtest, dann füge einfach eine neue Umgebungsatei hinzu:

```
 ~ # echo "LESSOPEN=\"\"" >> /etc/env.d/71less_no_lesspipe

 ~ # env-update && source /etc/profile && source ~/.bashrc

>>> Regenerating /etc/ld.so.cache...

 ~ # echo $LESSOPEN

 ~ # less /usr/share/doc/libsfml-2.1/readme.txt.bz2 

"/usr/share/doc/libsfml-2.1/readme.txt.bz2" may be a binary file.  See it anyway? 
```

Ohne die Anpassung wäre die Datei zum öffnen durch lesspipe entpackt worden.

In offenen Konsolen muss hierfür erneut "source /etc/profile" ausgeführt werden.

Grundsätzlich bevorzuge ich allerdings die "-L" Option. An die hatte ich (wohl dank temporärem Brett vor dem Kopf) garnicht mehr gedacht.

----------

## cryptosteve

Jip, ich habe ebenfalls alles probiert (mit Anführungszeichen, mit Backslash escapen, etc.) ... hat alles nicht funktioniert. Ist kein Beinbruch, verwundert mich aber trotzdem.

----------

## Randy Andy

Kurios das ganze,

denn nachdem ich hier das erste mal hier ein 

```
unset LESSOPEN
```

 eingegeben hatte, wohlgemerkt bei auskommentierten  /etc/env.d/70less Zeilen, stand deren Inhalt nach einem reboot endlich nicht mehr in der export Variable, es sah dann so aus:

```
export | grep less

declare -x PAGER="/usr/bin/less"
```

Bedeutet das nun, dass die unset Befehle die export variable betreffend persistente Wirkung haben, scheint es hier doch so zu sein, falls ich hier nicht total konfus bin.   :Rolling Eyes: 

So klappte es natürlich dann auch mit der Anzeige von less /var/log/messages.

Aber eben nicht mehr mit gepackten archiv-Dateien. Nun weiß ich auch wofür lesspipe nützlich ist und entschließe mich daher die Variablen standardmäßig wieder zu aktivieren.

Dann verwende ich eben künftig den -L Parameter wenn less mal wieder in hex anzeigt und gut ist!

Umgekehrt, sprich aktivieren durch einkommentieren der /etc/env.d/70less mit einem nachgeschalteten:

```
env-update && source /etc/profile
```

zeigte dagegen sofortige Wirkung, also auch ohne aus- / ein-loggen oder gar rebooten.

Schätze das wär damit mehr oder minder erledigt, aber als Änderungswunsch oder Bug vielleicht einen Hinweis an die Entwickler von less wert.

----------

## Yamakuzure

Der Tipp mit dem Doppelpunkt ist von 2004. Und stammt aus lynx. Mag ja sein, dass das damals, als HTML-Dateien mit lynx geöffnet wurden ging, aber heutzutage verwendet lesspipe den Befehl "html2text -style pretty" und keinen Browser mehr.  :Wink: 

----------

## Genone

 *Randy Andy wrote:*   

> Bedeutet das nun, dass die unset Befehle die export variable betreffend persistente Wirkung haben, scheint es hier doch so zu sein, falls ich hier nicht total konfus bin.   

 

Ist ganz einfach: Durch das auskommentieren + env-update werden die entsprechenden Variablen in Zukunft nicht mehr gesetzt. Das source /etc/profile setzt (neben anderen Dingen) lediglich die Variablen neu, es macht aber vorher kein generelles Reset (ist technisch auch nicht so ohne weiteres möglich), sprich Variablen die nicht (mehr) gesetzt werden behalten ihren alten Wert bis du dich ausloggst. Mit dem unset kannst du die Variablen halt vorher explizit zurücksetzen, hat aber keine persistente Wirkung (die erreichst du durch das auskommentieren).

----------

## Randy Andy

Zugegeben Genone, das klingt plausibel.

Vermutlich hat es sich so zugetragen, dass ich vor lauter Testen doch etwas "konfusioniert" war, auch wenns das gar nicht gibt.   :Laughing: 

Gruß, Andy.

----------

## Randy Andy

Hui,

gerade eben kam eine neu Version von less in den Tree, sie lautet:

```
sys-apps/less-462
```

und ich dachte noch, das gibts doch nicht, wenn das jetzt damit gefixt ist...

Aber kein Grund zur Beunruhigung, auch damit bleibt alles beim alten.   :Wink: 

Gruß, Andy.

----------

## gendjaral

Vorweg:

Frohe Weihnachten liebe Community!   :Very Happy: 

Ich bin nicht der Meinung das hier ein Mangel bei "less" existiert - wohl eher bei "syslog-ng".

Ein grep error /var/log/messages führte bei mir analog zu einer Fehlermeldung (... it's a binary file).

 *Genone wrote:*   

> Keine Ahnung wer die da reinschreibt (Kernel, Treiber, syslog, ...), aber NULL-Bytes haben in einer Textdatei nichts verloren....

 

Der Meinung schließe ich mich an, weshalb ich das Problem lieber an der Wurzel anpackte:

https://bugs.gentoo.org/show_bug.cgi?id=406623

Wie im bugtracker angesprochen half es auch bei mir

```
options {

        threaded(yes);

        chain_hostnames(no);

...

```

durch

```
options {

        threaded(no);

        chain_hostnames(no);

...

```

in /etc/syslog-ng/syslog-ng.conf zu ersetzen.

Vielleicht hilft dies ja weiter.

Wenn es übrigens einen Grund gibt warum ich dies nicht machen sollte; nur her damit.   :Smile: 

----------

## mv

 *Yamakuzure wrote:*   

> Der Tipp mit dem Doppelpunkt ist von 2004. Und stammt aus lynx.

 

Möglich, dass da auch der Doppelpunkt-Trick benutzt wurde.

Ich vermute aber, dass Christian99 das less aus dem mv Overlay mit USE=lesspipe benutzt: Das zugehörige lesspipe (von Wolfgang Friebel) ist wesentlich mächtiger als die Schmalspur-Variante, die in Gentoos "default" less.ebuild eingebaut ist. Und das lesspipe von Wolfgang Friebel unterstützt die Dopplepunkt-Konvention.

----------

## Christian99

ja genau, aber mir war nicht bewusst, dass das unterschiedliche lesspipes sind.

----------

## Yamakuzure

@mv Ach so ist das. Na, dann probiere ich das mal aus, sollte mir in der Schmalspurvariante was fehlen. Bislang habe ich lesspipe allerdings eher abgestellt.  :Wink: 

----------

## mv

 *Yamakuzure wrote:*   

> Bislang habe ich lesspipe allerdings eher abgestellt. 

 

Ich auch, aber das volle Projekt mit Support für Filetypen wie .pdf, .doc, .dvi, .mp3, .tar.bz2, .tar.xz, .zip usw (wenn die entsprechenden USE-Flags für sys-apps/lesspipe aktiviert sind) und Kolorierung von Shell-Scripten u.ä. ist dann doch ganz praktisch, zumal man es bei Bedarf mit ":" ja jederzeit temporär abstellen kann, wo es unerwünscht ist.

----------

## Randy Andy

 *gendjaral wrote:*   

> 
> 
> Ich bin nicht der Meinung das hier ein Mangel bei "less" existiert - wohl eher bei "syslog-ng".
> 
> Ein grep error /var/log/messages führte bei mir analog zu einer Fehlermeldung (... it's a binary file).
> ...

 

Man ey, ich glaub ich werd alt und vergesslich,

denn ich merke doch tatsächlich erst jetzt, beim nochmaligen durchlesen des von Dir verlinkten Bug-reports, das ich es selbst als erster war (2012-07-17 10:53:12 UTC ), der erkannt hat, dass das Problem an der Verwendung des threading liegt.  :Rolling Eyes: 

Angeregt durch die Nachfrage von Mr. Bones dort, hab ich mir das eben noch mal angesehen und mich über folgendes gewundert, weil's hier auf einmal ging, sprich less zeigt mir gerade mal wieder die /var/log/messages fehlerfrei als Text an und ich dachte mir, wie kann das sein?

Und tatsächlich, ich hab gerade eine messages auf der Platte, die, obwohl sie Null Byte Zeichen enthält noch als Text erkannt wird:

```
file /var/log/messages

/var/log/messages: ASCII text
```

Hier die besagte Passage daraus:

```

 syslog

0071b50: 2d6e 6720 7374 6172 7469 6e67 2075 703b  -ng starting up;

0071b60: 2076 6572 7369 6f6e 3d27 332e 342e 3727   version='3.4.7'

0071b70: 0a4a 616e 2031 3920 3138 3a32 373a 3431  .Jan 19 18:27:41

0071b80: 2000 0000 0000 0000 0000 0000 0000 0000   ...............

0071b90: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071ba0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071bb0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071bc0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071bd0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071be0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071bf0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071c00: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071c10: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071c20: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071c30: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071c40: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071c50: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071c60: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071c70: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0071c80: 206b 6572 6e65 6c3a 205b 2020 2020 302e   kernel: 
```

Verwende ich aber eine messages Datei eines anderen Rechners, wird diese hier wie da von less falsch angezeigt, auf drei verschiedenen Rechnern, was aber auch nun klar für mich ist, denn file lügt nicht:

```
file /var/log/less-message-test-nio

/var/log/less-message-test-nio: data
```

Alle Kisten sind auf dem gleichen stand, sprich verwenden syslog-ng-3.4.7 und less-462

Die heutige Preisfrage aber lautet für mich: Wieso wird eine Datei mit inkludierten Null Byte Zeichen mal als text und mal als data erkannt.

In den als data erkannten files kommen die Einträge allerdings häufiger vor, was ev. den Unterschied ausmachen könnte. Oder spielt die Position des Null Byte Zeichens die Maßgebliche Rolle.

Wo steht das eigentlich beschrieben (RFC?), wer hat das festgelegt?

Fragen über Fragen.

 *gendjaral wrote:*   

> Wenn es übrigens einen Grund gibt warum ich dies nicht machen sollte; nur her damit.  

 

Ich hab da eine These warum das threading implentiert und aktivert wurde: Vermutlich damit ein hängender oder exzessiver Schreibprozess nicht die Reaktionsfähigkeit des gesamten Systems in den Keller ziehen kann, im worst case eben, auch wenn wir so etwas selbst vielleicht noch nie erlebt haben oder es zu provozieren wüssten.

Aktuell kommen mir aber als Beispiel aber aus der systemd- und somit auch logd-Diskussion, die damit gelegentlich auftretenden Performance-Probleme in den Sinn, wenn mal etwas mangels Stabilität dort ins Straucheln gerät.

Sonst fällt mir aber kein plausibles Argument ein.

Da müsste man vielleicht den Programmierer Fragen, denn statt seit Jahren an neuen Releases zu tüfteln, hätte er ja einfach nur die Änderung in der ausgelieferten syslog-ng.conf zurück nehmen brauchen, wenn's so einfach wäre.  :Wink: 

Gruß an alle die's noch interessiert.

Andy.

----------

## Genone

 *Randy Andy wrote:*   

> In den als data erkannten files kommen die Einträge allerdings häufiger vor, was ev. den Unterschied ausmachen könnte. Oder spielt die Position des Null Byte Zeichens die Maßgebliche Rolle.
> 
> Wo steht das eigentlich beschrieben (RFC?), wer hat das festgelegt?

 

Das wird über die MIME Datenbank aufgelöst die auch vom 'file' Befehl verwendet wird. Ist aber nix wo man mal eben schnell was nachschauen bzw. ändern kann (nicht gnaz triviales Binärformat). Und ja, die Position der Nullbytes kann da wesentlichen Einfluss drauf haben, denn meistens wird für die Dateityperkennung aus Effizienzgründen nur der Anfang einer Datei benutzt, wenn da direkt in den ersten paar Bytes schon NULL (oder andere Steuerzeichen) steht kann es halt kein Text sein.

----------

