Вы можете использовать сам command-not-found
:
command-not-found --ignore-installed ls
сообщит вам, какой пакет содержит команду ls
.(--ignore-installed
не учитывает установленные пакеты и, в частности, гарантирует, что команда не запустится сразу, если она уже установлена.)
В качестве альтернативы вы можете использоватьapt-file
:
apt-file search bin/ls
выведет список всех пакетов, содержащих файл, путь которого содержит «bin/ls». Вы можете отфильтровать это, чтобы соответствовать толькоls
:
apt-file search bin/ls | grep bin/ls$
Похоже, что ApplicationThing должен быть исправлен, чтобы найти свои зависимости из определенного места, даже если он вызывается из другого рабочего каталога.
Вы можете сделать это, установив переменную окружения:
export ApplicationThingHome=/Users/user1/ApplicantionThing
и обращение ко всем зависимостям main.sh
с использованием значения этой переменной (с необязательно хорошим значением по умолчанию, если переменная не установлена ), например.
${ApplicationThingHome:-/usr/local/ApplicationThingDefaultDir}/dependancy.sh
вместо
./dependancy.sh
Затем вы можете поместить каталог main.sh
в $PATH
и использовать его из любого каталога.
Предлагаемое вами решение будет иметь проблему :если вы находитесь в любом другом каталоге и хотите создать там файл с именем, скажем, main.sh
или dependency.sh
, вместо этого вы перезапишете соответствующие файлы ApplicationThing. Вы буквально не сможете иметь/использовать какой-либо другой main.sh
, кроме того, который принадлежит ApplicationThing... и каталоги были придуманы именно для того, чтобы избежать подобных проблем!
Конечно, вы можете сделать условие, что "псевдо -файлы" будут там только тогда, когда main.sh
выполняется первым... но тогда вам понадобится другой набор инструментов, чтобы увидеть, что main.sh
видит для устранения неполадок всякий раз, когда он не делает то, что вы ожидаете.
Если вы не можете исправить ApplicationThing, вы можете создать скрипт-оболочку для вызова ApplicationThing из любого места в системе и поместить этот скрипт в каталог, который включен в ваш $PATH:
#!/bin/sh
# set the correct working directory for silly ApplicationThing
cd /Users/user1/ApplicationThing
# if ApplicationThing has any other environment requirements,
# this would be a great place to ensure they're satisfied too.
# Now execute the main.sh of ApplicationThing, giving it any
# command line arguments that were given to this script, exactly as-is.
exec./main.sh "$@"
Поскольку этот скрипт будет выполняться как отдельный процесс, команда cd
в скрипте никак не повлияет на сессию, вызывающую скрипт. Ключевое слово exec
при запуске main.sh
позволяет избежать дополнительного процесса между вызывающей оболочкой и main.sh
.
При таком подходе, если main.sh
принимает имена файлов в качестве параметров, вам придется указывать их как абсолютные пути, поскольку любые относительные пути будут интерпретироваться main.sh
как относительные к каталогу ApplicationThing, а не как относительные к CWD файла сеанс вызова.
Если это проблема, вы можете написать более сложную предварительную -обработку параметров командной строки перед их передачей в main.sh
. В этом вопросе StackExchange есть несколько идей, которые могут оказаться применимыми.