I have a few very simple Bash scripts that I cobbled together for things that I do regularly.
One of them is to run duplicity to do my backup tasks. Nothing clever, just a bunch of if .. then
statements really.
As this needs to be run as root, would it be best practice to put my script in /usr/bin
(or another location on PATH), chown
to root:root and chmod
to 700?
asked Jan 21, 2018 at 22:30
10
If no other user other than you uses these scripts
Then you can keep them in /home/$USER/bin
. Create the bin
directory if it doesn’t exist and move the files there. The bin
directory in your home will automatically get added to the PATH environment variable. The code is in the .profile
:
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
See How to add /home/username/bin to $PATH?
Or in some systems it may be in .bashrc
:
export PATH=${HOME}/bin/:${HOME}/.local/bin:${PATH}
Thanks Elder Geek.
If these script are to be used by other users:
Then either /usr/local/bin
or /opt/bin
are good options. See Is there a standard place for placing custom Linux scripts?
answered Jan 21, 2018 at 23:06
user68186user68186
30.7k12 gold badges83 silver badges111 bronze badges
1
I save my own scripts in /opt/scripts
.
If your script should executeable by every system user, you can create a symbolic link to /usr/bin
.
If only root should execute the script, you can create a symbolic link to /usr/sbin
.
Command to add a symbolic link in /usr/bin/
:
ln -s /opt/scripts/<script> /usr/bin/
You can execute the script, because /usr/bin/
is in your PATH by default.
answered Jan 21, 2018 at 22:53
3
I have a directory that I use for the quick collection of my local tools or things that I deploy on various computers in /usr/local/apollo
. There are branches off this directory for flags
, bin
and logs
.
For the applications that I download and install outside of the default apt-get
repositories are placed in /opt/
and a directory by the app’s name, with one more sub-directory for the specific version of the application. This way my compiled version of an application like vlc
or eclipse
won’t conflict with the distributed version.
My use of /opt
is the way it’s basically officially designed.
By the way the directories /usr/local/bin
, /usr/local/apollo
, and /opt
survives a fresh OS version installation overwrite.
answered Sep 26, 2016 at 23:39
L. D. JamesL. D. James
24.7k10 gold badges67 silver badges116 bronze badges
7
There may be several scripts called exactly the same thing on your file system, so locating it based on the name and then blindly executing it is probably a very bad idea.
To locate it, use find
as shown by J. Chomel in another answer to your question, or use locate
:
$ locate script.sh
This will find all files called script.sh
in locations that are readable by all users based on a database search on your system. Note that the database is updated on a regular basis (once daily or once weekly, depending on how it’s configured), so files added since the last file system scan will not be found, but it’s a lot faster than find
.
You could use select
to generate a menu from which you could select the correct script and execute it:
$ select script in $( locate script.sh ); do echo "$script"; break; done
Change echo
to command
to actually run the script you’ve selected rather than just printing its name.
Summary:
FULL_PATH_TO_SCRIPT="$(realpath "${BASH_SOURCE[-1]}")"
# OR, if you do NOT need it to work for **sourced** scripts too:
# FULL_PATH_TO_SCRIPT="$(realpath "$0")"
# OR, depending on which path you want, in case of nested `source` calls
# FULL_PATH_TO_SCRIPT="$(realpath "${BASH_SOURCE[0]}")"
# OR, add `-s` to NOT expand symlinks in the path:
# FULL_PATH_TO_SCRIPT="$(realpath -s "${BASH_SOURCE[-1]}")"
SCRIPT_DIRECTORY="$(dirname "$FULL_PATH_TO_SCRIPT")"
SCRIPT_FILENAME="$(basename "$FULL_PATH_TO_SCRIPT")"
Details:
How to obtain the full file path, full directory, and base filename of any script being run OR sourced…
…even when the called script is called from within another bash function or script, or when nested sourcing is being used!
For many cases, all you need to acquire is the full path to the script you just called. This can be easily accomplished using realpath
. Note that realpath
is part of GNU coreutils. If you don’t have it already installed (it comes default on Ubuntu), you can install it with sudo apt update && sudo apt install coreutils
.
get_script_path.sh (for the latest version of this script, see get_script_path.sh in my eRCaGuy_hello_world repo):
#!/bin/bash
# A. Obtain the full path, and expand (walk down) symbolic links
# A.1. `"$0"` works only if the file is **run**, but NOT if it is **sourced**.
# FULL_PATH_TO_SCRIPT="$(realpath "$0")"
# A.2. `"${BASH_SOURCE[-1]}"` works whether the file is sourced OR run, and even
# if the script is called from within another bash function!
# NB: if `"${BASH_SOURCE[-1]}"` doesn't give you quite what you want, use
# `"${BASH_SOURCE[0]}"` instead in order to get the first element from the array.
FULL_PATH_TO_SCRIPT="$(realpath "${BASH_SOURCE[-1]}")"
# B.1. `"$0"` works only if the file is **run**, but NOT if it is **sourced**.
# FULL_PATH_TO_SCRIPT_KEEP_SYMLINKS="$(realpath -s "$0")"
# B.2. `"${BASH_SOURCE[-1]}"` works whether the file is sourced OR run, and even
# if the script is called from within another bash function!
# NB: if `"${BASH_SOURCE[-1]}"` doesn't give you quite what you want, use
# `"${BASH_SOURCE[0]}"` instead in order to get the first element from the array.
FULL_PATH_TO_SCRIPT_KEEP_SYMLINKS="$(realpath -s "${BASH_SOURCE[-1]}")"
# You can then also get the full path to the directory, and the base
# filename, like this:
SCRIPT_DIRECTORY="$(dirname "$FULL_PATH_TO_SCRIPT")"
SCRIPT_FILENAME="$(basename "$FULL_PATH_TO_SCRIPT")"
# Now print it all out
echo "FULL_PATH_TO_SCRIPT = "$FULL_PATH_TO_SCRIPT""
echo "SCRIPT_DIRECTORY = "$SCRIPT_DIRECTORY""
echo "SCRIPT_FILENAME = "$SCRIPT_FILENAME""
IMPORTANT note on nested source
calls: if "${BASH_SOURCE[-1]}"
above doesn’t give you quite what you want, try using "${BASH_SOURCE[0]}"
instead. The first (0
) index gives you the first entry in the array, and the last (-1
) index gives you the last last entry in the array. Depending on what it is you’re after, you may actually want the first entry. I discovered this to be the case when I sourced ~/.bashrc
with . ~/.bashrc
, which sourced ~/.bash_aliases
with . ~/.bash_aliases
, and I wanted the realpath
(with expanded symlinks) to the ~/.bash_aliases
file, NOT to the ~/.bashrc
file. Since these are nested source
calls, using "${BASH_SOURCE[0]}"
gave me what I wanted: the expanded path to ~/.bash_aliases
! Using "${BASH_SOURCE[-1]}"
, however, gave me what I did not want: the expanded path to ~/.bashrc
.
Example command and output:
- Running the script:
~/GS/dev/eRCaGuy_hello_world/bash$ ./get_script_path.sh FULL_PATH_TO_SCRIPT = "/home/gabriel/GS/dev/eRCaGuy_hello_world/bash/get_script_path.sh" SCRIPT_DIRECTORY = "/home/gabriel/GS/dev/eRCaGuy_hello_world/bash" SCRIPT_FILENAME = "get_script_path.sh"
- Sourcing the script with
. get_script_path.sh
orsource get_script_path.sh
(the result is the exact same as above because I used"${BASH_SOURCE[-1]}"
in the script instead of"$0"
):~/GS/dev/eRCaGuy_hello_world/bash$ . get_script_path.sh FULL_PATH_TO_SCRIPT = "/home/gabriel/GS/dev/eRCaGuy_hello_world/bash/get_script_path.sh" SCRIPT_DIRECTORY = "/home/gabriel/GS/dev/eRCaGuy_hello_world/bash" SCRIPT_FILENAME = "get_script_path.sh"
If you use "$0"
in the script instead of "${BASH_SOURCE[-1]}"
, you’ll get the same output as above when running the script, but this undesired output instead when sourcing the script:
~/GS/dev/eRCaGuy_hello_world/bash$ . get_script_path.sh
FULL_PATH_TO_SCRIPT = "/bin/bash"
SCRIPT_DIRECTORY = "/bin"
SCRIPT_FILENAME = "bash"
And, apparently if you use "$BASH_SOURCE"
instead of "${BASH_SOURCE[-1]}"
, it will not work if the script is called from within another bash function. So, using "${BASH_SOURCE[-1]}"
is therefore the best way to do it, as it solves both of these problems! See the references below.
Difference between realpath
and realpath -s
:
Note that realpath
also successfully walks down symbolic links to determine and point to their targets rather than pointing to the symbolic link. If you do NOT want this behavior (sometimes I don’t), then add -s
to the realpath
command above, making that line look like this instead:
# Obtain the full path, but do NOT expand (walk down) symbolic links; in
# other words: **keep** the symlinks as part of the path!
FULL_PATH_TO_SCRIPT="$(realpath -s "${BASH_SOURCE[-1]}")"
This way, symbolic links are NOT expanded. Rather, they are left as-is, as symbolic links in the full path.
The code above is now part of my eRCaGuy_hello_world repo in this file here: bash/get_script_path.sh. Reference and run this file for full examples both with and withOUT symlinks in the paths. See the bottom of the file for example output in both cases.
References:
- How to retrieve absolute path given relative
- taught me about the
BASH_SOURCE
variable: Unix & Linux: determining path to sourced shell script - taught me that
BASH_SOURCE
is actually an array, and we want the last element from it for it to work as expected inside a function (hence why I used"${BASH_SOURCE[-1]}"
in my code here): Unix & Linux: determining path to sourced shell script man bash
–> search forBASH_SOURCE
:
BASH_SOURCE
An array variable whose members are the source filenames where the corresponding shell function names in the
FUNCNAME
array variable are defined. The shell function${FUNCNAME[$i]}
is defined in the file${BASH_SOURCE[$i]}
and called from${BASH_SOURCE[$i+1]}
.
See also:
- [my answer] Unix & Linux: determining path to sourced shell script
Управление операционной системой Linux осуществляется посредством терминала. Пользователь имеет дело со специальной командной оболочкой, через которую задаются те или иные команды для выполнения нужных действий. Об этом не знает разве что новичок, впервые столкнувшийся с ОС Линукс. Чтобы управление системой не вызывало излишних трудностей, разработчики придумали специальные скрипты. Их можно использовать по отдельности, либо объединять в единую команду. Каждый скрипт отвечает за определенное действие.
Опытные пользователи уже неоднократно убедились в том, насколько удобно работать с Линукс при помощи скриптов. Данная статья станет неким руководством для новичка. В ней мы подробно объясним, как запускать скрипты на ПК.
Скрипты в операционной системе Linux представляют собой обычные файлы. В них содержится текст. Если файлу присвоен атрибутив исполняемости, система (исключительно с подачи пользователя) начинает выполнять команды, которые содержатся в определенном файле.
Содержание
- 1 Запуск script bash
- 1.1 Запуск через оболочку bash
Запуск script bash
Чтобы лучше понять, как работать со скриптами, стоит рассмотреть несложный пример. Допустим, необходимо запустить script bash. Для этого, создам файл “primer.sh”, с помощью редактора nano.
$ nano primer.sh
Внутри файла пишем следующий код:
#!/bin/bash
echo «Primer vypolneniya scripta»
В представленном примере первая строка – это та самая оболочка, посредством которой выполняется определенное действие. Само действие в данном случае указано во второй строке. Примечательно, что у данного варианта могут быть альтернативные окончания. Например:
- /bin/sh – bash script.
- /usr/bin/php – php scpript.
- /usr/bin/python – язык python.
Далее необходимо сохранить файл. Согласно нашему примеру нажимаем “ctrl + O”, затем “ctrl + X”.
Чтобы script bash отработал, необходимо дать файлу специальные права на исполнение.
$ chmod ugo+x primer.sh
После этого файл будет доступен к запуску для всех категорий пользователей Линукс (без исключений). Чтобы найти нужный скрипт в системе, необходимо задать полный путь или относительный.
В нашем примере файл лежит в домашнем каталоге, поэтому просто для запуска вводи название скрипта.
$ primer.sh
А вот указание полного пути. Он будет выглядеть следующим образом:
$ /root/primer.sh
Запуск через оболочку bash
Далее мы рассмотрим альтернативный способ запуска script, используя для этих целей оболочку. Пользователь может сразу передать ей нужный скрипт для выполнения. Такое не часто встречается на практике в случае с bash, чего не скажешь о скриптах python и php. Как запустить скрипт указанным способом:
$ bash primer.sh
Предлагаем вашему вниманию еще один аналогичный способ запуска:
$ php primer.php
Чтобы произвести запуск сценария в операционной системе Линукс в виде фонового процесса, необходимо использовать специальный символ. Он будет указан ниже:
script.sh &
Заключение
Знакомство новичка с терминалом Linux часто приводит к некоторым сложностям. Разобравшись в том, как происходит управление устройством, данная проблема быстро пропадает. Данная статья лишь подтверждает это. Запускать script в Линукс действительно легко.
Где лежат пользовательские скрипты?
Модератор: Bizdelnick
-
Enar
- Сообщения: 300
Где лежат пользовательские скрипты?
Здравствуйте. Меня волнует такой вопрос, начал разбираться с bash скриптами и у меня стало появляться все больше и больше скриптов, запускаю их из ~/, но читал где-то что это не правильно, и /home вообще надо монтировать с запретом запуска приложений. Интересно куда помещают свои скрипты опытные пользователи linux. На сколько можно использовать /usr/bin, /usr/local/bin, или /opt.
-
SLEDopit
- Модератор
- Сообщения: 4814
- Статус: фанат консоли (=
- ОС: GNU/Debian, RHEL
Re: Где лежат пользовательские скрипты?
Сообщение
SLEDopit » 30.05.2012 10:02
Enar писал(а): ↑
30.05.2012 09:52
запускаю их из ~/
Это неудобно, в ~ начинает разводиться помойка. У меня всё в ~/scripts
Enar писал(а): ↑
30.05.2012 09:52
и /home вообще надо монтировать с запретом запуска приложений.
от запуска скриптов монтирование с noexec не спасёт. Скрипт всегда можно запустить как bash /path/to/script и тогда не важно, стоит execute бит у файла или нет. Имхо, опция noexec имеет смысл только на серверах, дабы там всякие левые бинарники не запускали. Однако, на 95% серверов это правило не соблюдают.
UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity. © Dennis Ritchie
The more you believe you don’t do mistakes, the more bugs are in your code.
-
Bizdelnick
- Модератор
- Сообщения: 20307
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Где лежат пользовательские скрипты?
Сообщение
Bizdelnick » 30.05.2012 11:56
~/bin/ – в редхатообразных дистрах официально для этого предназначенное место.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще |
в течение (часа) новичок нюанс по умолчанию |
приемлемо проблема пробовать трафик |
-
SLEDopit
- Модератор
- Сообщения: 4814
- Статус: фанат консоли (=
- ОС: GNU/Debian, RHEL
Re: Где лежат пользовательские скрипты?
Сообщение
SLEDopit » 30.05.2012 14:31
Yaros писал(а): ↑
30.05.2012 12:14
/usr/local/bin вроде по стандарту для этого.
(FHS) писал(а):/usr/local : Local hierarchy
PurposeThe /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.
Не, явно не подходит (:
Да и это придётся разрешить пользователю писать в /usr/local/bin или каждый раз повышать привилегии при создании нового скрипта, что в общем-то, не есть хорошо.
UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity. © Dennis Ritchie
The more you believe you don’t do mistakes, the more bugs are in your code.
-
Yaros
- Сообщения: 501
- ОС: Debian Wheezy / Gentoo
Re: Где лежат пользовательские скрипты?
Сообщение
Yaros » 30.05.2012 15:19
SLEDopit писал(а): ↑
30.05.2012 14:31
Yaros писал(а): ↑
30.05.2012 12:14
/usr/local/bin вроде по стандарту для этого.
(FHS) писал(а):/usr/local : Local hierarchy
PurposeThe /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.
Не, явно не подходит (:
Да и это придётся разрешить пользователю писать в /usr/local/bin или каждый раз повышать привилегии при создании нового скрипта, что в общем-то, не есть хорошо.
Если человек один работает за компом, то sudo cp,
Еще есть вариант
Код:
$ mkdir ~/bin
$ echo "export PATH=$PATH:/home/user/bin" >> ~/.bash_profile
UPD: Если не один, вроде тоже нормально.
=========
=Мой блог. =
=========
Gentoo-ниасилятар
-
eddy
- Сообщения: 3321
- Статус: Красный глаз тролля
- ОС: ArchLinux
- Контактная информация:
Re: Где лежат пользовательские скрипты?
Сообщение
eddy » 30.05.2012 16:15
У меня на работе – стандартно (как у всех, в ~/bin), а дома – в /Data/scripts.
Админам, монтирующим /home с noexec, следует отрывать руки.
RTFM
——-
KOI8-R – патриотичная кодировка
-
Bizdelnick
- Модератор
- Сообщения: 20307
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Где лежат пользовательские скрипты?
Сообщение
Bizdelnick » 30.05.2012 16:34
Yaros писал(а): ↑
30.05.2012 15:19
Еще есть вариант
Код:
$ mkdir ~/bin
$ echo "export PATH=$PATH:/home/user/bin" >> ~/.bash_profile
В некоторых дистрибутивах это уже сделано, надо сначала проверить echo $PATH.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще |
в течение (часа) новичок нюанс по умолчанию |
приемлемо проблема пробовать трафик |
-
eddy
- Сообщения: 3321
- Статус: Красный глаз тролля
- ОС: ArchLinux
- Контактная информация:
Re: Где лежат пользовательские скрипты?
Сообщение
eddy » 30.05.2012 21:56
Yaros писал(а): ↑
30.05.2012 16:29
eddy писал(а): ↑
30.05.2012 16:15
Админам, монтирующим /home с noexec, следует отрывать руки.
Это еще почему?
А куда будет бедный пользователь свои скрипты складывать?
RTFM
——-
KOI8-R – патриотичная кодировка
-
Bizdelnick
- Модератор
- Сообщения: 20307
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Где лежат пользовательские скрипты?
Сообщение
Bizdelnick » 30.05.2012 22:23
Yaros писал(а): ↑
30.05.2012 22:13
Я за /usr/local/[s]bin .
И давно ли у пользователя есть право на запись туда?
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще |
в течение (часа) новичок нюанс по умолчанию |
приемлемо проблема пробовать трафик |
-
Yaros
- Сообщения: 501
- ОС: Debian Wheezy / Gentoo
Re: Где лежат пользовательские скрипты?
Сообщение
Yaros » 31.05.2012 00:17
watashiwa_daredeska писал(а): ↑
31.05.2012 00:05
Yaros писал(а): ↑
30.05.2012 23:09
watashiwa_daredeska писал(а): ↑
30.05.2012 22:36
Вопрос на засыпку — какой пользователь будет туда складывать скрипты?
Sudo?
Тогда лучше сразу сделать домашние каталоги world readable/writeable, а не тратить время пользователей на рассаживание по чужим скриптам троянов с шелл-доступом.
Как вариант, поколдовать с группами.
У меня машина, на к-рой я делал скрипты в /usr/local/bin, вообще к сети не подключена, так что я тогда не заморачивался.
=========
=Мой блог. =
=========
Gentoo-ниасилятар
-
drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит…
- ОС: Slackware-current
- Контактная информация:
Re: Где лежат пользовательские скрипты?
Сообщение
drBatty » 31.05.2012 00:39
1. в ~ скрипты юзеры должны складывать. Юзерам, которые складывают скрипты в иное место надо руки отрывать (ну ладно, в /tmp/ ещё можно).
2. noexec это нормально, если юзер не программист, и если он не делает бинарники. ИМХО. Проблема в том, что я-то программист, и мне это не нужно.
3. очевидно, что-бы не устраивать помойки, нужно создать каталог ~/scripts, ежели юзер пишет более 1 скрипта…
-
Bizdelnick
- Модератор
- Сообщения: 20307
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Где лежат пользовательские скрипты?
Сообщение
Bizdelnick » 31.05.2012 12:15
Yaros писал(а): ↑
30.05.2012 23:09
Sudo?
А за использование sudo без надобности по рукам надо бить.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще |
в течение (часа) новичок нюанс по умолчанию |
приемлемо проблема пробовать трафик |
-
Vadimsky
- Сообщения: 30
- ОС: Fedora 17
- Контактная информация:
Re: Где лежат пользовательские скрипты?
Сообщение
Vadimsky » 31.05.2012 15:48
eddy писал(а): ↑
30.05.2012 16:15
Админам, монтирующим /home с noexec, следует отрывать руки.
Ну я админ, и я всегда так монтирую /home и буду монтировать именно так.
Приходите отрывать, я Вас жду!
Боле того, у узеров в /etc/passwd:
director:x:521:501:General_Direktor:/dev/null:/sbin/nologin
buh1:x:522:501:Glav_Buh:/dev/null:/sbin/nologin
buh2:x:523:501::/dev/null:/sbin/nologin
и т.д.
Но это видимо тоже по Вашему неправильно?
По теме, так например я, в домашней папке, создаю scripts и их кидаю туда (уже свыше десятка, правда регулярно пользуюсь всего тремя), и даже если /home смонтирован noexec то скрипт от туда всё равно запустить можно.
-
eddy
- Сообщения: 3321
- Статус: Красный глаз тролля
- ОС: ArchLinux
- Контактная информация:
Re: Где лежат пользовательские скрипты?
Сообщение
eddy » 31.05.2012 16:36
Vadimsky писал(а): ↑
31.05.2012 15:48
/sbin/nologin
Почтовый сервер? Я, вообще-то, про рабочую машину говорил, а не почтовик!
Vadimsky писал(а): ↑
31.05.2012 15:48
и даже если /home смонтирован noexec то скрипт от туда всё равно запустить можно.
А если “скрипт” – бинарник? У меня, например, кое-что – на С, т.к. средствами баша либо невозможно такое сделать, либо долго.
RTFM
——-
KOI8-R – патриотичная кодировка
-
Yaros
- Сообщения: 501
- ОС: Debian Wheezy / Gentoo
Re: Где лежат пользовательские скрипты?
Сообщение
Yaros » 31.05.2012 22:37
eddy писал(а): ↑
31.05.2012 16:36
Vadimsky писал(а): ↑
31.05.2012 15:48
/sbin/nologin
Почтовый сервер? Я, вообще-то, про рабочую машину говорил, а не почтовик!
Vadimsky писал(а): ↑
31.05.2012 15:48
и даже если /home смонтирован noexec то скрипт от туда всё равно запустить можно.
А если “скрипт” – бинарник? У меня, например, кое-что – на С, т.к. средствами баша либо невозможно такое сделать, либо долго.
Многие скрипты для сервера на Си пишут?
А для домашней машины, по большому счету, можно и без noexec.
Вроде есть еще /opt, но это тоже криво.
=========
=Мой блог. =
=========
Gentoo-ниасилятар
-
diesel
- Бывший модератор
- Сообщения: 5989
- ОС: OS X, openSuSE, ROSA, Debian
- Контактная информация:
Re: Где лежат пользовательские скрипты?
Сообщение
diesel » 31.05.2012 23:13
Yaros писал(а): ↑
31.05.2012 22:37
Многие скрипты для сервера на Си пишут?
А для домашней машины, по большому счету, можно и без noexec.
сколько людей, столько и мнений.
для домашней машины, на которой в своем собственном $HOME можно и со скриптами играться, да в принципе и с бинарниками иногда тоже – noexec как раз таки сомнительное преимущество. Ну или выносить этот playground куда-то еще, хотя, не помню чтобы FHS для этого было что-то предусмотрено, соответственно, будет это место не очень стандартное. Я, например, когда-то делал это в директории /data, а в $HOME оставались только конфиги и случайные файлы.
С другой стороны, на серверах… хранение скриптов/программ, которые имеют отношение к управлению сервером/тем что сервер занимается, в $HOME – ИМХО – идея странная. А эксперименты экспериментировать – ну, смотря какой сервер и для чего. noexec может быть более оправдан.
-
eddy
- Сообщения: 3321
- Статус: Красный глаз тролля
- ОС: ArchLinux
- Контактная информация:
Re: Где лежат пользовательские скрипты?
Сообщение
eddy » 01.06.2012 08:39
Yaros писал(а): ↑
31.05.2012 22:37
Многие скрипты для сервера на Си пишут?
Я пишу. У меня все CGI на сях. Я даже свою библиотечку делал (правда, на вебсокетах “завис”, т.к. пока что не нужны были).
И, кстати, у меня обычно CGI хранятся либо в /var/www/html/cgi-bin и /var/www/html/SSL/cgi-bin, либо в /Data/Misc/html/cgi-bin. Что-то я не припомню такого, чтобы стандартным было разрешать пользователю писать CGI в ~/www…
RTFM
——-
KOI8-R – патриотичная кодировка
-
Yaros
- Сообщения: 501
- ОС: Debian Wheezy / Gentoo
Re: Где лежат пользовательские скрипты?
Сообщение
Yaros » 01.06.2012 11:24
eddy писал(а): ↑
01.06.2012 08:39
Yaros писал(а): ↑
31.05.2012 22:37
Многие скрипты для сервера на Си пишут?
Я пишу. У меня все CGI на сях. Я даже свою библиотечку делал (правда, на вебсокетах “завис”, т.к. пока что не нужны были).
И, кстати, у меня обычно CGI хранятся либо в /var/www/html/cgi-bin и /var/www/html/SSL/cgi-bin, либо в /Data/Misc/html/cgi-bin. Что-то я не припомню такого, чтобы стандартным было разрешать пользователю писать CGI в ~/www…
Но вы же скрипты в папку сайту кладете, а не запускаете их кроном для админских нужд?
=========
=Мой блог. =
=========
Gentoo-ниасилятар
-
eddy
- Сообщения: 3321
- Статус: Красный глаз тролля
- ОС: ArchLinux
- Контактная информация:
Re: Где лежат пользовательские скрипты?
Сообщение
eddy » 01.06.2012 12:49
Yaros писал(а): ↑
01.06.2012 11:24
Но вы же скрипты в папку сайту кладете, а не запускаете их кроном для админских нужд?
CGI складываю в “папку с сайтом”, свои скрипты – к себе, админские – еще куда-нибудь.
RTFM
——-
KOI8-R – патриотичная кодировка
-
SLEDopit
- Модератор
- Сообщения: 4814
- Статус: фанат консоли (=
- ОС: GNU/Debian, RHEL
Re: Где лежат пользовательские скрипты?
Сообщение
SLEDopit » 01.06.2012 13:19
diesel писал(а): ↑
31.05.2012 23:13
С другой стороны, на серверах…
С другой на серверах даже в серьёзных организациях, где, казалось бы, работают отнюдь не новички, два дня назад поставившие бубунту под чутким руководством друга-админа, порой творится невероятная хрень. Так в одной из таких компаний для правки несчастного шелл скрипта считается нормой поднять на сервере сессию kde/gnome (зависит от личных предпочтений админа, на сервер одновременно представлены оба), подключиться к ней удалённо (не в холодной серверной перед монитором сидеть же), запустить в этой сессии эмулятор терминала и (внимание!!!) в нём запустить vi. А вы тут спорите о несчастном noexec. Куда уж там до него.
UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity. © Dennis Ritchie
The more you believe you don’t do mistakes, the more bugs are in your code.
-
Bizdelnick
- Модератор
- Сообщения: 20307
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Где лежат пользовательские скрипты?
Сообщение
Bizdelnick » 01.06.2012 13:25
SLEDopit писал(а): ↑
01.06.2012 13:19
поднять на сервере сессию kde/gnome (зависит от личных предпочтений админа, на сервер одновременно представлены оба), подключиться к ней удалённо (не в холодной серверной перед монитором сидеть же), запустить в этой сессии эмулятор терминала и (внимание!!!) в нём запустить vi.
Неужели вендоадмины настолько вендоадмины?
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще |
в течение (часа) новичок нюанс по умолчанию |
приемлемо проблема пробовать трафик |