Newsgroup: it.comp.os.linux.iniziare
Titolo: pipe con sed

ï¿œ possibile applicare il comando sed al risultato di un pipe anzichï¿œ un 
file?
per esempio, avendo: ls | grep ".txt", come faccio ad applicare sed 
all'elenco restituito da grep?
grazie


ls | grep ".txt" | sed 's/123/456/'
 
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 ls | grep ".txt" | sed 's/123/456/'
 
Pefetto grazie, ci lavoro sopra.
 

 file?
 
Al contrario, è sbagliato applicare sed ad un file piuttosto che ad un 
flusso.

 flusso.
 
Strozata colossale.
 
 
PS non postare all'una e mezza di  notte; è meglio dormire nel
letto piuttosto che davanti al computer.

 letto piuttosto che davanti al computer.
 
A te invece una bella dose di {educazione|umiltï¿œ|buonsenso|...} non
farebbe certo male. Sai essere inutilmente odioso.



 
 
Un file di input è un flusso, non c'è nulla di sbagliato a non usare sed 
in una pipe.
 
 
 

 farebbe certo male. Sai essere inutilmente odioso.
 
Senti bello, se non rispondi alle mie domande meotivando e spiegando
il perché ed il percome continuerò ad appplicare letichetta "stronzata 
colossale" al tuo post precedente, al post di Andrea D'Amore ed a 
tutti i post che fanno affermazioni gratuite e sbagliate.
 

 A parte che ti la tua scusa è pretestuosa
 
 
sed 's/ ti / /'

 in una pipe.
 
  Non è infatti sbagliato, ma non è l'uso tradizionale degli strumenti
di analisi e filtraggio dei flussi.  Questi comandi erano stati in
origine sviluppati per lavorare solo sui flussi e non sui file.  Sono
poi stati modificati per poter leggere i dati in input da un file quando
non hanno il loro standard input rediretto e "vedono" un oggetto del
filesystem come argomento sulla riga di comando, ma questa è stata
un'evoluzione successiva e non necessaria del loro uso.  Come infatti
scrive Bruce Barnett nel suo bellissimo e completo SED tutorial:
 
http://www.grymoire.com/Unix/Sed.html#uh-0
 
 
Sed has several commands, but most people only learn the substitute
command: s. The substitute command changes all occurrences of the
regular expression into a new value. A simple example is changing "day"
in the "old" file to "night" in the "new" file:
 
sed s/day/night/ <old >new
 
Or another way (for Unix beginners),
 
sed s/day/night/ old >new
 
 
  Ci sono infatti comandi che seguono ancora il criterio UNIX originale
e che  quindi non ammettono l'indicazione di un file quale argomento
sulla riga di comando come equivalente all'esplicita ridirezione
dell'input da quel file:
 
alessandro@krill ~ $ tr 'a-z' 'A-Z' /etc/passwd
tr: operando "/etc/passwd" in più
Usare «tr --help» per ulteriori informazioni.
 
alessandro@krill ~ $ tr 'a-z' 'A-Z' < /etc/passwd
ROOT:X:0:0:ROOT:/ROOT:/BIN/DASH
[...]
 
  Non che ci sia nulla di male nell'essere dei principianti, ma c'è
molto di male nell'esserlo e nell'aggredire chi fa le cose diversamente
da se dando per di più giustificazioni tecnicamente errate.
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 all'elenco restituito da grep?
 
  Puoi fare a meno di grep, che sed sa fare anche il lavoro di grep:
 
ls | sed '/.txt/s/txt/test/'
 
  Fai attenzione che "." non è usato letteralmente, perché è
un'espressione regolare che indica un qualsiasi carattere singolo.
Volessi usare proprio il carattere punto invece, dovresti fare così:
 
ls | sed '/\.txt/s/txt/test/'
 
  La differenza la vedi con questi esempi:
 
alessandro@krill ~ $ echo 'file.txt' | sed '/.txt/s/txt/test/'
file.test
 
alessandro@krill ~ $ echo 'file,txt' | sed '/.txt/s/txt/test/'
file,test
 
alessandro@krill ~ $ echo 'file.txt' | sed '/\.txt/s/txt/test/'
file.test
 
alessandro@krill ~ $ echo 'file,txt' | sed '/\.txt/s/txt/test/'
file,txt


 all'elenco restituito da grep?
 
Rispondo a me stesso, ma voglio dire grazie a tutti. Si impara anche dai 
battibecchi.
 

 letto piuttosto che davanti al computer.
 
In vena di consigli modera il tono del registro, dai l'idea di aspettare 
in agguato su Usenet l'errore (o quello che ritieni tale) per sfogarti, 
e di replicare poi in maniera sproporzionata alle critiche ai tuoi 
messaggi.
 
Magari non è così ma è l'idea che dai e non mi riferisco ad ora, momento 
in cui puoi pensare che potrei sentirmi offeso dalla tua risposta, ma al 
periodo precedente in cui ho seguito i vari gruppi icol* .
 
 
Finita l'analisi da tre soldi spiego che la risposta si riferiva all'uso 
di sed per il replace-in-file che ritenevo l'utente stesse facendo e 
alla famigerata [1] che passa frequentemente su #bash .
 
A rileggere ora il messaggio dell'OP non immagino proprio perché abbia 
intepretato la sua intenzione in quella maniera, senz'altro non dormivo 
ancora. 
 
 
[1] 
http://mywiki.wooledge.org/BashFAQ/021
 

 in una pipe.
 
Vedi altra risposta. Capisco l'obiezione di Alessandro Selli che un file 
come elemento del fs è più del semplice flusso ma capisco anche che 
quando è possibile definire una corrispondenza biunivoca, ad esempio ad 
ogni file associo biunivocamente uno stream, è possibile confondere in 
senso algebrico i due concetti.
Sinceramente non ricordo il concetto di C in UNIX ma immagino che lo 
erediti dalla libreria standard C.
Come si comporta con i file di tipo speciale, ad esempio le directory o 
i block device? C'è uno stream associato anche a questi?

 Quindi direi proprio che ha perfettamente ragione.
 
Forse avrei dovuto aggiungere un "filologicamente" :-)

 leggere i dati in input 
 
Avrei dovuto agganciare qui il mio messaggio agganciato invece a quello 
di gt.

 ...
 
 
ALT! Alessandro Selli ha detto alcune cose giuste pero voi due fate un
grosso errore confondendo "pipe" e "stream" chiamandole entrambi 
"flussi". 
Stream è un concetto più generale di file e giustamente io e gt lo 
abbiamo fatto notare.
Però tu usi il termine flusso e file come contrapposti dimenticando 
una dei concetti fondati di Unix: tutto è un file. Quindi un socket è 
un file, una pipe è un file, una directory è un file, un dispositivo è
un file. E le API Unix (pardon le system call) trattano tutto come
fosse un file. Ancora non capisco perché sed non si deve usare 
con i file.
 
 

Addì  martedì 3 gennaio 2012 12:21 Andrea D'Amore scrisse:

Filologicamente le systrem call di Unix trattano tutto come
file, quindi hai torto anche filologicamente.
 

 da se dando per di più giustificazioni tecnicamente errate.
 
Se mi spieghi dettagliatamente perché sarebbe corretto Il comando:
 
sed 's/Pippo/Topolino/g' > lettera-1.0.txt > lettera-1.1.txt
 
mentre sarebbe scorretto il comando:
 
sed 's/Pippo/Topolino/g' lettera-1.0.txt > lettera-1.1.txt
 
ti dò ragione.
 

 da se dando per di più giustificazioni tecnicamente errate.
 
Si entra nel filosofico, ma io trovo poco intelligente considerare uno 
"principiante" solo perché utilizza potenzialità nuove degli strumenti 
"moderni" (che una volta magari non c'erano); e considerare invece come 
un "guru" o un esperto quello che - a dispetto dell'evoluzione - 
continua a fare le cose come si facevano 30 anni fa...
 
-- 
Massimo Bacilieri AKA Crononauta

 alessandro@krill ~ $ tr 'a-z' 'A-Z' < /etc/passwd
 
Scusa in questi casi che differenza c'e tra "<" e "cat |" ? TIA
 
-- 
Tanti saluti
 

 sed 's/Pippo/Topolino/g' lettera-1.0.txt > lettera-1.1.txt
 
Non lo è, io mi riferivo al replace in file (opzione GNU -i) che credevo 
l'OP volesse mettere in atto
Per quanto riguarda TheZipman ovviamente non posso rispondere, posso 
azzardare però (siamo nella supposizione) che abbia avallato la mia 
affermazione seguendo alla lettera il significato dell'acronimo SED.

 in relazione il descrittore di file, che è un terzo oggetto.
 
Non sarebbe meglio dire che lo stream è uno dei modi possibili
d'interfacciarsi ad *alcuni* tipi di file? Il modo alternativo, di
più basso livello, è il descrittore di file.
 
E, detta così, a me sembra allora che lo stream sia un concetto
parallelo a quello di file, ma in certo senso *meno* generale
(perché lo stream può accompagnarsi solo ad *alcuni* tipi di file).
 
E sed è uno stream editor, perché funziona accedendo ai file
in modalità stream (e non in modalità file descriptor). Non è
così?
 
Insomma non capisco la contrapposizione fra file e stream, quando mi
sembrano invece concetti per i quali si debba parlare d'integrazione.
Perché possa esserci uno stream, deve prima esserci un file. Un certo
tipo di file, anzi.
 
Sono completamente a digiuno della materia, eh, ma la vostra
discussione m'ha incuriosito e sono corso a leggermi:
http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_10.html#SEC110
 
 
Magari l'osservazione di uno come me, che non sa, può sollecitare
un vostro chiarimento. :)
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_________________________________________________________________
Non sprecare i cicli idle della tua CPU, né quelli della tua GPU.
 
http://www.worldcommunitygrid.org/index.jsp
 
http://www.rnaworld.de/rnaworld/
 
http://dnahome.cs.rpi.edu/dna/
 
 
http://www.gpugrid.net/
 


 
io non mi offendo se mi dai del principiante o del tecnico errante, ma 
sei sicuro di rivolgerti a me?
no, perché non c'è nulla di male nell'intervenire in una discussione, ma 
intervenire a vanvera non è gran cosa.
 
 


 
Il subject dice tutto <g>

 sed 's/Pippo/Topolino/g' lettera-1.0.txt > lettera-1.1.txt
 
  Uffa.  Non ho scritto che è scorretto.  Ho scritto: «Non è infatti
sbagliato, ma non è l'uso tradizionale degli strumenti di analisi e
filtraggio dei flussi.»  Un'obiezione sensata avrebbe potuto essere che
Savux non intendeva elaborare un flusso, ma proprio un file.  Ma
rispondere invece con l'assurdità che un flusso sia un concetto di file
più generalizzato è un'arrampicata sugli specchi di peculiare risibilità.
 
  Ora, sono d'accordo che sulla riga di comando saltare qualche
carattere faccia comodo e che quindi si preferisca non usare la
ridirezione esplicita con comandi scritti apposta per lavorare anche sui
file.  Ma abituarsi ad usare la ridirezione esplicita negli script è una
buona cosa, soprattutto quando gli oggetti (se non proprio i comandi)
sono dichiarati implicitamente, non esplicitamente.  Inoltre, qualsiasi
cosa legga dallo stdin e scriva sullo stdout può essere usato come
elemento di una pipe.  E infatti sed lo fa, e grep e sed, insieme a
tutti i comandi degli UNIX software tools, sono nati subito dopo
l'introduzione delle pipe in UNIX  (E non a caso.  Prima
dell'introduzione delle pipe si doveva lavorare sempre sui file, per cui
si faceva tutto con ed.  Nate le pipe, si sono portati fuori da ed i
suoi comandi per "pipare" tra di loro le varie operazioni filtro in
maniera non interattiva).  Mentre uno script o un comando che si aspetta
i dati da un file o che pretende di scrivere in un file no (a meno di
non ingannarlo usando named pipe o "-" al posto del nome di file, cosa
quest'ultima che però non funziona sempre, m'è capitato un comando che
crea un file di nome "-" se usato come suo argomento di output - non
ricordo quale).


 l'OP volesse mettere in atto
 
Oh, ecco. ammetti che hai letto male il post dell'OP e finiamo 
poiché tutti gli altri discorsi sulla redirezione e il significato di 
stream servono solo ad aumentare l'entropia producendo aria 
calda.

 file,
 
  No.


 tipo di file, anzi.
 
  No.  Dove lo vedi il file in questa operazione?
 
alessandro@krill ~ $ telnet localhost chargen \
| dd bs=1024 count=1024 iflag=fullblock | strings | wc -c
1024+0 record dentro
1024+0 record fuori
1048576 byte (1,0 MB) copiati, 0,0516796 s, 20,3 MB/s
1048574
 
telnet legge da un socket TCP/IP e scrive verso lo stdout, dd legge da
stdin e scrive verso stdout, come pure fanno i comandi strings e wc.
Nessun file di mezzo, solo flussi.


mallin.shetland ha scritto:

  Cosa molto utile in questa stagione, e che mi guardo bene quindi dallo
smettere!  :-)


 memorizzati staticamente su un supporto capace di I/O.  Uno stream sono
 
 
No il file è una astrazione che Unix usa per accedere in modo 
uniforme alle risorse del computer.
 
_/|_/|_/|_/|_/|_/|_/|_/|_

 smettere!  :-)
 
 
LOL

 ricordo quale).
 
  Cazzabubbolo, l'ho usato appena un'ora fa: è dd.
 
alessandro@krill ~ $ dd bs=512 count=100 if=/dev/zero of=- | strings |\
wc -c
100+0 record dentro
100+0 record fuori
0
51200 byte (51 kB) copiati, 0,000443042 s, 116 MB/s
alessandro@krill ~ $ ll -- -
-rw-r--r-- 1 tecnico tecnico 51200  4 gen 01.08 -
 
  Poco male se usato interattivamente, basta non usare of=, ma in uno
script è una scocciatura, perché per poter usare of="$OF" senza temere
errori si deve prima controllare che non sia OF=-


    Ciao,
 
 
dd non pretende di scrivere su un file, sei tu a dirglielo con of
 
dd bs=512 count=100 if=/dev/zero | strings | wc -c
100+0 record dentro
100+0 record fuori
51200 byte (51 kB) copiati, 0,000455034 s, 113 MB/s
0
 
ma anche sed lo fa (w filename), se gli dici di scrivere su un file 
invece che sullo standard output.
 
sed 's/questo/quello/ w -' filename
 
 

 contenere qualsiasi tipo di dati.
 
MMhhh...
 
File descriptors provide a primitive, low-level interface to input and
output operations. Both file descriptors and streams can represent a
connection to a device (such as a terminal), or a pipe or socket for
communicating with another process, as well as a normal file. But,
if you want to do control operations that are specific to a particular
kind of device, you must use a file descriptor; there are no facilities
to use streams in this way. !!!_ You must also use file descriptors if your
program needs to do input or output in special modes, such as
nonblocking (or polled) input. _!!!


 nonblocking (or polled) input. _!!!
 
  Bene, concordo!  "Sia i file descriptor che i flussi possono
rappresentare una connessione ad un dispositivo (come un terminale), o
una pipe o un socket per comunicare con un altro processo, come pure un
file normale".  «come pure un file normale.»  Quindi un flusso può
instaurarsi su tutti i tipi di file nella tua accezione, ossia quelli
speciali, come anche su quelli regolari, che sono considerati a parte
proprio perché non sono la stessa cosa.


 sed 's/questo/quello/ w -' filename
 
alessandro@stn0b2 ~ $ sed 's/questo/quello/ w -' filename
sed: impossibile leggere filename: No such file or directory


 operativo non troverebbe da obiettare, contrariamente al primo caso.
 
  E invece si che trova da obiettare:
 
alessandro@stn0b2 ~ $ grep 'Bob Marley' /dev/snd/pcmC0D0c
grep: /dev/snd/pcmC0D0c: Il descrittore di file è in uno stato non valido


 proprio perché non sono la stessa cosa.
 
Può essere che io abbia sbagliato qui, perché conosco davvero poco la
materia: quel che è certo è che ci sono casi in cui è obbligatorio usare
i descrittori di file (e non si possono usare gli stream): dipenderà
solo dalle operazioni che si debbono fare, o anche dal tipo di file come
m'era parso, sinceramente non lo so.


   No.
 
Uh?
http://ph7spot.com/musings/in-unix-everything-is-a-file
 


 
http://ph7spot.com/musings/in-unix-everything-is-a-file
 
 
  Credo d'aver capito: hai problemi ad intendere l'inglese.
 
 
  A stasera, ciao.


   Credo d'aver capito: hai problemi ad intendere l'inglese.
 
Può darsi.
 
This key design principle consists of providing a unified paradigm for 
accessing a wide range of input/output resources: documents, directories, 
hard-drives, CD-Roms, modems, keyboards, printers, monitors, terminals 
and even some inter-process and network communications. The trick is to 
provide a common abstraction for all of these resources, each of which the 
UNIX fathers called a “file”. Since every “file” is exposed through the 
same API1, you can use the same set of basic commands to read/write to a 
disk, keyboard, document or network device.
 
Quanto sopra non significa che le "system call di Unix trattano tutto 
come file"?



 
 
E' uno scherzo o non hai capito veramente?
 
 
 

 Scusa in questi casi che differenza c'e tra "<" e "cat |" ? TIA
 
Che la redirezione è una cosa lecita mentre l'altro è un uso 
improprio del cat.
 
In altre parole un processo in più

 come file"?
 
  Oh, piano piano ci stai arrivando.  Intanto che completo una mia
risposta più articolata, sottolineo che è proprio questo il punto:
standardizzare certe operazioni comuni tra oggetti diversi trattandoli,
limitatamente a queste operazioni, tutti come fossero dei file *non*
vuol dire che sono tutti uguali ai file.  Parafrasando, il fatto che
tutti siano uguali davanti alla legge non vuol dire che tutti siano
uguali.  Gli oggetti del filesystem hanno ciascuno delle caratteristiche
uniche, in più e in meno, rispetto ai file e agli altri oggetti.  Cosa
questa che rende inadatti certi oggetti per certe operazioni che si
eseguono con i file, oppure che rende certe operazioni completamente
impossibili con altro che non i file.  La denominazione comune di "file"
deriva infatti non dall'avere proprietà uguali e usi compatibili, ma da
un retaggio storico: queste operazioni comuni sono state implementate
per prime sui file, che sono stati il primo oggetto nato insieme alle
directory.
 
  C'è altro che devo però elaborare.
 
 
  Ciao,


   Oh, piano piano ci stai arrivando.
 
Guarda, sinceramente a me però non interessa più "discuterne" così. Tu 
continui a ripetere le tue tesi, basate tutte sulla convenzione 
terminologica (che cosa è file) che tu prediligi, e che per qualche 
motivo dovrebbe essere secondo te l'unica lecita. Il che non ha molto 
senso: perché ogni nome è tale per convenzione, perché le convenzioni per 
definizione non possono essere ontologiche, e perché una definizione 
alternativa, funzionale, come quella per cui "tutto è un file" non ha 
nulla di intrinsecamente incoerente - e funziona infatti benissimo.
Ripeti le tue tesi, ma non le argomenti né le suffraghi nel merito.
 
Inoltre continui a parlare genericamente di stream come di flusso di 
dati, quando qui trattiamo di un concetto *applicato* ai comandi unix, ai 
tipi di dati e di funzioni C... E lo stream di *s*ed non può che essere 
ovviamente inteso in *questo* senso tecnico, applicato a *questa* realtà.
 
Comunque, a parte tanti bei discorsi, un modo per tagliare la testa al 
toro nel merito della questione sarebbe: vediamo i sorgenti di sed (mi 
piacerebbe saperlo fare, ma mi posso benissimo fidare di te, che 
certamente lo sai fare). Che cosa cambia quando gli si dà in pasto un 
file come argomento, e quando invece gli si ridirige lo standard input? 
In entrambi i casi apre quell'"entità" trattandola come stream? E allora 
che cosa cambia?


 E' uno scherzo o non hai capito veramente?
 
  Ho copincollato quello che hai scritto tu.


 Guarda, sinceramente a me però non interessa più "discuterne" così.
 
 
  D'accordo.



 
è stranissimo, filename è un file di sistema, c'è su ogni unix-like! :-)
hai provato con la redirezione?
magari il tuo sed è così tradizionale che riesce ad operare solo con i 3 
file descriptor standard.
se proprio non dovesse funzionare, prova ad usare un file che esiste, 
oppure anche una bella pipe.
 
 
 

 un caso di morphing, quindi
 
  No, di scarso comprendonio piuttosto.
