Newsgroup: it.comp.macintosh
Titolo: [terminale] ls formattato

Salve,
      se digito:
ls desktop/*.txt
ottengo tutti i files con suffisso txt ma in questo modo:
desktop/sgdf.txt desktop/sfglkdf.txt
desktop/uuuuf.txt desktop/jjjjf.txt
ora io vorrei ottenere solo il nome del file (magari senza suffisso) e 
sopratutto senza la dir che li contiene...quindi senza: desktop/ e poi 
li vorrei su una colonna sola...
si puň fare?
grazie

 li vorrei su una colonna sola...
$ cd Desktop; ls -1 *.txt
-- 
Vai Pietro Ichino, monda le stalle di Augia.

 si può fare?
al volo:
basename `ls -1 Desktop/*.txt` 
ma avrai problemi con i file il cui nome contiene uno spazio.

 si può fare?
( cd desktop ; \ls *.txt | sed s/.txt// )
Scrivo "\ls" perché spesso il comando "ls" è modificato con qualche
flag. Facendolo precedere da "\" viene usato il comando originale.
Ciao
Enrico

 si può fare?
Si, ti hanno dato alcune soluzioni. Ma IMHO quando lo shell scripting
diventa appena complesso (nel senso che bisogna cominciare a fare cicli
e manipolazioni di stringhe) fai molto prima usando Python o Ruby. O
anche Perl (ma a me non piace).
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 anche Perl (ma a me non piace).
Perché tu questi linguaggi già li mastichi e sei "addentro" la faccenda.
Se uno è molto pratico di bash e non di py/rb/pl probabilmente fa prima 
con bash che ad imparare quello che serve al suo scopo in uno di questi 
linguaggi.
Sai comunque devi andare a vedere qualcosina, un po' di sintassi per 
quanto semplice la devi leggere, come funzionano le strutture di 
controllo e altre amenità.

 anche Perl (ma a me non piace).
scusa eh, ma scomodare un runtime laddove due righe di bash risolvono e'
virtuosismo fine a se stesso ;)


 si può fare?
Facilissimo, e sono sorpreso che nessuno dei post che ti risponde mostri
il modo "ovvio":
ls desktop/*.txt | xargs basename
Se vuoi rimuovere anche la "estension" .txt, basta fare invece:
ls desktop/*.txt | xargs basename -s .txt
Dalla mancanza di questa risposta direi che la conoscenza dei fondamenti
di shell nel newsgroup e` scarsina:-).
Alex

 di shell nel newsgroup e` scarsina:-).
Direi che il tuo comando non funziona se nella directory c'č un file
che ha uno spazio nel nome e l'estensione .txt 
Il mio sě. Non c'č un modo "ovvio" per eseguire comandi nella shell.
Lo ripeto (con una piccola correzione, solo per precisione):
(cd desktop ; \ls *.txt | sed s/\.txt$//)
Ciao
Enrico

 virtuosismo fine a se stesso ;)
Credi che bash non abbia un runtime? :)
E comunque resta il fatto che a suo tempo Perl nacque (fra le altre
varie cose), proprio perchè lavorare mischiando di bash, sed, awk e
compagnia non era comodissimo.
Gli amministratori di sistema hanno accolto Perl a braccia aperte
proprio perchè rendeva loro la vita immensamente più facile.
Poi *oggi* preferisco di gran lunga Ruby a Perl e un pochetto Python a
Ruby.


 peccato che per manipolare le stringhe sia il più comodo :-)))
Sinceramente non è più comodo di Ruby (anche perchè hanno praticamente
la stessa interfaccia). 
Inoltre non ci trovo nulla da invidiare a quella di Python. Per dire. 


 si puň fare?
ruby -e "Dir.glob('*.txt').each{|f| puts f.gsub(/.txt$/, '')}"


 allora tutto diventa possibile :-)))
Se vuoi considerare interpretato Python, considera interpretato anche
Perl. Sono due linguaggi compilati in bytecode e sparati su macchina
virtuale. Dei tre quello che (per ora) è effettivamente interpretato è
Ruby. Anche se dalla prossima versione avrà una VM parecchio
promettente.
Per adesso le performance sono Python, poi Perl (non troppo distaccato e
quasi equivalente -- e ad ogni modo in questo contesto uno non sceglie
Python o Perl in base alle performance) e sotto Ruby. Ma YARV promette
di prendersi la pole (certo, bisogna vedere cosa faranno le prossime
macchine virtuali di Python e Perl).
Riguardo l'intentazione che dire, non lo uso per gli one-liner. Ma ne
faccio anche a meno eh... 
Per il resto indenterei più o meno allo stesso modo anche in Perl (e lo
faccio in Ruby, C, C++ etc). Quindi in pratica è una 'costrizione' che
non pesa. Detto questo, a molti 'nuovi' sembra un fastidio, ma nessuno
che lo usi davvero lo trova un problema per i motivi che dico io. 


 Ruby.
Io stesso devo ammettere di trovarmi, per certe cose molto "esotiche",
meglio con ruby che con awk, sed e compagnia bella.


 meglio con ruby che con awk, sed e compagnia bella.
Infatti. 


 qualche dubbio che python riuscirebbe ad essere più veloce del Perl.
Dubita, ma i dubbi non sono prove. Non che la cosa sia *davvero*
importante. Sinceramente non saprei (e comunque quando parsi, smonti,
rimonti hai anche computazione, non solo concatenazione di stringhe).


 zap.txt'
$ ls -l
total 0
-rw-r--r--   1 alex  wheel  0 Apr 11 18:36 zep.txt?zap.txt
$ ls *.txt|sed s/\.txt$//
zep
zap
$ find . -name '*.txt' -print0 -maxdepth 1 | xargs -0 basename -s .txt
zep.txt
zap
$
Il sed, erroneamente operando per righe di testo (invece che per
filename, come da specifico) si confonde e rimuove anche il .txt seguito
da fine-riga che e` _dentro_ il filename; basename, operando invece
sulla entita` logica "path del file", funziona come da specifiche.
Personalmente, per abitudine, evito di mettere spazi nei filename (e
immagino che tu eviti di metterci caratteri di fine-riga), quindi
operando da riga-comando (non in uno script) non me ne preoccupo:-)
Alex

 find Desktop -name "*.dmg" -maxdepth 1 -exec basename -s .dmg {} \;
ehi ehi, mica siamo su it.comp.os.linux.sys! :)))


 dell'errore.
si vede che non hai mai programmato con Ada, altrimenti cambieresti
idea all'istante.
Ciao Jack

 Uh, beh. Si. Ma non è certo quello che ti frega le performance, anzi.
Boh, la differenza c'e` ma non enorme.  In termine di dimensione
dell'eseguibile (comando size), su Mac OS X 10.4:
$ size /bin/bash /usr/lib/libpython2.dylib /usr
/lib/libruby.dylib 
__TEXT  __DATA  __OBJC  others  dec     hex
458752  36864   0       15440   511056  7cc50   /bin/bash
671744  151552  0       120588  943884  e670c
/usr/lib/libpython2.dylib
622592  65536   0       57856   745984  b6200   /usr/lib/libruby.dylib
(gli eseguibili per python e ruby sono piccoli "gusci" sulle rispettive
librerie).  In termini di footprint in memoria, fra una sessione
interattiva di python 2.3 e una di bash siamo anche piu` vicini: VSIZE
di 27.4M in un caso, 27.1M nell'altro...
Alex


 parzialmente inerenti per dimostrare il contrario, lo so :-P
Nah, stavolta mi risparmio -- sono ancora in afterglow per la
presentazione di ieri sera di Ivan Krstic all'SDforum su OLPC. Mi capita
spesso, quando parlo con tecnici con un importante passato Perl che si
sono convertiti a Python (come ad esempio Chip Turner), ma questa e`
stata proprio un'occasione speciale.
Se OLPC funziona anche la meta` di come sperano, grazie al bottone
magico "show source", milioni di bambini curiosi impareranno a
programmare giocando con i sorgenti dell'intero sistema (praticamente
tutti: in realta` kernel, X.org, browser e alcuni componenti restano in
C), dalle applicazioni, al filesystem "a oggetti", all'intero sistema di
sicurezza "a capabilities" -- tutto in Python.  Vedremo se marcia...
Alex

 di 27.4M in un caso, 27.1M nell'altro...
Uh! Tanto di cappello a Matz e co.
-- 
Nel 20° secolo, l'umanità trascorrerà gran parte del proprio
tempo all'interno di scatole d'acciaio in lunghe processioni

 sicurezza "a capabilities" -- tutto in Python.  Vedremo se marcia...
Ma OLPC non era un nome registrato M$ ?
Chiedo eh, a me i dispositivi portabili piacciono molto e quello che hai 
detto già mi stuzzica. Il problema semmai sarà il prezzo..

 Uh! Tanto di cappello a Matz e co.
Beh, per Python Matz conta poco (Ruby č a 'ben' 34 sulla mia macchina!)


 idea all'istante.
La type-safety è una cosa interessante e utile, anche se Ada ne ha un
sistema fascista. Ci sono svariati modi di avere type-safety: ci sono
linguaggi con type-safety statica ed esplicita (Ada e Java), statica ed
implicita (Haskell, ML), dinamica (Python, Ruby).
Chiaramente non puoi paragonare tutti questi sistemi fra loro: fanno
cose diverse.
Per cui se non ti piace la typesafety di Ada, è facilissimo che ti
piaccia quella di Haskell o quella di Python.


 detto già mi stuzzica. Il problema semmai sarà il prezzo..
Vedi sopra, temo che tu ti sia confuso con UMPC (che credo sia ultra
mobile pc o qualcosa di simile).
-- 
In a minute there is time for decisions and revisions which a minute
will reverse
T.S. Eliot

 una azienda intera eh... (con performances mirabolanti)
Ti rimando ad una parte della mia risposta a Marco:
Attenzione: io non ho detto che Perl va bene solo per degli scriptini.
Io ho detto che Perl *č* nato in quel contesto. Che č un'affermazione
senza dubbio vera (e avvallata da Larry Wall stesso).
Cioč se dico che Perl č nato precisamente perchč awk sed e compagnia
cantante erano (e sono) parecchio scomodi e Perl č nato per offrire a
sys-admin e analoghi un tool piů comodo dico una cosa vera e basta.


 Direi, scusami, bruttissimo eh.
Orrendo, se è per questo. 
D'altra parte è un one-liner. Basta che funzioni.


 finirà per costare qualche decina di dollari in più.
Confermo: lo vendono (rigorosamente solo a ministeri dell'educazione del
terzo mondo, perche` lo scopo di tutto il progetto e` rivoluzionare
l'istruzione di quei bambini) sui 150 dollari.
Oggi Ivan Krstic ha fatto un talk a Google (sara` senza dubbio su Google
Video entro 7-10 giorni) che mi e` parso molto interessante (anche piu`
di quello di ieri sera a SDForum).  Ma la cosa che mi ha colpito di piu`
e` successa dopo: eravamo in gruppo a pranzare all'aperto, e Ivan ha
acceso l'XO (nome del modello specifico; OLPC e` il nome dell'intero
progetto) e ce ne ha mostrato la leggibilita` in pieno sole (nella
modalita` B/N a 200 punti per pollice): perfetto, superiore persino al
lettore ebook Sony (da 500 dollari) che un pochino ero tentato di
comprarmi (cosa che ora non faro`: la nuova tecnologia di display
inventata dagli ingegneri dell'OLPC sicuramente si diffondera`, e
secondo me potrebbe spazzare via quella "ePaper" che usa Sony).
La macchina di cose interessanti a livello tecnologico ne ha tantissime,
per carita`, sia nell'hardware sia nel software, ma quello schermo e`,
di tutte le novita`, quella che mi rende irresistibile l'XO...
Alex

 mobile pc o qualcosa di simile).
Ma lollissimo, si mi ero confuso con ultra mobile pc.

 l'istruzione di quei bambini) sui 150 dollari.
Non vendono in perdita vero ?
Sarebbe interessante per il mercato "standard" (cioé noi), ma 
probabilmente visto che il prezzo basso premia sempre nessun grande 
produttore darebbe una tale mazzata anche a sé stesso.

 produttore darebbe una tale mazzata anche a sé stesso.
Quanta, che fisicamente fabbrica gli XO per conto di OLPC, ha annunciato
che sviluppera` un laptop basato su quelle tecnologie con l'intenzione
di venderlo in tutto il mondo a 200 dollari (senza dubbio s'intende
netti di tasse e balzelli visto che queste sono diverse in ciascun
paese).  Con un margine sul costo industriale di appena il 30%, la cifra
mi lascia un poco perplesso, ma forse contano di lanciarlo, magari fra
un annetto, quando la normale curva d'apprendimento permessa dalla
produzione in grande scala avra` abbassato i costi industriali cosi` da
permettere margini sensati (almeno 50-60%) per costi di distribuzione
ecc.  Si sanno pochi dettagli su cosa esattamente ci sara` sul laptop da
$200 di Quanta, o di quando uscira`, ma nell'annuncio confermano che
(come l'OLPC XO) si basera` su software open-source [1].
Quanta Computers, con revenues di 461 miliardi di dollari HK nel 2006
(circa 59 miliardi di dollari USA, un giro d'affari dello stesso ordine
di grandezza di quello di Dell e triplo di quello di Apple), mi sembra
che possa sicuramente essere considerata un produttore grosso (se non
"grande":-); secondo la classifica di Fortune e` fra le 500 piu` grandi
aziende del mondo.  Nel 2006 ad esempio fabricavano (oltre a tantissime
altre cose) tutti i laptop (e vari altri computer) venduti da Dell (nel
2007 no: Dell ha teste` passato il contratto ad un'altra azienda
cinese), e di recente Apple gli ha affidato la fabbricazione dei
MacBook.  Come rete di distribuzione al dettaglio nei paesi occidentali
dubito che siano messi altrettanto bene, ma non so nulla di preciso.
[1]: l'OLPC XO in realta` ha uno slot SD che permette di fare il boot:
pare che sia stato aggiunto su richiesta di alcuni paesi (Ivan non ha
voluto dirmi quali!-) che ci tenevano ad avere la possibilita` almeno
teorica di fare boot anche da Windows (per ora molto teorica perche` non
ci sono driver per i tanti componenti HW peculiari dell'XO, il suo
"bios" in realta` e` Open Firmware, ecc ecc).
Alex
 

 aggiornabili con un meccanismo analogo ad apt-get.
Allora in primo luogo il 'di tutto' può non essere importante: la cosa
importante è che ci sia quello che mi serve. Chiaramente più c'è e meno
è improbabile che non trovi. 
Ma attenzione alle librerie 'duplicate'. Per esempio uno dei motivi
della diffusione di Ruby in ambito web di recente è stata per assurdo la
disponibilità praticamente di *un* framework (in effetti ce ne sono
altri minori, ma non se li fila nessuno, e c'è anche Nitro).
Paradossalmente Python non ha potuto fare lo stesso giochetto perchè
esistevano *troppi* framework. E complessivamente direi che un problema
simile lo ha accusato anche Perl, visto dal di fuori.
Poi non ho nulla da dire contro CPAN. Dico solo che anche con Ruby e con
Python mi è sempre capitato di trovare quello di cui avevo bisogno (che
non vuole certo dire che ci sia altrettanta roba, solo che per ora c'è
'quella giusta').


 capitato (pure utilizzando librerie duplicate o di diverse versioni).
Ma certamente non provocano problemi: il problema è per chi apprende.
Come ti dicevo il successo di Ruby sul Web è determinato (in parte) dal
fatto che ci fosse una sola libreria 'famosa'. Per cui chi inizia non
doveva cominciare a spulciarsi n framework per capire quello che più gli
interessa.
