Devo usare parentesi singole o doppie per reindirizzare a / dev / null?

La maggior parte delle risposte qui ^{[ 1 ] [ 2 ] [ 3 ]} usa una parentesi angolare singola per reindirizzare a / dev / null, in questo modo:

command > /dev/null

Ma l'aggiunta a / dev / null funziona anche:

command >> /dev/null

Tranne il personaggio in più, c'è qualche motivo per non farlo? Uno di questi è "più bello" per l'implementazione sottostante di / dev / null?

Modifica:
la manpage aperta (2) dice che lseek viene chiamato prima di ogni scrittura su un file in modalità append:

O_APPEND
Il file viene aperto in modalità append. Prima di ogni scrittura (2), l'offset del file viene posizionato alla fine del file, come se con lseek (2). La modifica dell'offset del file e l'operazione di scrittura vengono eseguite come un singolo passaggio atomico.

il che mi fa pensare che potrebbe esserci una minuscola penalità prestazionale per l'utilizzo >>. D'altra parte, troncare / dev / null sembra un'operazione indefinita secondo quel documento:

O_TRUNC
Se il file esiste già ed è un file normale e la modalità di accesso consente la scrittura (ovvero O_RDWR o O_WRONLY) verrà troncata alla lunghezza 0. Se il file è un FIFO o un file del dispositivo terminale, il flag O_TRUNC viene ignorato. Altrimenti, l'effetto di O_TRUNC non è specificato.

e le specifiche POSIX indicano che troncerà >un file esistente , ma O_TRUNC è definito dall'implementazione per i file del dispositivo e non c'è parola su come / dev / null dovrebbe rispondere al troncamento .

Quindi, troncare / dev / null in realtà non è specificato? E le chiamate lseek hanno alcun impatto sulle prestazioni di scrittura?

Per definizione /dev/nullaffonda tutto ciò che vi è stato scritto , quindi non importa se si scrive in modalità append o no, è tutto scartato. Dal momento che non memorizza i dati, in realtà non c'è nulla da aggiungere.

Quindi, alla fine, è solo più breve scrivere > /dev/nullcon un >segno.

Per quanto riguarda l'aggiunta modificata:

La manpage open (2) dice che lseek viene chiamato prima di ogni scrittura su un file in modalità append.

Se leggi attentamente, vedrai che dice (enfasi mia):

l'offset del file viene posizionato alla fine del file, come se con lseek (2)

Significa che in realtà non è necessario (è necessario) chiamare la chiamata di lseeksistema e l'effetto non è neppure lo stesso: chiamare lseek(fd, SEEK_END, 0); write(fd, buf, size);senza O_APPENDnon è lo stesso di una scrittura in modalità append, poiché con chiamate separate un altro processo potrebbe scrivere nella file tra le chiamate di sistema, eliminando i dati aggiunti. In modalità accodamento, ciò non accade (ad eccezione di NFS, che non supporta la modalità accodamento reale ).

Il testo dello standard non menziona lseeka quel punto, solo che le scritture vanno alla fine del file.

Quindi, troncare / dev / null in realtà non è specificato?

A giudicare dalle Scritture a cui ti riferisci, apparentemente è definito dall'implementazione. Ciò significa che qualsiasi implementazione sana farà lo stesso che con le pipe e le TTY, vale a dire nulla. Un'implementazione folle potrebbe fare qualcos'altro e forse il troncamento potrebbe significare qualcosa di sensato nel caso di qualche altro file del dispositivo.

E le chiamate lseek hanno alcun impatto sulle prestazioni di scrittura?

Provalo. È l'unico modo per saperlo con certezza su un determinato sistema. Oppure leggi la fonte per vedere dove la modalità append modifica il comportamento, se ovunque.

Se è l'efficienza che desideri, usa command >&-invece. Questo chiude il descrittore di file piuttosto che reindirizzarlo, quindi non si perde tempo a scrivere cose su di esso.