Dotaz: BASH: Jak připsat údaj na začátek souboru?

[Honza]

Zdravím, chtěl bych se zeptat jestli někdo nevíte jak v BASH skriptu připsat údaj na začátek souboru. Tvořím něco jako souborovou databázi a potřeboval bych aby údaj, který se má zapsat, zapsal na první řádek. Něco jako:

echo "Hodnota1=15;Hodnota2=30;Hodnota3=5" >> /home/graf/data/stat.dat
Jenže tohle připíše na konec souboru jde nějak lehce a efektivně zapisovat na začátek do první řádky a zbytek dat "jakoby posunout" dále? Děkuji.

---

---

Odpovědi

[David Watzke]

No jde to snadno, ale je to chlívárna, protože tím víc fragmentuješ diskovej oddíl.

mv orig orig.old
echo "new record" > orig
cat orig.old >> orig
rm orig.old

[deadmail]

a co tak sed?

sed -i '1iHODNOTY' SUBOR

[Honza]

Skvely diky moc to je ono . Ten postup s kopirovanim a znovu vkladanim me napadl ale po delší dobe bude soubor dost velky a tahle operace by se dělala pro vice databazi a bylo by to časem naročne. Díky moc ten sed sem neznal.

[David Watzke]

Použití sedu je sice lepší, ale náročný to bude taky a furt platí to, co jsem psal já. Ostatně si to zkus na větší soubor...

[Semo]

Sed pri -i robi presne to, co ti rozpisal hore kolega do viacerych prikazov.

This option specifies that files are to be edited in-place. GNU `sed' does this by creating a temporary file and sending output to this file rather than to the standard output. When the end of the file is reached, the temporary file is renamed to the output file's original name.

Daj robit sedu nejaku narocnejsiu pracu na vacsom subore a sleduj *.tmp subory v aktualnom adresari, ktore sa na zaver presunu na povodne miesto. Skus si to v adreari, kde nemas pravo zapisu a uvidis nieco ako:

sed: couldn't open temporary file ./sedGiiwXI: Permission denied

Takze rychlostne si nijak nepomozes. Mozes skusit si nechavat na zaciatku suboru hlavicku ukazujucu na offset v subore, kde zacinaju skutocne data a medzi hlavickou a datami bude volny priestor, ktory sa bude postupne zaplnat a patricne aktualizovat hlavicka. Az sa zaplni cely, tak subor presypes do noveho a zase vyrobit volne miesto. Cim budes kopirovat obsah iba raz za cas.

[Honza]

Ok diky za informaci - jsem zas chytrejsi. Ale radeji zustanu u toho sice "krkolomensiho" presunu souboru (sed) kde to zatizi server pri pripisu nez kdyz se pak bude nacitat pres web rozhrani statistiky z techto databazi a pruchody by byli pomalejsi - resp bude to potrebovat vzdy jen prvni radek pokud budou pripisy na zacatek souboru neprochazi se cely file).

[Dejv]

Ahoj.

A co tak misto sedem na zacatek to zapisovat normalne na konec a lessem si vypsat jen posledni radek? Volani "neceho ze systemu" to je tak jako tak a rekl bych, ze less -n 1bude podstatne rychlejsi, nez sed -i.

Dejv

[Michal Kubeček]

Předpokládám, že místo less myslíte tail.

[jekub]

a nebylo by lepsi jednoduse pridavat data na konec a k souboru (soborum) pak pristupovat od konce?

[David Watzke]

Ještě lepší by bylo použít databázi...

[Honza]

prosim databazi jako takovou opravdu ne, znam jeji vyhody a nevyhody a v tomto pripade kdy se o tu souborovou databazi lehce postara system (linux) bude vyhodnejsi. Take sem o tom uvazoval a vyhrala to souborova databaze. Ale jinak dekuji

[rADOn]

Nedej se. Tahleta moda cpat vsechno do databazi stejne casem prejde.

[Pavel Stárek]

Copak databáze, to by ještě šlo, ale ty pitomé XML soubory to je zážitek. Místo třeba settings.ini:

playsound=1

Budu mít settings.xml:

<?xml version="1.0" encoding="UTF-8"?>
  <settings>
    <param name="playsound">1</param>
  </settings>

Takže oproti 12 bajtům, takovej bastl + xml parser v aplikaci.

[Michal Kubeček]

No hrůza… Tedy až na to, že ten XML parser vlastně není v aplikaci ale v knihovně a že v okamžiku, kdy se v budoucnu zkomplikuje struktura toho konfiguračního souboru, bude XML najednou jednodušší, přehlednější a hlavně snáze parsovatelné než ten původně jednoduchý konfigurační soubor.

Tím samozřejmě nechci tvrdit, že má být všechno v XML. Ale stejně tak nepovažuji za správné šmahem odsoudit konfiguraci v XML jako apriorní nesmysl.

[happy barney]

ono je to skôr o návrhu toho xml. param name= je skutočne choré (asi ako rakovina = množí sa a množí ...)

[Semo]

Pokial sa v name moze vyskytnut hocijaky retazec a zaroven mas par elementov, ktore tvoria kostru toho XML a nemozu sa vyskytnut kdekolvek len tak, tak skoncis pri <param name="nazov"

Nestaci si len precitat jeden clanok na webe, ktory to odsudzuje a vztiahnut to na cely svet.

Sam som nedavno v praci pisal program, ktory uzivatel bude krmit konfigurakom so stromovymi datami a v podstate s lubovolnymi nazvami. Inak ako param name="..." si neporadis a bez XML by som si tak akurat musel vymysliet vlastny hierarchicky format, parser na neho a uzivatel by ho pisal iba v nejakom obecnom editore. Takto mam format standardizovany, nemusim k nemu pisat dokumentaciu popisujucu kazdy znak, staci to oznacit za XML a dodat k tomu XSD. Parserov je dost, user si moze zohnat XML editor a editovat to kulturne.

Cim ale nevravim, ze v pripadoch, kde je struktura dat plocha a moznosti su dopredu zname nie je napr. INI format vhodnejsi a uspornejsi.

[Honza]

Heh docela se rozrostla debata o ukladani dat a nastaveni, co se tyče programů co občas v Delhpi delam (ja vim dinosaur ale na to C# furt ne a ne zvyknout i to XML tomu moc nepomaha), tak tam sem vzdycky delal ini soubory vyjimecne registry. A ohledne ukladani dat v dotazu sem vybral souborovou databazi proto, protoze do toho lehce vlozi data system (linux) jednim radkem kodu (echo "..." >> nebo sed ..) a jsou udaje v databazi. Takhle jednoduse a rychle by to do normalni databazky neslo - navic server ma mensi naroky takhle by musel mit web server s php a databazi ted si vystacim jen s web serverem s php - navic kdyz spadne normalni databaze bezne rychle se na data co potrebujete nepodivate - v té souborové databazi vyčtu nejporebnejsi (ty posledni) udaje behem dvou klinuti a otevreni v notepad/lister/less/vi/atd... Kazdopadne nove technologie shomaždovani dat (databaze, settings XML) nezavrhuju, jen mi prijde ze nekdo je pouziva uplne bez rozmyslu jen proto ze je to ted "in", ze to vsichni pouzivaj a protoze je to skoro jako "apple " pritom kdyby si srovnaly klady zapory mozna by jim nektera ze starsich technologii (moznosti) poslouzila lepe.

[rADOn]

+1

Pro XML jsou rozumny duvody, ale je jich malo. Vetsina lidi to pouziva z lenosti.

[Honza]

No ja si klidně necham poradit a nechci aby to vypadalo jako ze chci zalozit flame to opravdu ne ale pokud by nekdo byl hodny a poradil co bude efektivnejsi tak budu rad. jsou jen dve moznosti:
1)tu kterou sem tu nastinil - to jest aktualni data (mala do 1kb) se na serveru přičtou do souborove databaze na začatek - např zminovany sed. Tu databazi pak prochazi web server s PHP kdy potřebuju do tabulky (kterou generuju na zaklade dat v databazi) vepsat posledni udaj v databazi - ten je v tomto pripade na prvnim radku v databaze
2)druha moznost - mala aktualni data (1kb) se prictou lehce do databaze na konec souboru. web server s PHP potrebuje sahnout do databaze vzdy pro posledni (aktualni) data (takze na konec v tomto pripade).

No a mam pocit (nerikam ze spravny), ze bude toto reseni 1 rychlejsi protoze to PHP nebude muset natahnout cely soubor databaze do (fopen, mod => FRead (soubor, FileSize (soubor)) pameti aby zjistilo kolik ma radku, skocilo na posledni a vypsalo...

[Aleš Janda]

Pokud tušíš, jak ten řádek bude max. dlouhý, můžeš se FSeek()nout někam ke konci, přečíst ten zbytek, vybrat poslední řádek a je to. Zapisovat něco na začátek a kopírovat pořád celý soubor se mi zdá strašné řešení.

[cronin]

Zalezi, co je "kriticka" operacia, ci pridavanie zaznamov alebo citanie toho jedneho inkriminovaneho. A ak je treba skutocne iba jeden posledne pridany subor [a citanie je kriticke], preco ho nedrzat v samostatnom subore?

[kuka]

No asi tak, zapis to do toho "databazoveho" souboru nakonec a jeste do jineho souboru, kde je pouze ten posledni radek a prepisuje se.

[Honza]

ahooj diky vsem za navrhy a popisu jeste trochu vic co se s tou databazkou deje. S tim souborem pracujou asi 2 tabulky pričemž jedna tabulka pracuje jen a pouze s poslednim zaznamem (tim aktualnim) a druha by pak prochazela celym souborem - ta se ovšem nebude bežně použivat až v připadě problemu nebo archivaci databaze (udaje starši mesice se odpoji vloži do samostatneho souboru a zaarchivuji - tudis ta hlavni pouzivana databaze nebude nikdy nekonecna resp mela by si hlidat rozumnou (vyuzitelnou) velikost) Takze ta myslenka nejprve precist aktualni udaj a pak to pripojit me napadla ale pri tom pouziti by pak nebyla videt v druhe tabulce jeslti vam to pomuze muzu hodit link na web kde to tvorim (pokud nezkritizujete vsechno od grafiky po tabulky ).

[dustin]

Co myslíš těmi "tabulkami"? Nemělo to spíš být skripty?

[Honza]

jsou to php skripty ktere na zaklade dat v souboru tvori tabulku - tohle je skript ktery šahá po poslednich datech v souboru:

$p = 0;					//counter na 0
$slozka = dir("./data");			//urceni slozky s databazema
while($soubor=$slozka->read()) {		//cyklus dokud neprojde celou slozku
  if ($soubor=="." || $soubor=="..") continue;	//vynecha na zacatku cyklu radky "." a ".."
	$soubor = explode(".", $soubor);	//roseka string soubor.pripona na soubor
	$seznam_souboru[$p] = $soubor[0];	//a ulozi do pole seznam_souboru
	$p++;					//pricte counter
}
$slozka->close();				//zavre slozku

... ted nasledujou html tagy a v html zacatek deklarace tabulky ktera pokracuje generovanim jejiho obsahu pomoci php...

for ($p = 0; $p < count($seznam_souboru); ++$p){

  $soubor = fopen("./data/$seznam_souboru[$p].txt","r"); 
  $nalezeno = false;
  while(!$nalezeno && !feof($soubor)) { 
    $data = explode(";", fgets($soubor));
    $nalezeno = true;		//v pripade hledani (ted deakt.)
  }

echo "tr
            td".$seznam_souboru[$p]."/td
	    td".$data[1]."/td
            td".$data[2]."/td
            td".$data[3]."/td
            td".$data[4]."/td
            td".$data[5]."/td
            td".$data[6]."/td
            td".$data[7]."/td
            td".$data[8]."/td
            td".$data[9]."/td
            td".$data[10]."/td
       tr";
}

znacky <> jsem u tr a td musel odstranit pac se mi tu nechteli zobrazit (kdyz formatuju tagem < pre > ) A ta druha tabulka bude generovana obdobne akorat bude prochazet cely soubor a hledat + počitat nektere udaje. Díky moc snad tohle pomuže

[Semo]

Kuka ti radi zapisovat zaznam sucasne do oboch suborov. Do jednoho apendovat na koniec, ten bude stale narastat, ale bude drzat vsetky zaznamy (pre tabulku/skript 2). Druhy subor sa prepisuje, ma stale velkost jedineho zaznamu a pracuje s nim tabulka/skript 1.

[Honza]

jop to by nemuselo byt spatny, jeden soubor navic me nezabije a pristup k potrebnym datum bude rychly - od podrobneho prohledavni X databazovych souboru nikdo nepocita bleskovou reakci (ale u aktialnich a dulezitych udaju jo)

[František Bublík]

Zdar,

miluju jednoduchá řešení. Proto bych zapisoval normálně pomocí např "echo text >>" na konec souboru. Pro výpis souboru bych pak do roury předřadil "tac" je to ekvivalent "cat"u, ale vypisuje řádky v opačném pořadí - takže poslední řádek = první .

[Jiří Lisický]

No taky existuje souborová databáze sqlite. Jestli to neznáš mrkni na to.

[Semo]

Sqlite je asi tak suborova, ako Mysql. Obe maju datove subory, v ktorych maju data vo vlastnom formate. Vacsina beznych DB je suborova. Vynimka su tak akurat molochy ako napr. Teradata, kde uz s anehra na nejaky obecny fs, ale DB pristupuje rovno k disku a organizaciu sektorov si riesi sama. Ale bezny linuxovy pouzivatel sa s nimi velmi nestretava.

[kuka]

Pisatel mel asi na mysli, ze celou databazi sqlite tvori jeden soubor a extremne jednoduse se pouziva, nema konfiguraci, je velmi nenarocna na zdroje atd. Pokud bylo duvodem nepouziti databaze ze je to pro tento pripad kanon na vrabce, jak jsem pochopil z prispevku vyse, tak sqlite by mohlo prave pro svou jednoduchost stat za uvahu.

[rADOn]

Berkeley DB a klony je jeste jednodussi a pokud clovek nepotrebuje SQL casto i lepsi.

[cronin]

Ale zavislosti aplikacii na tej-ktorej verzii Berkeley DB su peklo.