Wer/Was definiert File-Types ?

[Hexxer]

Hi,

ich wusste nicht wo ich die Frage mal stellen kann. Das unten angesprochene Grep geht auch auf Linux nicht.

Eine Frage. Wo/wer oder was bestimmt was für ein File ich habe ?
Beispiel unter Solaris "file abcd.....Ausgabe Aciii Text" oder Commands Text usw..

Hintergrund: Ich hab eine Textfile aus Windows was ich unter Solaris problemlos lesen kann (Klartext). Allerdings funktioniert kein Grep. cat abcd | grep test gibt kein Ergebnis zurück, keine Fehler, kein nichts.
File sagt "Commands text".

Vermutet wird das es ein Binärfile ist oder zumindest so definiert ist.  Daraus ergibt sich die durchaus spannende Frage für mich: Wo ist definiert oder wer erkennt was ein File ist ?

[oreissig]

Es gibt unter Unix keinen Dateityp in dem Sinne, file wendet ausschließlich Heuristiken an und schätzt dann, was wohl in der datei sein könnte.

Meine Vermutung ist bisher die, dass da wohl beim kopieren was schiefgelaufen ist.
Wenn du nur cat $DATEINAME machst, siehst du denn dann auch das gleiche, wie an der windows-kiste?

[escimo]

"file" liest (auch) den Header der jeweils angegebene Datei aus, z.B. bei PDF:

$ file sparc-t3-chip-ds-173097.pdf
sparc-t3-chip-ds-173097.pdf: PDF document, version 1.5

@Hexxer: Was passiert, wenn du dos2unix <deine_Datei> und anschließend ein grep drauf machst?

[Ebbi]

Das steht in der /etc/magic:
http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/magic.htm

Wenn in der Datei abcd der String test nicht vorkommt, wird auch nichts zurückgegeben.

Guck doch mal mit od -c abcd nach.

[escimo]

Wenn ich in meine /etc/magic unter Linux (Ubuntu 8.10), sehe ich nur einen Kommentar drin:

Code:

# Magic local data for file(1) command.
# Insert here your local magic data. Format is described in magic(5).

Das ist bei Ubuntu (8.10) in einem anderen Pfad untergebracht: /usr/share/file/magic

... auch nachzulesen unter:
$ man 5 magic

Kann also locker erweitert werden.

[Hexxer]

Hi,

die Datei ist ein Log des Windows-Zeitdienstes. Kann man tatsächlich ganz normal in jedem Editor lesen, cat geht, more geht, vi unter Solaris scheinbar auch.
Ein Kollege hat unter Linux bei der Datei nur Unsinn stehen, nicht human readable.

dos2unix - geht nicht
cat datei > neue Datei - geht nicht
tail -100 datei > neue datei - geht nicht

geht nicht bedeutet das man die neue Datei ansehen kann (und auch lesen geht), aber das grep läuft wieder nicht.

od -c abcd

Hab ich gesehen weil ein Kollege das vorgeschlagen hat. Octetdump, OK. Aber was sollte der anzeigen ? Hab das einmal vor Jahren ausgeführt und da lief nur na Matrix-ähnliche schlange über den Screen.

Alles in allem reichlich Mysteriös. Nicht kriegsentscheidend, aber mysteriös

[Hexxer]

Hi,

so, ich hab das ganze mal @Home nachgestellt. Allerdings auf nem win7 Hosts. Windows.Zeit Debugger eingeschaltet (Google w32time debug), ein Log schreiben lassen.
Hab Linux hier, das zeigt es als "Data" an, wenngleich der Inhalt per cat lesbar ist und grep nicht geht. Hab kein Solaris hier, aber sol10/sparc hat sowas @work als Text gesehen.

Im Anhang das File. Hab es als "w32time.log" erstellen lassen, damit ich es hier reinhängen kann hab ich das .txt hinten dran gehängt.

MFG

[Fleedwood]

das sind wide character, womit dann viele 0 bytes drin sind, was den grep zu bemerkung binary file hinreißt und letztendlich ein simples
greppen nach abcd zum scheitern verurteilt

recode -f UTF-16LE < <file>

wirft schon ganz schön viel zum greppen aus...

Thomas.

[Hexxer]

OK, was auch immer wide Charakters sind. Da musst du ja auch ersteinmal drauf kommen. Wäre ich nie, sonst hätte ich nicht gefragt. Gerade bei nem Standard-Logfile. Nunja, MS hat Standards ja eh gerne selbst definiert ;9

[Fleedwood]

OK, was auch immer wide Charakters sind. Da musst du ja auch ersteinmal drauf kommen. Wäre ich nie, sonst hätte ich nicht gefragt. Gerade bei nem Standard-Logfile. Nunja, MS hat Standards ja eh gerne selbst definiert ;9

naja wirklich Standard hat das M$ nicht gemacht, ist halt eine 16Bit Codierung von Unicode. Aber anstatt den zwar zum Teil auch etwas häßlichern Einsatz von UTF-8
war M$ IMHO idiotischerweise der Meinung 16 Bit Charcter einzuführen...

Thomas.

[Hexxer]

OK. Gerade mal geschaut, zumindest unter Standard-Solaris gibts kein Recode. Wie gesagt, nicht weiter tragisch, ich hab alles was ich brauche.
Ist an sich ja wohl auch ein eher seltener Zufall.

MFG

[Fleedwood]

ist ein GNU tool.

Thomas.

[Ten Little Indyans]

Entsprechendes Solaris-Bordmittel ist iconv.

Ich hatte zwar schon obskure Fälle die nicht liefen, aber mit UTF-16 kann bereits Solaris 8 umgehen. (Die Datei habe ich mit Windows Notepad erzeugt und als "Unicode" gespeichert.

Code:

$uname -rsp
SunOS 5.8 sparc
$cat unitest.txt
��Dies ist ein Test
$od -c unitest.txt
0000000 377 376   D  \0   i  \0   e  \0   s  \0      \0   i  \0   s  \0
0000020   t  \0      \0   e  \0   i  \0   n  \0      \0   T  \0   e  \0
0000040   s  \0   t  \0  \r  \0  \n  \0
0000050
$grep Test unitest.txt
$iconv -f UTF-16 -t UTF-8 unitest.txt | grep Test
Dies ist ein Test
$iconv -f UTF-16 -t 8859-1 unitest.txt | grep ein
Dies ist ein Test

Die beiden Sonderzeichen am Anfang der Datei sind das BOM (Byte Order Mark) mit dem die Datei als Little-endian identifiziert werden kann.

Bei der Konvertierung von UTF-16 wird das BOM automatisch entsorgt. Gibt man explizit UTF-16LE an so wird offenbar versucht es mit zu konvertieren...

Code:

$iconv -f UTF-16 -t 8859-1 unitest.txt | od -c
0000000   D   i   e   s       i   s   t       e   i   n       T   e   s
0000020   t  \r  \n
0000023
$iconv -f UTF-16LE -t 8859-1 unitest.txt | od -c
0000000   ?   D   i   e   s       i   s   t       e   i   n       T   e
0000020   s   t  \r  \n
0000024