У меня была та же проблема. Google привел к этому ответу, но простейшее решение здесь не задокументировано:
ln -sT
-T помогает
man ln:
-T, --no-target-directory
treat LINK_NAME as a normal file always
Просто добавьте это здесь, чтобы любой, у кого возник такой же вопрос, мог найти это:)
{ {1}}Это обходной путь, который я использую для той же самой проблемы:
Создайте сценарий, который использует источники ~ / .profile
и сделать этот скрипт исполняемым. Назовем его /path/to/startup.sh
. Это может выглядеть примерно так:
#!/bin/bash
. ~/.profile
Создайте настольное приложение для запуска сценария. Для этого вам необходимо создать файл .desktop
и поместить его в ~ / .local / share / applications
(или / usr / share / applications
, если вы хотите, чтобы он работал для всех пользователей). Назовем его ~ / .local / share / applications / startup.desktop
. Это может выглядеть примерно так:
[Desktop Entry]
Name=Startup
Keywords=startup
Exec=/path/to/startup.sh
Type=Application
Для получения дополнительной информации о файлах .desktop
см. здесь .
Выйти. Войдите снова. Теперь у вас должна быть возможность искать свое приложение в меню приложений.
Установите это приложение как приложение для запуска. Для этого я использовал инструмент Gnome Tweak Tool и добавил свое приложение в список на вкладке «Приложения для запуска».
Вот и все! Теперь вы должны вернуть свои старые функции при каждом входе в систему. Он также сохраняет структуру файлов нетронутой, поэтому, когда ошибка в Wayland будет исправлена, все, что вам нужно сделать, это удалить приложение из списка запускаемых приложений, удалить два файла и все вернулось в норму.
Как @Guss указывает в комментариях, этот обходной путь не будет экспортировать переменные среды, потому что startup.sh
запускается в собственной оболочке. Поэтому нам нужен другой обходной путь для них.
Прочитав документацию GNOME , вы увидите, что есть несколько альтернатив. Единственное, что я мог заставить работать, - это создать файл в /usr/share/gdm/env.d/
и поместить в этот файл экспортируемые переменные. Однако это означает, что переменные будут экспортированы для всех пользователей, поэтому в итоге я сделал следующее:
Допустим, у нас есть два пользователя, john и sally . Для каждого из них создайте файл в /usr/share/gdm/env.d/
, назовем их startup_john.env
и startup_sally.env
. В эти файлы поместите переменные среды, которые будут экспортироваться при запуске нового сеанса GNOME.
$ cat startup_john.env
VAR=1
$ cat startup_sally.env
VAR=2
На этом этапе проблема в том, что оба файла будут загружены для обоих пользователей. Чтобы решить эту проблему, мы устанавливаем разрешение для каждого файла так, чтобы только его владелец мог читать его содержимое.
$ ls -l startup_john.env
-rw-r-----. 1 john john 4 Dec 27 15:17 startup_john.env
$ ls -l startup_sally.env
-rw-r-----. 1 sally sally 4 Dec 27 15:16 startup_sally.env
Не самое элегантное решение, я согласен, но, насколько я тестировал, похоже, оно выполняет свою работу.