Warum schreibt dieser parallele Prozess die Ausgabe nicht in Dateien, sondern druckt sie stattdessen auf der Konsole aus?

Question

Haftungsausschluss: Dies ist eine allgemeinere Frage der einenIch habe auf biostars.org nachgefragtüber Parallelität und das Schreiben in eine Datei.

Wenn ich ein Programm ausführe (obisplitab obitoolsPaket) liest es sequenziell eine Datei und erstellt eine Anzahl von Dateien basierend auf einem Kriterium (hier nicht wichtig) in der Originaldatei:

input_file.fastq
     |____ output_01.fastq
     |____ output_02.fastq
     |____ output_03.fastq

Wenn ich jedoch die Eingabedatei aufteile und sie parallel ausführe (Version aus Ubuntu-Repo: 20141022),

find . * | grep -P "^input_file" | parallel -j+3 obisplit -p output_{/.}_ -t variable_to_split_on {/}

Ich würde erwarten, Dateien zu bekommen

input_file_a.fastq
     |____ output_input_file_a_01.fastq
     |____ output_input_file_a_02.fastq
     |____ output_input_file_a_03.fastq
input_file_b.fastq
     |____ output_input_file_b_01.fastq
     |____ output_input_file_b_02.fastq
     |____ output_input_file_b_03.fastq
input_file_c.fastq
     |____ output_input_file_c_01.fastq
     |____ output_input_file_c_02.fastq
     |____ output_input_file_c_03.fastq

die Ausgabe wird aber nur auf der Konsole gedruckt.

Gibt es etwas Inhärentes, paralleldas diesen Ausdruck auf der Konsole verursacht, oder könnte es obisplitaus irgendeinem Grund so sein? Gibt es eine Möglichkeit, jeden von ihm kontrollierten Kern davon zu überzeugen, parallelin eine bestimmte Datei statt in die Konsole zu drucken?

Answer 1

Es hört sich so an, als ob obisplitsich das Verhalten anders verhält, wenn die Ausgabe umgeleitet wird.

Sie können GNU Parallel auffordern, in Dateien auszugeben:

seq 10 | parallel --results output_{} echo this is input {} >/dev/null

(oder wenn Ihre Version älter ist:

seq 10 | parallel echo this is input {} '>' output_{}

)

Es entsteht output_#, output_#.err, output_#.seq.