Problème au source d'une librairie sh

[esprism]

J'ai le problème suivant :

au login, le contenu d'un .sh qui est sourcé dans le .profile passe en ligne de commande.

(sourcé comme suit :
. lib.sh
)

Résultat, le fichier d'historique se remplit et écrase les information précédentes.

supposons que dans le .sh on ai :

#!/bin/sh
ma_fonction(){
moncode
}

Dans le fichier historique on aura :

moncode
}
\202^C\201

Je ne comprend pas ce qui se passe. D'autant plus que j'ai un autre système "sensé" être identique qui ne pose pas de problème. Je n'ai pas encore trouvé la différence entre les deux.

[Alek-C]

Tu as bien un ; à la fin de ta déclaration de fonction ?

http://www.shellunix.com/sh.html

[esprism]

Merci pour cette piste.

Effectivement il n'y a pas de ";" à la fin des fonction, cependant, une fois ajoutés ça ne change rien.

Ce qui m'intrigue le plus, c'est qu'au moment du source, HISTFILE et les autres variables concernant l'historique ne sont pas initialisées (elles le sont à la fin du ".profile" et le source est au début du ".profile").

Si je met "HISTFILE=/dev/null" je peux garder mon historique mais dans ce cas, je n'ai plus d'historique tant que je ne suis pas revenu en bash.

Je n'ai malheureusement pas les connaissances nécessaires pour trouver des pistes par moi même.

[jabbounet]

Envoyé par Alek-C

Tu as bien un ; à la fin de ta déclaration de fonction ?

http://www.shellunix.com/sh.html

tu es en sh??

je ne me souviens pas que sh supporte les fonctions (contrairement à ksh). ou je dit une bêtise.

[Alek-C]

Vu le lien que j'ai mis, il semble bien accepter les fonctions, mais j'avoue ne pas me servir de sh tous les jours

Tu as essayé de définir ta fonction comme cela:

Code :

1
2
nom_fonction ()
{ liste_commandes ;}

?

regarde ici aussi :

http://www.compuspec.net/reference/s...function.shtml

[esprism]

Je ne pense pas que ça vienne d'un problème à la définition des fonctions, elles marchent bien.

Je pense plutôt à un fonctionnement "normal" mais incompris. Et donc je ne sais pas comment le contourner ne comprenant pas d'où viens le problème.

(je suis bien en ksh)

[Alek-C]

Ben si tu as ça :

Code :

1
2
#!/bin/sh

au début de ton script, tu es en .sh

[jabbounet]

sous ksh la commande history se fait avec fc si je me souviens bien.

Code :

1
2
fc -l

[jlliagre]

Envoyé par Alek-C

Ben si tu as ça :

Code :

au début de ton script, tu es en .sh

Sauf si le script est exécuté explicitement (ex: ksh xxx) ou implicitement (. xxx) par un autre shell, ce qui est le cas ici.

[jlliagre]

Envoyé par jabbounet

sous ksh la commande history se fait avec fc si je me souviens bien.

Code :

Toutes les versions de ksh disposent en fait de l'alias interne "history".
Sur les dernières versions de ksh, c'est "hist -l" au lieu de "fc -l".

[jabbounet]

Envoyé par jlliagre

Toutes les versions de ksh disposent en fait de l'alias interne "history".
Sur les dernières versions de ksh, c'est "hist -l" au lieu de "fc -l".

exact, et fc est aliasé directement sur hist (renommage?)


ceci dit j'ai déjà vu plusieurs machines d'installation récente (des solaris notament) ou history n'etait pas reconnu comme commande,
contrairement a fc.

[esprism]

Pour en revenir au problème, je pense que la question c'est comprendre comment marche le source d'un fichier. Visiblement il passe le contenu du fichier en ligne de commande.

J'ai trouvé un moyen tout bête de contourner le problème (je sauve mon fichier historique avant et le recopie après) mais ça n'explique pas ce qui se passe.

Par contre, j'ai bien l'impression que mon .profile est lu 3 fois, certainement la piste à explorer.

[jlliagre]

Envoyé par jabbounet

exact, et fc est aliasé directement sur hist (renommage?)

hist est un alias de fc sur les ksh récents.

ceci dit j'ai déjà vu plusieurs machines d'installation récente (des solaris notament) ou history n'etait pas reconnu comme commande,
contrairement a fc.

Tu dois confondre. L'alias history est interne à ksh depuis très longtemps et par exemple documenté avec Solaris 2.4 (1994).

[jabbounet]

Envoyé par jlliagre

hist est un alias de fc sur les ksh récents.

Tu dois confondre. L'alias history est interne à ksh depuis très longtemps et par exemple documenté avec Solaris 2.4 (1994).

je crois que nous sommes d'accord, history est un alias, pas une commande.

j'ai déjà vu des station ou quand tu lançais history cela te renvoyais command not found. après je ne vais pas généraliser sur toutes les installations de la terre, je parle simplement d'une expérience personnelle.

sur cette machine a 2/3 ans tout au plus, history est un alias sur fc et non sur hist comme l'indique la norme ksh93.

$uname -a
SunOS xxxxx 5.10 Generic_125100-10 sun4u sparc SUNW,A70
$which history
no history in .....
$alias history
history='fc -l'
$which fc
/usr/bin/fc
$alias fc
fc: alias not found
$psrinfo -v
Status of virtual processor 0 as of: 09/15/2009 12:22:41
on-line since 07/10/2009 13:12:52.
The sparcv9 processor operates at 1600 MHz,
and has a sparcv9 floating point processor

autrement:
http://www.research.att.com/sw/downl.../man1/ksh.html

Aliasing

The first word of each command is replaced by the text of an alias if an alias for this word has been defined. An alias name consists of any number of characters excluding metacharacters, quoting characters, file expansion characters, parameter expansion and command substitution characters, and =. The replacement string can contain any valid shell script including the metacharacters listed above. The first word of each command in the replaced text, other than any that are in the process of being replaced, will be tested for aliases. If the last character of the alias value is a blank then the word following the alias will also be checked for alias substitution. Aliases can be used to redefine built-in commands but cannot be used to redefine the reserved words listed above. Aliases can be created and listed with the alias command and can be removed with the unalias command.

Aliasing is performed when scripts are read, not while they are executed. Therefore, for an alias to take effect, the alias definition command has to be executed before the command which references the alias is read.

The following aliases are compiled into the shell but can be unset or redefined:

autoload='typeset -fu'
command='command '
compound='typeset -C'
fc=hist
float='typeset -lE'
functions='typeset -f'
hash='alias -t - -'
history='hist -l'
integer='typeset -li'
nameref='typeset -n'
nohup='nohup '
r='hist -s'
redirect='command exec'
source='command .'
stop='kill -s STOP'
suspend='kill -s STOP $$'
times='{ { time;} 2>&1;}'
type='whence -v'

mais bon sur le fond je pense que nous sommes d'accord, donc pas trop la peine de philosopher sur history....

[jlliagre]

Oui. fc est à la fois une commande externe et une builtin. Si tu n'est pas en ksh, history ne marche pas mais fc marche toujours. Le problème est que l'historique n'est pas mis à jour.

Pour la question initiale, oui la commande "." source le fichier. Elle est strictement équivalente à la saisie au clavier du contenu du fichier et donc son exécution par le shell courant, contrairement à un script classique qui lance un autre shell pour être exécuté.

[Alek-C]

Envoyé par jlliagre

Sauf si le script est exécuté explicitement (ex: ksh xxx) ou implicitement (. xxx) par un autre shell, ce qui est le cas ici.

Décidément, il y a vraiment des évidences que je ne maîtrise pas...