/ usr / bin / time de um programa C com E / S não produz resultados

Question

UPDATE

Eu tinha linhas muito longas no arquivo e coloquei uma nova linha após cada caractere 80 (usei o comando sed para isso). Agora os programas funcionam bem. Eu posso cronometrá-los e os resultados fazem sentido.

No entanto, não tenho ideia de por que isso causou um problema.

TLDR;

Usar o comando / usr / bin / time em meus programas em C não funciona como esperado. O comando time termina antes do programa C, às vezes sem saída. Por exemplo,

/usr/bin/time ./cat_8 lorem_ipsum.txt

Descrição do problema

Estou fazendo o exercício 8.1 do K & R do capítulo 8.

Exercise 8-1. Rewrite the program cat from Chapter 7 using read, write, open and close instead of their standard library equivalents. Perform experiments to determine the relative speeds of the two versions.

Excerpt From: Brian W. Kernighan. The C Programming Language, Second Edition

Você pode ver os programas abaixo. O problema que tenho é com os dois programas.

Eu tento cronografar os programas para compará-los. O tamanho do arquivo lorem_ipsum.txt é 35M.

me@virtualbox:~$ ls -hs lorem_ipsum.txt
35M lorem_ipsum.txt

Os programas cat são executados sem problemas, mas não consigo obter um resultado do comando time por algum motivo. O Google não pode ajudar e estou sem noção.

Eu compilei os programas com gcc , sem opções, exceto o -o , é claro. Eu trabalho em uma máquina virtual Ubuntu.

Alguém sabe qual é o problema ou o que estou fazendo errado?

Capítulo 8 (programa cat_8)

#include <fcntl.h>
#include <syscall.h>
#include <stdio.h>

void error(char *fmt, ...);

/* cat: concatenate file */
int main(int argc, char** argv) {

    int fd;
    void filecopy(int, int);
    char *prog = argv[0]; /* program name for errors */

    if (argc == 1)
        filecopy(0, 1);
    else
        while (--argc > 0)
            if ((fd = open(*++argv, O_RDONLY, 0)) == -1)
                error("%s: can't open %s\n", prog, *argv);
            else {
                filecopy(fd, 1);
                close(fd);
            }

    return 0;
}

/* filecopy: copy file ifp to file ofp */
void filecopy(int fdin, int fdout) {
    char buf[BUFSIZ];
    int n;

    while ((n = read(fdin, buf, BUFSIZ)) > 0)
        write(fdout, buf, n);

}

Capítulo 7 (programa cat_7)

#include <stdio.h>
#include <stdlib.h>

/* cat: concatenate file, version 2 */
int main(int argc, char* argv[]) {

    FILE *fp;
    void filecopy(FILE *, FILE *);
    char *prog = argv[0]; /* program name for errors */

    if (argc == 1)
        filecopy(stdin, stdout);
    else
        while (--argc > 0)
            if ((fp = fopen(*++argv, "r")) == NULL) {
                fprintf(stderr, "%s: can't open %s\n", prog, *argv);
                exit(1);
            } else {
                filecopy(fp, stdout);
                fclose(fp);
            }

    if (ferror(stdout)) {
        fprintf(stderr, "%s: error writing stdout\n", prog);
        exit(2);
    }

    return 0;
}

/* filecopy: copy file ifp to file ofp */
void filecopy(FILE *ifp, FILE *ofp) {
    int c;

    while ((c = getc(ifp)) != EOF)
        putc(c, ofp);

}

    

Answer 1

Does anyone know what the problem might be or what I am doing wrong?

Eu não acredito que seja algo errado nas suas duas soluções. Simplesmente não há como eles solicitarem o comportamento que você descreve ... sem forçar um segundo processo (e você não chama fork() ), ou matar o processo time , ou hackear o kernel, etc.

Talvez seu computador esteja quebrado.

Anteriormente, tive um comportamento estranho causado pela corrupção do disco silencioso. Eu poderia tentar executar debsums ou rpm --verify -a para verificar.

Também pode ser um bug na cadeia de software que exibe a saída.

Por exemplo o gnome-terminal 3.22 possui um bug de travamento quando alimentado com uma seqüência de binários . Várias versões do kernel Linux tiveram este grande bug onde enviando mais de 4kB através de um emulador de terminal ("pseudo -tty ") para um programa habilitado para linha de leitura, como um shell, pode perder algumas linhas . Dumping de 35MB de texto por vez é relativamente incomum, pode haver algum bug como esse em seu sistema operacional.

Se você puder reproduzir o problema com um arquivo de entrada de apenas 100kB, aqui está um computador diferente para você que quase certamente não é corrompido da mesma forma que o computador host em que é executado. A saída do console é muito lenta, há apenas alguns megabytes de espaço livre também. A saída de executar seu programa em time não corresponderá a segundos reais por algum motivo, mas não importa para essa questão. A caixa de texto da área de transferência não aceita entrada de teclado para mim (Firefox 53), então usei o menu do botão direito para copiar os dados em /dev/clipboard de acordo com o FAQ.

    

Answer 2

Parece que o programa funciona.

O seu comando de tempo funciona bem?

Tente:

leisner@y50 ~ $ /usr/bin/time sleep 10s                                                                                                                 
0.00user 0.00system 0:10.00elapsed 0%CPU (0avgtext+0avgdata 1728maxresident)k
0inputs+0outputs (0major+75minor)pagefaults 0swaps

Você também está misturando a saída no resultado do tempo? Tente algo como:

time cat myfile.txt >/dev/null

Não deveria - mas a execução em uma VM causa uma camada extra de buffer.