[Newbie] Augmentation du volume où se trouve /var

Chris a écrit...

D'abord uname -a pour que l'on puisse connaitre l'unix en question
et sa version.
Cette commmande me retourne:

'HP-UX' suivi du nom de la machine et plein d'autres trucs dont je
ne pense pas que ce soit utile de préciser (si besoin, fais le moi
savoir)

D'après les infos que j'ai, c'est une station HP Visualize C3600 qui
tourne sous HP-UX 10.20
C'est un debut, note : dans ce ng c'est plus simple de commencer par

dire : un HP-UX 10.20B me fait des miseres, AIX 4.3 cherche la bagarre
SCO 5.05 pete les plomb bref de commencer par annoncer la couleur de
l'unix.

Bien compris! Mais je ne pensais pas qu'il existait autant d'Unix
différents,
et qu'ils ne se ressemblaient pas à ce point.

Sinon sur HP-UX 10.20 /var est plein et cette machine est orpheline
en cas d'urgence absolu :

trouver un repertoire ou il y a un peu de place, noter le path et
creer
un repertoire temporaire ( ex: /u1/sauve )
dans ce repertoire copier les fichiers se trouvant dans /var/tmp
/var/spool/cron/tmp /var/mail
cela peut permettre de gagner de la place ...

mais si cette manip te semble trop hasardeuse tu peux appeller le
service HP ou ton revendeur

Euh ouais, je vais laisser tomber. Pas envie de gaffer finalement.
Les responsables feront leur boulot en rentrant de vacances.
Merci de ton aide Chris,

--
Zephyro

-= Being able to listen is first of all sharing the same vision =-

Zephyro wrote:

Au pire, il suffit de retourner le clavier, c'est écrit dessous (ça
m'a surpris moi aussi la première fois...)

Un peu comme Terminator avec les clés de voiture sur le pare-soleil...

--
Don't let your status become too quo!

Erwann ABALEA <erwann@abalea.com> writes:

Un dernier conseil: si tu n'es pas l'administrateur de cette machine,
évite de faire quoi que ce soit, même si les responsables ne sont pas là
et qu'elle va planter et qu'elle est vitale. Si tu foires quelque chose,
on ne saura pas forcément mettre en balance le fait que les responsables
n'ont pas fait leur boulot, et tu t'en prendras plein la g***le, sans
compter que tu n'auras pas forcément résolu le problème.

Bah! Y-a toujours moyen de s'en sortir grâce à ce petit système expert:

-------------------(lti)------------------------------------------------
#!/bin/bash
trap "echo 'Fin de la session; le système expert vous remercie.';echo ''" 0
fmt <<EOF

SYSTÈME EXPERT DE TRAITEMENT DES INCIDENTS


Nous mettons à votre disposition ce système expert de
traitement des incidents. Comme toute intelligence artificielle, il
possède un sens de l'humour, disons, artificiel.

En espèrant qu'il puisse vous être utile pour
résoudre vos problèmes, voici :

---------------------------------------------------------

EOF


function demande () {
local commentaire="$1"
shift
local question="$1"
shift
state=""
while [ -z "$state" ] ; do
echo "Le système expert de traitement des incidents dit:"
echo ""
echo " $commentaire" | fmt
echo " $question" | fmt
if [ $# -eq 0 ] ; then
state=final
else
echo -n " > " ; read reponse
case "$reponse" in
[Oo]*) state=$1 ;;
[Nn]*) state=$2 ;;
*) echo " Ben, on n'est pas aidé! Répondez par oui ou par non!"
esac
fi
echo ""
done
echo "---------------------------------------------------------"
echo ""
}


state=initial
while [ $state != final ] ; do
case $state in
initial) demande "" "Est-ce que ce foutu machin fonctionne ?" o n ;;
n) demande "" "L'avez vous tripoté ?" no nn ;;
n3) demande "" "Voulez vous vraiment tenter le diable ?" n3o n4 ;;
n3o) demande "" "Pouvez vous sans risque dénoncer le coupable ?" nno n3on ;;
n3) demande "" "Est-ce que ça peut être réparé avant que le boss ne s'en aperçoive ?" no3 noon ;;
n4) demande "Foutez le à la poubelle !" ;;
nn) demande "" "Est-ce que l'un de vos subordonnés l'a tripoté ?" nno n3 ;;
nno) demande "Faites plonger le connard !" "Est-ce que ça peut être réparé avant que le boss ne s'en aperçoive ?" no3 noon ;;
no) demande "Pauvre andouille !" "Est-ce que quelqu'un sait que vous l'avez tripoté ?" noo non ;;
no3) demande "Vous avez de la chance ; réparez le vite!" "Fin de la session; le système expert vous remercie." ;;
non) demande "Surtout, fermez la !" ;;
noo) demande "Vous êtes encore plus bête que je le pensais !" "Est-ce que ça peut être réparé avant que le boss ne s'en aperçoive ?" no3 noon ;;
noon) demande "Vous êtes vraiment dans la merde !" "Voulez vous démissionner ?" noono noonn ;;
noonn) demande "Vous êtes viré !" ;;
noono) demande "Démissionnez !" ;;
o) demande "Surtout n'y touchez plus !" ;;
*) echo ERREUR INTERNE ; exit 1 ;;
esac
done

#### lti.sh -- 2004-01-18 00:58:10 -- pascal ####
------------------------------------------------------------------------


--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

2004-01-18, 00:59(+01), Pascal Bourguignon:
[...]

function demande () {
[...]

Juste une remarque.

"function" ne sert à rien en bash.
Il a été rajouté pour "compatibilité" (de syntaxe seulement)
avec ksh, mais si tu veux utiliser la syntaxe ksh, c'est

function demande {
# sans ()

La syntaxe Bourne, POSIX et portable, c'est:

demande() {
# sans "function"

local commentaire="$1"

Ici, les quotes ne sont pas nécessaires.
(note que "local" est bash/zsh specifique, il ne manque pas
grand chose pour que ton script soit portable).

[...]

if [ $# -eq 0 ] ; then

Là, elles seraient préférables (même s'il y a peu de chance que
$# contiennent des caractères qui soient dans IFS, ou des
wildcards, il n'en demeure pas moins, que sémantiquement, ce
n'est pas correct, ($# non-quoté est une liste (IFS separated)
de fichiers)).

[...]

echo -n " > " ; read reponse

Tant qu'à être bash-specifique, tu peux utiliser l'option "-p"
de read. "echo -n" n'est pas plus portable.

[...]

while [ $state != final ] ; do

Même remarque au niveau du quotage.

--
Stéphane ["Stephane.Chazelas" arobase "free.fr"]

Le Sun, 18 Jan 2004 15:16:03 +0100, Stephane nous disait:

echo -n " > " ; read reponse

Tant qu'à être bash-specifique, tu peux utiliser l'option "-p"
de read. "echo -n" n'est pas plus portable.

[...]

while [ $state != final ] ; do

Même remarque au niveau du quotage.

Si je puis me permettre un petit bug-report, certaines séquences de
réponses font apparaître _deux fois_ la phrase de conclusion "Fin de la
session; le système expert vous remercie.". Par exemple la séquence
"non", "oui", "oui", "oui".

--
Tinou

Stephane Chazelas <cette.adresse@est.invalid> writes:

2004-01-18, 00:59(+01), Pascal Bourguignon:
[...]

function demande () {
[...]

Juste une remarque.

"function" ne sert à rien en bash.
Il a été rajouté pour "compatibilité" (de syntaxe seulement)
avec ksh, mais si tu veux utiliser la syntaxe ksh, c'est

function demande {
# sans ()

La syntaxe Bourne, POSIX et portable, c'est:

demande() {
# sans "function"

Peut être qu'elle ne sert à rien pour bash, mais à moi elle me sert
assez, pour bien voir le début de mes fonction, et pour homogenéïser
la syntaxe avec d'autres langages que je connais.

local commentaire="$1"

Ici, les quotes ne sont pas nécessaires.
(note que "local" est bash/zsh specifique, il ne manque pas
grand chose pour que ton script soit portable).

Si, si, elles sont trés nécessaires:

[pascal@thalassa pascal]$ function f() { for f in $1 ; do echo $f ; done ; }
[pascal@thalassa pascal]$ f "a b c"
a
b
c

Si je devrais ne pas mettre les quotes pour un local, je devrais
allouer un petit paquet de neurones pour mémoriser une règle
arbitraire suplémentaire.

[...]

if [ $# -eq 0 ] ; then

Là, elles seraient préférables (même s'il y a peu de chance que
$# contiennent des caractères qui soient dans IFS, ou des
wildcards, il n'en demeure pas moins, que sémantiquement, ce
n'est pas correct, ($# non-quoté est une liste (IFS separated)
de fichiers)).

[pascal@thalassa pascal]$ cat /tmp/s
#!/bin/bash
echo "IFS=$IFS"
[pascal@thalassa pascal]$ IFS=x /tmp/s
IFS=

IFS n'est pas hérité comme une varible d'environnement normale. Si mon
programme n'y met pas de chiffre, je suis sur que $# ne comportera
qu'un seul mot.

[...]

echo -n " > " ; read reponse

Tant qu'à être bash-specifique, tu peux utiliser l'option "-p"
de read. "echo -n" n'est pas plus portable.

[...]

while [ $state != final ] ; do

Même remarque au niveau du quotage.

Même chose ici. Mon programme ne met qu'un seul mot dans la variable
state, ipso facto, la variable state ne contient qu'un seul mot.

Peut être pourrais tu râler qu'il n'y a pas assez d'assertion qui
explicite tout ces invariants, mais ce n'est pas ma faute si le
langage bash n'a pas la richesse d'Eiffel.


--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

Étienne Labaume <eltinou@free.fr> writes:

Le Sun, 18 Jan 2004 15:16:03 +0100, Stephane nous disait:

echo -n " > " ; read reponse

Tant qu'à être bash-specifique, tu peux utiliser l'option "-p"
de read. "echo -n" n'est pas plus portable.

[...]

while [ $state != final ] ; do

Même remarque au niveau du quotage.

Si je puis me permettre un petit bug-report, certaines séquences de
réponses font apparaître _deux fois_ la phrase de conclusion "Fin de la
session; le système expert vous remercie.". Par exemple la séquence
"non", "oui", "oui", "oui".

Effectivement, il faut enlever le deuxième message de la ligne no3:

no3) demande "Vous avez de la chance ; réparez le vite!" ;;


Ceci dit, c'est pas trop mal: une seule bogue sur un programme de 60 lignes.

Chez IBM, ils ont réussi à avoir trois bogues sur un programme d'une
seule instruction assembleur.
Voir IEFBR14: http://catless.ncl.ac.uk/Risks/6.14.html

--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

2004-01-25, 02:40(+01), Pascal Bourguignon:
[...]

La syntaxe Bourne, POSIX et portable, c'est:

demande() {
# sans "function"

Peut être qu'elle ne sert à rien pour bash, mais à moi elle me sert
assez, pour bien voir le début de mes fonction, et pour homogenéïser
la syntaxe avec d'autres langages que je connais.
[...]

C'est une affaire de gout après. Seulement, ici, j'éviterais de
promouvoir une syntaxe non standard (la syntaxe d'aucun shell,
juste la syntaxe de awk).

local commentaire="$1"

Ici, les quotes ne sont pas nécessaires.
(note que "local" est bash/zsh specifique, il ne manque pas
grand chose pour que ton script soit portable).

Si, si, elles sont trés nécessaires:

[pascal@thalassa pascal]$ function f() { for f in $1 ; do echo $f ; done ; }
[pascal@thalassa pascal]$ f "a b c"
a
b
c

Il y a assez peu d'endroits où elles ne sont pas nécessaires,
très peu où on ne doit pas les mettre. C'est pas compliqué, en
gros c'est là où le "word splitting" n'a pas de sens.

Elles ne sont pas nécessaires:
- dans les assignments a=$var
- dans case $var in
- à l'intérieur des [[ ]] (sauf à droite de = ou ==)
- à l'intérieur des $(( )), (( ))
- après les opérateurs de redirection sauf pour bash.

Partout ailleurs il faut mettre des quotes sauf si on veut
explicitement du "word splitting" et de la filename generation.

Par exemple dans ton exemple, si dans le répertoire courant il y
a les fichiers "ab", "a a*", "ba"

Et que tu fais: f 'a* b*', tu auras:
a a a* ab
ab
ba

(word splitting et filename generation au niveau de "$1" et de "$f").

Tout ça ne s'applique pas à zsh bien sûr.

[...]

if [ $# -eq 0 ] ; then

Là, elles seraient préférables (même s'il y a peu de chance que
$# contiennent des caractères qui soient dans IFS, ou des
wildcards, il n'en demeure pas moins, que sémantiquement, ce
n'est pas correct, ($# non-quoté est une liste (IFS separated)
de fichiers)).

[pascal@thalassa pascal]$ cat /tmp/s
#!/bin/bash
echo "IFS=$IFS"
[pascal@thalassa pascal]$ IFS=x /tmp/s
IFS=

IFS n'est pas hérité comme une varible d'environnement normale. Si mon
programme n'y met pas de chiffre, je suis sur que $# ne comportera
qu'un seul mot.

Tu es sûr ? Et si toi ou quelqu'un d'autre va plus tard modifier
ce script, ou copier-coller ces lignes de code dans un autre
contexte ? Il faut que tu te poses la question à chaque fois...
Le plus simple est de mettre des quotes là où on ne veut pas de
word splitting ou de filename generation (plus de question à ce
poser).

$ echo 'IFS=x' > /tmp/s
$ BASH_ENV=/tmp/s bash -c 'echo "$IFS"'
x

(mais le problème ne se pose que si quelqu'un veut
intentionnellement faire planter le script, ici).

--
Stéphane ["Stephane.Chazelas" arobase "free.fr"]

Stephane Chazelas <cette.adresse@est.invalid> writes:

Il y a assez peu d'endroits où elles ne sont pas nécessaires,
très peu où on ne doit pas les mettre. C'est pas compliqué, en
gros c'est là où le "word splitting" n'a pas de sens.

Elles ne sont pas nécessaires:
- dans les assignments a=$var
- dans case $var in
- à l'intérieur des [[ ]] (sauf à droite de = ou ==)
- à l'intérieur des $(( )), (( ))
- après les opérateurs de redirection sauf pour bash.

Partout ailleurs il faut mettre des quotes sauf si on veut
explicitement du "word splitting" et de la filename generation.

Donc, une règle bien compliquée, avec 5 items différents à retenir,
contre: mettre des quotes partout. Avec comme exception parce qu'on
est faignant: sauf si on est sûr (par déduction logique sur les
pré/post-conditions) que la variable ne contient qu'un seul mot.


Il me semble que dans $(( )), les quotes restent importantes:

[pascal@thalassa pascal]$ a="1 + 2"
[pascal@thalassa pascal]$ echo $(( $a ))
3
[pascal@thalassa pascal]$ echo $(( "$a" ))
-bash: "1 + 2" : syntax error: operand expected (error token is ""1 + 2" ")

(Bon d'accord, comme on ne peut qu'avoir des nombres comme opérande
dans $(()), il est important de ne pas mettre de quotes dans $(())).

Et pour rigoler un peu:

[pascal@thalassa pascal]$ IFS=2 a="123" ; echo $(( $a + $a ))
46
[pascal@thalassa pascal]$ IFS=2 a="123" ; echo $(( "$a" + "$a" ))
-bash: "123" + "123" : syntax error: operand expected (error token is ""123" + "123" ")

[pascal@thalassa pascal]$ cat /tmp/s
#!/bin/bash
echo "IFS=$IFS"
[pascal@thalassa pascal]$ IFS=x /tmp/s
IFS=

IFS n'est pas hérité comme une varible d'environnement normale. Si mon
programme n'y met pas de chiffre, je suis sur que $# ne comportera
qu'un seul mot.

Tu es sûr ? Et si toi ou quelqu'un d'autre va plus tard modifier
ce script, ou copier-coller ces lignes de code dans un autre
contexte ? Il faut que tu te poses la question à chaque fois...
Le plus simple est de mettre des quotes là où on ne veut pas de
word splitting ou de filename generation (plus de question à ce
poser).

Personnellement, j'ai perdu tout espoir de faire du "shell" modulaire
et réutilisable. Et je suis même passé par du shell "orienté objet",
c'est dire que je me suis posé la question... Si je veux faire un
module qui doit être maintenu, modifié, réutilisé ou copié-collé, ce
sera en Lisp.

$ echo 'IFS=x' > /tmp/s
$ BASH_ENV=/tmp/s bash -c 'echo "$IFS"'
x

(mais le problème ne se pose que si quelqu'un veut
intentionnellement faire planter le script, ici).

D'accord! :-)

Bin la prochaine fois, je posterais un programme compilé!

--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

2004-01-25, 13:15(+01), Pascal Bourguignon:
[...]

Partout ailleurs il faut mettre des quotes sauf si on veut
explicitement du "word splitting" et de la filename generation.

Donc, une règle bien compliquée, avec 5 items différents à retenir,
contre: mettre des quotes partout. Avec comme exception parce qu'on
est faignant: sauf si on est sûr (par déduction logique sur les
pré/post-conditions) que la variable ne contient qu'un seul mot.
[...]

Non, une seule règle : mettre des quotes partout, sauf quand une
variable doit etre considérée comme l'expression d'une liste de
fichiers (par un jeu de découpage et de wildcards).

Je voulais juste dire que tu en avais mis là où ce n'était pas
nécessaire alors que tu les avais oubliées aux autres endroits.

Il me semble que dans $(( )), les quotes restent importantes:

Oui, mettre des quotes dans $(( ... )) ne fait pas de sens. On
pourrait croire qu'il est inutile d'en mettre autour
("$((...))"), ce n'est pas le cas avec bash, ksh93 et les shells
des *BSDs...

Elles sont génantes quand:
- on veut du word splitting et/ou de la filename generation
(jouer avec IFS et set -f pour avoir que l'un ou que l'autre)
- quand on veut que les variables vides soient considérées comme
"pas d'argument" plutôt qu'un argument vide
- Quand on veut qu'une variable soit considérée comme un pattern
([[ foo = "$var" ]], case foo in "$var") ...)
Genre var='[a]' [[ $var = $var ]] est faux, [[ $var = "$var"
]] et [[ a = $var ]] sont vrais.
- Autour des `...` dans des vieux shells qui ont des problèmes
avec ça (vaut mieux passer par une variable intermédiare
var2=`cmd1 "$var1"`; cmd2 "$var2"
plutôt que :
cmd2 "`cmd1 "$var1"`"

C'est à dire en gros (sauf pour le dernier cas) chaque fois
qu'on ne veut pas qu'elles suppriment l'effet indésirable
qu'elles sont censées pallier.

[...]

Personnellement, j'ai perdu tout espoir de faire du "shell" modulaire
et réutilisable. Et je suis même passé par du shell "orienté objet",
c'est dire que je me suis posé la question... Si je veux faire un
module qui doit être maintenu, modifié, réutilisé ou copié-collé, ce
sera en Lisp.

C'est bien, c'est très bien de le dire, c'est bien de montrer
les limitations des solutions à base de shell. Cela dit, je suis
pas sûr que tu trouveras grand-monde aujourd'hui pour
"maintenir/modifier/reutiliser" du Lisp ;).

--
Stéphane ["Stephane.Chazelas" arobase "free.fr"]