Newsgroup: it.comp.os.linux.iniziare
Titolo: Esercizi in bash

Ciao la NG,
Sto sperimentando qualche manipolazione di files. Quello che non sono
riuscito a capire come un programma possa esportare una variabile in
modo che la prossima volta che viene lanciato sia possibile
utilizzarla. Ad esempio PATH e HOME son viariabili di sistema che
possono esser riutilizzate frequentemente.
Questa operazione serve per utilizzare un contatore che si incrementa
ogni volta che il programma riviene lanciato, visto che compiuta l'
operazione non resta traccia delle variabili interne. Vorrei evitare
di dover scriverlo su disco, visto l' uso ciclico del programmino.
Chi é il mago che mi aiuta?


Il manuale di bash. :-)
O piu' in profondita' ancora.
Ti manca un concetto basilare: quello della ereditarieta' della
shell e dell'ambiente.
Ogni volta che esegui uno script bash, lanci un figlio della shell
corrente, che assimila l'ambiente (variabili), esegue, e poi muore.
Visto che eredita (si copia) l'environment all'avvio, le variabili
che esistevano prima esistono anche nel figlio.
Quelle che crei o modifichi dal figlio muoiono con lui.
L'unica e' convincere il figlio ad eseguirsi nella stessa istanza di
shell.
Cio' si fa con il comando source, che si identifica con un punto.
Se il tuo script si chiama pippo, e contiene la manipolazione della
variabile, ad esempio come questo:
echo $pippo
pippo=`echo $pippo`Ciao
lo devi lanciare cosi':
poggir@proliant:~/prova$ pippo=
poggir@proliant:~/prova$ . ./pippo
poggir@proliant:~/prova$ . ./pippo
Ciao
poggir@proliant:~/prova$ . ./pippo
CiaoCiao
poggir@proliant:~/prova$ . ./pippo
CiaoCiaoCiao
poggir@proliant:~/prova$ . ./pippo
CiaoCiaoCiaoCiao
poggir@proliant:~/prova$ . ./pippo
CiaoCiaoCiaoCiaoCiao
poggir@proliant:~/prova$ . ./pippo
CiaoCiaoCiaoCiaoCiaoCiao
poggir@proliant:~/prova$ . ./pippo
CiaoCiaoCiaoCiaoCiaoCiaoCiao
poggir@proliant:~/prova$ . ./pippo
CiaoCiaoCiaoCiaoCiaoCiaoCiaoCiao
poggir@proliant:~/prova$ . ./pippo
CiaoCiaoCiaoCiaoCiaoCiaoCiaoCiaoCiao
poggir@proliant:~/prova$ . ./pippo
CiaoCiaoCiaoCiaoCiaoCiaoCiaoCiaoCiaoCiao
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 utilizzarla.
non sono sicuro di aver capito, ma credo basti una 
export VARIABILE=valore
ovviamente l' informazione, non essendo salvata su hd, viene persa al
riavvio della macchina
-- 
14/12/2004 | -3 all' alba!

 shell e dell'ambiente.
Il concetto é chiaro anche in ABS, non riesco a chiarire il fatto che
dopo l' avvio ci sono variabili Globali ma poi non se ne possono
aggiungere altre. Ora che mi hai spiegato il fatto, devo accettare la
conseguenza e siccome per la conoscienza che mi sono fatto adotterò un
metodo di dover scriverlo da qualche parte.

 
Purtroppo, export permette alla variabile di esser disponibile durante
la sessione del programma in esecuzione e sottoprogrammi chiamati.
Solo che se il programma esce le variabili svaniscono.
Per quanto riguarda la durata della variabile, ha poco valore di
riprenderla all' avvio. Ammetto che forse posso rivalutare l'
eventuale rischio di disporre o meno che la variabile sia salvata o
meno. Al massimo potrei aggiungere una riga alla procedura di rc.d .

 dopo l' avvio ci sono variabili Globali ma poi non se ne possono
Continua a non esserti chiaro il concetto di ambiente. :-)
Non sono globali, sono semplicemente state definite dalla shell primeva,
quella in cui fai il login.
Ogni altra shell le puo' ereditare, ma non puo' settare le shell dei
genitori, degli zii e dei fratelli.
In compenso, con source, puoi lavorare nella stessa generazione, senza
lanciare una shell figlia, percio' puoi manipolare l'ambiente della
shell di lancio.


 In compenso, con source, puoi lavorare nella stessa generazione
dunque..... Estratto di man bash
source filename [arguments]
 Read and execute commands from filename in the current shell
environment and return the exit status of the last command executed
from filename. If filename does not contain a slash, file names in
PATH are used to find the directory containing filename. The file
searched for in PATH need not be executable. When bash is not in posix
mode, the current directory is searched if no file is found in PATH.
If the sourcepath option to the shopt builtin command is turned off,
the PATH is not searched. If any arguments are supplied, they become
the positional parameters when filename is executed. Otherwise the
positional parameters are unchanged. The return status is the status
of the last command exited within the script (0 if no commands are
executed), and false if filename is not found or cannot be read.
Se il concetto non mi inganna, si può avere un valore di ritorno all'
uscita del 'filename', valore di ritorno di exit o (credo) quello che
da un comando export in esso.
Questo non soddisfa, sfortunatamente, la mia idea. In quanto il
programma potrebbe esser chiamato ora terminato e richiamato tra 1/4
d'ora. Quello che invece apparentemente non succede durante una
sessione se 
p.es
 facciamo rm $HOME/nomefile o cat $HOME/nomefile o
find $HOME/nomefile o echo $PATH.
Ho provato col comando env variabile=" " non sembra abbia efficacia,
data la mia incompletezza di informazione.
Credo che dovrei abbandonare l' idea e procedere alla scrittura su
disco, solo la seccatura della scrittura durante un ciclo loop per un
centinaio di volte non mi é molto simpatica. Forse passo a studiare
come installare un ramdisk.

 Se il concetto non mi inganna, si può avere un valore di ritorno all'
Il concetto ti inganna.  ;-)
O meglio, *quel* concetto non ti inganna, ma e' il concetto sbagliato.


 utilizzarla.
forse salvando su di un file il valore e rileggendolo
quando serve ?
io per avere il 'numero' sequenziale nei cd di backup
faccio cosi`.
VARIABILE=`cat /tmp/contatore`
 e alla fine (dopo averla modificata)
echo $VARIABILE > /tmp/contatore
-- 
mr_dub (______) 
fr (  \ ; ) fs 

 quando serve ?
Nel primo articolo (anche di seguito) avevo parlato di evitare tale
operazione, per il fatto che il programma potrebbe rientrare in una
fase iterativa a periodi brevi. Per questo cercavo risposta.
Ci dovrò studiare ancora un pò

 TheSaint  :

ok, allora scrivi il valore della variabile
su di un file solo quando 'esci' :)
altrimenti vedi risposta di ZeD e
tua risposta ..


 altrimenti vedi risposta di ZeD
Sto ragionandoci :-)
Ora ho anche un diverso problema di gestione di nome files con
spazi :-(. Anche qui sembra che non riesco ad usare in diverso modo la
variabile IPS ( o IFS?)
Dovrò googlare per maggior bibliografia o esempi. Oppure salterò a
REXX :-)
-- 
why do I've to sign here?

 variabile IPS ( o IFS?)
IFS='
' # si' sono andato a capo!
oppure proteggi ogni singolo valore...
VARIABILE="quelchee'"


 VARIABILE="quelchee'"
Ho sperimentato e vale da console root, solo un certo senso.
Ora qui si parla di bash ed eventualmente eseguibile da utente.
Relativamente per movimentare files con i permessi.
Ho fatto uno script che fino al momento che i nomi dei files erano
senza spazi poteva andar bene. In pratica si tratta di spostare file
da diverse fonti ed evitare di sovrascrivere quelli con lo stesso
nome. Inoltre, per mia comodità viene creata una directory per ogni
tipo di estensione del file, se la dir non esiste.
Ora con nomi che contengono spazi mi si impalla al primo processo di
rilevamento argomenti, allora dovrei interagire su IFS per rimuovere
il valore di spazio per non farlo interpretare come separazione degli
argomenti di linea. Al massimo alla fine ripristino i valori di
difetto. Un normale script di bash non ha il potere di farlo, come
pure di poter dare valori a variabili che finito lo script persistano
anche per altri programmi o script.
Pare di capire che lo script bash sia "nipote" di quella che ha il
potere di impostare le variabili globali (???). Qui mi perdo :-)


 argomenti di linea.
e t' ho detto come: imposti l' IFS su "invio", o su quel che vuoi te, e 
dunque NON tratta gli spazi come separatori


 e dunque NON
Ho capito che mi vuoi aiutare, sono io che son duro a capire :-)
So che IFS ha per valore spazio, tabulatore e linea-a-capo, vedo su ABS
come togliere i primi due :-)
Quando mi hai spiegato ho fatto la prova, ma mi é risultato un IFS di 4
spazi (???)


 spazi (???)
ma hai fatto copiaincolla?
boh, capace che i nr abbiano aggiunto quattro spazi
te scrivi sull' editor
IFS='[ACAPO]
'
e vedi che succede


 '
[user@laptop user]$ echo $IFS
[user@laptop user]$ echo \"$IFS\"
" "
Ovvero al primo comando si aspetta di chiudere la stringa e allora lo
chiusa alla riga sotto, ma non ho avuto cambiamenti.
Ultima prova :
$ IFS='
'; echo \"$IFS\"
" "
Rimane 'spazio ;-(


 " "
e' giusto
prova uno script del genere:
[zed@SwordFishII zed]$ cat script.sh
#!/bin/sh
IFS='
'
for i in $@; do
  echo $i
done
[zed@SwordFishII zed]$ . script.sh "ciao mondo" come va "a me" va_bene
ciao mondo
come
va
a me
va_bene


 va_bene
Ma non ha effetto, mi pare. Se fosse IFS cambiato a "a-capo" i campi
degli argomenti sarebbe stato diverso. Eccetto quelli in parentesi.
Addirittura sarebbe dovuto esser uno solo.


 Addirittura sarebbe dovuto esser uno solo.
[zed@SwordFishII zed]$ cat script.sh
#!/bin/sh
IFS='
'
for i in $(ls); do
  echo $i
done
[zed@SwordFishII zed]$ . script.sh
bin/
Desktop/
NGS/
tmp/
chattata.html
fota.jpg
GNU_Linux and DIB.rtf
script.sh
script.sh~
chattata.zip
come vedi ho anche file con spazi (vedi GNU_Linux and DIB.rtf), e vengono
gestiti in modo ottimale 


 
Fermo li! :-)
Ma il trhead non si parla di Bash?
A parte, che diff ci sono? influisce?


 A parte, che diff ci sono? influisce?
 [@vanilla:]~#ls -l /bin/sh
 lrwxrwxrwx    1 root     root    /bin/sh -> bash
-- 
echo 313842486316671647510282P | dc

 Ma il trhead non si parla di Bash?
nel mio caso sh e' un simlink alla bash ^^;;;
per la precisione
GNU bash, version 2.05b.0(1)-release (i586-mandrake-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.


 
Vabbé credo che per implementare il comando dovrò prima virgolettare l'
argomento dalla linea di comando. Poi rimane sempre un pò di casino
per la gestione particolareggiata di questo nome con spazi.
Se volessi mettere una sostituzione di " "=%20, dici che funza e
risponde visivamente allo stesso effetto?


 
A me non c'é > :
ls -l /bin/sh
bash: ls -l /bin/sh: No such file or directory


 bash: ls -l /bin/sh: No such file or directory
guarda che puoi anche crearlo, ne' ;P


 dici che funza e risponde visivamente allo stesso effetto?
mmmm
dici che "ciao mondo" e "ciao=%20mondo" son uguali?
naaaaa


 
Capito, solo che alcuni programmi si avviano con sh, e pare che non ne
subiscono le influenze. Ed il perché sh c' é > :
whereis sh
sh: /bin/sh
Torinèse? :-PP


 
Mio cuggino che usa win vien fuori che appare uno spazio, ma niente
virgolette.
Allora, se io ho scomposto il percorso ed il nome file alla fine del
processo vorrei che il mio script generi una stringa con un percorso
nuovo se necessario e un nuovo nome se il file ove va a finire esiste
già.
Al momento non avevo ancora incontrato il problema perché mi son sempre
capitati nomi senza spazi. In questo frangente son rimasto confuso e
conoscendo che si può manipolare IFS volevo trovarne la soluzione.
Solo che nel tentativo non ho trovato risultati.


 Torinèse? :-PP
figuriamoci, Ije so' dd' BBar!


 capacità (ancora).
te pensa allo script bash come a una sequenza di "righe di comando" e la
cosa e' fatta...


 
Già, infatti prima li provo nella shell :-) e poi li scrivo nello
script. Unica differenza e la separazione dei comandi da punto-virgola
ad a-capo. Manca ancora alcune conoscenze nella trattazione delle
stringe e l' espansione dei comandi.
Approp.. Esiste qualcosa di meno contorto di questo?
# strg= URL file
     strg=${strg:0:(${#strg}-${#file})}
Ovvero non esiste right$(strg,nchar)
Mi sa che ci devo fare una funzioncina :-)


 Mi sa che ci devo fare una funzioncina :-)
mmm
man cut
ma direi anche dirname...
