Відкрийте теку ~/.local/share/kservices5/ServiceMenus. Якщо цієї теки немає, просто створіть її.
mkdir -p ~/.local/share/kservices5/ServiceMenus
kate ~/.local/share/kservices5/ServiceMenus/edit-from-root.desktop
Щоб було зручно редагувати текстові файли від імені root - створити файл під назвою edit-from-root.desktop. Називати файл можна як завгодно, головне додати суфікс .desktop
[Desktop Action EditFromRoot]
Name=Edit from root
Name[uk]=Редагувати як root
Icon=alienarena
# Exec=konsole -e sudo nano -w %U
Exec=konsole -e sudo vim
Перша секція створює пункт контекстного меню із вказівником на дію (Actions). У рядку b>MimeType можна вказати типи файлів, для яких відображатиметься дія.
Друга секція визначає саму дію. Рядок Name визначає текст, яким буде підписано дію в контекстному меню. Ну, а Exec містить команду, яку потрібно виконати.
Сюди можна вписувати ті ж команди, що вводяться в термінал, або шлях до якогось скрипту.
Перед редагуванням файлу зберегти його резервну копію.
Вручну це робиться так: виклик контекстного меню файлу -> "Копіювати" -> "Вставити" -> введення нової назви файлу. Можна написати desktop-файл:
де dir_name — це ім'я нового каталогу, а [options] — необов'язкові параметри.
Наприклад, щоб створити новий каталог з ім'ям "hello_world", ми повинні ввести:
mkdir hello_world
Якщо ви хочете створити кілька каталогів,
просто помістіть їх у фігурні дужки та розділіть кожен каталог комою. Наприклад, наведений нижче код створює два каталоги з іменами «hello» та «world»:
mkdir {hello, world}
Параметри для mkdir
mkdir має 3 параметри, які ми можемо додати до нашої команди:
-p- це дозволяє створювати кілька каталогів один в одному.
-v- виводить інформацію про створений каталог або каталоги.
-m – це дозволяє нам встановити значення chmod/mode для нашого каталогу, тобто 777.
Створення декількох каталогів вкладених один в одного за допомогою mkdir-p
Припустимо, ми хотіли створити структуру тек, у якій ми маємо теку проекту в батьківській теці, у головній теці.
Якби ми використовували тільки mkdir, нам довелося створювати кожну теку окремо. Натомість ми можемо використовувати mkdir -p, щоб зробити всі теки відразу.
mkdir -p master/parent/project
Це створить три каталоги, кожен усередині іншого.
Переконайтеся, що тека створена за допомогою mkdir
Якщо ми хочемо побачити повідомлення про успішне виконання mkdir
ми можемо використовувати mkdir -v.
mkdir -v master
Наведене вище виведе наступне повідомлення:
mkdir: created directory 'master'
На жаль, -p і -v не працюватимуть разом, тому вам доведеться використовувати або одне, або інше.
Встановлення chmod або режиму каталогу за допомогою mkdir
Якщо ми хочемо встановити режим каталогу,
ми можемо встановити його за допомогою mkdir. Наприклад, щоб створити каталог зі значенням chmod 777, ми повинні написати таке:
mkdir -m777 master
Створення декількох каталогів із певним chmod або режимом за допомогою mkdir
За бажання ми можемо об'єднати -m та -p для mkdir в одну команду. Наприклад,
наведений нижче код створить структуру тек master/parent/project і встановить для кожного каталогу режим 777:
Щоб зробити перебазування, а не commit злитого вмісту, вкажіть для команди git pull параметр --rebase.
Параметр --rebase можна використовувати, щоб зберегти лінійну історію та уникнути непотрібних комітів злиття. Багато розробників вважають за краще виконувати перебазування, а не злиття, як би заявляючи: «Я хочу, щоб мої зміни додалися поверх усіх інших». У цьому сенсі команда git pull із прапором --rebase більше схожа на команду svn update,
ніж просту команду git pull.
Насправді команда pull із опцією --rebase використовується в робочому процесі настільки часто, що для неї існує виділена опція конфігурації:
git config --global branch.autosetuprebase always
Після виконання цієї команди всі команди git pull інтегруватимуться за допомогою команди git rebase,
а не git merge.
Команда git pull використовується для вилучення та завантаження вмісту з віддаленого репозиторію та негайного оновлення локального репозиторію цим вмістом.
git fetch / git merge
Команда git pull насправді є комбінацією двох інших команд: git fetch і git merge. На першому етапі git pull виконується команда git fetch, обмежена локальною гілкою, на яку вказує HEAD. Відразу після завантаження вмісту команда git pull виконує злиття. Для злитого вмісту створюється новий commit, а покажчик HEAD оновлюється і починає вказувати на цей новий commit.
git pull <remote>
Порядок дій
Спочатку команда git pull запускає команду git fetch для завантаження вмісту із зазначеного віддаленого репозиторію. Потім виконується команда git merge, що об'єднує посилання та покажчики віддаленого вмісту в новий локальний commit злиття.
git pull
Виклик команди git pull за умовчанням еквівалентний виконанню команд git fetch origin HEAD і git merge HEAD, де HEAD – це покажчик на поточну гілку.
Поширені опції
git pull <remote>
Витягти з зазначеного віддаленого репозиторію копію поточної гілки та негайно злити її з локальною копією. Ця команда аналогічна команді git fetch <віддалений-репозиторій>, після якої слідує команда git merge origin/<поточна-гілка>.
git pull --no-commit
Подібно до стандартного виклику, видаляє віддалений вміст, але не створює новий коміт зі злитим вмістом.
git pull --rebase
Аналогічно попередній команді pull тільки замість команди git merge для інтеграції віддаленої гілки з локальною гілкою використовується команда git rebase.
git pull --verbose
Під час виконання команди pull видає докладний висновок про вміст, що завантажується, і інформацію про злиття.
Перед push треба зв'язати локальний та віддалений репозиторії. Робиться це за допомогою команди:
git remote add <repository_name> <link>
Замість repository_name потрібно дати ім'я віддаленому репозиторію. Далі в інструкції замість цього параметра ми використовуватимемо origin, оскільки найчастіше використовують це ім'я.
Замість link — посилання на віддалений репозиторій, воно може виглядати по-різному, залежно від того, використовується ssh або https.
Надсилання змін
Перед push треба зафіксувати поточні зміни, тобто зробити git commit.
Далі для відправлення в терміналі пишемо:
git push origin <branch>
Замість branch – ім'я гілки, яку треба відправити. Найчастіше використовується master або main:
git push origin master
Таке щоразу писати надто громіздко, для цього придумали git push за замовчуванням.
Для цього один раз набираємо попередню команду з прапором -u:
git push -u origin master
Після цього можна писати коротше, тому що git запам'ятав, що пушити треба на сервер origin гілку під ім'ям master:
git push
Таким чином, git дозволяє запушити гілку у віддалений репозиторій. Щоб через git додати гілку у віддалений репозиторій, треба запушити існуючу локальну гілку.
Додаткові опції публікації
Надсилання гілки на сервер у гілку з іншим ім'ям
Для того щоб зробити git push в іншу гілку, є спеціальний синтаксис, де після імені гілки через двокрапку пишеться ім'я віддаленої гілки:
git push origin branch:server_branch
де branch – ім'я локальної гілки,
server_branch – ім'я віддаленої гілки на сервері.
Надсилання всіх гілок на сервер
Замість імені гілки пишемо прапор -all:
git push origin --all
Після цього всі зафіксовані зміни у гілках вирушать у віддалений репозиторій.
Надсилання поточної гілки
Зручний спосіб відправити поточну гілку з тим самим ім'ям на сервері.
git push origin HEAD
HEAD свідчить про поточну гілку (current branch). Тим самим не потрібно запам'ятовувати ім'я гілки, на якій ви знаходитесь.
Примусова публікація (git push - force ...)
При надсиланні може статися помилка публікації:
To github.com:example/test.git
! [rejected] master -> master (fetch first)
error: не вдалося надіслати деякі посилання до «github.com:example/test.git»
Це так званий git push rejected, він означає, що push був відхилений. Найправильніше — зробити те, що написано у підказці до помилки. Потрібно отримати та смержити зміни, потім знову відправити.
Ця помилка відбувається, тому що git перевіряє,
що новий commit заснований на попередніх комітах. Поки ви вносили зміни, хтось міг запустити зміни того, над чим ви працювали. Тому git не може виконати автоматичне злиття, ваш commit був раніше і він не базується на оновлених коммітах у віддаленому репозиторії.
Прапором -force або скороченою його версією -f вимикається перевірка коммітів і за потреби виконується перезапис історії.
git push --force
Потрібно бути обережними з цією командою, оскільки вона стирає роботу інших людей. Ця команда виправдана лише зрідка, наприклад, якщо ви майже одразу внесли зміни комміту за допомогою git commit-amend і запушили до того, як хтось зробив git pull.
Примусова публікація з параметром (git push - force-with-lease ...)
Це безпечніший, але так само нерекомендований варіант варіант примусового пушингу. Він не перезапише роботу у віддаленій гілці, якщо до неї були додані комміти від інших людей.
git push --force-with-lease
Примусова публікація з цим параметром загрожує появою git push rejected в інших людей
Не рекомендувано використовувати "git pull" взагалі, тому що ця команда бере на себе занадто багато функцій і її поведінка не є очевидною. Рекомендовано розібратися докладніше, як працює git, та використовувати fetch+merge або fetch+rebase
git reset --hard
git checkout master
git reflog
# Знайти хэш комміта, в якому знаходились до першого pull-а.
# Буде щось на кшталт: "8f05e00 HEAD@{4}: checkout: moving from master to master"
# або "4c31200 HEAD@{10}: commit: Awesome feature implemented."
git reset --hard [потрібний хеш]
Перший раз git reset потрібно, щоб очистити дерево від незакомічених змін, які могли залишитися від минулих pull-ів (merge конфлікти). Якщо таких змін немає, то команда нічого не зробить. З "брудним" деревом не вдасться зробити checkout master, а для останньої команди ми маємо перебувати на master
У TypeScript використовується кілька способів типизувати функції, які передаються як параметри.
Найпростіший – використовувати тип Function. Він описує функцію JavaScript з усіма її особливостями, включаючи властивості bind, call та apply.
Опишемо вхідний параметр callback функції process:
function process(callback: Function) {
const value = callback();
// ...
}
Function відключає перевірку типів для функції, що викликається. В результаті кількість і тип вхідних аргументів не перевіряються, а результатом роботи такої функції буде any. Це може призвести до логічних помилок та несподіваної поведінки:
process(Math.round); //?
Даний приклад спрацює, хоча поведінка навряд чи буде очікуваною, оскільки Math.round викличеться без аргументів і поверне NaN. Тому ми рекомендуємо уникати використання Function.
Інший спосіб описувати функції - використовувати стрілочну функцію із зазначенням вхідних та вихідних типів:
function process(callback: () => string) {
// value має тип string
const value = callback();
// ...
}
process(Math.round);
// Argument of type '(x: number) => number' is not
// assignable to parameter of type '() => string'.
Визначення стрілочної функції схоже на справжню, але тут важливо не переплутати. Тут бачимо саме опис типу, а не визначення функції.
Розглянемо ще кілька прикладів для закріплення:
function process(callback: () => number)
function process(callback: () => string[])
function process(callback: () => { firstName: string; })
Параметри синтаксично вказуються так само, як і для стрілочних функцій:
function process(callback: (n: number) => string) {
const value = callback(10);
// ...
}
Тут ми визначили тип callback функцією з параметром n з типом number і значення string, що повертається.
Якщо визначення функції зустрічається часто, то для нього можна створити псевдонім:
type myFunction = (n: number) => string;
function process(callback: myFunction) {
const value = callback(10);<
// ...
}
Такий запис спрощує читання коду та дозволяє уникнути дублювання.
Метод process.cwd() — це вбудований інтерфейс прикладного програмування process module, який використовується для отримання поточного робочого каталогу процесу node.js.
Цей метод не приймає жодних параметрів. Повертає рядок, що вказує поточний робочий каталог процесу node.js. Нижче наведено приклад використання методу process.cwd() в Node.js
// Include process module
const process = require('process');
// Printing current directory
console.log("Current working directory: ",
process.cwd());