이 병렬 프로세스가 출력을 파일에 쓰지 않고 콘솔에 인쇄하는 이유는 무엇입니까?

이 병렬 프로세스가 출력을 파일에 쓰지 않고 콘솔에 인쇄하는 이유는 무엇입니까?

면책조항: 이것은 보다 일반적인 질문입니다.biostars.org에 물어보니병렬 처리 및 파일 쓰기 정보.

프로그램을 실행할 때(obisplitobitools포장 에서)는 파일을 순차적으로 읽고 원본 파일의 일부 기준에 따라 여러 파일을 만듭니다(여기에서는 중요하지 않음).

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

그러나 입력 파일을 분할하여 병렬로 실행하면(우분투 저장소 버전: 20141022),

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

파일을 받고 싶습니다.

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

그러나 출력은 콘솔에만 인쇄됩니다.

parallel이것이 콘솔을 인쇄하는 고유한 이유가 있습니까 ? 아니면 obisplit어떤 이유로든 그렇게 작동하는 것일 수 있습니까? 각 코어가 parallel콘솔 대신 특정 파일로 인쇄하도록 설득하는 방법이 있습니까 ?

답변1

obisplit출력이 리디렉션되면 동작이 달라질 것 같습니다.

GNU Parallel에게 파일로 출력하도록 요청할 수 있습니다:

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

(또는 버전이 이전인 경우:

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

)

output_#, output_#.err, 을 생성합니다 output_#.seq.

관련 정보