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

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

면책조항: 이것은 보다 일반적인 질문입니다.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.

관련 정보