Путь к исполняемому файлу оболочки dotnet не является файлом или символической ссылкой
Обновлено: 05.07.2024
Команда 'dotnet' не найдена, но может быть установлена с помощью: sudo snap install dotnet-sdk`
Я ожидал, что сценарий сделает все и сделает доступным dotnet .
2 ответа
TL; DR: curl | bash не может изменить PATH , поэтому он не добавит dotnet в ваш PATH . Вам нужно добавить dotnet в свой путь вручную. Добавьте export PATH="$PATH:/home/<!username!>/.dotnet" в свой
/.bashrc или аналогичный), выйдите из системы и снова войдите в систему.
Когда вы запускаете команду в оболочке (например, bash), оболочка пытается найти исполняемый файл с именем во всех путях, перечисленных в переменной среды PATH . PATH обычно устанавливается на что-то вроде /bin:/usr/bin . Поэтому, когда вы набираете команду типа curl , ваша оболочка ищет как в /bin , так и в /usr/bin исполняемый файл с именем curl .
Вы можете увидеть, что делает ваш PATH , выполнив env | grep PATH или echo $PATH .
Другая важная информация - это то, как распространяются переменные среды. На самом деле это довольно просто:
- Программа (или процесс) может изменять только свой собственный набор переменных среды.
- Любые дочерние процессы, создаваемые процессом, наследуют его переменные среды.
Это означает, что программа, которую вы выполняете, не может изменять переменные среды другой случайной программы. Оболочка фактически предоставляет специальную команду export для установки собственных переменных среды (и любые дочерние процессы, которые она создает позже, наследуют их).
Обратите внимание на результат в конце шага 1.
Примечание. Это изменение будет видно только при поиске скрипта.
Если вы запустите curl | bash , он запустит bash как дочерний процесс. Этот дочерний процесс не может изменять переменные среды программы, которая его запустила (оболочки, которая вызвала curl | bash ). Таким образом, он не может изменить PATH , чтобы добавить к нему местоположение dotnet . Он даже (услужливо) говорит вам, что не может.
На шаге 2 вы перезагружаете
/.profile . Но содержит ли он какие-либо команды для добавления dotnet в PATH ? Я так не думаю. Я знаю, что сценарий dotnet-install.sh исторически не добавлял его. Вам нужно добавить строку вроде
/.bashrc , или аналогичный) вручную.
На самом деле, чтобы сделать изменение более переносимым для других пользователей, я бы написал его следующим образом:
Исполняемый файл не найден
Имя исполняемого файла определяет то, как вызывается средство. Формат описывается в приведенной ниже таблице.
| Формат имени исполняемого файла | Формат вызова |
|---|---|
| dotnet-<toolName>.exe | dotnet <toolName> |
| <toolName>.exe | <toolName> |
Глобальные средства
Глобальные средства можно установить в каталоге по умолчанию или в выбранном вами расположении. Каталоги по умолчанию:
| Операционная система | Path |
|---|---|
| Linux/macOS | $HOME/.dotnet/tools |
| Windows | %USERPROFILE%\.dotnet\tools |
Если вы пытаетесь запустить глобальное средство, убедитесь в том, что переменная среды PATH на компьютере содержит путь, по которому установлено глобальное средство, и что исполняемый файл находится по этому пути.
Локальные средства
Если вы пытаетесь запустить локальное средство, убедитесь в наличии файла манифеста с именем dotnet-tools.json в текущем каталоге или в любом из его родительских каталогов. Этот файл также может находиться в папке .config где угодно в иерархии папок проекта, а не в корневой папке. Если файл dotnet-tools.json существует, откройте его и проверьте наличие средства, которое вы пытаетесь запустить. Если в файле нет записи для "isRoot": true , также проверьте наличие дополнительных файлов манифестов средств выше в иерархии файлов.
Среда выполнения не найдена
Накат не выполняется по умолчанию в двух распространенных сценариях:
- доступны только более ранние версии среды выполнения; при накате выбираются только более поздние версии среды выполнения;
- доступны только более поздние основные версии среды выполнения. При накате границы основной версии не пересекаются.
Если приложению не удается найти подходящую среду выполнения, оно не запускается и сообщает об ошибке.
Изменение имен пакетов
Корпорация Майкрософт изменила правила в отношении идентификаторов пакетов для средств, из-за чего некоторые средства теперь невозможно найти по прежним именам. Согласно новым правилам имена средств Майкрософт должны иметь префикс "Microsoft.". Этот префикс зарезервирован и может использоваться только для пакетов, подписанных с помощью авторизованного сертификата Майкрософт.
Во время перехода некоторые средства Майкрософт будут иметь старую форму идентификатора пакета, а другие — новую форму:
По мере обновления идентификаторов пакетов необходимо будет перейти на новый идентификатор, чтобы получить последние обновления. Пакеты с упрощенными именами средств станут нерекомендуемыми.
Предварительные выпуски
- Вы пытаетесь установить предварительный выпуск и не использовали параметр --version для указания версии.
NU1212: недопустимое сочетание проекта и пакета для <toolName> . Стиль проекта DotnetToolReference допускает только ссылки типа DotnetTool.
Веб-канал NuGet недоступен
- Не удается получить доступ к требуемому веб-каналу NuGet, возможно, из-за проблемы с подключением к Интернету.
Для установки средства требуется доступ к веб-каналу NuGet, содержащему пакет средства. Установка завершается сбоем, если этот веб-канал недоступен. Вы можете изменить веб-каналы с помощью nuget.config , запросить определенный файл nuget.config или указать дополнительные веб-каналы с помощью параметра --add-source . По умолчанию NuGet выдает ошибку для каждого веб-канала, к которому не удается подключиться. Флаг --ignore-failed-sources позволяет пропускать недоступные источники.
Неправильный идентификатор пакета
401 (не санкционировано)
Скорее всего, вы указали альтернативный канал NuGet, и этот канал требует проверки подлинности. Вот несколько разных способов решить проблему:
Добавьте параметр --ignore-failed-sources , чтобы обойти ошибку из закрытого канала и использовать общедоступный канал Майкрософт.
Если вы устанавливаете средство из канала Microsoft NuGet, пользовательский канал возвращает эту ошибку, прежде чем канал Microsoft NuGet вернет результат. Ошибка завершает запрос, отменяя любые другие ожидающие запросы канала, который может быть каналом Microsoft NuGet. Добавление параметра --ignore-failed-sources приводит к тому, что команда обрабатывает эту ошибку как предупреждение и позволяет другим каналам обработать запрос.
Принудительно используйте канал Microsoft NuGet с параметром --add-source .
Возможно, в глобальном или локальном файле конфигурации NuGet отсутствует общедоступный канал Microsoft NuGet. Используйте сочетание параметров --add-source и --ignore-failed-sources , чтобы избежать ошибочного канала и использовать общедоступный веб-канал Майкрософт.
Используйте настраиваемую конфигурацию NuGet, параметр --configfile <FILE> .
Я создаю сценарий оболочки, который берет имя файла / путь к файлу и определяет, является ли файл символической ссылкой или жесткой ссылкой.
Единственное, я не знаю, как узнать, являются ли они жесткой связью. Я создал 2 файла, один из которых является жесткой ссылкой, а другой - символической ссылкой для использования в качестве тестового файла. Но как мне определить, является ли файл жесткой ссылкой или символическим в сценарии оболочки?
Кроме того, как я могу найти целевой раздел символической ссылки? Допустим, у меня есть файл, который ссылается на другой раздел, как мне найти путь к этому исходному файлу?
Что вы подразумеваете под жесткой ссылкой? Все файлы являются жесткими ссылками. @terdon ln /foo/bar/ /foo/bar2 делает жесткую ссылку, в то время как ln -s /foo/bar /foo/bar2 делает символическую ссылку, вот что он имеет в виду? @DisplayName да, но все файлы являются жесткими ссылками на их индекс. Вот как работают файловые системы Linux. В вашем примере bar2 и bar обе жесткие ссылки, просто указывающие на один и тот же индекс. @DisplayName да, это жесткие ссылки на другие иноды . Здесь нет противоречия. Файл - это ссылка на индекс. Это определение файла. В вашем случае у вас есть эти ссылки в разных местах, но это не меняет основную структуру данных. Моя точка зрения заключается в том, что оба bar и bar2 одинаково важны. Одна не является ссылкой на другую, они обе являются ссылками, но указывают на один и тот же индекс. @ Скотт нет, я говорю, что обычные файлы - это жесткие ссылки, и созданные жесткие ссылки ln ничем не отличаются от обычных файлов.Ответ Джим объясняет , как проверить на линке: с помощью test «s -L тест.
Но тестирование на «жесткую ссылку», строго говоря, не то, что вы хотите. Жесткие ссылки работают из-за того, как Unix обрабатывает файлы: каждый файл представлен одним индексом. Тогда один инод имеет ноль или более имен или записей каталога или, технически, жестких ссылок (то, что вы называете «файлом»).
К счастью, stat команда, где она доступна, может сказать вам, сколько имен у inode.
Итак, вы ищете что-то вроде этого (здесь предполагается реализация GNU или busybox stat ):
Этот -c '%h' бит говорит stat просто выводить количество жестких ссылок на индекс, т. Е. Количество имен в файле. -gt 1 затем проверяет, больше ли это 1.
Обратите внимание, что символические ссылки, как и любые другие файлы, также могут быть связаны с несколькими каталогами, поэтому вы можете иметь несколько жестких ссылок на одну символическую ссылку.
Хорошо, просто для ясности, я могу вывести количество жестких ссылок, которые имеет файл, используя команду stat, и если его значение больше 1, то у него есть другой файл, связанный где-то в разделе. @ K-Rocker Да. Тогда у него есть второе имя где-то в разделе. На OS X или * BSD это так stat -f %l /path/to/file . Вы также можете использовать, gstat -c %h /path/to/file если у вас установлены GNU coreutils без имен по умолчанию (с Homebrew на OS X).В f1 , f2 и f3 запись каталога и тот же файл (тот же индексный дескриптор: 10802124, вы заметите , количество ссылок является 3). Это жесткие ссылки на один и тот же обычный файл.
s4 а s5 также тот же файл (10802384). Они имеют тип symlink , а не обычные . Они указывают на путь, здесь s3 . Поскольку s4 и s5 являются записями одного и того же каталога, этот относительный путь s3 указывает на один и тот же файл (файл с inod 10802347) для обоих.
Если вы делаете ls -Ll , то запрашиваете информацию о файле после разрешения символических ссылок:
Вы найдете, что они все разрешают к тому же файлу (10802124).
Вы можете проверить, является ли файл символической ссылкой [ -L file ] . Точно так же вы можете проверить, является ли файл обычным файлом [ -f file ] , но в этом случае проверка выполняется после разрешения символических ссылок.
Жесткие ссылки - это не тип файла, это просто разные имена для файла (любого типа).
Использование -h и -L операторы test команды:
Согласно этому потоку SO , они ведут себя одинаково, но -L предпочтительнее.
хорошо, круто, а как насчет жестких ссылок? Я проверил шаг, но ничего о жестких ссылках. Если -L возвращает false, означает ли это жесткую ссылку? или просто обычный файл? Жесткие ссылки делят то же самое inode . Кроме того, программные ссылки показывают l в начале ls -l вывода . Я думаю, что вы можете объединить эти правила в сценарии, а также [[ -L file ]] проверить, является ли данный файл мягким или жестким . Хорошо, также, как я могу найти целевой раздел символической ссылки?Если ты читаешь все это и понимаешь, что происходит, тогда ты в порядке; Вам не нужно читать мою маленькую часть. Если вы все еще в замешательстве, то продолжайте.
Действительно очень короткий ответ заключается в том, что жесткая ссылка на самом деле вовсе не ссылка, а не символическая ссылка. Это новая запись в структуре каталогов, которая указывает на тот же набор байтов, что и оригинальная запись каталога, и после того, как вы ее создали, она так же «реальна» и легитимна, как и первая. Каждый «нормальный» файл на вашем диске имеет хотя бы одну жесткую ссылку; без этого вы бы не увидели ни в одномкаталог, и не сможет ссылаться на него или использовать его. Поэтому, если у вас есть файл Fred.txt и вы жестко связываете с ним Wilma.txt и Barney.txt, все три имени (и записи каталога) ссылаются на один и тот же файл, и все они одинаково действительны. Для ОС нет никакого способа сказать, что одна из записей была создана, когда вы нажали «сохранить» в текстовом редакторе, а другие были сделаны с помощью команды «ln».
ОС действительно должны отслеживать , сколько различных записей , указывающих на тот же файл, хотя. Если вы удалите Wilma.txt, не удивительно, что вы не освободите место на диске. Но если вы удалите Fred.txt («оригинальный» файл), вы все равно не освободите место на диске, потому что данные на диске, который был известен как Fred.txt, по-прежнему также Barney.txt. Только когда вы удалите все записи каталога, ОС освободит место, которое занимали сами данные.
Поскольку ОС должна отслеживать, сколько разных записей каталога указывают на один и тот же кусок данных, вы можете определить, была ли жесткая ссылка на конкретный файл, даже если вы не можете точно сказать, является ли эта запись каталога Вы смотрите на «оригинал» или нет. Одним из способов является команда «ls», а именно «ls -l» (это строчная буква L после тире)
Заимствовать более ранний пример .
Первая буква - тире, так что это не каталог или что-то еще экзотическое, это обычный файл. Но если бы оно было действительно обычным, это число после части rwx-ish было бы «1», как, например, «есть одна запись каталога, указывающая на этот блок данных». Но это часть демонстрации жестких ссылок, поэтому вместо этого написано «3».
Обратите внимание, что это может привести к странному и таинственному поведению (то есть, если вы не обернулись вокруг жестких ссылок). Если вы откроете Fred.txt в текстовом редакторе и внесете некоторые изменения, увидите ли вы те же изменения в Wilma.txt и Barney.txt? Может быть. Вероятно. Если ваш текстовый редактор сохраняет изменения, открыв исходный файл и записав в него изменения, то да, все три имени будут по-прежнему указывать на один и тот же (недавно измененный) текст. Но если ваш текстовый редактор создает новый файл (Fred-new-temp.txt), записывает в него измененную версию, затем удаляет Fred.txt, а затем переименовывает Fred-new-temp.txt в Fred.txt, Вильма и Барни по-прежнему указывать на оригинальную версию, а не на новую измененную версию. Если вы не понимаете жестких ссылок, это может привести вас в бешенство. :) [Ладно, я лично не знаю ни одноготекстовые редакторы, которые будут выполнять функцию new-file / rename, но я знаю много других программ, которые делают именно это, так что будьте начеку.]
И последнее замечание: одна из вещей, которую проверяет fsck (проверка файловой системы), состоит в том, есть ли на вашем диске блоки данных, на которые почему-то больше не ссылаются какие-либо записи каталога. Иногда что-то идет не так, и единственная запись в каталоге, которая указывает на индекс, удаляется, но само пространство диска не помечается как «доступное». Таким образом, одна из задач fsck - сопоставить все выделенное пространство со всеми записями каталога, чтобы убедиться, что нет никаких файлов, на которые нет ссылок. Если он находит некоторые, он создает новые записи каталога и помещает их в «lost + found».
Внутри /usr/local/lib/ я использую три библиотеки. Я буду называть их здесь как lib1 , lib2 а также lib3 .
Теперь, когда я делаю ldd в моем двоичном файле, это приводит к:
Но все они находятся в той же папке, что и /usr/local/lib/.so .
Каждый раз, когда я запускаю ldconfig , появляется одна и та же ошибка:
Я думал /usr/local/lib должно быть объявлено дважды в /etc/ld.conf.d/*.conf , но нет:
ld.so.conf включает только /etc/ld.so.conf.d/*.conf , так что это *.old не обрабатывается, а относится к /usr/local/projectA/lib .
Через некоторое время я удалил все lib1 и lib2 (в какой-то момент я проверил их в папке бинарного файла), возникает та же ошибка.
Я столкнулся с этой проблемой с клиентом Oracle 11R2. Не уверен, что установщик Oracle сделал это или кто-то сделал это здесь до моего приезда. Это был не 64-битный против 32-битный, все было 64-битным.
Ошибка была в том, что libexpat.so.1 не было символической ссылкой.
Оказалось, что там было два одинаковых файла, libexpat.so.1.5.2 а также libexpat.so.1 . Удаление поврежденного файла и превращение его в символическую ссылку на версию 1.5.2 привело к исчезновению ошибки.
Имеет смысл, что вы хотите, чтобы известное имя было символической ссылкой на текущую версию. Если вы сделаете это, менее вероятно, что вы получите устаревшую библиотеку.
Решено, по крайней мере, в точке вопроса.
Я искал в Интернете, прежде чем спросить, не было окончательного решения, причина этой ошибки: lib1.so и lib2.so не в порядке, очень вероятно, где не скомпилированы для 64 ПК, но для 32-битной машины в противном случае lib3.so - это 64-битная библиотека. По крайней мере, это моя гипотеза.
ldconfig:/folder_where_the_wicked_lib_is/не является символической ссылкой
Я решил это, когда удалил библиотеки, не найденные ldd, над двоичным файлом. Теперь мне легче понять, в чем проблема.
Я просто запустил команду ниже:
Сейчас работает нормально.
Вам нужно указать путь к библиотекам внутри /etc/ld.so.conf и повторно запустить ldconfig, чтобы обновить список
Другой возможностью является включение в переменную env LD_LIBRARY_PATH пути к вашей библиотеке и повторный запуск исполняемого файла.
проверьте символические ссылки, если они указывают на действительную библиотеку .
Вы можете добавить путь непосредственно в /etc/ld.so.conf, без включения .
бег ldconfig -p чтобы увидеть, хорошо ли ваша библиотека включена в кеш.
простой запуск в Shell: Sudo apt-get install --reinstall libexpat1
та же проблема с libxcb - решена таким образом - очень быстро :)
Символическая ссылка (симлинк, символьная ссылка, Symbolic link) это специальный файл на файловой системе, которые сам не содержит данных, а является по сути ярлыком, указывающим на какой-то другой объект (файл или папку). При обращении к симлику операционная система считает, что это оригинальный файл (папка) и работает с ними совершенно прозрачно.
Символические ссылки используются в Windows довольно часто для системных файлов и каталогов. Пользователь может их применять, когда нужно перенести часть “тяжелых” файлов на другой диск, но чтобы Windows считала, что файлы все еще находятся в исходном каталоге (например в ситуациях, когда нужно экономить место на SSD, перенеся некоторые каталоги на более медленный и емкий SSD, не нарушая работоспособности программ). Можно использовать симлинки на SMB файловом сервере, когда каталоги с разных LUN должны быть доступны через одну точку входа.
В Windows есть три типа файловых ссылок для NTFS томов: жесткие, мягкие (симлинки), точки соединения (Junction point).
- Hard Links (жесткие ссылки) – могут указывать только на локальный файл, но не на папку. Такой файл – это ссылка на другой файла на этом же диске без фактического дублирования самого файла. У него отображается такой же размер и свойства, как у целевого файла (но реальное место на диске он не занимает);
- Junction Points (Directory Hard Link, точка соединения) – могут указывать только на папку (на этом же или на другом разделе);
- Symbolic Links (мягкая ссылка, симлинк) – могут указывать на локальный файл, папку и сетевой каталог на удаленном компьютере (UNC), поддерживаются относительные пути.
В подавляющем большинстве случаев вам будет достаточно функционала symbolic link, как наиболее универсального средства создания ссылки на любой объект.
Как создать символическую ссылку в Windows?
Для создания символических и жестких ссылок в Windows можно использовать встроенную утилиты mklink или PowerShell.
Создадим в каталоге C:\PS символическую ссылку на файл notepad.exe:
mklink C:\PS\note.exe c:\Windows\System32\notepad.exe
Теперь для запуска процесса notepad.exe можно использовать символическую ссылку note.exe.
Теперь создадим в этом каталоге симлинк на другой каталог на этом же диcке:
mklink /D “C:\PS\Downloads” “C:\Users\user\Downloads”
Теперь при переходе в каталог C:\PS\Downloads вы будете видеть содержимое каталога, на который он ссылается.
Выведем содержимое каталога C:\PS:
Как вы видите, в атрибутах некоторых файлов указано, что это symlink/simlinkd. Также указан объект, на который они ссылаются. В Windows File Explorer симлинки отображаются с иконками ярлыков, а в их свойствах можно посмотреть целевой объект на который они ссылаются.
Также можно создать символически ссылки в Windows 10 с помощью PowerShell (в этом примере я использую относительные пути, чтобы создать символическую ссылку):
New-Item -ItemType SymbolicLink -Path ".\test\tmpfiles" -Target "..\tmp\files"
Можно создать символическую ссылку на сетевую папку на удаленном компьютере/сервере. Адрес сетевой папки нужно указывать в формате UNC. Следующий пример создаст симлинк на сетевой каталог на сервере:
mklink /D c:\ps\share \\mskfs01\Share
Например, подключим административную шару C$ с удаленного компьютера по IP адресу:
mklink /D c:\remotePC\server1 \\192.168.31.15\С$
Если при доступе к сетевой папке через симлинк, вы получили ошибку
проверьте разрешенные способы использования символических ссылок на вашем компьютере:
fsutil behavior query SymlinkEvaluation
Чтобы включить использование символических ссылок на удаленные ресурсы, выполните команды:
fsutil behavior set SymlinkEvaluation R2R:1
fsutil behavior set SymlinkEvaluation R2L:1
Вы можете работать с символическими ссылками, как с обычными объектами файловой системы, можно переименовать, переносить или удалить их. Система автоматически изменит настройки таких симлинков, чтобы они указывали на верные целевые объекты.
Для удаления симлинков используются обычные команды, как и для удаления файлов:
Del c:\ps\note.exe
RD c:\ps\downloads
Как найти и вывести все символические ссылки на диске?
В Windows нет простых инструментов для просмотра и управления всеми симлинками на диске.
Вы можете вывести список всех символических ссылок на диске с помощью команды:
dir /AL /S C:\ | find "SYMLINK"
Также можно вывести список всех символических ссылок на диске с помощью PowerShell. Для этого нужно просканировать все каталоги и найти NTFS объекты с атрибутом ReparsePoint:
Get-ChildItem -Path C:\ -Force -Recurse -ErrorAction 'silentlycontinue' | Where
Читайте также: