je me trouve face a un comportement bizarre, soit le script suivant:
#!/usr/bin/python
from subprocess import *
import sys
try:
retcode=call("ls -al &> ls.out",shell=True)
except OSError, e:
print sys.stderr, "Execution Failed:", e
print 'done', retcode
sur une debian squeeze (python 2.5) j'obtiens le comportement attendu (liste le repertoire et redirige la sortie dans le fichier ls.out)
sur une ubuntu 9.04 (python 2.6 ou 2.5) le script me renvoie le contenu du repertoire courant sur stdout et cree un fichier ls.out vide. Est-ce que vous avez une idee de ce qu'il peut se passer parce que la je seche ?
merci d'avance
ps: j'utilise le module subprocess pour remplacer os.system mais j'ai le meme probleme avec os.system
# A quoi sert le ampersand ?
Posté par Joël Thieffry (site web personnel) . Évalué à 1.
ls -al > ls.out
et ça marche.<br/>
Au pire si tu veux récupérer aussi les erreurs de ls dans ls.out:<br/>
ls -al 2>&1 > ls.out
[^] # Re: A quoi sert le ampersand ?
Posté par beb . Évalué à 1.
Mais le probleme n'est pas vraiment dans la commande lancée, j'ai juste pris un exemple simple pour expliquer le probleme.
Avec la commande que tu mentionnes j'ai le meme probleme sur une Ubuntu 9.04
[^] # Re: A quoi sert le ampersand ?
Posté par Joël Thieffry (site web personnel) . Évalué à 1.
Je ne connaissais pas cette syntaxe &>, peut-être que c'est spécifique à bash car je ne l'avais pas rencontré en sh pur. J'ai testé dans mon bash, ça marche très bien.
Bien sûr avant de poster j'ai testé ma modif chez moi (comme toi Ubuntu 9.04 toute neuve, avec le python de base v2.6.2), et ça marche. Tu as peut-être un problème d'installation. Sans ma modif j'ai le même comportement que toi.
# Et en faisant comme tout le monde ?
Posté par Kerro . Évalué à 2.
[^] # Re: Et en faisant comme tout le monde ?
Posté par beb . Évalué à 1.
reste a comprendre pourquoi, car dans la page man de bash, on trouve
There are two formats for redirecting standard output and standard error:
& > word
and
> & word
Of the two forms, the first is preferred. This is semantically equivalent to
> word 2 > &1
tout doit etre dans le semantically ...
# Différence de shell
Posté par Barnabé . Évalué à 3.
Je ne connais pas subprocess, mais a priori il forke le shell par défaut pour exécuter la commande, et dash ne permet pas les mêmes redirections que bash.
[^] # Re: Différence de shell
Posté par beb . Évalué à 1.
[^] # Re: Différence de shell
Posté par chimrod (site web personnel) . Évalué à 1.
A noter que le projet à été initié par Debian ( Debian alchemist shell ), et permet aussi de vérifier que les scripts tourneront sous n'importe quel shell en empêchant l'inclusion de syntaxe propre à Bash.. ( gênant dans les scripts d'installation ou système.. )
[^] # Re: Différence de shell
Posté par calandoa . Évalué à 2.
Conclusion, débarassez vous de bash : c'est pas standard et ça fait prendre de mauvaises habitudes. Vous voulez du shell qui roxor? zsh est fait pour ça. Et puis pendant qu'on y est, virez Debian et installez Ubuntu... bon ok, je suis plus là.
[^] # Re: Différence de shell
Posté par benoar . Évalué à 2.
RESTRICTED SHELL
It behaves identically to bash with the exception that the following are
disallowed or not performed:
redirecting output using the >, >|, <>, >&, &>, and >> redirec tion operators
Je suppose que ça doit correspondre à une conformance POSIX plus "stricte".
[^] # Re: Différence de shell
Posté par NeoX . Évalué à 2.
pas de bash
neox@C2D:~$ ls -l /bin/bash
-rwxr-xr-x 1 root root 833592 2009-03-02 15:23 /bin/bash
neox@C2D:~$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 2008-11-03 23:02 /bin/sh -> dash
reste à savoir quel shell est invoqué par python
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.