Error al redirigir la salida de un programa a un archivo

Error al redirigir la salida de un programa a un archivo

Entonces tengo un programa, llamémoslo foo. Estoy intentando redirigir la salida de su terminal a un archivo usando el siguiente comando.

foo > ./someFile.txt

Ahora, cuando ejecuto ese comando, se crea someFile.txt, pero está vacío. ¿Alguna sugerencia sobre cómo podría redirigir la salida del terminal?

Respuesta1

Se espera que someFile.txtse cree un archivo. Si este archivo contiene algo o no, depende de lo que foose supone que debe hacer su programa.

Cualquiera que sea el problema que encuentre, no parece estar relacionado con la redirección de salida. Puedes probar el siguiente comando como prueba:

cat > someFile.txt

escribe cualquier cosa. Todo lo que hayas escrito será redirigido a someFile.txt(termina con ctrl+ d).

Por cierto, el archivo de salida lo crea su shell, no su programa foo. Incluso si escribe un comando inexistente, el archivo de salida seguirá creado (vacío):

/bin/nonexistent > zzz

Respuesta2

Otra posibilidad es que foouse isattyy no escriba nada en stdout si stdout no apunta a algún lugar interactivo.

SINOPSIS

#include <unistd.h>
int isatty(int fd);

DESCRIPCIÓN La función isatty() prueba si fd es un descriptor de archivo abierto que hace referencia a una terminal.

Este breve programa de Python lo demuestra:

import sys, os

if sys.stdout.isatty():
    print "Hello, tty %s" % os.ttyname(1)
else:
    print "stdout: not a typewriter: how boring"

Al igual que este breve programa en C:

#include <stdio.h>
#include <unistd.h>

int main (void) {
    if ( isatty(stdout) ) {
        printf("Hello, tty %s\n", ttyname(1));
    } else {
        printf("stdout: not a typewriter: how boring\n");
    }
    return 0;
}

Ambos programas tienen el mismo comportamiento:

$ ./isatty > notatty ; cat notatty
stdout: not a typewriter: how boring

$ ./isatty.py
Hello, tty /dev/pts/1

$ ./isatty | cat
stdout: not a typewriter: how boring

Los programas pueden elegir cómo, qué y si imprimen o no en función de si están siendo redirigidos.

Una aplicación común de esto es evitar escribir secuencias de escape ANSI leídas por terminales ( \e[33;1m, etc.) para colorear texto en archivos, lo que se ve feo y confunde a los analizadores.

Respuesta3

Yo tuve el mismo problema. El registro de mi programa no se escribió en [stdout] como se esperaba, sino en [stderr]. Por lo tanto, la solución fue una redirección tanto de [stdout] como de [stderr]:

foo >> someFile.txt 2>&1

información relacionada