Linux и Excel

Единственное, по чему можно скучать в Windows при переходе на Linux — это Excel. Можно перепробовать всё, что только можно: клоны Office, базы данных, работу с данными в Python… но Excel уникален. Если вы работаете с числами, замены ему нет. Если вы с этим не согласны — значит, вы просто никогда не пользовались PowerQuery :)

Жить без Excel для многих оказывается настоящим испытанием. Один из очевидных способов — запустить Windows в виртуальной машине, например через Oracle VirtualBox. Это работает, но требует каждый раз поднимать отдельную ОС внутри Linux — со всеми вытекающими: расход ресурсов, свой рабочий стол, отдельный буфер обмена, отдельные папки. Уже само время, которое уходит на запуск и работу виртуалки, превращает такой подход в неудобный и тяжёлый, не говоря уже о проблемах с путями к файлам и копированием данных.

Windows-приложения в Linux

Пару недель назад всё поменялось, когда я наткнулся на WinApps. WinApps тоже использует виртуалку, но позволяет запускать Windows-приложения как удалённые — так, что они выглядят как родные для Linux. Вау! Настроить всё это было непросто, но в итоге (почти) заработало, и я был впечатлён. Windows-приложения запускались, и я мог обращаться с ними почти как с нативными на своей Linux-машине. WinApps даже создаёт ярлыки, которые появляются в меню приложений.

Как я уже сказал, настройка оказалась непростой, и даже когда всё завелось, до идеала было далеко. WinApps использует виртуальную машину в связке с Docker и FreeRDP, а ещё требует правильной настройки KVM — иначе ничего не взлетит. У меня постоянно возникали какие-то рандомные проблемы: виртуалка не всегда корректно завершалась, приложения иногда переставали запускаться, да и другие странности случались. Так что Windows-приложения на Linux — это хорошо. Надёжность и отсутствие головной боли — увы, нет.

Ища решения, я наткнулся на WinBoat. Представьте WinBoat как более аккуратно упакованную версию того, что делает WinApps. По сути, WinBoat основан на тех же технологиях, но «делает всю настройку за вас, если у вас уже стоят нужные зависимости», и в итоге процесс становится гораздо проще. У меня всё заработало заметно лучше. Приложения запускались стабильно, проблем с ресурсами почти не было. Главный минус — запуск идёт через приложение WinBoat, так что интеграция с рабочим столом не такая глубокая, как у WinApps. Но, на мой взгляд, это мелочь по сравнению с огромным плюсом в простоте и стабильности. Если вы хотите Windows-приложения в Linux без лишней боли — попробуйте WinBoat.

И WinApps, и WinBoat — это гораздо более удобные и интегрированные решения по сравнению с моей первой попыткой с виртуалкой, но именно их «вписанность» в рабочий стол Linux меняет всё.

Ничего нового

Подумав, что откопал что-то гениальное, я рассказал об этом брату (он пользуется Mac). Он сказал: «О, звучит как Parallels», — и тут же начал объяснять, что уже много лет так делает. Потом добавил, что вообще-то он уже ушёл от Parallels и просто пользуется Windows RemoteApp, чтобы запускать нужные приложения. Когда мы обсудили это и я разобрал, что делают WinApps и WinBoat, оказалось, что это по сути тот же самый RemoteApp, только упакованный так, чтобы среднему пользователю было проще всё запустить. Но вместе с этой «упаковкой» приходит и лишний оверхед, который, как мне показалось, не нужен. Поэтому я решил попробовать собрать всё сам.

После пары экспериментов и ошибок у меня получилось сделать это так, что система стала есть гораздо меньше ресурсов и при этом дала мне больше контроля.

DIY-подход

Какой бы способ вы ни выбрали, стоит понимать заранее: вам понадобится полноценная Windows. Если хотите запускать Office (или Microsoft 365), нужна лицензия. Так что это точно не вариант для FOSS-пуристов, но, думаю, если вы уже хотите гонять Windows-приложения под Linux, вопрос идеологии вас не особо тревожит — вам просто нужно работать.

У меня завалялся старый ноутбук, который пылился без дела, и я подумал: а что если использовать RemoteApp на нём и не держать Docker с Windows-VM локально? Так можно разгрузить основной компьютер и переложить всю работу на отдельную Windows-машину. Ответ — да, так можно.

Чтобы всё заработало, вам понадобится:

Компьютер с Windows 10 или 11 (обязательно версия Pro, так как нужен Remote Desktop).
Очень рекомендую сразу настроить статический IP для этой машины.
FreeRDP на вашей Linux-машине.

Шаг 1: Настройка Windows-машины

Запускаем Windows, включаем Remote Desktop и убеждаемся, что знаем IP-адрес этой машины. Ещё понадобятся имя пользователя и пароль для учётной записи, под которой вы будете подключаться. У меня для этого есть один админский аккаунт, но теоретически можно создать отдельную учётку специально для удалённого доступа — главное, чтобы у неё был включён Remote Desktop.

Шаг 2: Установка FreeRDP

Когда Windows готова, нужно поставить FreeRDP на ваш Linux-компьютер. Ничего сложного: есть готовые пакеты для Ubuntu, Debian, Fedora и OpenSUSE.

После установки нужно проверить, что удалённое подключение к рабочему столу (RDC) работает. Открываем терминал и выполняем что-то вроде:

xfreerdp /u:"username" /p:"password" /v:192.168.1.1 /cert:tofu

Где username и password — ваши учётные данные Windows, а 192.168.1.1 — IP вашей машины.

Если всё настроено правильно, вы попадёте на рабочий стол Windows.

Конечно, можно просто запускать любые Windows-приложения внутри этого рабочего стола, но цель — запускать их удалённо как отдельные приложения. На этом месте мы двинемся дальше.

Шаг 3: Тестируем запуск приложений удалённо

Когда вы убедились, что удалённое подключение к Windows работает, можно переходить к запуску отдельных приложений через RemoteApp.

Здесь важно знать точный путь к исполняемому файлу в Windows — иначе ничего не выйдет. Запишите пути к нужным программам заранее. Я, например, вначале ошибся: написал Office 16 вместо Office16, и из-за этого потерял больше часа, разбираясь, почему оно не запускается.

Чтобы протестировать запуск, можно выполнить в терминале команду примерно такого вида:

xfreerdp /u:"username" /p:"password" /v:192.168.1.1 /cert:tofu /dynamic-resolution /app:program:"C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE" -themes +clipboard

Разберём, что здесь происходит:

xfreerdp /u:"username" /p:"password" /v:192.168.1.1 /cert:tofu

Это просто подключение к машине — та же команда, что мы использовали раньше для входа в Windows.
/dynamic-resolution
Включает динамическое изменение разрешения, чтобы можно было свободно менять размер окна приложения, как у нативных Linux-программ.
/app:program:"C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE"
Вот тут магия: этот флаг говорит FreeRDP, что мы хотим запустить конкретное приложение, и указывает путь к его .exe на Windows-машине.
Не работает? Проверьте путь ещё раз — чаще всего проблема именно в нём.
-themes +clipboard
-themes отключает загрузку тем оформления Windows (оно нам не нужно при запуске отдельных приложений, зачем тащить лишний мусор).
+clipboard включает работу буфера обмена между Linux и Windows. Это важно помнить: приложения на самом деле работают на удалённой Windows, а системы друг о друге ничего не знают. Этот флаг позволяет копировать/вставлять данные между ними.

Хорошая новость в том, что этот способ сработает для любого Windows-приложения, которое вы хотите запускать.

А ещё приятно, что если программа внутри себя вызывает другую (например, настройки Windows), они тоже откроются на вашей Linux-машине как отдельные окна.

Например, я как-то открыл Word, решил распечатать документ, а принтер в Windows ещё не был настроен. Word вызвал стандартное окно настроек принтера Windows — я добавил устройство и спокойно продолжил печатать. Красота, работает как нативное.

На этом этапе уже можно остановиться и просто запускать нужные приложения из терминала.

Либо можно использовать графический RDP-клиент и настроить отдельные RDP-сеансы для каждого приложения (я проверял — Thincast работает), получив что-то вроде WinBoat.

Но мне хотелось настоящей интеграции с рабочим столом Linux — и два следующих шага дали именно это.

Шаг 4 (опционально): создаём shell-скрипты

Мне нужна максимальная гибкость, поэтому я решил сделать исполняемые shell-скрипты для запуска каждого приложения. Располагать их можно где угодно, но для порядка я сложил всё в /home/[user]/.local/bin/remoteapps/. Скрипты предельно простые — они просто вызывают команду FreeRDP, которую мы уже смотрели. Вот мой excel.sh:

#!/bin/bash
echo -ne "\033]0;Excel\007"
xfreerdp /u:"username" /p:"password" /v:192.168.1.1 /cert:tofu /dynamic-resolution /app:program:"C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE" -themes +clipboard

Не забудьте сделать скрипт исполняемым. В терминале это будет:

chmod +x excel.sh

или клик правой кнопкой по файлу → «Свойства» → отметить как исполняемый в GUI.

Я делаю такой скрипт для каждого приложения, которое хочу запускать на Linux-машине, включая отдельный — для самой Windows, чтобы при необходимости быстро зайти в ОС по RDP.

Шаг 5 (опционально): создаём desktop-файлы

Последний штрих для полноценной интеграции — ярлыки на рабочем столе, чтобы запускать приложения с десктопа и/или из лаунчера как любые другие. Эти ярлыки указывают на только что созданные shell-скрипты. Ваши .desktop-файлы должны лежать там же, где и остальные .desktop-файлы. В моём дистрибутиве это /home/[user]/.local/share/applications/.

Вот мой .desktop для Excel:

[Desktop Entry]
Name=Excel
Exec=/home/[user]/.local/bin/remoteapps/excel.sh %F
Terminal=false
Type=Application
Icon=/home/[user]/.local/share/remoteapps/icons/excel/icon.svg
StartupWMClass=Microsoft Excel
Comment=Microsoft Excel
Categories=WinApps;Office
MimeType=application/vnd.ms-excel;application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;application/vnd.openxmlformats-officedocument.spreadsheetml.template;application/vnd.ms-excel.sheet.macroEnabled.12;application/vnd.ms-excel.template.macroEnabled.12;application/vnd.ms-excel.addin.macroEnabled.12;application/vnd.ms-excel.sheet.binary.macroEnabled.12;

Пара моментов, на которые стоит обратить внимание.

Так как вы задаёте категории и MIME-типы, Linux сможет ассоциировать эти ярлыки как приложения по умолчанию для определённых файлов. Например, можно связать .xlsx с ярлыком Excel. НО так как Excel работает в другой ОС, приложение откроется, а файл — нет, из-за различий в путях. Обидно, но не критично: просто открывайте файл вручную.
Вы увидите путь к иконке приложения. В WinApps и WinBoat иконки идут «из коробки», но в DIY-подходе это нужно настроить вручную. У меня иконки лежат в /home/[user]/.local/share/remoteapps/icons, а сами файлы я взял из репозитория WinApps: https://github.com/winapps-org/winapps/tree/main/apps.
В строке Exec указан путь к созданному shell-скрипту. Теоретически можно запускать команду FreeRDP прямо отсюда и обойтись без скрипта — я этого не пробовал.

Файлы, нюансы и другие мысли

Один важный момент, который нужно продумать заранее, — как хранить файлы так, чтобы к ним был доступ и с Windows, и с Linux. Я делаю так, чтобы закрыть все сценарии:

NextCloud для всего «офисного».

Файлы, почта, календарь, задачи — всё это у меня в NextCloud. Десктопный клиент NextCloud синхронизирует данные между всеми моими машинами и телефоном. Если запустить его и на Linux, и на Windows, можно спокойно сохранять файлы в папки NextCloud и держать их в актуальном состоянии в обеих системах.

Сетевой ресурс на Linux как запасной вариант.

Пока не понадобилось, но на всякий случай у меня есть шаринг с Linux-машины. В Windows просто подключаю его через Проводник и закрепляю в «Избранном».

OneDrive — потому что он идёт в комплекте с Microsoft 365.

В моём случае NextCloud умеет подключать OneDrive как плагин, так что я могу видеть его файлы прямо в NextCloud.

Стоит знать: некоторые функции Office работают только если файлы лежат в OneDrive (AAARGH!).

Например, автосохранение и часть нового функционала Copilot не работают, если документ не в OneDrive. Плохой дизайн, на мой взгляд (спасибо, Microsoft), но это реальность, и важно понимать ограничения.

Главный минус OneDrive — для Linux нет нормального официального клиента.

Поэтому всё, что вы кладёте в OneDrive, нужно как-то синхронизировать с Linux — например, через NextCloud или rclone (можно настроить автоматизацию). Это работает, но не особенно красиво и требует отдельной настройки, которую я тут подробно не описываю.

Конечно — вот как этот кусок можно оформить в том же стиле, что и остальная статья, без лишнего официоза и добавлений «от себя», только по делу:

(Бонус) Автоматическое открытие файлов из Linux в Excel

После того как всё заработало, я захотел пойти ещё дальше — запускать Excel сразу с нужным файлом, передавая ему путь прямо из Linux.

Проблема в том, что Linux и Windows видят файловую систему по-разному, а Excel внутри RemoteApp ожидает Windows-путь вроде Z:\Documents\file.xlsx, а не /home/user/Documents/file.xlsx.

Чтобы это обойти, я смонтировал свою домашнюю директорию Linux в Windows как сетевой диск (у меня это буква Z:), а затем чуть доработал скрипт excel.sh, чтобы он автоматически конвертировал путь.

#!/bin/bash
echo -ne "\033]0;Excel\007"

# Берём первый аргумент (путь к файлу в Linux)
# Заменяем /home/[user] на Z: — путь к примонтированному диску в Windows
winpath="${1/\/home\/[user]/Z:}"

# Меняем прямые слэши на обратные для Windows
winpath="${winpath//\//\\}"

# Запускаем Excel, передавая получившийся путь
xfreerdp /u:"username" /p:"password" /v:192.168.1.1 /cert:tofu \
  /dynamic-resolution \
  /app:program:"C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE",cmd:"$winpath" \
  -themes +clipboard

Теперь можно просто написать:

excel.sh ~/Documents/report.xlsx

и Excel откроется сразу с этим файлом на удалённой Windows-машине — никакого ручного поиска документа в Проводнике.

💡 Если у вас файлы живут в Nextcloud или OneDrive, можно сделать то же самое — просто заменить /home/[user]/Nextcloud (или другой путь) на реальный путь к этой папке в Windows, например C:\Users\Имя\Nextcloud.