Как перенаправить вывод утилиты, которая генерирует множество отдельных выходных файлов?

Question

Мой процесс сборки использует множество сторонних утилит с закрытым исходным кодом. Эти инструменты генерируют множество файлов, разделенных на три категории: файлы, которые я хочу, отчеты и дерьмо. Иногда я могу выбрать выходной каталог одного или двух из этих файлов, но не все. Остальные файлы просто появляются в текущем каталоге или в новом подкаталоге. Большинство из этих нежелательных файлов не документированы. Новые нежелательные файлы появляются в каждой новой версии этих утилит.

Есть ли способ запустить эти утилиты и перенаправить все операции файловой системы в какой-то указанный подкаталог, где я мог бы скопировать хорошие файлы перед удалением остальных? Я могу перейти в подкаталог для запуска инструментов, но это все портит, поскольку процесс сборки относится к корню проекта. (Инструменты не могут найти нужные файлы.)

UPDATE:

Я надеялся на ответы, в которых использовался какой-то подход «копировать при записи» к файловой системе, чтобы инструменты работали на верхнем уровне, но все файлы эффективно создавались в своем собственном подкаталоге. Если это не вариант, то я думаю, что следующей лучшей вещью будет переход в подкаталог для запуска инструмента. Тогда возникает новый вопрос: как исправить входные данные инструментов, чтобы инструменты могли найти правильные исходные файлы? Это нетривиально. Примерами входных данных для исправления являются аргументы командной строки и пути к файлам внутри файлов конфигурации. Это похоже на подверженную ошибкам и, возможно, неразрешимую проблему.

Answer 1

Давайте рассмотрим несколько эфемер, которые генерирует сборка, в этом примере я в основном думаю о ab

Пример: файлы зависимостей

Пример: скомпилированные объектные файлы

Пример: на самом деле нет, ** дерьмо - это дерьмо **

ОБНОВЛЕНО:

Дополнительные возможные решения

unionfs

Ретаргетинг выход

Волшебная переменная окружения

Xilinx

Игнорирование файлов

• ls --ignore = *. D
• rsync --exclude = .svn, *. D
• grep --exclude = *. D

Answer 2

Краткий ответ: нет. Если эти инструменты должны запускаться в корневом каталоге проекта, то именно здесь они должны запускаться, а если они портят гнездо, то именно это они и делают.

Более длинный ответ: возможно. Если они действительно должны работать в корневом каталоге проекта, то пусть так и будет, но может быть способ автоматически очистить их эффлювию. Вы заранее не знаете имен нежелательных файлов и каталогов, но если вам известны имена требуемых файлов и каталогов, вы можете внести их в белый список и удалить все остальное.

В качестве альтернативы, в зависимости от специфики вашего проекта и ОС, вы можете создать временный каталог с символическими ссылками на файлы в корневом каталоге проекта; для стороннего инструмента это будет выглядеть так же, как настоящий корневой каталог, но когда работа будет завершена, вы сможете выбрать хорошие файлы и удалить остальные, как с обычным временным каталогом. Это будет хорошо работать, если инструмент не пытается создавать файлы в существующих подкаталогах - другими словами, он, вероятно, будет работать, но без обещаний.

Answer 3

Напишите скрипт-обертку для каждой утилиты cd в соответствующий каталог и оттуда запустите реальную утилиту. Сохраните эти сценарии оболочки в вашем «локальном» каталоге bin и поместите этот каталог первым в $ PATH.

Это не удастся, если инструмент использует полный путь при выполнении сторонних утилит.

Вы можете переопределить переменную PATH , указанную в Makefile из командной строки, следующим образом:

$ make PATH=foo:$PATH