2008-10-08 26 views

Respuesta

12

Sirve como una buena advertencia para aquellos de nosotros que no usamos bash como nuestro caparazón, porque nos olvidaremos de que una característica que está en nuestro caparazón cotidiano no estará disponible cuando este código se ejecuta a la hora acordada.

decir

[email protected]$ at 23:00  
warning: commands will be executed using /bin/sh 
at> rm **/*.pyc 
at> <EOT> 
job 1 at 2008-10-08 23:00 

El uso de '**' no es zsh perfectamente válido, pero no/sbin/sh! Es fácil cometer estos errores si está acostumbrado a usar un caparazón diferente, y es su responsabilidad recordar hacer lo correcto.

+0

/bin/sh es el shell Bourne, no Bash. –

+1

Heck, even/bin/bash y/bin/sh actúan de manera diferente, incluso cuando/bin/sh está enlazado a bash. – ephemient

+0

@John Bueno, por lo general es un enlace simbólico para bash ... (no en Ubuntu sin embargo ... así que sí importa) – Spudd86

2

Si desea conseguir alrededor de ese mensaje, que 'en el' ejecutar un script que llama a un entorno determinado, ya sea ksh, bash, csh, zsh, Perl, etc.

Además - ver el 'at' man page http://www.rt.com/man/at.1.html para obtener más información.

at and batch read commands from standard input or a specified file which are to be executed at a later time, using /bin/sh. 
+2

No, quiero decir, ¿cómo desactivo * el mensaje de advertencia? * – raldi

4

¿La advertencia tiene algún efecto perjudicial aparte de ser molesto? La página man no menciona ninguna forma de desactivarlo, por lo que no creo que pueda evitar que se emita sin reconstruir su en desde la fuente.

Ahora, si quieres simplemente no verlo, puede utilizar a las [hora] 2>/dev/null a enviarla al olvido, pero, por desgracia, la a> indicaciones se imprimen a STDERR por alguna razón (un error, IMO - deberían ir a STDOUT), así que también están ocultos por esto. Es posible trabajar algunas tuberías de shell que eliminarán la advertencia sin tener que seguir las indicaciones, pero a) mi intento de esto (en [tiempo] 2> & 1 | grep -v advertencia) no funciona y b) incluso si puede encontrar una combinación que funcione, no será adecuada para alias (ya que el tiempo pasa en el medio en lugar de al final), por lo que tendrá que escribirlo en su totalidad cada vez que use o bien, escriba un script de envoltura alrededor de en para manejarlo.

Así que, a menos que cause problemas reales, diría que probablemente sea mejor que simplemente ignore la advertencia como el resto de nosotros.

+1

Ah, buena adición sobre el STDERR y no el STDOUT. Siempre me estaba preguntando por qué el redireccionamiento normal no funcionaba. El efecto secundario de escribir en el STDERR es que envía un correo electrónico al administrador (que soy yo en mi sistema local) que, como usted dice, no es un efecto perjudicial, pero sí es molesto ;-) – Michel

3

Le recuerda que los comandos serán ejecutados por el Bourne Shell estándar, lo que significa que su sintaxis de comando debe ser compatible con ese shell. ("Diversión" hecho: Acabo de notar que advierte que a pesar de que su shell actual es/bin/sh Debe ser un error..)

Un 'truco fácil' para eliminar el mensaje es simplemente eliminar la primera línea de la salida. Esto se puede hacer de una forma sencilla mediante la redefinición de la orden at:

at() { /usr/bin/at [email protected] 2>&1 | tail -n +2; } 

puedes añadir al fichero que contiene sus otros alias de shell (~/.bashrc, ~/.zshrc o equivalente de su shell).

NOTA: el comando tail en el 'truco' anterior también eliminará el prefijo at> al escribir comandos en línea. Probablemente no sea un factor decisivo, pero algo a tener en cuenta.

Cuestiones relacionadas