Как найти скрипты в linux

Как найти скрипты в linux

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?

Matthias Braun's user avatar

asked Jan 21, 2018 at 22:30

hatterman's user avatar

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?

Matthias Braun's user avatar

answered Jan 21, 2018 at 23:06

user68186's user avatar

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

SynPrime's user avatar

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. James's user avatar

L. D. JamesL. D. James

24.7k10 gold badges67 silver badges116 bronze badges

7

Источник

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:

  1. 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"
  2. Sourcing the script with . get_script_path.sh or source 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:

  1. How to retrieve absolute path given relative
  2. taught me about the BASH_SOURCE variable: Unix & Linux: determining path to sourced shell script
  3. 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
  4. man bash –> search for BASH_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:

  1. [my answer] Unix & Linux: determining path to sourced shell 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

Модератор
Сообщения: 20324
Статус: 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
Purpose

The /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
Purpose

The /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

Модератор
Сообщения: 20324
Статус: 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

Модератор
Сообщения: 20324
Статус: 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

Модератор
Сообщения: 20324
Статус: 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

Модератор
Сообщения: 20324
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Где лежат пользовательские скрипты?

Сообщение

Bizdelnick » 01.06.2012 13:25

SLEDopit писал(а): ↑

01.06.2012 13:19

поднять на сервере сессию kde/gnome (зависит от личных предпочтений админа, на сервер одновременно представлены оба), подключиться к ней удалённо (не в холодной серверной перед монитором сидеть же), запустить в этой сессии эмулятор терминала и (внимание!!!) в нём запустить vi.

Неужели вендоадмины настолько вендоадмины?

Пишите правильно:

в консоли
вку́пе (с чем-либо)
в общем
вообще		 в течение (часа)
новичок
нюанс
по умолчанию		 приемлемо
проблема
пробовать
трафик

Источник

I have a bunch of shell scripts under the ‘abc’ directory (some of them are nested deep). There could be 100 shell scripts under it. I want to find which shell scripts that are currently running.

I can get the list of scripts with the below command

find abc -name "*.sh" | awk -F/ '{print $NF}'

When I want to find out if an individual script is running or not, I would use

ps aux | grep "[t]emp.sh"

I am not sure how to combine the above 2 commands to achieve what I want without writing a shell script.

whoan's user avatar

whoan

8,0034 gold badges39 silver badges47 bronze badges

asked Nov 24, 2014 at 19:25

rahul's user avatar

0

Using process substitution (bash):

grep -f <(find . -name "*.sh" -printf "%fn") <(ps aux)

answered Nov 24, 2014 at 19:40

whoan's user avatar

whoanwhoan

8,0034 gold badges39 silver badges47 bronze badges

0

Here is another method:

ps aux | grep `find . -name "*.sh"`

A more literal ‘join’ of the two commands – using the backquote (`) char to enclose the part that is executed first. The output from the command enclosed in the backquotes is fed into the input of the first command.

whoan's user avatar

whoan

8,0034 gold badges39 silver badges47 bronze badges

answered Nov 24, 2014 at 20:50

philbrooksjazz's user avatar

Источник

Определение Bash-сценария

Сценарий (скрипт) оболочки Bash представляет собой текстовый файл с набором команд, которые необходимо выполнить в определенном порядке и/или условиями. Bash-скрипт призван избавить пользователей Linux от ввода множества различных команд для решения частых задач.

Где хранить Bash-сценарии?

Перед началом написания сценария нужно определиться с местом его хранения. Системные сценарии обычно находятся в директориях /bin и /sbin, а также в /usr/bin и /usr/sbin. Для собственных сценариев рекомендую использовать каталоги /usr/local/sbin и /usr/local/bin, однако ничто вам не мешает (кроме ограничения прав записи) хранить свои сценарии в любых других не системных каталогах.

Если вы решили использовать, какой-либо нестандартный каталог, то не забудьте добавить его в переменную среды $PATH, чтобы вы могли запускать свои сценарии по имени, без указания полного пути.

Изменять переменную $PATH следует в файле ~/.bash_profile, если его нет то в ~/.profile.

Например,  если я хочу хранить сценарии в каталоге ~/oleg/bash_scripts, то мне необходимо написать следующую строку.

PATH="$PATH:~/oleg/bash_scripts"

Так при инициализации работы оболочки ваш каталог уже будет добавлен в переменную $PATH.

Как создать и выполнить Bash-сценарий?

Для примера, в каталоге /usr/local/sbin,  создадим скрипт say_hi.sh, который будет выводить в консоли текстовую строку “Hello Universe!”.

touch /usr/local/sbin/say_hi.sh

Далее откроем этот файл любым текстовым редактором, например Vim.

vim /usr/local/sbin/say_hi.sh

И укажем в нем следующие строки.

#!/bin/bash

echo “Hellow Universe!”

Здесь первая строка является комментарием где указывается путь до интерпретатора, который будет выполнять скрипт.

Если не указать интерпретатор вручную, то будет использоваться интерпретатор по умолчанию, чаще всего это оболочка /bin/sh.

Во второй строке указана команда вывода echo и ее аргумент “Hello Universe!”.

Чтобы скрипт мог быть выполнен к нему необходимо добавить бит исполнения файла.

chmod +x /usr/local/sbin/say_hi.sh

Теперь можно просто указать имя скрипта и запустить его.

say_hi.sh

В результате увидим следующее.

meliorem@ubuntu:~$ say_hi.sh
Hello Universe!

Скрипт можно также передать самой оболочке в качестве аргумента . В этом случае делать скрипт исполняемым не обязательно.
bash say_hi.sh

Ввод и вывод данных в Bash

Вывод текстовой информации можно осуществлять с помощью команд echo и printf.

Разница между ними лишь в том, что echo не позволяет форматировать текст (без добавления ключа -e) и делает автоматический перенос строки в отличии от printf.

Различия команд представлены ниже.

#!/bin/bash

echo “tHello there! u263bn”

printf “tHello there! u263bn”

meliorem@ubuntu:~$ say_hi.sh
tHello there! u263bn
Hello there! ☻
meliorem@ubuntu:~$

Ввод данных осуществляется с помощью команды – read. Результат ввода необходимо сохранять в переменную.

#!/bin/bash

echo –n “Введите ваше имя: “

read user_name

echo “Добрый день, $user_name!”

meliorem@ubuntu:~$ Введите ваше имя: Oleg
Добрый день, Oleg!
meliorem@ubuntu:~$

Комментарии в Bash

Комментарии предназначены для описания того, что происходит в скрипте на отдельных его участках, чтобы сам создатель скрипта и другие пользователи могли быстрее разобраться в тонкостях его работы.

Комментарии полностью игнорируются интерпретатором (кроме первой строки).

Однострочным комментарием будет считаться одна или несколько строк в начале которых стоит символ – #.

#!/bin/bash

echo –n “Введите ваше имя: “

# Просим пользователя ввести своё имя.

read user_name

echo “Добрый день, $user_name!”

В Bash также доступны многострочные комментарии, которые начинаются с символа – : и находятся внутри двойных или одинарных кавычек.

Не забудьте оставить пробел между : и первой кавычкой.

#!/bin/bash

: “

Данный скрипт принимает два числа

в качестве аргументов

и выводит результат

их суммы.

“

((sum=$1+$2))

echo $sum

exit

Еще один вариант составления многострочного комментария.

#!/bin/bash

echo –n “Введите ваше имя: “

&lt;&lt;bigcomment

Просим пользователя

ввести своё имя.

bigcomment

read user_name

echo “Добрый день, $user_name!”

Отладка Bash-скриптов

В Bash поддерживается отладка скриптов и проверка синтаксиса.

Используйте команду bash c ключом -x для запуска скрипта в режиме отладки.

bash -x script.sh

Также есть возможность передать ключ в самом скрипте.

#!/bin/bash -x

echo “Ждать 5 секунд”

sleep 5

echo “Выполнено!”

Отладку также можно производить выборочно для отдельных участков кода. В этом поможет настройка параметров оболочки с помощью команды set.

Чтобы начать отладку определенного участка кода, вставьте строку с set -x в начало участка и set +x в его конец.

С помощью команды set можно включать и выключать определенные параметры оболочки. Ознакомится со списком параметров можно после ввода команды set -o.

  • set -x/set +x – начать/закончить отладку.
  • set -v – выводить строки ввода по мере их чтения.
  • set -n – проверка синтаксиса, без выполнения самого кода.
  • set -o [параметр]/set +o [параметр] – включение/выключение параметра.

В следующем примере команда создания каталога не будет выполнена, также в консоли появится сообщение об ошибке синтаксиса.

#!/bin/bash

# Включаем параметр проверки синтаксиса

set –o noexec

if [someerror]

mkdir project

echo “Создан новый каталог.”

# Выключаем параметр проверки синтаксиса

set +o noexec

# Другой код далее…

Особенности написания Bash-скриптов

  1. В первой строке всегда указывается интерпретатор, который будет выполнять скрипт.
    Помимо Bash вы также можете использовать другие интерпретаторы, например #!/bin/sh, #!/usr/bin/perl, #!/usr/bin/python и другие.
    Чтобы узнать путь к интерпретатору используйте команду which, например which python.
  2. Так как расширение файла не играет в Linux особой роли то приписывать .sh совсем не обязательно.
    Это делается для удобства самого пользователя.
  3. Слишком длинные команды вы можете разбить на несколько строк с помощью символа – .
  4. Вне зависимости того в какой оболочке вы находитесь, будь это zsh, csh или любая другая, скрипт будет выполнять та оболочка, путь к которой указан в первой строке.
Источник

Добавить комментарий