Si, esa es... a mi no me funcionan... os funciona a todos los demás??
Y como precisamente hay reportado un bug con ese problema y aún está
marcado como no solucionado... pues.. pensé que no le funcionaba a
nadie...
Saludos
Joe
El lun, 07-02-2011 a las 16:45 -0600, gerardo Juarez escribió:
> Hola
Hola joe,
Pues, cosa extraña, a mí me está mandando correos cada vez que alguien
agrega una respuesta a la pregunta en
la que yo participé. Es esta la notificación a la que te refieres?
Gerardo
joe di castro wrote:
Hay un pequeño problema, la aplicación tiene un bug que aún no está
resuelto
Hay un pequeño problema, la aplicación tiene un bug que aún no está
resuelto por los desarrolladores por el cual no funciona el envío de los
correos de notificación a los usuarios, así que de momento, la única
forma de seguir la evolución de la página es por RSS.
Estoy mirando alguna manera de sor
El script que he hecho esta listo para aplicaciones de escritorio, pero
cada cual ya sabra cambiarse "xmessage" por "echo" si necesita adaptarlo
a otras condiciones.
/bin/sh se encuentra en todas las distribuciones y versiones de GNU, y
ademas se encuentra disponible desde el arranque y enlaza
Hola Narcis,
La práctica convencional es usar 'env'. No me preguntes por qué, pero es
la más extendida. Los scripts que has hecho dependen de que sh exista
en /bin. Aparentemente, la misma confiabilidad puedes esperar de 'env' y
es una sola línea al principio del programa. Los lanzadores que
Bueno, tuve que corregir algunas imperfecciones del programa-lanzador.
Aqui va la revision:
#!/bin/sh
# Lanzador de programa con su version de Python
# Version 2011.02.07
# Copyright (GNU GPL) Narcis Garcia
EjecutableLanzar="./gsciber.py"
VersionDeseadaPython="2"
# Busqueda de componentes
Resu
Aqui va el codigo de un lanzador estandar:
#!/bin/sh
# Lanzador de programa con su version de Python
# Version 2011.02.07
# Copyright (GNU GPL) Narcis Garcia
EjecutableLanzar="miprograma.py"
VersionDeseadaPython="2"
# Busqueda de componentes
Result=0
RutaPython="$(which python)"
Alternativas=""
Hola,
El día 7 de febrero de 2011 13:40, ray escribió:
> algunas razones). No sé si alguien sepa alguna forma de realizar esta tarea
> o de cómo usar subprocess para responder a la pregunta de la contraseña :)
Una posible solución sería utilizar pexpect para automatizar la
introducción de usuari
Gracias.
De todas formas, en prevision de convivir Python 2 y Python 3, tendre
que hace lanzadores en Bash.
Al 07/02/11 13:04, En/na Francisco Javier Cuadrado ha escrit:
El día 7 de febrero de 2011 12:48, Narcis Garcia - GiLUG
escribió:
¿En cambio si que es de esperar que "env" se encuentr
Saludos lista,
Necesito algunos scripts para manejar cuentas de LDAP, para esto he creado
una clase que encapsula los métodos de python-ldap. El problema está en que
la librería no puede ser instalada en el servidor LDAP por problemas de
dependencias y tuve que instalarlo en otra máquina, así que
El 07/02/11 13:04, Francisco Javier Cuadrado escribió:
El día 7 de febrero de 2011 12:48, Narcis Garcia - GiLUG
escribió:
¿En cambio si que es de esperar que "env" se encuentre en /usr/bin en
cualquier entorno GNU?
Aquí tienes una discusión de la lista «tutor» de python:
http://mail.python.o
Hola,
Aunque el campo de trabajo sea muy específico, me han pedido que de
máxima difusión a esto.
Se trata de una beca para una estancia de 8 meses para Trento (Italia).
Yo he estado en la fundación Bruno Kessler (para nuestro último curso de
programación avanzada) y la verdad es que me quedé
El día 7 de febrero de 2011 12:48, Narcis Garcia - GiLUG
escribió:
> ¿En cambio si que es de esperar que "env" se encuentre en /usr/bin en
> cualquier entorno GNU?
>
Aquí tienes una discusión de la lista «tutor» de python:
http://mail.python.org/pipermail/tutor/2007-June/054808.html
En este mens
¿En cambio si que es de esperar que "env" se encuentre en /usr/bin en
cualquier entorno GNU?
Por lo de la version, quizas vale la pena hacer un lanzador escrito en
Bash que busque si hay un "python2*" ejecutable.
Al 07/02/11 12:38, En/na Jesús Espino ha escrit:
Si usas /usr/bin/python y el
Si usas /usr/bin/python y el usuario tiene instalado python en /bin o
en /usr/local/bin, no funcionara si usas /usr/bin/env python eso queda
independizado.
Un saludo.
2011/2/7 Narcis Garcia - GiLUG :
> ¿Para que hacer intervenir a "env" si ya hay el ejecutable "python"?
>
>
> Al 07/02/11 12:11, E
El día 7 de febrero de 2011 12:27, Narcis Garcia - GiLUG
escribió:
> ¿Para que hacer intervenir a "env" si ya hay el ejecutable "python"?
>
Para no tener que poner la ruta completa del ejecutable, que puede
variar entre plataformas o, incluso, distribuciones.
>
> Al 07/02/11 12:11, En/na Jesús E
¿Para que hacer intervenir a "env" si ya hay el ejecutable "python"?
Al 07/02/11 12:11, En/na Jesús Espino ha escrit:
Para diferenciar entre python 3 y python 2, ahora mismo no sabría
decirte, pero en Ubuntu y supongo que en el resto de los Linux
funciona muy bien su usas #!/usr/bin/env python
La recomendación es poner:
#!/usr/bin/python
Ese alias apuntará a la versión del interprete por defecto en cada
instalación. Si escribes código que no es compatible para 3.x, yo
suelo controlarlo por código (sys.version_info) y cortar la ejecución
advirtiendo al usuario.
2011/2/7 Narcis Garci
Para diferenciar entre python 3 y python 2, ahora mismo no sabría
decirte, pero en Ubuntu y supongo que en el resto de los Linux
funciona muy bien su usas #!/usr/bin/env python y si usas
#!/usr/bin/env python3 pues ejecutaria con python3. El comando env
escoge la versión que el usuario tenga instal
Hola y gracias por leer mi consulta.
Al escribir un programa en Python, que lo estoy intentando en Python 2,
como primera linea del fichero pongo:
#!/usr/bin/python2
Pero hay instalaciones en donde no esta el ejecutable "python2", sino
que hay el "python" a secas o subversiones como "python2.6
20 matches
Mail list logo