Newsgroup: it.comp.os.linux.sys
Titolo: problemaccio AWK

Allora, andiamo al problemaccio.
ho impostato due variabili:
port_range=1-9900
allowed_ports="22|25|80|443|465|636|4444|8112"
Adesso mi devo creare la variabile "open_ports" e per farlo uso l'output 
del seguente comando:
nmap -n -T Aggressive -p $port_range 192.168.0.2|awk -F/ '/open/ && ! 
/ENVIRON["allowed_ports"]/{print $1}'
ma non funziona. Se al posto di ENVIRON["allowed_ports", ci schiaffo 
dentro i numeri allora funziona. Esempio:
nmap -n -T Aggressive -p $port_range 192.168.0.2|awk -F/ '/open/ && ! 
/22|25|80|443|465|636|4444|8112/{print $1}'
Ma il problema � ancora pi� strano.
In genere *NON* stampa in alcun caso quella variabile.
Esempio:
cat /etc/passwd|awk '{print ENVIRON["LANG"]}'  (Funziona!!)
cat /etc/passwd|awk '{print ENVIRON["allowed_ports"]}' (NON Funziona!!!)
Sono perplessissimo.
Secondo problema, nel problema:
se scrivo di escludere "22", mi esclude, di conseguenza anche "2222".
Con grep basta usare l'opzione "-w" ed � fatta. E con awk?
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo

 Con grep basta usare l'opzione "-w" ed è fatta. E con awk?
Devi ancorarla: /^22$/

 Sono perplessissimo.
export

 export
deng-you! non sono pi� perplessissimo :-)


 Devi ancorarla: /^22$/
ops: thanks :-)


 :-) cavolo... allora awk molla la shell completamente.
No, qualunque programma eseguito dalla shell non vedrebbe quella variabile 
se non fosse esportata.


qualcunque programma che richiama un'altra shell... ma io nei miei test 
lo facevo sul prompt, senza richiamare altre shell.
Comunque, in realt�, il problema � risolto solo a met�.
La variabile in quel modo viene stampata, per�, non funziona il match :(
Ovvero, se ci metto i numerini funziona, ma se metto la variabile in 
quel modo non funziona.
Ovvero, ad esempio, questo non funziona:
echo $LANG | awk '/ENVIRON["LANG"]/{print}'
e questo funziona senza problemi:
echo "$LANG" | awk '/it_IT.UTF-8/{print}'
sono di nuovo perplessissimo.... che confusione....


 echo $LANG | awk '/ENVIRON["LANG"]/{print}'
Ovvio.
awk 'ENVIRON["LANG"] ~ /it_IT\.UTF-8/ {print}'

 awk 'ENVIRON["LANG"] ~ /it_IT\.UTF-8/ {print}'
si ma questo non centra il problema. Cioï¿œ non mi aiuta: come faccio a 
fare il match di una variabile? (poi nel caso mio devo fare il reverse 
match... ma non importa).


 match... ma non importa).
lo fai con l'operatore "~":
awk '$0 ~ variable { do something }'

 awk '$0 ~ variable { do something }'
mmhh... non capisco. Io devo usare la variabile, e non mettere i numeri.
Cioï¿œ questo continua a non funzionare:
echo $LANG | awk '$0 ~ ENVIRON["LANG"] {print}'
o forse non ho capito come interpretare il tuo suggerimento.


 o forse non ho capito come interpretare il tuo suggerimento.
A me questo funziona:
$ echo $LANG | awk '$0 ~ ENVIRON["LANG"] {print}'
en_US.utf8
anche se dovresti fare l'escaping dei caratteri speciali presenti in 
ENVIRON["LANG"], ma in questo caso funziona ugualmente.


aah.. che idiota che sono... a furia di giocare avevo rimosso la 
variabile lang: proabilmente avrï¿œ lanciato un "unset LANG" :-)


 richiede l'export, anche nella stessa shell.
Quindi il programma C che ti ho messo non necessita export, se usato nella 
stessa shell, vero?
Rispondi a questa domanda.

 $ echo massimiliano | sed -e s/massimiliano/"$a"/
sono superflui pure gli apici doppi...
basta cosï¿œ:
echo massimiliano | sed -e s/massimiliano/"$a"/
evidenetemente il dollaro assume significato solo tra i primi due slahs, 
ma non tra il secondo e il terzo.
p.s.: fino ad ora avevo messo l'escape anche nella seconda parte ma non 
serve a nulla. Esempio:
echo massimiliano | sed -e s/^massimiliano/^a/
non lo usa come carattere speciale....


 echo ABC | awk '{print ENVIRON["a"]}'
Puoi fare a meno dell'export, che forse ï¿œ anche meglio
port_range=1-9900
allowed_ports="22|25|80|443|465|636|4444|8112"
nmap -n -T Aggressive -p $port_range 192.168.0.2|awk -F/ -v 
buoneporte=$allowed_ports '/open/ && ! /buoneporte/{print $1}'


ti rispondo che "sed *�* un programma in C", che a differenza di awk, e 
del tuo codice, si comporta come *TUTTI* i programmi Linux.
Ennesimo esempio (ho perso il conto):
a=XX
echo MassXXimiliano | tr -d $a
Anche in questo caso N-O-N � necessario fare export.


 Anche in questo caso N-O-N è necessario fare export.
Ok, anche l'ultima speranza che tu non fossi un perfetto idiota e' andata 
(non che avessi molte speranze eh). In bocca al lupo con i tuoi script.
 ____    _                   _      _   _   _ 
|  _ \  | |   ___    _ __   | | __ | | | | | |
| |_) | | |  / _ \  | '_ \  | |/ / | | | | | |
|  __/  | | | (_) | | | | | |   <  |_| |_| |_|
|_|     |_|  \___/  |_| |_| |_|\_\ (_) (_) (_)


non mi funge :-( Faccio copia e incolla della riga che hai suggerito ma 
il '22' continua a comparire, quando invece non dovrebbe. Sigh, mi avevi 
illuso :(
Evidentemente tu sul 192.168.0.2 non hai un server SSH che gira :-)



Pazzesco. Siete dei bambini che non siete in grado di risconoscere nella 
vostra di aver detto una cosa sbagliata.
Qualcuno si rilegga il thread intero e mi spieghi perchï¿œ non sono 
riuscito a fargli capire una cosa assolutamente banale, evidente e sotto 
gli occhi del cieco piï¿œ cieco che ci sia.
Addirittura, per imbrogliare le carte mi ha messo in mezzo una riga, 
assolutamente stupida, con un sed tarocco che fa l'escape del dollaro.
Tutto assolutamente degno di un asilo nido.


 buoneporte=$allowed_ports '/open/ && ! /buoneporte/{print $1}'
Forse intendevi questo:
port_range=1-9900
allowed_ports="22|25|80|443|465|636|4444|8112"
 
nmap -n -T Aggressive -p $port_range 192.168.0.2|awk -F/ -v
buoneporte="$allowed_ports" '/open/ && $0 !~ buoneporte {print $1}'


  __________
< pazzesco >
  ----------
       \                _
        \              (_)
         \   ^__^       / \
          \  (oo)\_____/_\ \
             (__)\       ) /
                 ||----w ((
                 ||     ||>>
  __________
< pazzesco >
  ----------
   \                 __
    \               (oo)
     \              (  )
      \             /--\
        __         / \  \
       UooU\.'@@@@@@`.\  )
       \__/(@@@@@@@@@@) /
            (@@@@@@@@)((
            `YY~~~~YY' \\



That's it! Dopo un'ora di sparare minchiate finalmente mi hai risolto il 
problema.
G-R-A-Z-I-E.
Ok?


 buoneporte="$allowed_ports" '/open/ && $0 !~ buoneporte {print $1}'
sï¿œ, molto meglio

 sï¿œ, molto meglio
se avete sempre voglia, mi permetto di riaprire i giochi :-)
visto che come dice lo scorbutico di Antani (per evitare di confondere 
il 22 con il 2222) devo ancorare i singoli campi, al posto di "22|25..." 
dovrï¿œ apparire:
^22$|^25$|^80$|^443$|^465$|^636$|^4444$|^8112$
Quindi, normalmente farei cosï¿œ:
echo \^"$allowed_ports"\$ | awk '{gsub(/\|/,"$|^");print}'
ma sarï¿œ possibile integrarlo nella riga di cui sopra?
tipo:
buoneporte="qui_che_ci_metto_ per_sistemarlo??"
Oh, se non si puï¿œ fare, o se si complica troppo, va bene cosï¿œ... 
approfitto di voi per imparare e nel frattempo faccio contento Antani 
che cosï¿œ puï¿œ fare lo sborrone :-)



Momento: ï¿œ andato tutto di nuovo in merda!
Usando ^22$|^80$!.... l'ultima sintassi buona non funziona piï¿œ .... :-(
E questo mi crea problemi di confusione tra 22 e 2222 ....
p.s.: e giï¿œ che il buon grep fa tutto in un sol colpo, perï¿œ mi fa rabbia 
dover mollare lï¿œ la cosa (specie dopo un thread cosï¿œ lungo).


 quello che fa.
Mi scuso con antani che è strato tirato in ballo da me pur essendo
innocente.
Caro max, bash, awk, italiano... I linguaggi che non conosci sono molti.

 Caro max, bash, awk, italiano... I linguaggi che non conosci sono molti.
e si vede come conosci tu AWK .... vada via che abbiamo da fare.
io ho fatto semplicemente notare che "export" si rende necessario SOLO 
in due casi:
primo caso è quando forki la shell.
secondo caso è quando usi AWK.
In *tutti* gli altri casi è superfluo.



This one:
nmap -n -T Aggressive -p $port_range 192.168.0.2|awk -F/ -v 
buoneporte="$allowed_ports" '/open/ && $0 !~ 
"^22$|^25$|^80$|^443$|^465$|^636$|^4444$|^8112$" {print $1}'
won't work at all :-(


 ... 
Una sola parola PEBKAC.
Caro antani, non vale la pena. Cme diceva mio padre:
"Perdi la scommessa che sono solo dei fessi"

 
visto che devi matchare righe del genere:
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
lascierei tutto come suggerito da antani e dichiarerei la variabile cosï¿œ:
allowed_ports="^22/|^25/|^80/|^443/|^465/|^636/|^4444/|^8112/"


AHAHAHAHAHAHAHAH: sei ancora qui?
già che ci sei prova questi due comandi:
echo ciao| awk '{print $allowed_ports}'
echo ciao| awk '{print ENVIRON["allowed_ports"]}'
(ovviamente, come abbiamo capito: DOPO AVER FATTO export della variabile).
Provali e poi vai a letto... anzi: com'era la storia degli aggettivi in 
inglese che si usano al femminile? Ancora aspetto che mi tu dica il 
femminile "beauty"? :-)



si, ma se vedi il mio ultimo messaggio, sono le ancorette che con questa 
sintassi non funzionano piï¿œ, anche senza usare la variabile:
Esempio:
nmap -n -T Aggressive -p $port_range 192.168.0.2|awk -F/ -v 
buoneporte="$allowed_ports" '/open/ && $0 !~ 
"^22$|^25$|^80$|^443$|^465$|^636$|^4444$|^8112$" {print $1}'


Max_Adamo wrote:


forse perchï¿œ dovresti metterle tra // e non tra "".


no no (appena provato).
comunque, se rimuovi le ancorette, tutto funziona alla perfezione:
nmap -n -T Aggressive -p $port_range 192.168.0.2|awk -F/ -v 
buoneporte="$allowed_ports" '/open/ && $0 !~ 
"22|25|80|443|465|636|4444|8112" {print $1}'


 forse perché dovresti metterle tra // e non tra "".
No, e' perche' e' un idiota (ma non voglio ripetermi).

 No, e' perche' e' un idiota (ma non voglio ripetermi).
non so se mi leggi o meno...
Antï¿œ, io non ho mai messo in discussione il fatto che tu sia sgamato 
nello scripting. Perï¿œ:
1. non sei il piï¿œ grande genio sulla terra ... far away from that: awk 
non l'hai scritto tu :-) E quindi, come tutti gli esseri umani, anche tu 
sei soggetto a sbagliare. E giï¿œ: non sei dio.
2. su quella cosa *HAI* torto perchï¿œ ti ho evidenziato qual ï¿œ il 
comportamento piï¿œ comune di tutti i programmi che girano su Linux (ti ho 
portato l'esempio di 'tr' e di 'sed', ma potrei portarne altri).


 E da quando in AWK le variabili si dichiarano così?
Se speieghi a me (ed ad antani ed a gt)  perché la sostituzione 
dei parametri la debba fare awk e non la bash eviterai il plonk.


Partiamo dalle origini:
1. sono in grado di eseguire quella sostituzione in mille altri modi 
(direi: come ciascuno di noi qui dentro). Tanto è vero che quello script 
funziona già da tempo (ma senza AWK messo in quel modo). Però, ogni 
tanto, a singhiozzi, mi metto a ri-imparare qualcosa di AWK. Non si sa 
mai dovesse comparire come requisito per fare un concorso. Quindi, se 
voglio farlo con AWK è chiaro che mi interessa volerlo fare con AWK, se 
chiederò perl, vuol dire che mi interesserà farlo con perl. Ripeto: si 
può fare in 10mila modi, e se vuoi si può anche discutere su quale è il 
modo più efficiente (ma la discussione parte per la tangente).
2. cronistoria del problema:
  2.1: a differenza di altri tool, con AWK, anche sulla shell corrente 
devi fare l'export (quindi con sed, tr, cut, se mantieni la shell, 
l'export non è necessario. Con AWK è necessario. Non torniamo più su 
questa cosa per cortesia perché altrimenti impazziamo tutti). E questa 
era la prima causa di "malfunzionamento"
  2.2: se al posto della variabile ENVIRON["blabla"], ci metti il suo 
corrispondente valore, allora funziona alla perfezione. Ma se usi la 
variabile non funziona più. Missing ficiur o mi sfugge qualcosa? boooh?
  2.3 gt escogita l'escamotage, Antani lo raffina e sembra funzionare.
  2.4 le ancorette "^" e "$" che mi servivano per fare il match della 
parola intera (per evitare di confondere 22 con 2222) funzionavano con 
la direttiva precedente, ma con la soluzione successiva smettono di 
funzionare: sia con la variabile, sia con il suo valore.
p.s.: ripeto che il punto non è trovare la soluzione con "grep" o con 
"sed". Ma ti pare che lo venivo a chiedere qui? Lo script è già 
funzionante da circa un anno. Il mio post ha finalità puramente 
didattiche, per me, per te, per Antani, per GT e per chiunque ci sta 
leggendo.
Se poi ognugno deve avere tutte queste prosopopee (vedi Antani) allora 
diventa veramente difficile anche dire buongiorno e buonasera, che ne 
esce subito fuori un gran casino.


C'e` un meraviglioso ng che si chiama comp.unix.shell.
Non che questo sia inadeguato o che dispiaccia leggerti qui su questi 
temi, ma per ottenere risultati piu` rapidi e far incazzare meno gente, 
almeno qui, potrebbe essere una valida alternativa di prima scelta.
Andrea

twistedbrain wrote:

Si', eccome no. Se lo mangiano vivo li'.

 almeno qui, potrebbe essere una valida alternativa di prima scelta.
a parte Antani (che piï¿œ che altro ï¿œ incazzato con se stesso per essersi 
incaparbito stupidamente su una sciocchezza) siamo tutti abbastanza 
tranquilli.



Assolutamente no, perch� non avrei assolutamente nulla da replicargli. 
Mica mi risponderebbero con le sciocchezze che hai scritto tu.


 [Una marea di cavolate]
Pronto? C'È NESSUNO NELLA TUA TESTA?
Se vuoi solo la soluzione al tuo problemuccio banale già
ti è stata data: usa export. Il punto è che invece di provare 
a capire il perché export funziona hai cominciato a dire 
tante cavolate e non la finisci più. Ormai è evidente a tutti 
che hai il cervello attorcigliato. Finiscila, dai ascolto ad antani 
perché è uno che se ne intende della bash.
PLONK


ma bafangulo è la seconda volta che mi plonki in soli due giorni, 
pertanto non è vero che plonki :)
Ma HAI CAPITO CHE ANCORA NON FUNZIONA UN CAZZO? Lo hai capito o sei un 
cretino totale, il cui cervello è messo peggio del buco dell'ozono?
PLONK pure io, perché sei veramente la persona più stupida che c'è qui 
dentro.


 ti sembrano scemi quelli che usano: ENVIRON["allowed_ports"] ?
Attento: ENVIRON lo usi *dentro* lo "script", cioè dentro le parentesi
graffe.
Quello che sta fuori è sotto il controllo di bash.
(varicomandi) | awk "/$allowed_ports/{print;}"
intercetta in awk quello che nello stream passato da (varicomandi)
incontra $allowed_ports, e lo stampa.
ENVIRON lo usi se invece vuoi gestire la variabile dentro ad awk, e in
questo caso la variabile va esportata:
export $allowed_ports ; awk 'BEGIN {print ENVIRON["allowed ports"];}'
anche se per la semplice assegnazione delle variabili, in casi come
questo, non disdegnerei l'opzione -v :
awk -v AP=$allowed_ports '{print AP;}'
Inoltre fai attenzione all'uso dei singoli apici o delle virgolette
doppie, man bash riguardo alla sostituzione delle variabili e capirai
perché:
allowed_ports="..." (senza export, non serve in questo caso)
(varicomandi) | awk "/$allowed_ports/{print;}"
funziona, mentre:
(varicomandi) | awk '/$allowed_ports/{print;}'
_non_ funziona, e ti può portare a strade più complicate quali quelle di
esportare la variabile e richiamarla dentro awk con ENVIRON per poi
gestirla internamente.
-- 
Massimo Bacilieri AKA Crononauta

 /ENVIRON["allowed_ports"]/{print $1}'
Nota le barre attorno a ENVIRON["allowed_ports"]

 Si', eccome no. Se lo mangiano vivo li'.
Non credi in Darwin?
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

> /ENVIRON["allowed_ports"]/{print $1}'
Stavo per scrivere che in quel caso avrei semmai fatto qualcosa del genere:
... | awk -F/ "/open/ && ! /$allowed_ports/ {print $1;}"
senza dover esportare $allowed_ports, ma vedo che era già stato proposto.
Il problema lì non è awk o bash, il problema è che con quella sintassi
$allowed_ports deve essere *di per sé* un pattern corretto.
Quel che mi sfugge ora è la deriva che ha preso il thread :-O


 Quel che mi sfugge ora è la deriva che ha preso il thread :-O
Facile. Ognuno ha spento il cervello, si è intestardito sulle proprie
convinzioni per quanto sbagliate, non ragiona e fa riferimento a 
thread vecchi che parlano di tutt'altro argomento. 

 thread vecchi che parlano di tutt'altro argomento.
Per quel che mi riguarda, la "deriva" e' (o meglio era) molto semplice:
- io sostengo che una variabile definita nella shell va obbligatoriamente 
esportata se si vuole che un qualunque programma lanciato da quella shell la 
possa vedere, dove per "vedere" intendo "vedere la variabile 
nell'environment", non "vedere il suo valore sostituito dalla shell". Ma 
forse e' una distinzione troppo complicata per alcune persone.
- il coglione si e' impuntato dicendo che non e' vero, e' vero solo per awk, 
e altre cazzate che non stanno ne' in cielo ne' in terra, portando esempi 
SBAGLIATI che non spiegano niente, e dimostrando con le sue riposte (o 
meglio non-risposte) che non ha la piu' pallida idea di cosa stavo parlando; 
non solo quello, ma si ostina a non volerlo capire (e d'altronde altrimenti 
non sarebbe coglione).
- unica conclusione possibile e': plonk, visto che ogni parola e' tempo 
perso. L'unica cosa che mi dispiace e' che ci potrebbero essere dei lettori 
che poi leggono le minchiate e recepiscono l'informazione sbagliata.
Se qualcuno e' interessato, qui c'e' una spiegazione (una tra le centinaia 
che vengono fuori con google):
http://www.fnal.gov/docs/UNIX/unix_at_fermilab/htmldoc/rev1997/uatf-62.html

 richiede l'export, anche nella stessa shell.
Con awk è la stessa identica cosa degli altri programmi, non è magico:
~> ciccio=123 # senza fare export
~> awk "BEGIN { print $ciccio }" </dev/null
123
~>
Perchè in questo modo è la shell che espande la variabile, non awk, nè
sed, nè altro.
Se invece usi i singoli apici la shell non espande più la variabile e
il giochino non funziona più.

 echo massimiliano | sed -e s/massimiliano/"$a"/
  Max, la riga di comando che scrivi, prima di essere vista dal comando, sed
in questo caso, è analizzata (o parsata, se ti piace) dalla shell che sta
raccogliendo il tuo input da tastiera.  È la shell che vede i caratteri "$a"
e che gli sostituisce il contenuto della variabile "a", non sed.  Quando sed
va in esecuzione, vede direttamente il valore che contiene la viariabile,
non vede la variabile, non può sapere che il dato su cui lavora era il
contenuto di una variabile!
  Se infatti fai:
$ a=ABC
$ echo sed -e s/massimiliano/"$a"/
vedi quello che la shell manda in effetti in esecuzione:
sed -e s/massimiliano/ABC/
  Ma se invece dici a, ad esempio, awk di leggersi la variabile di nome "a",
e non permetti alla shell di farne l'espansione *prima* che questa mandi in
esecuzione awk, questo comando la variabile "a" non la vede se non è esportata:
$ awk 'BEGIN {print ENVIRON["a"]}'
$
  Questo perché va in esecuzione questo:
$ echo awk 'BEGIN {print ENVIRON["a"]}'
awk BEGIN {print ENVIRON["a"]}
  Vedi che awk si deve leggere la variabile "a", che non è stata espansa
dalla shell.  E infatti non la vede.  Ma se la esporti invece la vede:
$ export a
$ awk 'BEGIN {print ENVIRON["a"]}'
ABC
$
  Un'alternativa è di passare il valore della variabile "a" ad awk sulla
riga di comando senza esportarla:
$ unset a
$ a=ABC
$ awk -v a="$a" 'BEGIN {print a}'
  Quello che va in esecuzione è infatti questo:
$ echo awk -v a="$a" 'BEGIN {print a}'
awk -v a=ABC BEGIN {print a}
  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.
Chiave PGP/GPG: EC885A8B

 nell'environment", non "vedere il suo valore sostituito dalla shell". 
Questo è pacifico e sacrosanto.


 Questo � pacifico e sacrosanto.
Eh, prova a spiegarlo a certa gente.

 il giochino non funziona pi�.
Ma va! E lo sai 2+2 fa 4?


 SBAGLIATI che non spiegano niente,
non � che il tuo esempio sia stato molto pi� brillante, eh:
$ echo massimiliano | sed 's/massimiliano/$a/'
... sta roba l'hai scritta tu, non io.
Quindi, finiamola con 'sta prosopopea che non � proprio il caso.



non so che dire.
Premetto che la risposta al quesito non è mai arrivata. E slla fine 
nessuna tra le direttive suggerita sembri funzionare. Tuttavia, io non 
ho emesso fattura, per cui non prentendo che qualcuno debba per forza 
rispondere.
Però, da un'altra parte, assisto a una sfilata di maestrine che si 
mettono in bella mostra: c'è gente che cerca persino di spiegare come 
funzionano gli apici... pensa te.... va buo'...
Io, facendo dei test da linea di comando, ho commesso l'errore di non 
esportare la variabile. Da lì è nato il putiferio, l'offesa e il plonk.


 Ma va! E lo sai 2+2 fa 4?
  Che la riga di comando sia analizzata dalla shell prima di essere
mandata in esecuzione (con tanto di tilde expansion, parameter e
variable expansion, arithmetic expansion, command substitution, process
substitution, e quote removal) lo capiscono tutti tranne te.


 femminile "beauty"? :-)
  "beauty" è sostantivo: 
http://dictionary.reference.com/browse/beauty


 mandata in esecuzione
Scusa: mi spieghi cosa c'entra questo che dici con l'affermazione 
sull'uso degli apici singoli? Esiste un nesso?


    "beauty" è sostantivo: 
http://dictionary.reference.com/browse/beauty
VA BENE (miiinchia): l'aggettivo è beautiful... comunque la discussione 
era imperniata su un'altra questione.
Ho detto a quel demente che in italiano, il genere dell'aggettivo viene 
stabilito, in base al sostantivo al quale l'aggettivo stesso si riferisce.
Al che l'idiota mi dice che questo è vero per l'inglese, ma che non è 
vero per l'italiano. Ma si può perdere tempo a discutere con simili idioti?
In inglese l'aggettivo non ha alcun genere: beautiful girl, beautiful 
boy. Mentre in italiano diventa: bel ragazzo, bella ragazza.



Ma soprattutto: tutte queste risposte in stila maestrina, hanno un nesso 
con la richiesta del post iniziale?
Dato che DOPO aver commesso l'errore di non esportare (per tutti i 
motivi che siete stati bravissimi a spiegarmi), se qualcuno avesse 
risposte inerenti il topic, si faccia sentire altrimenti "vaffanculo". 
Non ti sto dicendo vaffanculo a te... OK?)
Vaffanculo, perch� con il senno di poi son tutti bravi a ripetere sempre 
la stessa cosa. Peccato che invece nessuno sia bravo a rispondere al 
quesito posto.


 quesito posto.
Ormai mi sono perso fra insulti e controinsulti, tu 6 stupido, no 6 +
stupido tu, etc etc etc ...
Se ha ancora una qualche rilevanza pratica e/o teorica, potresti -
magari in nuovo thread, che questo e` marcio -
riesporre brevemente il problema (e/o poi e comunque andarlo a postare
anche in comp.unix.shell)?
Andrea

 anche in comp.unix.shell)?
seguo il tuo consiglio.


 Anche in questo caso N-O-N � necessario fare export.
Stai confondendo variabili d'ambiente con variabili di shell.
Esempio:
$ pippo=1
$ set | grep pippo
pippo=1
Invece
$ env | grep pippo
mostra nulla.
pippo � una variabile di shell.
$ printf "2 - 1 = %d\n" $pippo
Restituisce:
2 - 1 = 1
In realt� printf niente sa di $pippo, neanche la vede la variabile, la 
sostituzione della medesima viene eseguita in fase di parsing della 
linea di comando da parte della shell e prima di eseguire printf per 
cui, dal punto di vista di printf, � come se tu avessi scritto:
$ printf "2 - 1 = %d\n" 1
Altro esempio.
$ export pluto=2
$ set | grep pluto
pluto=2
$ env | grep pluto
pluto=2
Pluto � variabile d'ambiente e anche di shell.
Ora, tornando alla tua domanda iniziale,
$ cat /etc/passwd|awk '{print ENVIRON["pippo"]}'
ti stampa delle righe vuote, mentre
$ cat /etc/passwd|awk '{print ENVIRON["pluto"]}'
ti stampa un sacco di 2.
Perch�? Per il semplice motivo che tu hai chiesto a awk di andare a 
recuperare pippo e pluto *fra le variabili d'ambiente*. La prima non 
c'�, la seconda s�.
Se invece scrivi:
$ cat /etc/passwd|awk "{print $pippo}"
ecco che ti stampa un sacco di 1, ma solo perch� quando i parametri 
arrivano ad awk, sono stati gi� tradotti dalla shell in questo modo:
"{print 1}"
Chiaro ora?

 sull'uso degli apici singoli? Esiste un nesso?
  Così come la shell effettua la sostituzione della variabile con il suo
contenuto quando il nome della variabile è preceduta dal dollaro, così è
sempre la shell che interpreta gli apici, singoli o doppi, sulla riga di
comando.


 con la richiesta del post iniziale?
  Hanno a che fare con il tuo messaggio
<l6ol47-...@yasna.homelinux.doma> delle 18:24 in cui hai scritto:
«allora awk molla la shell completamente.» e successivi in cui hai
reiterato lo stesso concetto.  awk si conporta nella stessa maniera di
sed come di qualsiasi altro comando su riga di comando. È la shell che
ha effettuato la sostituzione della variabile, non awk, nell'esempio che
antani ha esposto.


 comando.
mi pare OLTREMODO chiaro che se faccio "perl -e", sar� perl ha 
intepretare gli apici secondo la sua sintassi. Cos� come � chiaro che se 
lo lancio da bash sar� la bash a interpretare gli apici secondo la sua 
sintassi.
E' chiaro che *non* � la variabile in se che contiene gli apici o meno.
Tu mi stai spiegando come funzionano gli apici singoli in bash. Libero 
di continuare. Magari per qualcun altro che legge potr� essere di 
qualche utilit�.
Il discorso � oltremodo chiaro: se non faccio "export" la variabile 
resta ancorata alla shell, ma non viene mostrata tramite il comando 
"env". Quindi, il programma che dovesse cercare la variabil� come 
environment non la troverebbe
Dobbiamo continuare ancora con 'sta menata?


 �allora awk molla la shell completamente.�
  ______________________________________
/ Va bene. Chiarissimo. Ora, se ti va, \
\ passiamo al resto del problema.      /
  --------------------------------------
         \   ^__^
          \  (oo)\_______
             (__)\       )\/\
                 ||----w |


 environment non la troverebbe
Prego, eh.


grazie :-)))
sono una persona riconoscentissima.



 _________________________________
< Prego, dopo di Lei, cavaGliere! >
 ---------------------------------
        \   ^__^
         \  (ºº)\_______
            (__)\       )\/\
             V ||----w |


 Per quel che mi riguarda, la "deriva" e' (o meglio era) molto semplice:
]zac[
Per quanto mi riguarda (ma credo anche per quanto riguarda anche le regole 
dei news-group e quella cosa ormai vecchissima e ammuffita chiamasi buona 
educazione e cortesia), max adamo fa solo il suo '''lavoro''', mentre quello 
da biasimare e mettere in ingore sei tu (e altri nella stessa situazione), 
primo perch� usi toni inutilmente pesanti e insultanti, secondo perch� sei 
tu (e gli altri nella stessa situazione) che alimentate il flame/trollata.
Se non fosse per te (e per gli altri), questi thread durerebbero pochissimo, 
e potrebbero avere un minimo di utilit�.

 pochissimo, e potrebbero avere un minimo di utilità.
Sono d'accordo; quando mi sono reso conto del mio errore ho preso 
provvedimenti (e, a posteriori, dico anche che avrei dovuto farlo prima). 
Mi piacerebbe (o forse e' piu' corretto dire "mi sarebbe piaciuto") vedere 
questo tuo commento, con gli stessi toni moralizzatori, anche in tutti gli 
altri thread inutili (e anche piu' lunghi di questo, e anche piu' OT) che ci 
sono stati negli ultimi tempi. Pero' non mi pare di avere letto nulla di tuo 
al riguardo.

 e potrebbero avere un minimo di utilit�.
Scusate l'intromissione ma direi che ha avuto una pazienza encomiabile:
infatti ha cominciato a irritarsi (lievemente) alla quinta risposta;
risposte, peraltro, precise e corredate da esempi.

 questo tuo commento, con gli stessi toni moralizzatori, anche in tutti gli
]zac[
Tanto per pignoleggiare e chiarire (se liberissimo di rispondere, ma non ci 
saranno altre mie risposte):
- Mi bastano i miei nipoti che ogni volta che li '''sgridi''' ribattono con 
'e lui niente?', 'ha incominciato lui', 'lo fanno tutti'.
- E' difficile dire certe cose senza che sembrino delle tirate.
- Non ritengono di nessuna utilit� e nemmeneno di esserne in grado, di fare 
il guardiano di tutti.
- Ritengo insensato ribattere ad ogni post thread che mi infastidsce, e 
faccio quel che posso per non farlo.
- Tendo a scrivere certe tirate in risposta a chi, a intuito, mi sembra che 
sia una persona sufficentemente 'aperta' per accettare la tirata nel verso 
giusto.
- Evito pi� che posso di scrivere certe tirate ai rototrolloflammatori at 
simili, non avrebbero altro effetto che alimentare la flammata.

 pochissimo, e potrebbero avere un minimo di utilità.
Scusa ma quale utilità può avere un thread dove ti prospettano 
la soluzione e tu la rifiuti. 

 risposte, peraltro, precise e corredate da esempi.
Quale intromissione?
Posso invitarti a leggere bene i consigli di comportamento nei news-group?
Il consiglio di evitare tassativamente di dare risposte pesanti, insultati, 
ecc., sono regole che seguono semplimente la logica, cio� che sbaglia e fa 
molto pi� danno chi alimenta la fiammata di chi ci mette il fiammifero.
Poi chi prova a far partire le fiammate fa semplicemnte il suo mestiere, che 
infastidirebbe poco e niente se non venisse ampiamente sostenute.
In sintesi, l'unico modo che abbia senso in un news-group (e in altro luogo 
pubblico) di perdere la pazienza � quello di smettere di rispondere e/o 
leggere (e al dire il vero � anche il modo pi� perfido di comportarsi con un 
rotrolloflammatore).

 simili, non avrebbero altro effetto che alimentare la flammata.
Su questo sono d'accordo. Il problema e' che spesso i rototrolloflammatori 
non ce l'hanno scritto in faccia che sono tali, e capita quindi che passino 
un po' di post prima di accorgersene. Non sto dicendo questo per 
giustificarmi, dico solo che capita.

 la soluzione e tu la rifiuti.
Qual'� la cosa pi� importante di un news-group?

 Qual'è la cosa più importante di un news-group?
Se vuoi fare il moderatore del gruppo accomodati. Ricordati di postare il
manifesto del gruppo almeno una volta al mese.


come da consiglio ricevuto, ho aperto un nuovo thread... qui � diventato 
un macello incredibile.



uff... mi da noia dover rispondere a chi non mi legge.
Sia chiaro agli altri che leggono che quella soluzione *non* funziona.
Per questo ho aperto un altro thread, e per questo stiamo discutendo 
nuovamente la questione.


 educazione e cortesia), max adamo fa solo il suo '''lavoro''',
non dissento e non assento. Non avrebbe fra l'altro senso mettermi a 
giudizio e discutere su me stesso.
Mi pu� dar fastidio certa prosopopea, poich� se ciascuno avesse un 
minimo di onest�, e prendesse un metro per misurare se stesso, ti 
accorgeresti coem questa prosopopea, come per incanto, svanirebbe 
all'istante.
L'assunto � che ho posto un quesito su un tema, che secondo la media 
della difficolt� della materia informatica, sono, se non banali, diciamo 
di natura *non* esoterica (io direi: mezze cazzate).
Se mi si deve fare il "pippone" perch� non ho ben inteso il 
funzionamento dell'ancoraggio della variabile alla shell, con la unica 
finalit� di voler mettere in mostra se stessi, la cosa mi da un tantino 
fastidio.
si discuteva d'altro e - SEMPLICEMENTE - la differenza tra variabile 
ancorata alla shell, e "envinronment" mi sfuggiva ... fino alla fine.
Posto questo, questi luoghi, oltre che strumento per imparare (sigh: e 
diffondere saccenteria?), sono anche luoghi, dove in senso lato, si 
impara pure a vivere.
Non mi dilungo oltre e sintetizzo il tutto con una semplice 
affermazione: ho conosciuto Thorin e posso affermare in tutta franchezza 
che � una specie di psicopatico sociale.
Quella persona � - a mio avviso - l'esempio preciso di come ciascuna 
persone dovrebbe evitare di comportarsi.
Vedo per� che alcuni tendono invece in quella direzione.


 come da consiglio ricevuto, ho aperto un nuovo thread
Giustamente, non essendoti bastato, hai ben pensato di duplicare la 
rottura di cazzo.


uff ... l'altro thread si è chiuso (con soluzione) dopo appena 3 messaggi.


 fastidio.
Qui nessuno tira "pipponi", hai scritto un'affermazione infondata e
qualcuno, seguendo lo spirito che dovrebbe animare i ng, si è
prodigato per cercare di farti capire dove sbagliavi.
Se la cosa ti infastidisce pazienza, io invece avrei ringraziato, ma
non siamo fatti tutti allo stesso modo. Certo è che se, a chi cerca di
spiegarti dove sbagli, rispondi stizzito di non fare la maestrina...
bè, a me personalmente la voglia di impiegare il mio tempo per
risolvere un tuo problema passa in fretta; e se a qualcuno è scappato
anche il plonk, non mi meraviglia più di tanto.

 Se la cosa ti infastidisce pazienza, io invece avrei ringraziato,
Io ringrazio sempre e comunque (forse puoi ancora leggere il messaggio 
dove ho ringraziato Antani, nonostante lui mi avesse gi� plonkato).


 mi sta benissimo.
Comunque, io non sto usando il comando "sudo" (*) pertanto ognuno faccia 
quel che gli pare. L'importante � rispettare il prossimo.
(*) fatti du risate:
http://maxadamo.dyndns.org/joomla/index.php?option=com_content&task=view&id=9&Itemid=23


 ...
Il link non funziona.


hai provato ieri mentre facevo le prove di clonezilla :-)
riprova adesso o in qualsiasi momento.
