Основной целью команды OS X open
является открытие файла в связанном приложении. Эквивалент такового на современных униках, не относящихся к OSX, - xdg-open
.
xdg-open index.html
xdg-open
не имеет эквивалента open -a
OSX для открытия файла в конкретном приложении. Это потому, что обычный способ открыть файл в приложении - просто ввести имя приложения, а затем имя файла. Точнее, нужно ввести имя исполняемой программы, реализующей приложение.
sublime_text index.html
Linux, как и другие Unix-системы (но не, насколько мне известно, не-Unixy части OS X) управляет программным обеспечением, отслеживая его с помощью диспетчера пакетов, и помещает отдельные файлы там, где они используются . Например, все исполняемые программы находятся в небольшом наборе каталогов, и все эти каталоги перечислены в переменной PATH
; при выполнении sublime _ text
выполняется поиск файла sublime _ text
в каталогах, перечисленных в PATH
. ОС X требуется дополнительный уровень косвенности через open -a
для обработки приложений, которые распакованы в одном дереве каталогов и зарегистрированы в базе данных приложений. У Linux нет базы данных приложений, но она организована путь, что она не нужна.
Если выполнение команды sublime _ text
не работает для вас, то Sublime Text не был установлен должным образом. Я никогда не использовал его, и, видимо, он приходит как архив смолы, а не как дистрибутивный пакет (например, deb или rpm), поэтому возможно, что вам нужно сделать дополнительный шаг установки. Это действительно работа создателей Sublime Text, чтобы сделать это автоматически, но если они не сделали это, вы, вероятно, можете сделать это самостоятельно, выполнив команду
sudo -s …/sublime_text /usr/local/bin
Заменить ...
по пути, где sublime _ text
исполняемый файл, конечно.
Команда open
является более ранним именем для команды openvt
(некоторые дистрибутивы Linux включают ее только под именем openvt
). Команда openvt
создает новую виртуальную консоль , которая может быть выполнена только с помощью root и не используется очень часто в этом веке, так как большинство людей когда-либо работают только в среде графического окна.
-121--36360-
Я бы изменил ваш .bashrc, а затем выполнил следующее:
. .bashrc
Это забирает ваш .bashrc материал и помещает его в вашу текущую среду.
-121--153449-
Вы можете получить импульс от текущего basename
и dirname
(Я не понимаю, почему это не builtins - если это не кандидаты, я не знаю, что это), но реализация должна обрабатывать такие вещи, как:
path dirname basename
"/usr/lib" "/usr" "lib"
"/usr/" "/" "usr"
"usr" "." "usr"
"/" "/" "/"
"." "." "."
".." "." ".."
^ от basename (3)
и другие
Я использовал:
basename(){
test -n "$1" || return 0
local x="$1"; while :; do case "$x" in */) x="${x%?}";; *) break;; esac; done
[ -n "$x" ] || { echo /; return; }
printf '%s\n' "${x##*/}";
}
dirname(){
test -n "$1" || return 0
local x="$1"; while :; do case "$x" in */) x="${x%?}";; *) break;; esac; done
[ -n "$x" ] || { echo /; return; }
set -- "$x"; x="${1%/*}"
case "$x" in "$1") x=.;; "") x=/;; esac
printf '%s\n' "$x"
}
(Последняя реализация GNU basename
и dirname
добавляет некоторые специальные модные переключатели командной строки для обработки нескольких аргументов или удаления суффиксов, но это очень легко добавить в оболочку.)
Это не так сложно сделать в bash
builtins (используя базовую реализацию системы), но вышеуказанная функция не должна быть скомпилирована, и они также обеспечивают некоторый импульс.
Поскольку вам нужны разные разрешения для файлов (чтение и запись )и каталоги (чтение и выполнение ), я бы рекомендовал использовать две отдельные команды вместо того, чтобы пытаться объединить их в одну. Подстановочный знак *
будет соответствовать файлам и каталогам.
Во-вторых, разрешение X
добавляет "выполнить"...
if the file is a directory or already has execute permission for some user
... поэтому, если файл был запущен с каким-либо (пользователем, группой или другим )разрешением на выполнение, то в конечном итоге он будет иметь права на выполнение.
Рассмотрим две отдельные команды:
find /base/path -type d -exec chmod u+rx,g+rx,o+rx {} +
и
find /base/path -type f -exec chmod u-x+rw,g-x+rw,o=r {} +
Настройте наборы разрешений в соответствии с собственными политиками; вышеуказанные команды:
После небольшого тестирования я обнаружил, что следующая команда chmod должна дать вам ожидаемое поведение:
chmod -R ugo-x+Xr,ug+w FILE
Например, начнем с каталога и файла с правами доступа 775:
[root@testvm1 ~]# ls -ld testdir/
drwxrwxr-x. 2 root root 22 Dec 14 16:47 testdir/
[root@testvm1 ~]# ls -l testdir/testfile
-rwxrwxr-x. 1 root root 0 Dec 14 16:47 testdir/testfile
А теперь запускаем команду:
[root@testvm1 ~]# chmod -R --verbose ugo-x+Xr,ug+w testdir/
mode of ‘testdir/’ retained as 0775 (rwxrwxr-x)
mode of ‘testdir/testfile’ changed from 0775 (rwxrwxr-x) to 0664 (rw-rw-r--)
Каталог сохранил свое разрешение на выполнение, в то время как файл был лишен разрешения на выполнение.
Предполагая, что вам нужны разрешения 775 для всех каталогов и разрешения 664 для всех файлов, вы можете использовать следующий вариант, который также манипулирует разрешением на запись:
chmod -R ugo-wx+Xr,ug+w *
Исходная команда chmod
в вопросе не лишает файл разрешения на выполнение. Эта разница в поведении, по-видимому, является результатом того, как оцениваются режимы. chmod mode1, mode2 file
дает тот же результат, что и chmod mode1 file; chmod mode2 file
. Поскольку права пользователя оцениваются в первую очередь в исходной команде, разрешение на выполнение в группе/других категориях приведет к тому, что файл сохранит разрешения на выполнение. Пример показан ниже:
[root@testvm1 testdir]# chmod 775 testfile
[root@testvm1 testdir]# chmod -R --verbose u-x+Xrw,g-x+Xrw,o-x+Xr testfile
mode of ‘testfile’ retained as 0775 (rwxrwxr-x)
[root@testvm1 testdir]# chmod -R --verbose u-x+Xrw testfile
mode of ‘testfile’ retained as 0775 (rwxrwxr-x)
[root@testvm1 testdir]# chmod -R --verbose g-x+Xrw testfile
mode of ‘testfile’ retained as 0775 (rwxrwxr-x)
[root@testvm1 testdir]# chmod -R --verbose o-x+Xr testfile
mode of ‘testfile’ retained as 0775 (rwxrwxr-x)
Обратите внимание, что каталоги автоматически получают бит выполнения с помощью X
, поэтому такое поведение влияет только на файлы.