Я пытаюсь запустить простую программу c++ ниже на компьютерном кластере (под управлением Linux, CentOS 6).
#include <iostream>
#include <fstream>
int main(int argc, char *argv[]) {
std::ofstream file;
file.open("/dev/stdout");
file << "Hello, world\n";
file.close();
return 0;
}
Когда я компилирую (используя g++ test.cpp
) и запускаю программу на головном узле, он работает так, как я ожидал бы, если я дам выход перейти на терминал, чтобы перенаправить его в файл. То есть,
$ ./a.out > myfile.txt
создает файл myfile.txt
, содержащий строку "Hello, world" (я использую bash). Если я запустил его на любом из узлов выполнения и давал вывод на терминал, он работает нормально; однако, если я попытаюсь перенаправить вывод в файл, файл всегда пуст.
Я знаю, что это не "стандартный" способ написать мировую программу hello в c++. У меня действительно возникают трудности с сторонней программой, которая пытается записать двоичные данные в стандартный вывод с использованием библиотеки, требующей имени файла. Пытаясь сократить код для публикации, я обнаружил, что приведенный выше простейший код воспроизводит проблему, которую я вижу в более крупной программе.
Я не являюсь программистом c++, поэтому понятия не имею, должен ли приведенный выше пример работать или не должен работать, но тот факт, что он работает на некоторых компьютерах, как я ожидал, но не с другими, меня смутили. Я также не уверен, связано ли это с кодом c++, bash или конфигурацией системы. Люди, о которых я спрашивал об этом, уже кажутся одинаково запутанными и не могли даже предложить, с чего начать.
Я создал простые мировые программы hello на других языках, и все они работают как ожидалось на узлах выполнения, поэтому я предполагаю, что это что-то особенное для c++.
Может кто-нибудь объяснить мне или помочь мне определить, почему я наблюдаю различное поведение на машинах, работающих с той же ОС (и которые должны быть настроены одинаково), и есть ли (предпочтительный) способ в c++ получить библиотеку функции, для которых требуется имя файла для записи в stdout?
Я осмотрелся и нашел, что может быть или не быть программой, которую вы используете: uuencode. Если это не так, проигнорируйте весь этот ответ. Эта программа выглядит сложно, поэтому я опишу, что я думаю, это разумный способ ее использования:
Дайте что-нибудь как "имя выходного файла" в uuencode
uuencode mybinaryfile anything > mytextfile
Затем передайте полученный "mytextfile" в новую систему, в которой вы запускаете
uudecode mytextfile -o mynewbinaryfile
Что производит "mynewbinaryfile". Опять же, дизайн этой программы (особенно аргумент, который я передал как "что-либо") невелик, и существуют проблемы с контентом и типом при перемещении двоичных файлов с одной машины на другую, которую игнорирует эта программа. Я рекомендую отойти от него.
Что касается объяснения, то uudecode пытался писать в /dev/stdout, а на кластерах и машинах HPC все обычные размещения, такие как /dev/stdout, уже не то, что они кажутся.
file /dev/stdout
на вычислительном узле?
Вероятно, проблема fstream.open()
с параметром mode
для fstream.open()
.
И, кстати, это довольно странный способ выполнить вывод configure...
stdout
и он действительно работает на головном узле - проблема может заключаться в том, что у вашего кластера нет безопасного кластерного стандартногоstdout
; что это за кластер?