Dotaz: Jak nahradit cut sedem?

[pulpe]

Zdravím všechny,

potřeboval bych pomoci, jak nahradit příkaz cut -c4- pomocí sedu. Našel jsem si toto

cut -c 10     =     sed 's/\(.\)\{10\}.*/\1/'

Díky za nápady.

---

---

Odpovědi

[pulpe]

$ echo 1234567890 |cut -c4-
4567890
$ echo 1234567890 |sed 's/\(.\{3\}\)\(.*\)/\2/'
4567890

Řetězec se rozdělí na dvě části:
\(.\{3\}\) - první tři znaky
\(.*\) - zbytek (od čtvrtého znaku až na konec)

A následně se celý řádek nahradí za obsah druhé části \2.

[pulpe]

Děkuji moc.

[pulpe]

Nebo v případě právě toho příkladu ( -cX- ) by stačilo jen:

$ echo 1234567890 | sed "s/.\{3\}//"
4567890

(nebo samozřejmě pro -c4- sed "s/...//" ).

[pc2005]

Hmmm asi jsem měl použít "pre" místo "code" :-/.

[David Watzke]

Opraveno

[Patrik Uhrak]

Zdravim,

aky je zmysel tvojho pocinania, myslim vymeny cut za sed ? Cisto zo zaujimavosti sa pytam a z rovnakeho zakladu som odskusal cut, sed a bash v nasledujucom skripte:

 

#! /bin/bash

VAR='abcdefgh'

CUT_FUNCTION()
{
local INDEX
while [[ ${INDEX} -lt 1000 ]]
do
	echo "${VAR}" | cut -c4- > /dev/null
	let INDEX++
done
}

SED_FUNCTION()
{
local INDEX
while [[ ${INDEX} -lt 1000 ]]
do
	echo "${VAR}" | sed 's/.\{3\}//' > /dev/null
	let INDEX++
done
}

BASH_BUILTIN_FUNCTION()
{
local INDEX
while [[ ${INDEX} -lt 1000 ]]
do
	echo "${VAR:3}" > /dev/null
	let INDEX++
done
}

time CUT_FUNCTION
echo '-----------------------------------------'
time SED_FUNCTION
echo '-----------------------------------------'
time BASH_BUILTIN_FUNCTION
echo '-----------------------------------------'

A vystup skriptu je :

 

real    0m1.524s
user    0m0.824s
sys     0m0.764s
-----------------------------------------

real    0m1.630s
user    0m3.224s
sys     0m1.104s
-----------------------------------------

real    0m0.055s
user    0m0.056s
sys     0m0.000s
-----------------------------------------

Niekolkokrat som to spustil a vzdy bol sed najpomalsi. A pokial mozes pouzit bash, tak potom je zrejme, co je pouzit najvhodnejsie a najrychlejsie. Ale mozno mas specificku situaciu, kedy to musi byt sed.

Kazdopadne to ber len ako zaujimavost, ak vobec. Nemal som co na robote, tak to takto vyzera potom. :)

[Ash]

Ale no tak :) Vytvářet/spouštět 1000x proces cut/sed a říkat "jak je to pomalé" oproti jednou spuštěnému bash (ve kterém 1000x uděláte nějakou řetězovou operaci) je trochu nefér vůči cutu/sedu. Až zase budete mít volnou chvilku, chtělo by to zopáknout měření a tentorkát férově - třeba na 1000řádkovém souboru (cut ... soubor.txt, sed ... soubor.txt, while read; echo ...; done <souboru.txt).

[Patrik Uhrak]

Tak aby sme boli ferovy, tak som to zopakoval:

#! /bin/bash

SUBOR=subor.txt

CUT_FUNCTION()
{
cut -c4- "${SUBOR}" > /dev/null
}

SED_FUNCTION()
{
sed 's/.\{3\}//' "${SUBOR}" > /dev/null
}

BASH_BUILTIN_FUNCTION()
{
declare LINE
declare -i INDEX
while read LINE
do
	echo "${LINE:3}" > /dev/null
done < "${SUBOR}"
}

time CUT_FUNCTION
echo '-----------------------------------------'
time SED_FUNCTION
echo '-----------------------------------------'
time BASH_BUILTIN_FUNCTION
echo '-----------------------------------------'

a vysledok je, ze sed a cut je v rozmedzi 10 az 20x rychlejsi. Vid vysledok:

real    0m0.003s
user    0m0.004s
sys     0m0.004s
-----------------------------------------

real    0m0.005s
user    0m0.004s
sys     0m0.000s
-----------------------------------------

real    0m0.062s
user    0m0.044s
sys     0m0.008s
-----------------------------------------

Takze ano, mas pravdu a chapem, co vravis. Je pravda, ze som to podal dost jednostranne v predchadzajucom prispevku. Avsak je to vsetko o aktualnej situacii. Za predpokladu, ze nas nic nenuti pouzit vyhranenu mnozinu nastrojov, tak pokial by som cital textovy subor, tak pouzijem sed alebo cut. Ale pokial by na vstupe mali byt premenne, tak urcite bash a jeho schopnosti.

Myslim, ze tedka je to dostatocne ferove. :)

[Ash]

... "podal dost jednostranne" hezky řečeno :D Jo teď je to lepší, teď už to nepřipomíná výsledky výběrového řízení na ministerstvu obrany. Už trochu OT, ale u souborů v UTF-8 se dají (některé) nástroje ještě výrazně zrychlit přes LANG=C program.... Příklad ze života:

bash$ head lags
0.00006891027516632080
-0.00000000850478210449
0.00002081826979675293
-0.00000000850478210449
0.00000087157315521240
0.00003280476159362793
0.00004395083016662598
0.00001094384869537353
0.00000000639637908936
0.00000092118244476318

bash$ wc -l lags
500000 lags

bash$ time grep "^-" lags >/dev/null

real    0m13.539s
user    0m13.426s
sys     0m0.017s

bash$ time LANG=C grep "^-" lags >/dev/null

real    0m0.010s
user    0m0.000s
sys     0m0.007s

neb čtení každého utf-8 znak má režii navíc.

[Patrik Uhrak]

Vdaka za tip s LANG=C .

[Ash]

Samozřejmě za předpokladu že nepotřebujete zpracovávat utf-8 znaky, např. je ten soubor v ascii.

[Patrik Uhrak]

Bolo pekne vidiet vysledky s LANG=C, ale u  mna je to zjavne ine:

pato@debian:~$ head -n10 log 
24321
28838
22269
15558
14989
9363
25462
1941
393
8833

pato@debian:~$ wc -l log 
1000000 log

pato@debian:~$ file --mime-encoding log 
log: us-ascii

pato@debian:~$ locale
LANG=en_GB.utf8
LC_CTYPE="en_GB.utf8"
LC_NUMERIC="en_GB.utf8"
LC_TIME="en_GB.utf8"
LC_COLLATE="en_GB.utf8"
LC_MONETARY="en_GB.utf8"
LC_MESSAGES="en_GB.utf8"
LC_PAPER="en_GB.utf8"
LC_NAME="en_GB.utf8"
LC_ADDRESS="en_GB.utf8"
LC_TELEPHONE="en_GB.utf8"
LC_MEASUREMENT="en_GB.utf8"
LC_IDENTIFICATION="en_GB.utf8"
LC_ALL=en_GB.utf8

pato@debian:~$ time grep '^0' log >/dev/null 

real    0m0.063s
user    0m0.048s
sys     0m0.020s

pato@debian:~$ time LANG=C grep '^0' log >/dev/null 

real    0m0.063s
user    0m0.044s
sys     0m0.024s

Mam za to, ze chyba je medzi stolickou a klavesnicou. System funguje s utf8 (vid LC_ALL=en_GB.utf8), subor je ascii (obsahuje nahodne cisla generovane bashom) a zlepsenie ziadne. Vedel by si mi povedat, kde robim chybu ?

p.s.: Som si stiahol aj zdrojove kody pre grep. Som to prehladal, ci nahodou sa nezmenila moda, ale stale je tam

setlocale(LC_ALL,"")

co je presne to, co som nasiel aj na http://www.cl.cam.ac.uk/~mgk25/unicode.html#activate . Som si len chcel overit, ze to tam nie je nejako napevno nastavene vychodzie kodovanie, ak sa ziadne nenajde nastavene. Ale o tom som presvedceny neni a vzhladom na nalez to zjavne funguje, ako je vysvetlene na odkazovanom zdroji.

[Ash]

Tak to máte nejspíš již patchnutou verzi grep, já mám 2.5.4, trápilo to dost lidí takže je dost pravděpodobné, že v 2.6 nebo 2.7 to je opravené. Problém byl konkrétně ve volání mbrtowc pro každý znak kopky sena, nebo snad ještě častější jak demonstruje následující:

bash$ wc lags
 100  100 1400 lags

bash$ time ltrace grep "^-" lags 2>&1 | LANG=C grep '^mbrtowc(' | wc -l
11633

real    0m2.217s
user    0m0.563s
sys     0m1.790s

Když si projedete začátek toho ltrace logu tak tam také uvidíte jak pracuje s locale.

_{(Jo, také jsem si kdysi říkal že nejlepší je si přečíst zdrojáky, ale už jsem v paranoidní fázi... a raději trasuji binárku :))}.

[pulpe]

Hledal jsem chybu proč WAIT_TIME=$(echo "$MSG1" | cut -c4-) nemá hodnotu 30.
Tak jsem zkoušel jestli to není náhodou chyba cutu, ale pak se ukázalo,
že to vrací 30 a to je problém ISO-8859-1 (něco z googlu)

Kompletní problém zde.

[Patrik Uhrak]

Vdaka, som si pozrel aj kompletny log z tej diskusie. Je mozne aj takto:

echo "${MSG1:3}"

teda pokial je ta hatlanina a cas ako vstupny retazec. Co som skusil, tak problem ma s tym retazcom iba cut. Nie ale sed alebo bash.

[l4m4]

Proboha, BOM v UTF-8. (Ne, nemá to nic společného s ISO-8895-1 kromě toho, že takhle ta sekvence bajtů vypadá, když se intepretuje jako ISO-8895-1.)

Už nám tenhle mor zamořuje i Linux?

[Šangala]

if ( SoftwareAddBOMAutomaticlyToUTF-8(software) ) //is it a stupid software?
{
  bool r = DestroyTheSoftwarePernamently (software); //Protect your PC
  SendMessageToTheWorld ("DestroyTheSoftwarePernamently", software); //Help protect others
  return r; //return true on protect your PC
}