Depuis un moment je cherche une technique permettant de créer des macro
ou plus precisement "extensions syntaxique", de manière la plus propre
qui soit.
par exemple redefinir la commande cp pour que quand je tape : $ cp toto
tutu
j'ai ceci à la place qui est executé : $ pv toto > tutu
(ceci afin d'avoir une barre progressive lors d'une operation de copie).
La solution bete et mechante : je supprime le binaire cp et le remplace
par un script qui fait ce que je lui demande => à eviter.
Ou bien, je defini un ~/bin/cp que j'ajouterais dans mon $PATH en le
plaçant au début pour qu'il soit executé avant le cp systeme. Ca me
semble la solution la plus interessante mais il faut que je trouve le
moyen de dire que seul moi manuellement à le droit d'utiliser cette
commande (en faisant une condition si $TERM = le nom de mon terminal,
mais je ne pense pas que cela suffise).
J'ai peur d'être coincé et un peu d'aide ne serais pas de refus : Merci
d'avance !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michel
Le 08/11/2014 11:09, FERREC Romain a écrit :
Bonjour,
Depuis un moment je cherche une technique permettant de créer des macro ou plus precisement "extensions syntaxique", de manière la plus propre qui soit.
par exemple redefinir la commande cp pour que quand je tape : $ cp toto tutu
j'ai ceci à la place qui est executé : $ pv toto > tutu
(ceci afin d'avoir une barre progressive lors d'une operation de copie).
La solution bete et mechante : je supprime le binaire cp et le remplace par un script qui fait ce que je lui demande => à eviter.
Ou bien, je defini un ~/bin/cp que j'ajouterais dans mon $PATH en le plaçant au début pour qu'il soit executé avant le cp systeme. Ca me semble la solution la plus interessante mais il faut que je trouve le moyen de dire que seul moi manuellement à le droit d'utiliser cette commande (en faisant une condition si $TERM = le nom de mon terminal, mais je ne pense pas que cela suffise).
J'ai peur d'être coincé et un peu d'aide ne serais pas de refus : Merci d'avance !
Tu peux peut-être essayer en créant des "alias" dans ton .bashrc ?
Michel
Le 08/11/2014 11:09, FERREC Romain a écrit :
Bonjour,
Depuis un moment je cherche une technique permettant de créer des macro
ou plus precisement "extensions syntaxique", de manière la plus propre
qui soit.
par exemple redefinir la commande cp pour que quand je tape : $ cp toto
tutu
j'ai ceci à la place qui est executé : $ pv toto > tutu
(ceci afin d'avoir une barre progressive lors d'une operation de copie).
La solution bete et mechante : je supprime le binaire cp et le remplace
par un script qui fait ce que je lui demande => à eviter.
Ou bien, je defini un ~/bin/cp que j'ajouterais dans mon $PATH en le
plaçant au début pour qu'il soit executé avant le cp systeme. Ca me
semble la solution la plus interessante mais il faut que je trouve le
moyen de dire que seul moi manuellement à le droit d'utiliser cette
commande (en faisant une condition si $TERM = le nom de mon terminal,
mais je ne pense pas que cela suffise).
J'ai peur d'être coincé et un peu d'aide ne serais pas de refus : Merci
d'avance !
Tu peux peut-être essayer en créant des "alias" dans ton .bashrc ?
Depuis un moment je cherche une technique permettant de créer des macro ou plus precisement "extensions syntaxique", de manière la plus propre qui soit.
par exemple redefinir la commande cp pour que quand je tape : $ cp toto tutu
j'ai ceci à la place qui est executé : $ pv toto > tutu
(ceci afin d'avoir une barre progressive lors d'une operation de copie).
La solution bete et mechante : je supprime le binaire cp et le remplace par un script qui fait ce que je lui demande => à eviter.
Ou bien, je defini un ~/bin/cp que j'ajouterais dans mon $PATH en le plaçant au début pour qu'il soit executé avant le cp systeme. Ca me semble la solution la plus interessante mais il faut que je trouve le moyen de dire que seul moi manuellement à le droit d'utiliser cette commande (en faisant une condition si $TERM = le nom de mon terminal, mais je ne pense pas que cela suffise).
J'ai peur d'être coincé et un peu d'aide ne serais pas de refus : Merci d'avance !
Tu peux peut-être essayer en créant des "alias" dans ton .bashrc ?
Michel
Sergio
Le 08/11/2014 11:09, FERREC Romain a écrit :
Depuis un moment je cherche une technique permettant de créer des macro ou plus precisement "extensions syntaxique", de manière la plus propre qui soit.
par exemple redefinir la commande cp pour que quand je tape : $ cp toto tutu
j'ai ceci à la place qui est executé : $ pv toto > tutu
(ceci afin d'avoir une barre progressive lors d'une operation de copie).
Tu peux ajouter des alias. Par exemple :
# demandera confirmation pour chaque effacement alias rm 'rm -i'
# pour les nostalgiques du DOS alias md='mkdir' alias del='rm' alias cls='clear' alias copy='cp'
# Variantes de ls alias la='ls -A' alias lal='ls -Alh' alias ll='ls -lh ' alias lld='ls -ldh'
Ou alors créer des fonctions. Pour ton truc :
cp () { pv $1 > $2 } # (fonction à améliorer pour tenir compte des options de cp)
La solution bete et mechante : je supprime le binaire cp et le remplace par un script qui fait ce que je lui demande => à eviter.
Ou bien, je defini un ~/bin/cp que j'ajouterais dans mon $PATH en le plaçant au début pour qu'il soit executé avant le cp systeme. Ca me semble la solution la plus interessante mais il faut que je trouve le moyen de dire que seul moi manuellement à le droit d'utiliser cette commande (en faisant une condition si $TERM = le nom de mon terminal, mais je ne pense pas que cela suffise).
Dangereux pour des scripts que tu n'as pas écrits ! (par exemple la commande "firefox" est un script). L'intérêt des alias et des fonctions shell c'est qu'ils ne sont pas interprétés dans les scripts.
J'ai peur d'être coincé et un peu d'aide ne serais pas de refus : Merci d'avance !
Tu peux aussi mettre tes scripts persos dans ~/bin et rajouter ~/bin à $PATH en rajoutant au .bashrc :
Depuis un moment je cherche une technique permettant de créer des macro
ou plus precisement "extensions syntaxique", de manière la plus propre
qui soit.
par exemple redefinir la commande cp pour que quand je tape : $ cp toto
tutu
j'ai ceci à la place qui est executé : $ pv toto > tutu
(ceci afin d'avoir une barre progressive lors d'une operation de copie).
Tu peux ajouter des alias. Par exemple :
# demandera confirmation pour chaque effacement
alias rm 'rm -i'
# pour les nostalgiques du DOS
alias md='mkdir'
alias del='rm'
alias cls='clear'
alias copy='cp'
# Variantes de ls
alias la='ls -A'
alias lal='ls -Alh'
alias ll='ls -lh '
alias lld='ls -ldh'
Ou alors créer des fonctions. Pour ton truc :
cp ()
{
pv $1 > $2
}
# (fonction à améliorer pour tenir compte des options de cp)
La solution bete et mechante : je supprime le binaire cp et le remplace
par un script qui fait ce que je lui demande => à eviter.
Ou bien, je defini un ~/bin/cp que j'ajouterais dans mon $PATH en le
plaçant au début pour qu'il soit executé avant le cp systeme. Ca me
semble la solution la plus interessante mais il faut que je trouve le
moyen de dire que seul moi manuellement à le droit d'utiliser cette
commande (en faisant une condition si $TERM = le nom de mon terminal,
mais je ne pense pas que cela suffise).
Dangereux pour des scripts que tu n'as pas écrits ! (par exemple la commande "firefox" est un script). L'intérêt des alias et des
fonctions shell c'est qu'ils ne sont pas interprétés dans les scripts.
J'ai peur d'être coincé et un peu d'aide ne serais pas de refus : Merci
d'avance !
Tu peux aussi mettre tes scripts persos dans ~/bin et rajouter ~/bin à $PATH en rajoutant au .bashrc :
PATH=$HOME/bin:$PATH
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Depuis un moment je cherche une technique permettant de créer des macro ou plus precisement "extensions syntaxique", de manière la plus propre qui soit.
par exemple redefinir la commande cp pour que quand je tape : $ cp toto tutu
j'ai ceci à la place qui est executé : $ pv toto > tutu
(ceci afin d'avoir une barre progressive lors d'une operation de copie).
Tu peux ajouter des alias. Par exemple :
# demandera confirmation pour chaque effacement alias rm 'rm -i'
# pour les nostalgiques du DOS alias md='mkdir' alias del='rm' alias cls='clear' alias copy='cp'
# Variantes de ls alias la='ls -A' alias lal='ls -Alh' alias ll='ls -lh ' alias lld='ls -ldh'
Ou alors créer des fonctions. Pour ton truc :
cp () { pv $1 > $2 } # (fonction à améliorer pour tenir compte des options de cp)
La solution bete et mechante : je supprime le binaire cp et le remplace par un script qui fait ce que je lui demande => à eviter.
Ou bien, je defini un ~/bin/cp que j'ajouterais dans mon $PATH en le plaçant au début pour qu'il soit executé avant le cp systeme. Ca me semble la solution la plus interessante mais il faut que je trouve le moyen de dire que seul moi manuellement à le droit d'utiliser cette commande (en faisant une condition si $TERM = le nom de mon terminal, mais je ne pense pas que cela suffise).
Dangereux pour des scripts que tu n'as pas écrits ! (par exemple la commande "firefox" est un script). L'intérêt des alias et des fonctions shell c'est qu'ils ne sont pas interprétés dans les scripts.
J'ai peur d'être coincé et un peu d'aide ne serais pas de refus : Merci d'avance !
Tu peux aussi mettre tes scripts persos dans ~/bin et rajouter ~/bin à $PATH en rajoutant au .bashrc :
Tu peux ajouter des alias. Ou alors créer des fonctions. Pour ton truc :
cp () { pv $1 > $2 }
# (fonction à améliorer pour tenir compte des options de cp)
Hmm interessant, et je formule mon alias ainsi :
alias cp=my_cp
Dans ce cas je pourrais utiliser cp avec des arguments... J'ai toujours vu jusqu'a là qu'on ne pouvait s'en servir que comme raccourcis simple à des commandes complexes.
Dangereux pour des scripts que tu n'as pas écrits ! (par exemple la commande "firefox" est un script). L'intérêt des alias et des fonctions shell c'est qu'ils ne sont pas interprétés dans les scripts.
Tu peux aussi mettre tes scripts persos dans ~/bin et rajouter ~/bin à $PATH en rajoutant au .bashrc :
PATH=$HOME/bin:$PATH
Ah j'ignorais aussi, donc même si mon alias est initialisé seul moi pourrait l'utiliser. Et bien ça semble parfaitement repondre à mes besoins.
merci !
Le 08-11-2014, Sergio <serge.laposte@delbono.net.invalid> a écrit :
Tu peux ajouter des alias. Ou alors créer des fonctions. Pour ton
truc :
cp () { pv $1 > $2 }
# (fonction à améliorer pour tenir compte des
options de cp)
Hmm interessant, et je formule mon alias ainsi :
alias cp=my_cp
Dans ce cas je pourrais utiliser cp avec des arguments... J'ai toujours
vu jusqu'a là qu'on ne pouvait s'en servir que comme raccourcis simple à
des commandes complexes.
Dangereux pour des scripts que tu n'as pas écrits ! (par exemple la
commande "firefox" est un script). L'intérêt des alias et des
fonctions shell c'est qu'ils ne sont pas interprétés dans les scripts.
Tu peux aussi mettre tes scripts persos dans ~/bin et rajouter ~/bin à
$PATH en rajoutant au .bashrc :
PATH=$HOME/bin:$PATH
Ah j'ignorais aussi, donc même si mon alias est initialisé seul moi
pourrait l'utiliser. Et bien ça semble parfaitement repondre à mes
besoins.
Tu peux ajouter des alias. Ou alors créer des fonctions. Pour ton truc :
cp () { pv $1 > $2 }
# (fonction à améliorer pour tenir compte des options de cp)
Hmm interessant, et je formule mon alias ainsi :
alias cp=my_cp
Dans ce cas je pourrais utiliser cp avec des arguments... J'ai toujours vu jusqu'a là qu'on ne pouvait s'en servir que comme raccourcis simple à des commandes complexes.
Dangereux pour des scripts que tu n'as pas écrits ! (par exemple la commande "firefox" est un script). L'intérêt des alias et des fonctions shell c'est qu'ils ne sont pas interprétés dans les scripts.
Tu peux aussi mettre tes scripts persos dans ~/bin et rajouter ~/bin à $PATH en rajoutant au .bashrc :
PATH=$HOME/bin:$PATH
Ah j'ignorais aussi, donc même si mon alias est initialisé seul moi pourrait l'utiliser. Et bien ça semble parfaitement repondre à mes besoins.
merci !
Benoit Izac
Bonjour,
le 08/11/2014 à 12:32, FERREC Romain a écrit dans le message <m3kuvo$vp8$ :
Tu peux aussi mettre tes scripts persos dans ~/bin et rajouter ~/bin à $PATH en rajoutant au .bashrc :
PATH=$HOME/bin:$PATH
Ah j'ignorais aussi, donc même si mon alias est initialisé seul moi pourrait l'utiliser. Et bien ça semble parfaitement repondre à mes besoins.
Attention, il faut être conscient que généralement le PATH est exporté, ce qui a pour conséquence que tous les programmes lancés depuis un shell bash de login utiliseront ton « cp » et non pas celui du système. C'est plutôt casse-gueule.
Un peu mieux, redéfinir « cp » par une fonction : cp() { pv "$1" > "$2" } Mais c'est également casse-gueule si par la suite tu fais « cp -i a b ».
Pourquoi ne pas plutôt appeler « pv » lorsque c'est nécessaire ?
-- Benoit Izac
Bonjour,
le 08/11/2014 à 12:32, FERREC Romain a écrit dans le message
<m3kuvo$vp8$1@dont-email.me> :
Tu peux aussi mettre tes scripts persos dans ~/bin et rajouter ~/bin à
$PATH en rajoutant au .bashrc :
PATH=$HOME/bin:$PATH
Ah j'ignorais aussi, donc même si mon alias est initialisé seul moi
pourrait l'utiliser. Et bien ça semble parfaitement repondre à mes
besoins.
Attention, il faut être conscient que généralement le PATH est exporté,
ce qui a pour conséquence que tous les programmes lancés depuis un shell
bash de login utiliseront ton « cp » et non pas celui du système. C'est
plutôt casse-gueule.
Un peu mieux, redéfinir « cp » par une fonction :
cp() {
pv "$1" > "$2"
}
Mais c'est également casse-gueule si par la suite tu fais « cp -i a b ».
Pourquoi ne pas plutôt appeler « pv » lorsque c'est nécessaire ?
le 08/11/2014 à 12:32, FERREC Romain a écrit dans le message <m3kuvo$vp8$ :
Tu peux aussi mettre tes scripts persos dans ~/bin et rajouter ~/bin à $PATH en rajoutant au .bashrc :
PATH=$HOME/bin:$PATH
Ah j'ignorais aussi, donc même si mon alias est initialisé seul moi pourrait l'utiliser. Et bien ça semble parfaitement repondre à mes besoins.
Attention, il faut être conscient que généralement le PATH est exporté, ce qui a pour conséquence que tous les programmes lancés depuis un shell bash de login utiliseront ton « cp » et non pas celui du système. C'est plutôt casse-gueule.
Un peu mieux, redéfinir « cp » par une fonction : cp() { pv "$1" > "$2" } Mais c'est également casse-gueule si par la suite tu fais « cp -i a b ».
Pourquoi ne pas plutôt appeler « pv » lorsque c'est nécessaire ?
-- Benoit Izac
FERREC Romain
Le 08-11-2014, Benoit Izac a écrit :
Attention, il faut être conscient que généralement le PATH est exporté, ce qui a pour conséquence que tous les programmes lancés depuis un shell bash de login utiliseront ton « cp » et non pas celui du système. C'est plutôt casse-gueule.
Hm oui c'est juste, dans ce cas il faudrait que j'ajoute un autre shell dans lequel je defini mes alias personnalisé, l'autre reste standard et je passe de l'un vers l'autre via un keybinding.. moué.. :p.
Un peu mieux, redéfinir « cp » par une fonction : cp() { pv "$1" > "$2" } Mais c'est également casse-gueule si par la suite tu fais « cp -i a b ». Pourquoi ne pas plutôt appeler « pv » lorsque c'est nécessaire ?
Oui c'est également un soucis (décidement), néammois je viens de voir qu'il serait plus interessant d'utiliser rsync du fait que contrairement à pv il conserve les même droits. Et je pourrais selon mes besoins, faire des conversions des options de rsync à cp avec des conditions.
L'idée c'était de garder la syntaxe de base, mais je me rend compte que c'est effectivement problèmatique de remplacer ces commandes sans faire de sacrifices quelques part.
Sinon je peut opter pour une convention qui consiste à doubler la première lettre, soit ccp.
Le 08-11-2014, Benoit Izac <use.reply.to@INVALID.ADDRESS> a écrit :
Attention, il faut être conscient que généralement le PATH est exporté,
ce qui a pour conséquence que tous les programmes lancés depuis un shell
bash de login utiliseront ton « cp » et non pas celui du système. C'est
plutôt casse-gueule.
Hm oui c'est juste, dans ce cas il faudrait que j'ajoute un autre shell
dans lequel je defini mes alias personnalisé, l'autre reste
standard et je passe de l'un vers l'autre via un keybinding.. moué.. :p.
Un peu mieux, redéfinir « cp » par une fonction :
cp() {
pv "$1" > "$2"
}
Mais c'est également casse-gueule si par la suite tu fais « cp -i a b ».
Pourquoi ne pas plutôt appeler « pv » lorsque c'est nécessaire ?
Oui c'est également un soucis (décidement), néammois je viens de voir
qu'il serait plus interessant d'utiliser rsync du fait que contrairement
à pv il conserve les même droits. Et je pourrais selon mes besoins,
faire des conversions des options de rsync à cp avec des conditions.
L'idée c'était de garder la syntaxe de base, mais je me rend compte que
c'est effectivement problèmatique de remplacer ces commandes sans faire
de sacrifices quelques part.
Sinon je peut opter pour une convention qui consiste à doubler la
première lettre, soit ccp.
Attention, il faut être conscient que généralement le PATH est exporté, ce qui a pour conséquence que tous les programmes lancés depuis un shell bash de login utiliseront ton « cp » et non pas celui du système. C'est plutôt casse-gueule.
Hm oui c'est juste, dans ce cas il faudrait que j'ajoute un autre shell dans lequel je defini mes alias personnalisé, l'autre reste standard et je passe de l'un vers l'autre via un keybinding.. moué.. :p.
Un peu mieux, redéfinir « cp » par une fonction : cp() { pv "$1" > "$2" } Mais c'est également casse-gueule si par la suite tu fais « cp -i a b ». Pourquoi ne pas plutôt appeler « pv » lorsque c'est nécessaire ?
Oui c'est également un soucis (décidement), néammois je viens de voir qu'il serait plus interessant d'utiliser rsync du fait que contrairement à pv il conserve les même droits. Et je pourrais selon mes besoins, faire des conversions des options de rsync à cp avec des conditions.
L'idée c'était de garder la syntaxe de base, mais je me rend compte que c'est effectivement problèmatique de remplacer ces commandes sans faire de sacrifices quelques part.
Sinon je peut opter pour une convention qui consiste à doubler la première lettre, soit ccp.
Benoit Izac
Bonjour,
le 08/11/2014 à 14:35, FERREC Romain a écrit dans le message <m3l67h$of4$ :
Sinon je peut opter pour une convention qui consiste à doubler la première lettre, soit ccp.
Dans ce cas, autant mettre le vrai nom de la commande, ça t'évitera de te poser la question de ce qu'est « ccp » dans quelques semaines/mois/années.
-- Benoit Izac
Bonjour,
le 08/11/2014 à 14:35, FERREC Romain a écrit dans le message
<m3l67h$of4$1@dont-email.me> :
Sinon je peut opter pour une convention qui consiste à doubler la
première lettre, soit ccp.
Dans ce cas, autant mettre le vrai nom de la commande, ça t'évitera de
te poser la question de ce qu'est « ccp » dans quelques
semaines/mois/années.
le 08/11/2014 à 14:35, FERREC Romain a écrit dans le message <m3l67h$of4$ :
Sinon je peut opter pour une convention qui consiste à doubler la première lettre, soit ccp.
Dans ce cas, autant mettre le vrai nom de la commande, ça t'évitera de te poser la question de ce qu'est « ccp » dans quelques semaines/mois/années.
-- Benoit Izac
Lucas Levrel
Le 8 novembre 2014, Benoit Izac a écrit :
le 08/11/2014 à 12:32, FERREC Romain a écrit dans le message <m3kuvo$vp8$ :
Tu peux aussi mettre tes scripts persos dans ~/bin et rajouter ~/bin à $PATH en rajoutant au .bashrc :
PATH=$HOME/bin:$PATH
Ah j'ignorais aussi, donc même si mon alias est initialisé seul moi pourrait l'utiliser. Et bien ça semble parfaitement repondre à mes besoins.
Attention, il faut être conscient que généralement le PATH est exporté, ce qui a pour conséquence que tous les programmes lancés depuis un shell bash de login utiliseront ton « cp » et non pas celui du système. C'est plutôt casse-gueule.
Si le système est correctement foutu, .bashrc n'est utilisé que par les shells interactifs, et *n'est pas* sourcé par .profile (shells de login).
Ceci étant, les programmes lancés depuis lesdits shells interactifs hériteront du PATH modifié (à moins d'enlever l'export, mais pas sûr que le programme apprécie de ne pas avoir de PATH).
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 8 novembre 2014, Benoit Izac a écrit :
le 08/11/2014 à 12:32, FERREC Romain a écrit dans le message
<m3kuvo$vp8$1@dont-email.me> :
Tu peux aussi mettre tes scripts persos dans ~/bin et rajouter ~/bin à
$PATH en rajoutant au .bashrc :
PATH=$HOME/bin:$PATH
Ah j'ignorais aussi, donc même si mon alias est initialisé seul moi
pourrait l'utiliser. Et bien ça semble parfaitement repondre à mes
besoins.
Attention, il faut être conscient que généralement le PATH est exporté,
ce qui a pour conséquence que tous les programmes lancés depuis un shell
bash de login utiliseront ton « cp » et non pas celui du système. C'est
plutôt casse-gueule.
Si le système est correctement foutu, .bashrc n'est utilisé que par les
shells interactifs, et *n'est pas* sourcé par .profile (shells de login).
Ceci étant, les programmes lancés depuis lesdits shells interactifs
hériteront du PATH modifié (à moins d'enlever l'export, mais pas sûr que
le programme apprécie de ne pas avoir de PATH).
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
le 08/11/2014 à 12:32, FERREC Romain a écrit dans le message <m3kuvo$vp8$ :
Tu peux aussi mettre tes scripts persos dans ~/bin et rajouter ~/bin à $PATH en rajoutant au .bashrc :
PATH=$HOME/bin:$PATH
Ah j'ignorais aussi, donc même si mon alias est initialisé seul moi pourrait l'utiliser. Et bien ça semble parfaitement repondre à mes besoins.
Attention, il faut être conscient que généralement le PATH est exporté, ce qui a pour conséquence que tous les programmes lancés depuis un shell bash de login utiliseront ton « cp » et non pas celui du système. C'est plutôt casse-gueule.
Si le système est correctement foutu, .bashrc n'est utilisé que par les shells interactifs, et *n'est pas* sourcé par .profile (shells de login).
Ceci étant, les programmes lancés depuis lesdits shells interactifs hériteront du PATH modifié (à moins d'enlever l'export, mais pas sûr que le programme apprécie de ne pas avoir de PATH).
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
FERREC Romain
Le 09-11-2014, Lucas Levrel a écrit :
Si le système est correctement foutu, .bashrc n'est utilisé que par les shells interactifs, et *n'est pas* sourcé par .profile (shells de login).
Ceci étant, les programmes lancés depuis lesdits shells interactifs hériteront du PATH modifié (à moins d'enlever l'export, mais pas sûr que le programme apprécie de ne pas avoir de PATH).
Hmm, bah sur ma debian j'ai pourtant le bashrc qui est intepreté après m'étre connecté dans un shell de login.. (par exemple ceux que l'on peut acceder via C-M-{F1,F7}).
D'accord, donc à moins de pouvoir indiquer automatiquement un PATH specifique si jamais je lance un script en console, et le réinitialiser une fois son execution terminée, je n'ai guère le choix.
Sinon il y a la solution de personnaliser un shell à part (zsh par exemple) et ne l'utiliser que pour ces cas là, avec dans le .zshrc le PATH contenant les scripts persos, et dans le bashrc un PATH "normal".
Je pensais qu'il y aurait eu plus simple, autrement tant pis je me contenterais du retour du prompt sans pouvoir connaitre le temps de copie ou la vitesse de transfert.
Le 09-11-2014, Lucas Levrel <lucas.levrel@u-pec.fr> a écrit :
Si le système est correctement foutu, .bashrc n'est utilisé que par
les shells interactifs, et *n'est pas* sourcé par .profile (shells de
login).
Ceci étant, les programmes lancés depuis lesdits shells interactifs
hériteront du PATH modifié (à moins d'enlever l'export, mais pas sûr
que le programme apprécie de ne pas avoir de PATH).
Hmm, bah sur ma debian j'ai pourtant le bashrc qui est intepreté après
m'étre connecté dans un shell de login.. (par exemple ceux que l'on peut
acceder via C-M-{F1,F7}).
D'accord, donc à moins de pouvoir indiquer automatiquement un PATH
specifique si jamais je lance un script en console, et le réinitialiser
une fois son execution terminée, je n'ai guère le choix.
Sinon il y a la solution de personnaliser un shell à part (zsh par
exemple) et ne l'utiliser que pour ces cas là, avec dans le .zshrc le
PATH contenant les scripts persos, et dans le bashrc un PATH "normal".
Je pensais qu'il y aurait eu plus simple, autrement tant pis je me
contenterais du retour du prompt sans pouvoir connaitre le temps de
copie ou la vitesse de transfert.
Si le système est correctement foutu, .bashrc n'est utilisé que par les shells interactifs, et *n'est pas* sourcé par .profile (shells de login).
Ceci étant, les programmes lancés depuis lesdits shells interactifs hériteront du PATH modifié (à moins d'enlever l'export, mais pas sûr que le programme apprécie de ne pas avoir de PATH).
Hmm, bah sur ma debian j'ai pourtant le bashrc qui est intepreté après m'étre connecté dans un shell de login.. (par exemple ceux que l'on peut acceder via C-M-{F1,F7}).
D'accord, donc à moins de pouvoir indiquer automatiquement un PATH specifique si jamais je lance un script en console, et le réinitialiser une fois son execution terminée, je n'ai guère le choix.
Sinon il y a la solution de personnaliser un shell à part (zsh par exemple) et ne l'utiliser que pour ces cas là, avec dans le .zshrc le PATH contenant les scripts persos, et dans le bashrc un PATH "normal".
Je pensais qu'il y aurait eu plus simple, autrement tant pis je me contenterais du retour du prompt sans pouvoir connaitre le temps de copie ou la vitesse de transfert.
Lucas Levrel
Le 10 novembre 2014, FERREC Romain a écrit :
Le 09-11-2014, Lucas Levrel a écrit :
Si le système est correctement foutu, .bashrc n'est utilisé que par les shells interactifs, et *n'est pas* sourcé par .profile (shells de login).
Ceci étant, les programmes lancés depuis lesdits shells interactifs hériteront du PATH modifié (à moins d'enlever l'export, mais pas sûr que le programme apprécie de ne pas avoir de PATH).
Hmm, bah sur ma debian j'ai pourtant le bashrc qui est intepreté après m'étre connecté dans un shell de login.. (par exemple ceux que l'on peut acceder via C-M-{F1,F7}).
Ce sont aussi des shells interactifs (.profile et .bashrc ne sont pas mutuellement exclusifs).
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 10 novembre 2014, FERREC Romain a écrit :
Le 09-11-2014, Lucas Levrel <lucas.levrel@u-pec.fr> a écrit :
Si le système est correctement foutu, .bashrc n'est utilisé que par
les shells interactifs, et *n'est pas* sourcé par .profile (shells de
login).
Ceci étant, les programmes lancés depuis lesdits shells interactifs
hériteront du PATH modifié (à moins d'enlever l'export, mais pas sûr
que le programme apprécie de ne pas avoir de PATH).
Hmm, bah sur ma debian j'ai pourtant le bashrc qui est intepreté après
m'étre connecté dans un shell de login.. (par exemple ceux que l'on peut
acceder via C-M-{F1,F7}).
Ce sont aussi des shells interactifs (.profile et .bashrc ne sont pas
mutuellement exclusifs).
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Si le système est correctement foutu, .bashrc n'est utilisé que par les shells interactifs, et *n'est pas* sourcé par .profile (shells de login).
Ceci étant, les programmes lancés depuis lesdits shells interactifs hériteront du PATH modifié (à moins d'enlever l'export, mais pas sûr que le programme apprécie de ne pas avoir de PATH).
Hmm, bah sur ma debian j'ai pourtant le bashrc qui est intepreté après m'étre connecté dans un shell de login.. (par exemple ceux que l'on peut acceder via C-M-{F1,F7}).
Ce sont aussi des shells interactifs (.profile et .bashrc ne sont pas mutuellement exclusifs).
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
