Pull to refresh
5
0
Send message

Разве этот код не вылетает по переполнению стека?

check_idle_time() {
    ...
    check_idle_time
}

check_idle_time

По п5. Все верно. Редактируете /etc/apt/sources.list и /etc/apt/sources.list.d/* - пишете туда все, что вам требуется, а потом apt update ; apt dist-upgrade -y ; apt install все что надо для счастья . Или вендор рекомендует другой путь?

Несколько замечаний

1.

#Получение короткого имени hostname
hostnamectl set-hostname DC_NAME.DOMAIN_NAME

В первом листинге: коммент не соответствует действию

2.

$IPADDR $SERVER_NAME.DOMAIN_NAME $PC_NAME

Во втором листинге используется необъявленная переменная PC_NAME

3.

ALDPRO_CHECK=`dpkg -l | grep aldpro-client`
if [[ -z $ALDPRO_CHECK ]];

это можно упростить до

if ! dpkg -l aldpro-client >/dev/null 2>&1

4.

-d "{
"data": {

Чтобы не мучиться с экранированием кавычек в кавычках, лучше вызватьcat в субшелле, например:

-d "$(
  cat - <<-DATA
  {
    "data": {
    ...
DATA
)"

5.

обновление ОС - первый скрипт

#Обновление ОС до актуальной версии
apt update -y
apt install astra-update -y && sudo astra-update -A -r -T

обновление ОС - второй скрипт

#Установка пакетов ALD Pro
apt update -y
DEBIAN_FRONTEND=noninteractive apt-get install -q -y aldpro-client

Получается на второй машине почему-то игнорируется обновление системы. И вообще в целом, обновление репозиториев выстроено нелогично. Лучше прописать все источники в sources.list и//или sources.list.d/, а потом выполнить обновления репо, системы и установку нужных пакетов.

Дальше уже читал по диагонали.

А вот &> — маст‑хэв для тех, кто хочет всё в одном флаконе: и stdout, и stderr вместе.

Спорное утверждение. Почему оно именно мастхэв? Чем оно лучше явных1>FILE 2>FILE или >FILE 2>&1 кроме того, что &> это нововведение баша и просто более короткий вариант?

Тогда уж вкупе с этим неплохо было бы рассказать и про башевский массив PIPESTATUS. Хоть статья и рассказывает о потоках, но примеры все башевские. В других шеллах эти примеры могут и не сработать.

Не первый раз мне попадаются статьи и разборы про знаки препинания, и, конкретно, эти мне больше всего не понятны.

  1. Наверно, многие их не различают и не понимают, что они значат. Например, мне, как читателю достаточно понятно, что написано: "пять - восемь книг" (с пробелами или без), или "5-8 книг", или "любовь - это...".

  2. Другой момент. Ужели на письме кто-то все эти тире, дефисы, минусы отмечает и различает? Может это автор выразил свою экспрессию и вместо тире у него вышло длинное тире? И когда кто-то другой переносит авторский рукописный текст в цифру, понимает ли он пунктуационную мысль автора?

найти прямоугольник без чёрных клеток максимальной площади

на сайте по ссылке под фразой "Answer should be a single value - size of the largest rectangle". Наверно подразумевается "Answer should be a single value - area of the largest rectangle"?

В программировании важны алгоритмы, а не ЯП и фреймворки.

Попробуйте найти человека (школьный учитель, преподаватель вуза, знакомый программист) любого, который просто и доступно расскажет об алгоритмах: как правильно формулировать задачу, какие бывают алгоритмы, почему для одной задачи в разных условиях можно использоваться разные алгоритмы, как на основе описания составлять алгоритм, как учитывать "граничные" условия, ну а уже потом реализовывать алгоритм с помощью нескольких ЯП - вначале наиболее знакомого ученику, потом на другим. Вместе с реализацией алгоритма раскрывать характерные приемы и идиомы того или иного ЯП. Паралельно можно (и нужно) рассказать о нескольких наиболее популярных форматах данных.

И, по началу, держитесь подальше от онлайн скилл-курсов и прочих практикумов.

Что такое регулярные выражения? Это измерительная рулетка, где вместо металлической ленты - резиновая. Растягивая такую рулетку можно "измерить" почти любой текст, подгоняя разметку под текст.

Или нужно узнать, сколько будет 18 процентов от 50: 50 * 18 %, результат 9

18% * 50 = 18 * 50% = 9

Из-за того, что у калькулятора ограничена память программ, производилась какая-то дичайшая оптимизация, поэтому она выглядит так запутанно. Но, к моему сожалению, ни толковой литературы, ни описания, как это делалось, мне не удалось найти.

Ребятишки узнали про аппаратные ограничения и возможности/способы эти ограничения обойти.

Искра-1256 нашлась в поиске. Сам не сразу вспомнил, как она звалась. Я на такой фортран мучил и какой-то странный фортрано-подобный язык по названием "символьно-скобочный язык".

Нууу...

Первое задание. Можно было бы решить проще:

select *
from #Movements
where EventCode <> 'EMI'
or EventCode = 'EMI'
and CreateDate = (
  select min(CreateDate)
  from #Movements
  where EventCode = 'EMI'
)

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

В целом: на супер-пупер сборник задач не тянет, но порешать можно.

Команда ls по умолчанию сортирует результат своего выполнения. Вероятно, сортировка производится в памяти. Однажды я столкнулся с проблемой падения ls * на нескольких десятках тысяч файлов. В таких случаях ls -U или find спасают ситуацию.

Есть переменная $PATH, которая содержит список путей, где искать файлы на исполнение. Например:

PATH=/bin:/usr/bin:/usr/local/bin

Когда в командой строке пишете что-то вроде:

$ какая-то-команда с какими-то ключами

то оболочка (bash, sh, zsh или, прости господи, cmd) ищет файл, перебирая все пути из переменной $PATH. То есть оболочка ищет исполнимый файл, один из:

/bin/какая-то-команда
/usr/bin/какая-то-команда
/usr/local/bin/какая-то-команда

Как только будет найден файл для запуска (исполнения), поиск прекращается и вызывается команда с параметрами, например:

/какой/то/путь/какая-то-команда с какими-то ключами

Если вы явно описываете путь

./какая-то-команда с какими-то ключами

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

Здесь описана упрощенная схема. Здесь не описаны особые случаи для псевдонимов (alias), функций, которые обрабатываются в первую очередь. Также не сказано про очень особый случай с cmd.exe, который а) дополнительно смотрит на расширение файла (сравнивает с переменной %PATHEXT%, ищет ассоциации по расширению, выполняет еще какие-то магические действия), б) игнорирует переменную %PATH%, если в текущем каталоге имеется исполнимый файл с таким именем и в) некоторые его подводные камни.

Нууу. Сильный акцент, часто повторяющиеся слова, быстрая речь, но очень живая - он не монотонно долбит, как перфоратор, но использует интонацию. Конечно, очень широкую улыбку вызывает. Но речь-то очень и очень грамотная. Аригатин?

Забыл сказать. Хранить временные файлы в текущем каталоге - не есть хорошо. Если вы рут, то вы просто засоряете ФС. Если рядовой - у вас может не быть прав на текущий каталог и результат вашего скрипта - не предсказуем.

Почему это важно. Скрипт можно завершить разными способами: клавишами CTRL-C, командой kill. В результате - команды rm FILE в конце скрипта могут быть и не выполнены. А в ФС вы оставите следы выполнения скрипта в произвольном месте.

Лучшее решение для этого (но этого не гарантирует от полной очистки ФС и, тем более, от авадакедавры типа kill -9) - в начале скрипта описать что-то вида:

# Какой-то временный файл, который нужен только на время выполнения скрипта
# $$ - PID текущего процесса в имени файла, обеспечивает уникальность файла
TMPFILE="${TMP:-/tmp}/certmgr-list-$$.out"

# ловушка - код, который будет выполнен по выходу (`EXIT`) из скрипта
# может быть внешней или внутренней командой или шелл-функцией
trap 'rm -f "$TMPFILE"' EXIT

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

предложениям по оптимизации bash скрипта

1

Сразу скажу, что #!/bin/sh и конструкции вида [[ ... ]] или (( ... <= ... )) (которые назыаются башизмами) - несовместимые вещи. Такой шебанг в начале скрипта предполагает, что это будет классифеский шелл, который не поддерживает удобные, расширенные возможности баша.

Поэтому: или #!/usr/bin/env bash и используйте всю мощь баша или откажитесь от башизмов.

2

Выхлоп команды всегда оборачивайте в двойные кавычки. Хотя это уже давно не так, но не каждый шелл понимает, что строка вида "слово слово слово" это одна цельная строка а не одно слово как значение переменной, а все остальное это некоторая команда, которую шелл может и выполнить.

3

Надо оптимизировать скрипт: я насчитал 5 вызовов команды certmgr -list. При этом в трех местах используется grep -E "Subject ". Понятно, что в каждый момент вы собираете разную информацию, но это очень не рационально.

4

Ваш скрипт построен по принципу

команда1 > FILE
команда2 >> FILE
cat FILE

Вероятно нет смысла вначале все сохранять в файл, а потом этот файл выводить. надо сразу писать в STDOUT. Если промежуточный результат надо еще как-то дополнительноо обработать, то можно сделать примерно так:

что-то-писать() {
	команда1
	команда2
}

что-то-писать | как-то-обрабатывать

5

Простите, но cat FILE | tail -n $COUNTER | head -n 1 - это ужасно. Определенно, требуется оптимизация в части пунктов 3 и 4.

Я понимаю, что оно уже работает и чего его трогать. Но неоптимально написанный код в будущем порождает "неоптимальную оптимизацию".

6. Резюме

Я не знаю, как работает certmgr и каков его выхлоп, но смею предположить, что однократный вызов certmgr -list | grep -e 'Subject ' -e 'Not valid after' > "$TMP/certmgr-$$.out" уже будет существенной оптимизацией. А дальше работать с файлом "$TMP/certmgr-$$.out".

Выразительных средств awk/perl будет достаточно, чтобы оптимизировать скрипт, поддерживать его в дальнейшем и даже, при необходимости, с легкостью улучшать.

люди задействовали два самых важных канала для общения – зрение и слух

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

1
23 ...

Information

Rating
9,984-th
Registered
Activity