Esempi con n = 4
echo funzionefichissima(1) --> 0001
echo funzionefichissima(123) --> 0123
Che tu ci creda o no: printf
printf "%04d" 123 = 0123
man printf
man... questo sconosciuto
Davide
ovviamente (ma che te lo dico a fare?)
$ n=4
$ printf "%0${n}d" 123
> printf "%04d" 123 = 0123
>
> man printf
>
> man... questo sconosciuto
Già, ma se un ignorante non sospetta di printf deve impiccarsi? :-)
Mi ero sgrullato vanamente man awk e man sed...
Comunque ecco qua. Idee più eleganti per ottenere quell'output?
Grazie.
#!/bin/sh
echo -----------------------------------------------
echo 'Gino, un pin di 4 cifre è mortalmente insicuro'
echo 'anche se ti salvi in DB solo un hash.'
echo -----------------------------------------------
echo 'pin;sha1;md5' > hash-dei-pin.csv
for (( i=0; i<=9999; i++ ))
do
a=`printf "%04d" $i`
echo $a';'`echo -n $a | sha1sum | cut -c1-40`';'`echo -n $a \
| md5sum | cut -c1-32` >> hash-dei-pin.csv
done
less hash-dei-pin.csv
> Già, ma se un ignorante non sospetta di printf deve impiccarsi? :-)
Sì perché studiare è al di là delle tue capacità.
apprezzo sempre molto le tue lezioni di scripting, dalle quali posso solo
imparare.. molto meno quando, come in questo caso, ci vai giù pesante
senza alcun motivo valido.. il tutto è ancor più valido se pensiamo che
qui siamo su .iniziare
quasi certamente anche tu sarai un newbie in qualcosa, non penso che
essere trattato gratuitamente a pesci in faccia ti faccia piacere..
tutto IMHO
S.
apprezzo sempre molto le tue lezioni di scripting, dalle quali posso solo
sto seriamente pensando che ci sia una strategia sotto tutto cio'
forse trattano male i nuovi arrivi per "testarli" e vedere se reggono
l'urto?
una specie di "selezione" per far approdare a linux solo gli esemplari
piu' forti?
:)
forse l'unica che mi sentirei di consigliarti e' di cercare di evitare
l'uso di less dentro allo script
manda fuori l'output come fanno tutti i comandi, e poi richiami lo
script e lo "pippi" a less da shell
in questo modo eviti anche di dover salvare un file su disco... che per
correttezza poi andrebbe anche distrutto... e sempre per correttezza
andrebbe salvato su /tmp con un nome univoco (ci sono comandi che
generano nomi univoci per file temporanei)
un'altra cosa
nel mio pc (ma e' un PIII a 500MhZ) e' lentissimo... ma immagino anche
in un PIV sia piuttosto lento
potrebbe essere una buona idea, ogni 100 righe, aggiornare una
percentuale di progressione... cosi' uno non pensa che il computer si
sia impallato (e ti maledisca pensando che il tuo script non funzioni...)
se lo fai, manda l'output sullo standard error
cosi' se uno redirige lo standard output non se lo trova sporcato dai
messaggi di scorrimento
riciao
> nel mio pc (ma e' un PIII a 500MhZ) e' lentissimo... ma immagino anche
> in un PIV sia piuttosto lento
> potrebbe essere una buona idea, ogni 100 righe, aggiornare una
> percentuale di progressione... cosi' uno non pensa che il computer si
> sia impallato (e ti maledisca pensando che il tuo script non funzioni...)
per la percentuale la cosa � un pelo pi� complicata, per un normale
avviso di avanzamento:
echo -n "."
forse riguardo alla forma, avresti fatto meglio a salvare il sha1sum e
l' md5sum su due variabili, e poi echoizzare le due evitando righe
troppo "criptiche"
bash e' gia' parecchio criptico di suo...
altrimenti sai cosa sembra?
sembra come quei soliti mezzi ignoranti che per cercare di fare bella
figura si mettono ad usare paroloni complicati...
se devi dire una cosa, dilla semplice
se e' una cosa buona, si apprezzera' di piu'
se e' una cazzata fara' prima la giusta fine che si merita
giusto
e magari caricare i valori in una tabella, mentre compaiono i puntini
e poi buttare in output la tabella in un colpo solo
altrimenti viene una cosa scattosa...
Mi hai tolto le parole da bocca.
Antonio Macchi wrote:
> ...
> forse riguardo alla forma, avresti fatto meglio a salvare il sha1sum e
> l' md5sum su due variabili, e poi echoizzare le due evitando righe
> troppo "criptiche"
> ...
Per quell' "ecoizzare" verrai torturato con la tortura
della carta vetrata al posto della carta igienica.
Poi perché fare cose cosi assurde: sha1sum e md5 sono usati
una sola volta, salvarli in una variabile complica le cose.
Antonio Macchi wrote:
> ...
> altrimenti sai cosa sembra?
> sembra come quei soliti mezzi ignoranti che per cercare di fare bella
> figura si mettono ad usare paroloni complicati...
> ...
Non ti seguo. La bash offre molti costrutti molto potenti per
facilitare la programmazione e rendere più rapida l'esecuzione
degli script. Essere complessi non è nè essere arroganti nè
essere complicati, è solo che programmare con la bash è un
altro paradigma di programmazione.
Per essere chiari tutto quel casino di script si riduce ad un
semplice one-liner
for (( i=0; i<9999; i++ ));
do
printf '%04d;%40s;%32s\n' \
$i \
$(printf %04d $i | sha1sum ) \
$(printf %04d $i | md5sum )
done > hash-dei-pin.csv
senza bisogno di file temporanei. senza bisogno di
variabili inutili e senza bisogno di fare uno script;
lo script si fa se vale la pena p.e. se si usa spesso
questa sequenza di comandi o se ha una utilità anche
per altre persone.
Ed a proposito di less; è stupido usarlo in uno script ma
nulla vieta di fare:
for .... done | less
A te dire come aggiungere una intestazione ma se lo
fai ti aspettano altre torture. Intestazioni, caratteri di
riempimento, code, righe in bianco, abbellimenti
distruggono la possibilità di usare le pipe.
Mi hai tolto le parole da bocca.
Antonio Macchi wrote:
> ...
> forse riguardo alla forma, avresti fatto meglio a salvare il sha1sum e
> l' md5sum su due variabili, e poi echoizzare le due evitando righe
> troppo "criptiche"
> ...
Per quell' "ecoizzare" verrai torturato con la tortura
della carta vetrata al posto della carta igienica.
Poi perché fare cose cosi assurde: sha1sum e md5 sono usati
una sola volta, salvarli in una variabile complica le cose.
Antonio Macchi wrote:
> ...
> bash e' gia' parecchio criptico di suo...
Non ti seguo. La bash offre molti costrutti molto potenti per
for .... done | less
PS mi scuso se ho fatto qualche casino con le citazioni.
ridotto ad un one-liner ok... "semplice" mi pare eccessivo...
la cosa che hai scritto tu ha due inconvenienti
uno ovvio e' che una volta chiusa la shell, se rivuoi l'output con una
leggera modifica devi rismazzarti tutto il "semplice" one-liner
l'altra e' che anche se sei ancora nella stessa shell, e vuoi fare una
modifica, la cosa diventa parecchio fastidiosa
la shell mette tutto su una riga, rendendo assai difficile l'editing
io lo script l'avrei scritto cosi'
#!/bin/bash
echo -n "calculating " >&2
head=
rows=
nrows=10000
head[0]=`printf "%-4s %-40s %-32s" pin sha1 md5`
head[1]=`printf "%-4s %-40s %-32s" --- ---- ---`
for (( i=0; i<$nrows; i++ )); do
pin=$i
sha1=`echo -n $pin | sha1sum | cut -c1-40`
md5=`echo -n $pin | md5sum | cut -c1-32`
rows[$i]=`printf "%04d %s %s\n" $pin "$sha1" "$md5"`
test $(( $i % 100 )) -eq 0 && echo -n . >&2
done
echo
echo "${head[0]}"
echo "${head[1]}"
for (( i=0; i<$nrows; i++ )); do echo "${rows[$i]}"; done
> Per essere chiari tutto quel casino di script si riduce ad un
> semplice one-liner
>
> for (( i=0; i<9999; i++ ));
> do
> printf '%04d;%40s;%32s\n' \
> $i \
> $(printf %04d $i | sha1sum ) \
> $(printf %04d $i | md5sum )
> done > hash-dei-pin.csv
eh...
$ cat foo.sh
#!/bin/bash
for (( i=0; i<9999; i++ ));
do
printf '%04d;%40s;%32s\n' \
$i \
$(printf %04d $i | sha1sum ) \
$(printf %04d $i | md5sum )
done > hash-dei-pin.csv
$ ./foo.sh
0000;39dfa55283318d31afe5a3ff4a0e3253e2045e43;
-
./foo.sh: line 5: printf: 4a7d1ed414474e4033ac29ccb8653d9b: invalid number
0000; -;
0001;7a6779700f09e1eafe9ad40e390f3a15b94dfa4b;
-
./foo.sh: line 5: printf: 25bbdcd06c32d477f7fa1c3e4a91b032: invalid number
0000; -;
0002;c5e8754637504e5ebf868efc915ae09cb8ba1c3b;
-
./foo.sh: line 5: printf: fcd04e26e900e94b9ed6dd604fed2b64: invalid number
0000; -;
[snip]
eh... ma come sei pignolo!
dovevi andare "oltre" quello che c'era scritto... coglierne l'essenza,
:)
cosi' l'errore non compare piu'...
for (( i=0; i<9999; i++ ));
do
printf '%04d;%40s;%32s\n' \
$i \
"$(printf %04d $i | sha1sum)" \
"$(printf %04d $i | md5sum)"
done
errore comunque curioso...
$ printf "%s\n" ok -
ok
-
perche' scrive l'argomento d'avanzo a capo riga?
$ printf "%d %s\n" 1 ok -
1 ok
-bash: printf: -: invalid number
0
perche' nel primo caso non da' errore, e nel secondo "invalid number"?
cos'e' quello zero?
--------
comunque risolto il primo ne nasce un'altro, ovvero l'output non viene
troncato come sembrerebbe
anche qui comportamento curioso di printf
$ printf "%2s\n" qwerty
qwerty
se la stringa e' piu' lunga la scrive lostesso tutta.
bello questo bash
non smette mai di sorprenderti, no?
buonanotte!
Perch� glielo dici tu di farlo. Scrive una stringa (ok) poi un "a capo" (\n)
come stringa e se poi trova altri argomenti li stampa di seguito
riapplicando la stessa formattazione, quindi stringa e "a capo" ad libitum
sfumando...
> $ printf "%d %s\n" 1 ok -
> 1 ok
> -bash: printf: -: invalid number
> 0
Perch� passi 3 argomenti e la formattazione � "%d %s\n" che viene ripetuta
dall'inizio fino ad esaurimento degli argomenti, esattamente come c'�
scritto nel manuale. Il terzo argomento deve essere un numero (%d) e - � un
numero invalido.
> perche' nel primo caso non da' errore, e nel secondo "invalid number"?
> cos'e' quello zero?
A cosa si deve tutta questa reticenza nel fare man printf?
> comunque risolto il primo ne nasce un'altro, ovvero l'output non viene
> troncato come sembrerebbe
>
> anche qui comportamento curioso di printf
>
> $ printf "%2s\n" qwerty
> qwerty
Cosa c'� di curioso? � esattamente il comportamento di printf da manuale.
> se la stringa e' piu' lunga la scrive lostesso tutta.
Cosa dovrebbe fare secondo te? Certo che se ti inventi come dovrebbero
comportarsi i comandi difficilmente rimarrai soddisfatto.
> bello questo bash
> non smette mai di sorprenderti, no?
Sarebbe anche carino capire che c'entra printf con la bash... direi che tu
sorprendi ben pi� della bash e del printf messi assieme.
--
Flavio Visentin
Nel messaggio <hcn9tv$ec$3...@news.albasani.net> un cretino ha scritto:
"Il microkernel e' morto da molto tempo ed ancora non lo sa." (cit. Bluff)
tutto giusto fin qui.
qui purtroppo, il nostro ZipMan ha "zippato"...
printf e' un builtin
$ help printf
comunque man printf a me da poco o niente
#!/bin/bash
echo -n "calculating " >&2
rows=
nrows=10000
for (( i=0; i < $nrows; i++ )); do
pin=$i
sha1=`echo -n $pin | sha1sum | cut -c1-40`
md5=`echo -n $pin | md5sum | cut -c1-32`
rows[$i]=`printf "%04d %40s %32s" $pin $sha1 $md5`
test $(( $i % 100 )) -eq 0 && echo -n . >&2
done
echo -en "\e[H\e[J" >&2
printf "%-4s %-40s %-32s\n" pin sha1 md5
printf "%-4s %-40s %-32s\n" --- ---- ---
for (( i=0; i < $nrows; i++ )); do echo "${rows[$i]}"; done
> uno ovvio e' che una volta chiusa la shell, se rivuoi l'output con una
> leggera modifica devi rismazzarti tutto il "semplice" one-liner
1) man history
2) Quale parte di "Se ti serve più di una volta ti fai uno script"
non ti è chiara?
Antonio Macchi wrote:
> l'altra e' che anche se sei ancora nella stessa shell, e vuoi fare una
> modifica, la cosa diventa parecchio fastidiosa
> la shell mette tutto su una riga, rendendo assai difficile l'editing
1) man bash /Readline Command
2) man ksh
3) man tcsh
4) man eshell
3) Quale parte di "Se ti serve più di una volta ti fai uno script"
non ti è chiara?
Antonio Macchi wrote:
> io lo script l'avrei scritto cosi'
> ...
Non stai programmando in C
La redirezione su file non va messa nello script.
A parte questo ho dimenticato qualche virgoletta.
#! /bin/bash
for (( i=0; i<9999; i++ ));
do
printf '%04d;%.40s;%.32s\n' \
"$i" \
"$(printf %04d $i | sha1sum )" \
"$(printf %04d $i | md5sum )"
done
--
I debug non finiscono mai.
> La redirezione su file non va messa nello script.
volendo anche s�:
#! /bin/bash
unlink hash-dei-pin.csv
for (( i=0; i<9999; i++ ));
do
printf '%04d;%.40s;%.32s\n' \
"$i" \
"$(printf %04d $i | sha1sum )" \
"$(printf %04d $i | md5sum )" >> hash-dei-pin.csv
done
cosa vorresti dire?
che per essere un bravo "basher" devo scrivere male?
Allora ti do' una super-dritta: "apropos"
apropos format
e vedrai
Davide
> Il Thu, 12 Nov 2009 01:28:33 +0100, mallin.shetland ha scritto:
>
>> La redirezione su file non va messa nello script.
>
> volendo anche sì:
Nel caso specifico è un errore di stile.
Nel caso generale se uno script deve scrivere in un file
diverso dallo standard output allora questo o deve essere
un file temporaneo o il nome del file deve essere passato
come argomento.
> cosa vorresti dire?
> che per essere un bravo "basher" devo scrivere male?
Se scrivere male significa scrivere secondo un paradigma di
programmazione che non è quello dei linguaggi procedurali sì.
ah... carina... mi fai un link a wikipedia col paradigma di
programmazione che dovrei seguire per diventare un bravo "basher"?
un comando che scrive dentro un file (temporaneo?) il cui nome viene
passato come argomento?
mi fai un esempio di un comando cosi'?
scusami... forse mi so spiegato male
quello che voglio dire e' che obbligare una scrittura e non usare lo
standard output rende un comando "rigido"...
linux (ma unix credo...) e' bello proprio per questa sua "astrazione"
sull'input/output
a volte magari tocca romperla... ma anche quando questo succede (dd,
tar... son tanti in effetti), c'e' sempre l'opzione aggiuntiva per usare
lo standard output lostesso
quindi cambio la domanda
mi fai un esempio di un comando che "non puo'" scrivere sullo standard
output ma solo su un file?
Ganzissimo, questa non la sapevo proprio. Grazie!
Tranquilli, sono solo uno che morpha spesso. Conosco le reazioni del
buon Mallin da un pezzo. :-P Non farò certo come Palladilardo quando
impiomba il sergente testadicazzo. :-D
>> Nel caso specifico � un errore di stile.
ma lo fai apposta a non capire o cosa?
dove hai letto "comando" ?
comunque:
un esempio di script dove si passa il nome del file?
mkinitrd opzione -o
ecco anche una lista dei "comandi" (che non c'entra una mazza col topic)
dove si specifica il nome del file.
wget
cp
mv
mkdir
mencoder
tar
e altri 2000
alcuni se non passi il nome del file, scrivono con nu nome standard, che
leggi nel man (vedi mkinitrd e mencoder) , altri danno semplicemente
errore (vedi tar e mkdir)
> .. mi fai un link a wikipedia ...
Sì, come se wikipedia fosse le summa di S. Tommaso
> ... col paradigma di programmazione che dovrei seguire
> per diventare un bravo "basher"?
Diventare bravo, si, come no, Questo è l'ultimo tentativo ma
ormai non ci sono speranze che tu non sia un troll.
http://tldp.org/LDP/Bash-Beginners-Guide/Bash-Beginners-Guide.pdf
script e comando sono sinonimi, dal punto di vista di chi li usa
> wget
$ wget www.google.it -O -
> cp
cp non crea nessun output
l'output del file create era gia' stato creato da un altro comando che
di sicuro offriva la possiilita' di riversare in stdout
> mv
idem come cp
> mkdir
una directory non ha nessun output da riversare
> mencoder
? forse su questo hai ragione tu?
non conosco il comando, ma scommetto di no.
> tar
tar -c <(echo ok) -O
> e altri 2000
me ne basterebbe un paio
>
> alcuni se non passi il nome del file, scrivono con nu nome standard, che
> leggi nel man (vedi mkinitrd e mencoder) , altri danno semplicemente
> errore (vedi tar e mkdir)
non so mencoder, ma mkinitrd non si puo' considerare un comando "ordinario"
$ wget http://tldp.org/LDP/Bash-Beginners-Guide/Bash-Beginners-Guide.pdf
--2009-11-12 12:37:48--
http://tldp.org/LDP/Bash-Beginners-Guide/Bash-Beginners-Guide.pdf
Risoluzione di tldp.org... 152.46.7.81
Connessione a tldp.org|152.46.7.81|:80... connesso.
HTTP richiesta inviata, in attesa di risposta... 200 OK
Lunghezza: 1198170 (1,1M) [application/pdf]
Salvataggio in: "Bash-Beginners-Guide.pdf"
100%[======================================>] 1.198.170 166K/s in
7,2s
2009-11-12 12:38:01 (162 KB/s) - "Bash-Beginners-Guide.pdf" salvato
[1198170/1198170]
$ ps2ascii < Bash-Beginners-Guide.pdf > Bash-Beginners-Guide.txt
$ grep paradigma Babylon_English_Italian.dic
paradigm n. esempio, modello, esemplare; (Gramm) paradigma
paradigmic adj. esemplare; paradigmatico, di paradigma
suppletion n. (linguist.) forma suppletiva, forma che pur avendo un
etimo diverso da altre forme presenta lo stesso paradigma
$ grep paradigma Babylon_English_Italian.dic | sed 's/[[:space:]].*//' |
while read word; do grep "$word" Bash-Beginners-Guide.txt || echo "$word
NOT FOND in file Bash-Beginners-Guide.txt"; done
paradigm NOT FOND in file Bash-Beginners-Guide.txt
paradigmic NOT FOND in file Bash-Beginners-Guide.txt
suppletion NOT FOND in file Bash-Beginners-Guide.txt
-----------------
purtroppo sembra che nel manuale che mi hai consigliato non si faccia
menzione di nessun paradigma di programmazione da adottare nella stesura
di script bash
non hai forse qualcosa si piu' avanzato da propormi?
grazie e ciao
> tar -c <(echo ok) -O
Questa è da incorniciare.
Usi a sproposito e senza reale necessità un costrutto
esotico quale la sostituzione di processo che non è
portabile, che è posseduto solo dalla bash e dalla korn
shell, che non funziona su tutti i sistemi invece della
normale e corretta e portabile pipe.
E tutto questo solo per fare un esempio sbagliato.
>> ma lo fai apposta a non capire o cosa?
>> dove hai letto "comando" ?
>
> script[]
ma la tua insegnante di sostegno quante ore ti permettere di stare davanti
al pc , ogni giorno?
dai vai un po' al parco
> non hai forse qualcosa si piu' avanzato da propormi?
> grazie e ciao
http://www.youtube.com/watch?v=nmDYwthZrF0&feature=related
:-p
--
|Save our planet!
Ciao |Save wildlife!
roberto |For your E-MAIL use ONLY recycled Bytes !!
|roberto poggi rpo...@softhome.net
in effetti non serviva usare sed
un cut -f1 era piu' che sufficiente
almeno credo, che sed sia piu' pesante di cut
$ ls -sh1 /usr/bin/cut /bin/sed
40K /bin/sed*
36K /usr/bin/cut*
come potrei fare per esserne sicuro?
zipmantp:/tmp# which printf
/usr/bin/printf
zipmantp:/tmp# dpkg -S /usr/bin/printf
coreutils: /usr/bin/printf
zipmantp:/tmp# dpkg -L coreutils
[CUT]
/usr/share/man/man1/dirname.1.gz
/usr/share/man/man1/printf.1.gz
/usr/share/man/man1/touch.1.gz
[CUT]
/usr/bin/shred
/usr/bin/printf
/usr/bin/sort
[CUT]
> On 11/12/2009 02:39 AM, Antonio Macchi wrote:
>> tutto giusto fin qui.
>> qui purtroppo, il nostro ZipMan ha "zippato"...
>>
>> printf e' un builtin
>>
>> $ help printf
>
> zipmantp:/tmp# which printf
> /usr/bin/printf
> zipmantp:/tmp# dpkg -S /usr/bin/printf
> coreutils: /usr/bin/printf
> zipmantp:/tmp# dpkg -L coreutils
> [CUT]
> /usr/share/man/man1/dirname.1.gz
> /usr/share/man/man1/printf.1.gz
> /usr/share/man/man1/touch.1.gz
> [CUT]
> /usr/bin/shred
> /usr/bin/printf
> /usr/bin/sort
> [CUT]
Hai dimenticato il piu' importante:
$ type printf
printf is a shell builtin
$ type -a printf
printf is a shell builtin
printf is /usr/bin/printf
E in man printf dice:
"NOTE: your shell may have its own version of printf, which usually
supersedes the version described here. Please refer to your shell's
documentation for details about the options it supports."
Bash ce l'ha built-in (e viene preferito a quello esterno - ed ha anche piu'
opzioni); altre shell potrebbero non averlo, ed e' principalmente questo il
motivo per cui viene anche fornito un eseguibile esterno standalone, come
d'altronde capita anche con altri comandi come echo, true, false, kill e
altri.
che c'entra which con la shell?
which non e' un builtin
ti pare che ad ogni aggiornamento di bash vanno ad aggiornare anche
tutta la suite di sowftare che fanno qualche tipo di ricerca sull'hard disk?
> zipmantp:/tmp# dpkg -S /usr/bin/printf
> coreutils: /usr/bin/printf
mmmm... ma lo sai cosa sono i builtin?
sono comandi riimplementati dentro la shell per evitare di doverli
avviare con un fork, e quindi per avere gli script un pelo piu' veloci
guarda:
$ time for i in {1..1000}; do printf ok >/dev/null; done
real 0m0.113s
user 0m0.088s
sys 0m0.028s
$ time for i in {1..1000}; do /usr/bin/printf ok >/dev/null; done
real 0m4.409s
user 0m1.340s
sys 0m2.980s
la sai la cosa divertente?
che nel manuale di riferimento di bash, della printf non dicono niente
(se non i pochi parametri in piu' non presenti nell'originale), perche'
dicono che per il resto basta andare a guardare la documentazione
originale di printf
Niente, infatti, which ti dice che cosa � realmente il comando
che metti come parametro, nel caso, un eseguibile in /usr/bin
� che tu stai studiando linux come uno che va in giro al buio
pestando qua e l�, sperando che sia cioccolata.
Adieu.
poggirpc:/home/poggir# man printf
PRINTF(1) User Commands
PRINTF(1)
NAME
printf - format and print data
SYNOPSIS
printf FORMAT [ARGUMENT]...
printf OPTION
DESCRIPTION
Print ARGUMENT(s) according to FORMAT, or execute according to
OPTION:
--help display this help and exit
--version
output version information and exit
FORMAT controls the output as in C printf. Interpreted
sequences are:
\" double quote
\NNN character with octal value NNN (1 to 3 digits)
Che e' la cosa giusta da fare anziche' duplicare tutto.
mah... dice mezza verita'... e anche meno
meglio usare sempre type
No.
E questo caso ne � la prova sperimentale.
??
o sfugge qualcosa a me o sfugge qualcosa a te.
a chi sfugge qualcosa?
nessuno lo sa come capire quanto pesa un comando in memoria?
pazienza... prima o poi lo scopriro' lostesso. :)
comunque si possono sempre confrontare per la velocita'.
$ time for i in {1..100}; do cat /usr/share/common-licenses/GPL; done |
sed 's/[[:space:]].*//' >/dev/null
real 0m4.919s
user 0m4.500s
sys 0m0.288s
$ time for i in {1..100}; do cat /usr/share/common-licenses/GPL; done |
cut -d" " -f1 >/dev/null
real 0m0.558s
user 0m0.236s
sys 0m0.316s
come dire... quando possibile meglio usare cut, che sed
peccato non sappia come fare la prova della memoria... :(
adios
Ti sfugge il significato del comando which.
Ti sfugge che printf � anche un programma, come ti ha gi� detto
Zipman, ma tu non hai abbastanza neuroni collegati per capirlo.
Come ti sfugge il significato di studiare un sistema operativo.
>
> a chi sfugge qualcosa?
A me stai sfuggendo definitivamente.
Ti lascio a chi ha pazienza di sopportarti.
Scusa se non ti faccio la funzione direttamente ma credo che puoi
usare 'wc -c' x determinare la lunghezza della stringa (e quindi la
quantita` di zeri a cui concatenarla.)
--
pardo
]zac[
> ma lo fai apposta a non capire o cosa?
]zac[
(Non posso, non devo, ... resisti ... va beh, tanto poi smentisco tutto ...)
LA PRIMAAAAAAAAAAA!!!!!!!!!!!!!!!
]zac[
> A me stai sfuggendo definitivamente.
> Ti lascio a chi ha pazienza di sopportarti.
P.S. Solo che, anche si si ha ragione a perdere la pazienza, quando si perde
la pazienza si finisce praticamente sempre per avere più torto di chi ti ha
fatto perdere la pazienza (cosa per cui molte donne/compagne finiscono per
farsi loro la fama di persone con un pessimo carattere).
echo "printf --h" > prova.sh
chmod 755 prova.sh
./prova.sh
/prova.sh: line 1: printf: --: invalid option
printf: usage: printf [-v var] format [arguments]
echo "/usr/bin/printf --h" > prova.sh
./prova.sh
Uso: /usr/bin/printf FORMATO [ARGOMENTO]...
o: /usr/bin/printf OPZIONE
Stampa gli ARGOMENTI secondo il FORMATO.
--help display this help and exit
--version stampa le informazioni sulla versione ed esce
FORMAT controls the output as in C printf. Interpreted sequences are:
]zac[
Questo test dice, come riportato nel manuale della shell bash, che gli
interpreti della shell che hanno istruzioni interne uguali a comandi
esterni built in, a meno che non sia specificato diversamente, danno
priorità all'esecuzione delle istruzioni interne.
Comunque questa è pignoleria, nel 99% dei casi la cosa è ininfluente (spesso
cambia poco o nulla che il comando sia interno o esterno).
> Davide Bianchi, on 11/12/2009 09:03 AM, wrote:
>> On Nov 11, 6:10 pm, SultrySultan <sul...@sult.an> wrote:
>>> Già, ma se un ignorante non sospetta di printf deve impiccarsi? :-)
>>
>> Allora ti do' una super-dritta: "apropos"
>>
>> apropos format
>
> Ganzissimo, questa non la sapevo proprio. Grazie!
Aggiungo, per i sistemi che lo hanno l'opzione -K di man (man man per i
dettagli):
man -K format
> Davide Bianchi, on 11/12/2009 09:03 AM, wrote:
>> On Nov 11, 6:10 pm, SultrySultan <sul...@sult.an> wrote:
>>> Già, ma se un ignorante non sospetta di printf deve impiccarsi? :-)
>>
>> Allora ti do' una super-dritta: "apropos"
>>
>> apropos format
>
> Ganzissimo, questa non la sapevo proprio. Grazie!
... e ancora aggiungo (sto esagerando vero?) google -> bash string format
(nella prima pagina printf è citato 5/6 volte).
> Conoscete qualche comando shell che mi aggiunga zeri a sinistra di
> un numero fino a raggiungere n cifre? In pratica mi serve ul left
> padding con un carattere predefinito.
>
> Esempi con n = 4
> echo funzionefichissima(1) --> 0001
> echo funzionefichissima(123) --> 0123
fingiamo che printf non sia un builtin, usiamo solo variabili e
sostituzione di parametri (non so se alcune siano bash-specific)
% cat zeros.sh
# 1234567890
z="0000000000"
n="1234"
echo ${z::$((${#z} - ${#n}))}$n
% sh zeros.sh
0000001234
%
--
sapete contare fino a venticinque?
Olimpia Milano Jugoplastika Split Partizan Beograd
Roberto Premier Duska Ivanovic Zarko Paspalj
> % cat zeros.sh
> # 1234567890
> z="0000000000"
> n="1234"
> echo ${z::$((${#z} - ${#n}))}$n
> % sh zeros.sh
> 0000001234
> %
O anche
#!/bin/bash
a=0000000000$1
echo ${a: -10:10}
$ zeros.sh 1234
0000001234
non sono equivalenti
% cat z1
z="0000000000"
echo ${z::$((${#z} - ${#1}))}$1
% cat z2
a=0000000000$1
echo ${a: -10:10}
% sh z2 12345678901
2345678901
% sh z1 12345678901
z1: line 2: $((${#z} - ${#1})): substring expression < 0
%
e poi il mio script � MOLTO pi� incomprensibile, che son punti, no?
--
Mangiate pure le vostre carote, noi mangeremo le nostre salsicce!
-- Claud, in IHC
Beh bisogna scegliere tra un risultato errato e un errore a run time,
onestamente non saprei :/
Io partivo dal presupposto che il numero di partenza sia sempre lungo meno
di 10 cifre.
> Beh bisogna scegliere tra un risultato errato e un errore a run time,
> onestamente non saprei :/
imvho, errore a runtime :\
--
non ho capito un apascio -- pp, tra se e se