По п5. Все верно. Редактируете /etc/apt/sources.list и /etc/apt/sources.list.d/* - пишете туда все, что вам требуется, а потом apt update ; apt dist-upgrade -y ; apt install все что надо для счастья . Или вендор рекомендует другой путь?
Получается на второй машине почему-то игнорируется обновление системы. И вообще в целом, обновление репозиториев выстроено нелогично. Лучше прописать все источники в sources.list и//или sources.list.d/, а потом выполнить обновления репо, системы и установку нужных пакетов.
А вот &> — маст‑хэв для тех, кто хочет всё в одном флаконе: и stdout, и stderr вместе.
Спорное утверждение. Почему оно именно мастхэв? Чем оно лучше явных1>FILE 2>FILE или >FILE 2>&1 кроме того, что &> это нововведение баша и просто более короткий вариант?
Тогда уж вкупе с этим неплохо было бы рассказать и про башевский массив PIPESTATUS. Хоть статья и рассказывает о потоках, но примеры все башевские. В других шеллах эти примеры могут и не сработать.
Не первый раз мне попадаются статьи и разборы про знаки препинания, и, конкретно, эти мне больше всего не понятны.
Наверно, многие их не различают и не понимают, что они значат. Например, мне, как читателю достаточно понятно, что написано: "пять - восемь книг" (с пробелами или без), или "5-8 книг", или "любовь - это...".
Другой момент. Ужели на письме кто-то все эти тире, дефисы, минусы отмечает и различает? Может это автор выразил свою экспрессию и вместо тире у него вышло длинное тире? И когда кто-то другой переносит авторский рукописный текст в цифру, понимает ли он пунктуационную мысль автора?
найти прямоугольник без чёрных клеток максимальной площади
на сайте по ссылке под фразой "Answer should be a single value - size of the largest rectangle". Наверно подразумевается "Answer should be a single value - area of the largest rectangle"?
В программировании важны алгоритмы, а не ЯП и фреймворки.
Попробуйте найти человека (школьный учитель, преподаватель вуза, знакомый программист) любого, который просто и доступно расскажет об алгоритмах: как правильно формулировать задачу, какие бывают алгоритмы, почему для одной задачи в разных условиях можно использоваться разные алгоритмы, как на основе описания составлять алгоритм, как учитывать "граничные" условия, ну а уже потом реализовывать алгоритм с помощью нескольких ЯП - вначале наиболее знакомого ученику, потом на другим. Вместе с реализацией алгоритма раскрывать характерные приемы и идиомы того или иного ЯП. Паралельно можно (и нужно) рассказать о нескольких наиболее популярных форматах данных.
И, по началу, держитесь подальше от онлайн скилл-курсов и прочих практикумов.
Что такое регулярные выражения? Это измерительная рулетка, где вместо металлической ленты - резиновая. Растягивая такую рулетку можно "измерить" почти любой текст, подгоняя разметку под текст.
Из-за того, что у калькулятора ограничена память программ, производилась какая-то дичайшая оптимизация, поэтому она выглядит так запутанно. Но, к моему сожалению, ни толковой литературы, ни описания, как это делалось, мне не удалось найти.
Ребятишки узнали про аппаратные ограничения и возможности/способы эти ограничения обойти.
Искра-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. То есть оболочка ищет исполнимый файл, один из:
Как только будет найден файл для запуска (исполнения), поиск прекращается и вызывается команда с параметрами, например:
/какой/то/путь/какая-то-команда с какими-то ключами
Если вы явно описываете путь
./какая-то-команда с какими-то ключами
то поиск не производится, а делается попытка запустить такую команду.
Здесь описана упрощенная схема. Здесь не описаны особые случаи для псевдонимов (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
И вам уже не надо писать отдельные команды для удаления временных файлов.
Сразу скажу, что #!/bin/sh и конструкции вида [[ ... ]] или (( ... <= ... )) (которые назыаются башизмами) - несовместимые вещи. Такой шебанг в начале скрипта предполагает, что это будет классифеский шелл, который не поддерживает удобные, расширенные возможности баша.
Поэтому: или #!/usr/bin/env bash и используйте всю мощь баша или откажитесь от башизмов.
2
Выхлоп команды всегда оборачивайте в двойные кавычки. Хотя это уже давно не так, но не каждый шелл понимает, что строка вида "слово слово слово" это одна цельная строка а не одно слово как значение переменной, а все остальное это некоторая команда, которую шелл может и выполнить.
3
Надо оптимизировать скрипт: я насчитал 5 вызовов команды certmgr -list. При этом в трех местах используется grep -E "Subject ". Понятно, что в каждый момент вы собираете разную информацию, но это очень не рационально.
4
Ваш скрипт построен по принципу
команда1 > FILE
команда2 >> FILE
cat FILE
Вероятно нет смысла вначале все сохранять в файл, а потом этот файл выводить. надо сразу писать в STDOUT. Если промежуточный результат надо еще как-то дополнительноо обработать, то можно сделать примерно так:
Простите, но 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 будет достаточно, чтобы оптимизировать скрипт, поддерживать его в дальнейшем и даже, при необходимости, с легкостью улучшать.
Разве этот код не вылетает по переполнению стека?
По п5. Все верно. Редактируете
/etc/apt/sources.list
и/etc/apt/sources.list.d/*
- пишете туда все, что вам требуется, а потомapt update ; apt dist-upgrade -y ; apt install все что надо для счастья
. Или вендор рекомендует другой путь?Несколько замечаний
1.
В первом листинге: коммент не соответствует действию
2.
Во втором листинге используется необъявленная переменная PC_NAME
3.
это можно упростить до
4.
Чтобы не мучиться с экранированием кавычек в кавычках, лучше вызвать
cat
в субшелле, например:5.
обновление ОС - первый скрипт
обновление ОС - второй скрипт
Получается на второй машине почему-то игнорируется обновление системы. И вообще в целом, обновление репозиториев выстроено нелогично. Лучше прописать все источники в sources.list и//или sources.list.d/, а потом выполнить обновления репо, системы и установку нужных пакетов.
Дальше уже читал по диагонали.
Спорное утверждение. Почему оно именно мастхэв? Чем оно лучше явных
1>FILE 2>FILE
или>FILE 2>&1
кроме того, что&>
это нововведение баша и просто более короткий вариант?Тогда уж вкупе с этим неплохо было бы рассказать и про башевский массив
PIPESTATUS
. Хоть статья и рассказывает о потоках, но примеры все башевские. В других шеллах эти примеры могут и не сработать.Не первый раз мне попадаются статьи и разборы про знаки препинания, и, конкретно, эти мне больше всего не понятны.
Наверно, многие их не различают и не понимают, что они значат. Например, мне, как читателю достаточно понятно, что написано: "пять - восемь книг" (с пробелами или без), или "5-8 книг", или "любовь - это...".
Другой момент. Ужели на письме кто-то все эти тире, дефисы, минусы отмечает и различает? Может это автор выразил свою экспрессию и вместо тире у него вышло длинное тире? И когда кто-то другой переносит авторский рукописный текст в цифру, понимает ли он пунктуационную мысль автора?
на сайте по ссылке под фразой "Answer should be a single value -
size
of the largest rectangle". Наверно подразумевается "Answer should be a single value -area
of the largest rectangle"?В программировании важны алгоритмы, а не ЯП и фреймворки.
Попробуйте найти человека (школьный учитель, преподаватель вуза, знакомый программист) любого, который просто и доступно расскажет об алгоритмах: как правильно формулировать задачу, какие бывают алгоритмы, почему для одной задачи в разных условиях можно использоваться разные алгоритмы, как на основе описания составлять алгоритм, как учитывать "граничные" условия, ну а уже потом реализовывать алгоритм с помощью нескольких ЯП - вначале наиболее знакомого ученику, потом на другим. Вместе с реализацией алгоритма раскрывать характерные приемы и идиомы того или иного ЯП. Паралельно можно (и нужно) рассказать о нескольких наиболее популярных форматах данных.
И, по началу, держитесь подальше от онлайн скилл-курсов и прочих практикумов.
Что такое регулярные выражения? Это измерительная рулетка, где вместо металлической ленты - резиновая. Растягивая такую рулетку можно "измерить" почти любой текст, подгоняя разметку под текст.
18% * 50 = 18 * 50% = 9
ГОСТ 16876-71 таблица 2
https://en.wikipedia.org/wiki/GOST_16876-71
Ребятишки узнали про аппаратные ограничения и возможности/способы эти ограничения обойти.
Искра-1256 нашлась в поиске. Сам не сразу вспомнил, как она звалась. Я на такой фортран мучил и какой-то странный фортрано-подобный язык по названием "символьно-скобочный язык".
Нууу...
Первое задание. Можно было бы решить проще:
Второе задание. Сколько его я ни перечитывал, так и не понял, как описание, согласуется с видимым результатом.
В целом: на супер-пупер сборник задач не тянет, но порешать можно.
Команда
ls
по умолчанию сортирует результат своего выполнения. Вероятно, сортировка производится в памяти. Однажды я столкнулся с проблемой паденияls *
на нескольких десятках тысяч файлов. В таких случаяхls -U
илиfind
спасают ситуацию.Есть переменная
$PATH
, которая содержит список путей, где искать файлы на исполнение. Например:Когда в командой строке пишете что-то вроде:
то оболочка (bash, sh, zsh или, прости господи, cmd) ищет файл, перебирая все пути из переменной
$PATH
. То есть оболочка ищет исполнимый файл, один из:Как только будет найден файл для запуска (исполнения), поиск прекращается и вызывается команда с параметрами, например:
Если вы явно описываете путь
то поиск не производится, а делается попытка запустить такую команду.
Здесь описана упрощенная схема. Здесь не описаны особые случаи для псевдонимов (alias), функций, которые обрабатываются в первую очередь. Также не сказано про очень особый случай с
cmd.exe
, который а) дополнительно смотрит на расширение файла (сравнивает с переменной%PATHEXT%
, ищет ассоциации по расширению, выполняет еще какие-то магические действия), б) игнорирует переменную%PATH%
, если в текущем каталоге имеется исполнимый файл с таким именем и в) некоторые его подводные камни.Нууу. Сильный акцент, часто повторяющиеся слова, быстрая речь, но очень живая - он не монотонно долбит, как перфоратор, но использует интонацию. Конечно, очень широкую улыбку вызывает. Но речь-то очень и очень грамотная. Аригатин?
Забыл сказать. Хранить временные файлы в текущем каталоге - не есть хорошо. Если вы рут, то вы просто засоряете ФС. Если рядовой - у вас может не быть прав на текущий каталог и результат вашего скрипта - не предсказуем.
Почему это важно. Скрипт можно завершить разными способами: клавишами
CTRL-C
, командойkill
. В результате - командыrm FILE
в конце скрипта могут быть и не выполнены. А в ФС вы оставите следы выполнения скрипта в произвольном месте.Лучшее решение для этого (но этого не гарантирует от полной очистки ФС и, тем более, от авадакедавры типа
kill -9
) - в начале скрипта описать что-то вида:И вам уже не надо писать отдельные команды для удаления временных файлов.
1
Сразу скажу, что
#!/bin/sh
и конструкции вида[[ ... ]]
или(( ... <= ... ))
(которые назыаются башизмами) - несовместимые вещи. Такой шебанг в начале скрипта предполагает, что это будет классифеский шелл, который не поддерживает удобные, расширенные возможности баша.Поэтому: или
#!/usr/bin/env bash
и используйте всю мощь баша или откажитесь от башизмов.2
Выхлоп команды всегда оборачивайте в двойные кавычки. Хотя это уже давно не так, но не каждый шелл понимает, что строка вида "слово слово слово" это одна цельная строка а не одно слово как значение переменной, а все остальное это некоторая команда, которую шелл может и выполнить.
3
Надо оптимизировать скрипт: я насчитал 5 вызовов команды
certmgr -list
. При этом в трех местах используетсяgrep -E "Subject "
. Понятно, что в каждый момент вы собираете разную информацию, но это очень не рационально.4
Ваш скрипт построен по принципу
Вероятно нет смысла вначале все сохранять в файл, а потом этот файл выводить. надо сразу писать в STDOUT. Если промежуточный результат надо еще как-то дополнительноо обработать, то можно сделать примерно так:
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 будет достаточно, чтобы оптимизировать скрипт, поддерживать его в дальнейшем и даже, при необходимости, с легкостью улучшать.
Вот ведь как оно все повернулось - вначале жабры видоизменились в ухо-горло-нос, а потом хлеборезкой мы научились транслировать мысли.