Issue #3090301 by Balu Ertl: [HU] Remove unnecessary prompt signs before commands

source/hu/extend-git.txt

@@ -35,7 +35,7 @@ Ezeket a lépéseket csak egyszer kell elvégezni, miután létrehoztuk tároló
 
 . Nyissunk meg egy parancssoros ablakot és navigáljunk el abba a könyvtárba, ahol a webhelyünk szoftverének forráskódja található.
 
-. Mivel a Drupal eltérő könyvtárszerkezetekkel, több féle módon is telepíthető, verziókövetni pedig általában a gyökérkönyvtártól (angolul „docroot”) lefelé érdemes, ezért meg kell állapítanunk, hogy nekünk a gyökérkönyvtárunk hol található. Ha parancssorban egy `$ ls` parancsot kiadva látjuk a _core_, _modules_ és _themes_ könyvtárakat, akkor már meg is találtuk. Ha viszont Composer használatával telepítettünk, akkor egy szinttel mélyebben, a _web/_ alkönyvtárban találjuk ezeket, ilyenkor ez lesz a gyökérkönyvtárunk.
+. Mivel a Drupal eltérő könyvtárszerkezetekkel, több féle módon is telepíthető, verziókövetni pedig általában a gyökérkönyvtártól (angolul „docroot”) lefelé érdemes, ezért meg kell állapítanunk, hogy nekünk a gyökérkönyvtárunk hol található. Ha parancssorban egy `ls` parancsot kiadva látjuk a _core_, _modules_ és _themes_ könyvtárakat, akkor már meg is találtuk. Ha viszont Composer használatával telepítettünk, akkor egy szinttel mélyebben, a _web/_ alkönyvtárban találjuk ezeket, ilyenkor ez lesz a gyökérkönyvtárunk.
 
 . Alapértelmezés szerint a verziókövetés minden egyes alkönyvtárra, és bennük valamennyi fájlra kiterjed. Bár a verziókövetés az esetek többségében valóban hasznos, de bizonyos dolgok változásait veszélyes vagy felesleges nyilvántartani:
 +
@@ -52,21 +52,21 @@ sites/*/files
 config
 ----
 
-. Hozzuk létre (idegen szóval _inicializáljuk_) a tárolót a `$ git init` paranccsal. Ezzel a csak sima, átlagos könyvtárunkat máris egy Git-tárolóvá alakítottuk, amiben innentől kezdve használhatjuk a verziókövetést.
+. Hozzuk létre (idegen szóval _inicializáljuk_) a tárolót a `git init` paranccsal. Ezzel a csak sima, átlagos könyvtárunkat máris egy Git-tárolóvá alakítottuk, amiben innentől kezdve használhatjuk a verziókövetést.
 
-. Adjuk hozzá valamennyi létező fájlt és alkönyvtárat (kivéve persze a fenti _.gitignore_-ban kizártakat) a menteni kívánt állapothoz a `$ git add -A` paranccsal. Így közöljük a Git-tel, hogy a következő állapotmentéskor mikről készítsen majd pillanatfelvételt.
+. Adjuk hozzá valamennyi létező fájlt és alkönyvtárat (kivéve persze a fenti _.gitignore_-ban kizártakat) a menteni kívánt állapothoz a `git add -A` paranccsal. Így közöljük a Git-tel, hogy a következő állapotmentéskor mikről készítsen majd pillanatfelvételt.
 
-. Ha szükséges, a `$ git status` paranccsal bármikor ellenőrizhetjük, hogy jelenleg mi szerepel a menteni kívánt állapotban (angolul „staged”). Ez általában egy tucat vagy még annál is kevesebb fájlt szokott jelezni, ahogy fejlődik a webhelyünk. De most – mivel a tárolónk változástörténetének legeslegelején vagyunk – a Drupal összes fájlját és könyvtárát (ami tízezernél is több!) fel fogja sorolni, hiszen mindegyik új a Git számára.
+. Ha szükséges, a `git status` paranccsal bármikor ellenőrizhetjük, hogy jelenleg mi szerepel a menteni kívánt állapotban (angolul „staged”). Ez általában egy tucat vagy még annál is kevesebb fájlt szokott jelezni, ahogy fejlődik a webhelyünk. De most – mivel a tárolónk változástörténetének legeslegelején vagyunk – a Drupal összes fájlját és könyvtárát (ami tízezernél is több!) fel fogja sorolni, hiszen mindegyik új a Git számára.
 
-. Kezdeményezzük az állapotmentést (vagy a magyar nyelvű webfejlesztők által gyakran használt kifejezéssel élve _kommitoljuk be_) a `$ git commit -m "Ez az első kommit ebben a repóban."` paranccsal.
+. Kezdeményezzük az állapotmentést (vagy a magyar nyelvű webfejlesztők által gyakran használt kifejezéssel élve _kommitoljuk be_) a `git commit -m "Ez az első kommit ebben a repóban."` paranccsal.
 
-. Ha szeretnénk meggyőződni az állapotmentés (vagyis _kommit_) sikerességéről, akkor a `$ git log` paranccsal vessünk egy pillantást a tárolónk – immár megkezdődött – változástörténetére.
+. Ha szeretnénk meggyőződni az állapotmentés (vagyis _kommit_) sikerességéről, akkor a `git log` paranccsal vessünk egy pillantást a tárolónk – immár megkezdődött – változástörténetére.
 
 . Eddig jól haladunk, már létezik egy biztos pont webhelyünk életében, ahová bármikor visszajöhetünk a jövőben, ha úgy érezzük majd, jobb lenne visszatérni a mostani kezdetekhez. Talán már sejtjük, hogy az „időutazás” ilyesféle formája mekkora segítség tud lenni bizonyos helyzetekben. Éppen ezért a Git-tárolónk információit – ahogy minden fontosabb adatot általában – érdemes több számítógépen is elhelyezni vész esetére. Most azonban még csak egy gépen van meg: azon, ahol a fenti parancsokat az előbb kiadtuk.
 
-. Jelezzük a helyi Git-kliensünknek, hogy hol éri el a tárolónk távoli párját a `$ git remote add origin https://gitlab.com/pelda-nev/pelda-tarolo.git` paranccsal. Természetesen a webcím helyett a saját tárolónk korábban már feljegyzett klónozási webcímét használjuk.
+. Jelezzük a helyi Git-kliensünknek, hogy hol éri el a tárolónk távoli párját a `git remote add origin https://gitlab.com/pelda-nev/pelda-tarolo.git` paranccsal. Természetesen a webcím helyett a saját tárolónk korábban már feljegyzett klónozási webcímét használjuk.
 
-. Végezetül kezdeményezzünk szinkronizálást a tároló két példánya között a `$ git push -u origin master` paranccsal.
+. Végezetül kezdeményezzünk szinkronizálást a tároló két példánya között a `git push -u origin master` paranccsal.
 
 . Ha GitLabon vagy más verziókövetési szolgáltatónál helyeztük el a távoli tárolópéldányunkat, akkor innentől látni fogjuk az imént _bekommitolt_ fájlrendszerünket annak online felületén.
 
@@ -76,17 +76,17 @@ Míg az előbbi lépéssort egyetlenegyszer, a tároló létrehozásakor kell cs
 
 . Nyissunk meg egy parancssoros ablakot és navigáljunk el abba a könyvtárba, ahol a webhelyünk szoftverének forráskódja található.
 
-. A korábban már bemutatott `$ git status` paranccsal ellenőrizzük, hogy mely fájlok változtak és jelenleg mi szerepel a menteni kívánt állapotban (angolul „staged”). Most azonban a fentiekkel ellentétben nem a Drupal összes tízezer körüli fájlját fogjuk látni felsorolva, hanem csak azt a párat, amit nemrég mi magunk módosítottunk – hiszen a Gitnek így már van viszonyítási alapja, amihez képest a különbözőségüket kiszámíthatja.
+. A korábban már bemutatott `git status` paranccsal ellenőrizzük, hogy mely fájlok változtak és jelenleg mi szerepel a menteni kívánt állapotban (angolul „staged”). Most azonban a fentiekkel ellentétben nem a Drupal összes tízezer körüli fájlját fogjuk látni felsorolva, hanem csak azt a párat, amit nemrég mi magunk módosítottunk – hiszen a Gitnek így már van viszonyítási alapja, amihez képest a különbözőségüket kiszámíthatja.
 
-. Magunk is megtekinthetjük ezeket a változásokat: az egyszerű szöveges fájlok (tehát nem a bináris adatokat tartalmazók, például képek vagy videók) előtte-utána állapotai közötti különbségeket a `$ git diff konyvtarneve/fajlneve.txt` paranccsal listázhatjuk ki.
+. Magunk is megtekinthetjük ezeket a változásokat: az egyszerű szöveges fájlok (tehát nem a bináris adatokat tartalmazók, például képek vagy videók) előtte-utána állapotai közötti különbségeket a `git diff konyvtarneve/fajlneve.txt` paranccsal listázhatjuk ki.
 
-. Ha minden módosult fájl változásait egyetlen állapotmentésben kívánjuk eltárolni, akkor a fentebb már megismert `$ git add -A` paranccsal hozzáadjuk őket a menteni kívánt állapothoz. Ekkor a `$ git status` paranccsal ismét ellenőrizhetjük, hogy mi fog bekerülni a _kommitba_. Ha parancssoros ablakunk támogatja a színek használatát (általában igen), akkor ami a 2. lépésben még vörös színnel volt írva, az immár zöld színűvé változott.
+. Ha minden módosult fájl változásait egyetlen állapotmentésben kívánjuk eltárolni, akkor a fentebb már megismert `git add -A` paranccsal hozzáadjuk őket a menteni kívánt állapothoz. Ekkor a `git status` paranccsal ismét ellenőrizhetjük, hogy mi fog bekerülni a _kommitba_. Ha parancssoros ablakunk támogatja a színek használatát (általában igen), akkor ami a 2. lépésben még vörös színnel volt írva, az immár zöld színűvé változott.
 
-. Ha a _staged_ listáját látva meggondolnánk magunkat, és egy bizonyos fájlnak mégsem kellene ebbe a _kommitba_ bekerülnie, akkor azt a `$ git reset HEAD konyvtarneve/fajlneve.txt` módon vissza tudjuk venni a menteni kívánt állapotból. Ha ennek éppen az ellenkezőjére, azaz csak egyetlen fájl _staged_ listához való hozzáadására van szükségünk, akkor azt is megtehetjük a `$ git add konyvtarneve/fajlneve.txt` módon. (Ne felejtsük, ha azt szeretnénk, hogy ezt az adott fájlt vagy könyvtárat a Git hagyja figyelmen kívül, akkor hozzáadhatjuk az útvonalát a korábban már tárgyalt _.gitignore_ fájlhoz.)
+. Ha a _staged_ listáját látva meggondolnánk magunkat, és egy bizonyos fájlnak mégsem kellene ebbe a _kommitba_ bekerülnie, akkor azt a `git reset HEAD konyvtarneve/fajlneve.txt` módon vissza tudjuk venni a menteni kívánt állapotból. Ha ennek éppen az ellenkezőjére, azaz csak egyetlen fájl _staged_ listához való hozzáadására van szükségünk, akkor azt is megtehetjük a `git add konyvtarneve/fajlneve.txt` módon. (Ne felejtsük, ha azt szeretnénk, hogy ezt az adott fájlt vagy könyvtárat a Git hagyja figyelmen kívül, akkor hozzáadhatjuk az útvonalát a korábban már tárgyalt _.gitignore_ fájlhoz.)
 
-. Kommitoljuk be a _staged_ listára összeválogatott fájlok módosításait a `$ git commit -m "Összefoglaló a módosításokról emlékeztetőül."` paranccsal. Miután a `$ git log`-gal ellenőriztük, hogy elégedettek vagyunk az új állapotmentés tartalmával és szövegével, küldjük fel a Git-tárolónk távoli példányába is a `$ git push` utasítással.
+. Kommitoljuk be a _staged_ listára összeválogatott fájlok módosításait a `git commit -m "Összefoglaló a módosításokról emlékeztetőül."` paranccsal. Miután a `git log`-gal ellenőriztük, hogy elégedettek vagyunk az új állapotmentés tartalmával és szövegével, küldjük fel a Git-tárolónk távoli példányába is a `git push` utasítással.
 
-. Ha a Git-tárolónknak több példánya is van (például a kollégánk is ebbe dolgozik), akkor a mások által felküldött változtatásokat (amik éppen ezért még nem lehetnek meg a mi gépünkön), a `$ git pull` paranccsal bármikor lehívhatjuk a saját helyi példányunkba is.
+. Ha a Git-tárolónknak több példánya is van (például a kollégánk is ebbe dolgozik), akkor a mások által felküldött változtatásokat (amik éppen ezért még nem lehetnek meg a mi gépünkön), a `git pull` paranccsal bármikor lehívhatjuk a saját helyi példányunkba is.
 
 ===== Egy teljes tároló beszerzése a helyi gépünkre
 
@@ -94,7 +94,7 @@ Ahogy az előző lépéssor végén már utaltunk rá, a verziókövetés nem cs
 
 . Nyissunk meg egy parancssoros ablakot és navigáljunk el abba a könyvtárba, amin belül szeretnénk, hogy a helyi tárolópéldányunk létrejöjjön.
 
-. A Git `clone` parancsának meghívásakor átadhatunk neki két értéket: a távoli tárolópéldány klónozási webcímét és egy tetszőleges könyvtárnevet (ha még nem létezik, automatikusan létrehozza), amin belülre kezdje el letölteni a fájlokat. Például `$ git clone https://gitlab.com/pelda-nev/pelda-tarolo.git masik-webhely-konyvtara`.
+. A Git `clone` parancsának meghívásakor átadhatunk neki két értéket: a távoli tárolópéldány klónozási webcímét és egy tetszőleges könyvtárnevet (ha még nem létezik, automatikusan létrehozza), amin belülre kezdje el letölteni a fájlokat. Például `git clone https://gitlab.com/pelda-nev/pelda-tarolo.git masik-webhely-konyvtara`.
 
 ===== A webhely konfigurációjának kezelése a Git-tárolónkban
 

source/hu/extend-maintenance.txt

@@ -78,15 +78,15 @@ image:images/extend-maintenance-mode-disabled.png["Webhely rendes üzemmódban m
 . Parancssoros ablakban futtassuk az alábbi utasításokat, amelyek először engedélyezik a karbantartási módot, majd rögtön utána kiürítik a gyorsítótárat:
 +
 ----
-$ drush state:set system.maintenance_mode 1 --input-format=integer
-$ drush cache:rebuild
+drush state:set system.maintenance_mode 1 --input-format=integer
+drush cache:rebuild
 ----
 
 . A letiltás nagyon hasonló az előzőekhez, azzal a különbséggel, hogy a karbantartási mód értékét nullára állítjuk:
 +
 ----
-$ drush state:set system.maintenance_mode 0 --input-format=integer
-$ drush cache:rebuild
+drush state:set system.maintenance_mode 0 --input-format=integer
+drush cache:rebuild
 ----
 
 . Bármelyik parancsot is futtatjuk, javasolt ellenőrizni a megváltozott működést úgy, hogy a webhelyünket egy másik böngészőben (amiben nem vagyunk bejelentkezve)  megnyitjuk.

source/hu/extend-manual-install.txt

@@ -88,7 +88,7 @@ image:images/extend-manual-install-directories.png["Javasolt könyvtárszerkezet
 . Csomagoljuk ki a _.tar.gz_ (vagy más) tömörített állományt, ami így egy alkönyvtárat hoz létre a fájllal azonos szinten. Ha a távoli kiszolgálónk Linuxon fut, és van parancssori hozzáférésünk, akkor egyszerűen futtathatjuk az alábbi parancsot, természetesen a fájlnevet lecserélve:
 +
 ----
-$ tar -xzf admin_toolbar-8.x-1.17.tar.gz
+tar -xzf admin_toolbar-8.x-1.17.tar.gz
 ----
 Ha nem Linuxon fut a kiszolgáló, vagy nem használhatjuk a parancssort, akkor a tárhelyszolgáltatónk valószínűleg kínál valamilyen grafikus felületet a kicsomagolás elvégzésére.
 

source/hu/extend-module-install.txt

@@ -81,7 +81,7 @@ image:images/extend-module-install-admin-toolbar-do.png["Modultelepítési oldal
 . Miután a <<extend-manual-install>> vagy <<install-composer>> szakaszok egyikének lépéseit követve a letöltéssel megvagyunk, utána a következő Drush parancs lefuttatásával engedélyezzük (angolul „enable”, de véletlen egybeesésként magyarul is illik, így könnyű megjegyezni). A parancs paramétereként minden esetben meg kell adnunk a modul gépi nevét:
 +
 ----
-$ drush pm:enable admin_toolbar
+drush pm:enable admin_toolbar
 ----
 
 . Ezután már csak kövessük a parancssorban megjelenő utasításokat.

source/hu/extend-theme-install.txt

@@ -82,8 +82,8 @@ image:images/extend-theme-install-appearance-page.png["Uninstalled themes on App
 . Miután a <<extend-manual-install>> vagy <<install-composer>> szakaszok egyikének lépéseit követve a letöltéssel megvagyunk, utána a következő Drush parancsok lefuttatásával először engedélyezzük (angolul „enable”, de véletlen egybeesésként magyarul is ugyanígy kezdődik, így könnyű megjegyezni), majd pedig beállítjuk alapértelmezettként. A parancsok paramétereként minden esetben meg kell adnunk a smink gépi nevét:
 +
 ----
-$ drush theme:enable mayo
-$ drush config:set system.theme default mayo
+drush theme:enable mayo
+drush config:set system.theme default mayo
 ----
 
 . Ezután már csak kövessük a parancssorban megjelenő utasításokat.

source/hu/install-composer.txt

@@ -53,7 +53,7 @@ Ha még nem töltöttük le az alaprendszer forráskódját, és szeretnénk él
 . Adjuk ki az alábbi parancsot, melyben a +webhelyem+ részt helyettesítsük be a létrehozni kívánt könyvtárunk nevével:
 +
 ----
-$ composer create-project drupal-composer/drupal-project:8.x-dev webhelyem --no-interaction
+composer create-project drupal-composer/drupal-project:8.x-dev webhelyem --no-interaction
 ----
 
 Sikeres lefutást követően létrejön a +webhelyem+ argumentumként megadott könyvtár, benne pedig egy _/web_ alkönyvtárban a Drupal alaprendszer legfrissebb kiadásának forráskódja. Emellett olyan hasznos fejlesztői eszközöket is kapunk, mint a _Drush_ és a _Drupal Console_.
@@ -62,9 +62,9 @@ Sikeres lefutást követően létrejön a +webhelyem+ argumentumként megadott k
 
 Bárkivel előfordulhat, hogy miután már feltelepítette a Drupalt a Drupal.org-ról letöltött _zip_ vagy _tar.gz_ fájlból (tehát Composer használata nélkül), később meggondolja magát és mégis szeretne élni inkább az automatikus függőségkezelés lehetőségével. Szerencsére ez sem lehetetlen: ha már telepítettük a Composert a gépünkre, de az még nem kezeli a Drupal kódbázisát, akkor az alábbi két lépéssel megtehetjük.
 
-. Webhelyünk gyökérkönyvtárában adjuk ki a `$ composer global require grasmash/composerize-drupal` parancsot, mely letölti és a gépünkön általánosan elérhetővé teszi Matthew Grasmick átalakítóprogramját a Composerhez.
+. Webhelyünk gyökérkönyvtárában adjuk ki a `composer global require grasmash/composerize-drupal` parancsot, mely letölti és a gépünkön általánosan elérhetővé teszi Matthew Grasmick átalakítóprogramját a Composerhez.
 
-. Ha ez sikeresen települt, utána meghívhatjuk a Composeren keresztül a `$ composer composerize-drupal --composer-root=. --drupal-root=.` paranccsal.
+. Ha ez sikeresen települt, utána meghívhatjuk a Composeren keresztül a `composer composerize-drupal --composer-root=. --drupal-root=.` paranccsal.
 
 Így futtatva feltérképezi a Drupalunk könyvtárszerkezetét és összegyűjti belőle azokat az információkat, amikre majd a Composer-nek szüksége lesz. Ha webhelyünkhöz már töltöttünk le közösségi modulokat vagy sminkeket, és azokat az ajánlásoknak megfelelően a _modules/contrib_, _themes/contrib_, vagy _profiles/contrib_ nevű alkönyvtárakba tettük, akkor ez a program azokat is fel fogja fedezni és hozzáadja őket a Composer listájához. Ha viszont nem tettük őket ilyen alkönyvtárakba, akkor jobban járunk, ha letöröljük őket és a következő részben leírtakat követve újra beszerezzük őket, de immár a Composer segítségével.
 
@@ -77,7 +77,7 @@ Külső függőségei azonban nemcsak az alaprendszernek lehetnek, hanem tulajdo
 . Ha megvan a neve, akkor azt a következő parancsban a példaként használt „geofield” helyére behelyettesítve és egy parancssoros ablakban lefuttatva a Composer letölti a modult minden további szükséges függőségével együtt:
 +
 ----
-$ composer require drupal/geofield
+composer require drupal/geofield
 ----
 
 ===== Korábban már Composerrel letöltött közösségi projektek frissítése
@@ -89,20 +89,20 @@ Miután az előző részeknél leírtak szerint már használunk Composert a web
 . Második lépésként meg kell határoznunk, hogy az adott szoftverelem melyik verzióját szeretnénk letöltetni a Composerrel. Egyszerű dolgunk van, ha a legfrissebb verziót kérjük:
 +
 ----
-$ composer update drupal/geofield --with-dependencies
+composer update drupal/geofield --with-dependencies
 ----
 
 . Ha valamilyen oknál fogva egy adott verzióra van szükségünk, akkor jó, ha tudjuk, hogy a kötőjeles verziószámok esetén a főverzió számát sosem kell külön megadnunk, hiszen az magától értetődő. Ha tehát azt látjuk a modul projektoldalán, hogy +8.x-1.7+ (amiben a kötőjel előtti szám webhelyünk Drupal-főverzióját jelöli), akkor a Composernek elég már csak az +1.7+ verziószámot megadnunk. Mindez azonban nem érvényes a Drupal 8 alaprendszerre, mert az a régies kéttagú verziószámok (például „Drupal 7.59”) helyett már a korszerű _szemantikus verziószámozás_ elvét követve háromtagú jelölést használ. Mivel pedig a +core+ magasabb szintű, mint a kiegészítők, ezért kötőjel sem szerepel benne. Ezt tehát továbbra is ugyanúgy ki kell írnunk a Composer-parancsokban: például +drupal/core:8.6.3+.
 +
 ----
-$ composer require drupal/geofield:1.7
+composer require drupal/geofield:1.7
 ----
 +
 . Ha minden információ rendelkezésre áll, akkor a parancssoros ablakban webhelyünk gyökérkönyvtárában állva adjuk ki a fentiekhez hasonló parancsunkat, melyben a +geofield+ mintát értelemszerűen a frissíteni kívánt projekt nevére cseréltük.
 
 ==== Az ismeretek elmélyítése
 
-A Composer használatát kézenfekvő módon annak beépített súgójából ismerhetjük meg. Például a fentebb már említett `$ create-project` utasításról a `$ composer help create-project` paranccsal olvashatunk bővebben.
+A Composer használatát kézenfekvő módon annak beépített súgójából ismerhetjük meg. Például a fentebb már említett `create-project` utasításról a `composer help create-project` paranccsal olvashatunk bővebben.
 
 //==== Kapcsolódó témák
 

source/hu/install-dev-making.txt

@@ -33,13 +33,13 @@ Lemásoljuk a meglévő webhelyünket, hogy legyen belőle egy másik példányu
   * Ha az előbb említett grafikus felület nem elérhető számunkra, de van parancssori hozzáférésünk, akkor küldhetjük az utasítást közvetlenül a MySQL kiszolgálónak is (természetesen behelyettesítve a webhelyünk adatbázisának nevét, felhasználóját és annak jelszavát):
 +
 ----
-$ mysqldump -u USERNAME -p 'PASSWORD' DATABASENAME > BACKUPFILE.sql
+mysqldump -u USERNAME -p 'PASSWORD' DATABASENAME > BACKUPFILE.sql
 ----
 
   * Ha inkább Drusht használnánk, akkor ezt a parancsot futtassuk:
 +
 ----
-$ drush sql:dump --result-file=BACKUPFILE.sql
+drush sql:dump --result-file=BACKUPFILE.sql
 ----
 
   * Használhatjuk a https://www.drupal.org/project/backup_migrate[Backup and Migrate] nevű közösségi modult is. A modulok webhelyünkre való feltelepítéséről a <<extend-module-install>> részben volt szó.
@@ -72,13 +72,13 @@ $settings['trusted_host_patterns']
   * Ha viszont parancssoron keresztül exportáltuk fentebb, akkor az alábbi utasítást használhatjuk a MySQL kiszolgáló felé (a paramétereket ismét behelyettesítve persze):
 +
 ----
-$ mysql -u USERNAME -p PASSWORD  DATABASE_NAME < BACKUPFILE.sql
+mysql -u USERNAME -p PASSWORD  DATABASE_NAME < BACKUPFILE.sql
 ----
 +
   * Drushsal is lehet importálni, mégpedig így:
 +
 ----
-$ drush sql:query --file=BACKUPFILE.sql
+drush sql:query --file=BACKUPFILE.sql
 ----
 
 . Ahogy fentebb már tapasztaltuk, két példány – bár ugyanannak az egy webhelynek a másolatai – eltérő beállításokat használhat a szétválasztott működésük érdekében. Az előbb átírt adatbáziskapcsolatokon kívül azonban számos további beállításuk különbözhet, amit ugyanúgy a _settings.php_ fájljaikban tárolnak. Lehetőség van azonban felülírást megvalósítani közöttük a `$config` változó segítségével. Például az éles webhely neve továbbra is maradjon „Bárkifalva Termelői Piac”, de a fejlesztési példányon ez inkább figyelmeztessen azzal, hogy átírjuk „DEV! – Bárkifalva Termelői Piac” címre. Ezt úgy érhetjük el, hogy mindkettő adatbázisában továbbra is meghagyjuk az éles szövegváltozatot, de a fejlesztési példány _settings.php_ fájljában elhelyezzük az alábbi kiegészítő sort:

source/hu/install-manual.txt

@@ -44,7 +44,7 @@ image:images/extend-module-install-download.png["Egy közösségi projekt letöl
 . Itt tömörítsük ki a _tar.gz_ (vagy _zip_) fájlt, ami egy új könyvtárat fog létrehozni. Ha nincs parancssori hozzáférésünk, vagy a tárhely nem Linux operációs rendszeren fut, akkor a szolgáltató vezérlőpultjának fájlkezelője általában biztosít kicsomagolási lehetőséget. Ha viszont van parancssori hozzáférésünk a távoli szerverhez (és az Linuxon fut), akkor a következő parancs kiadásával csomagolhatjuk ki a tömörített fájlt:
 +
 ----
-$ tar -xzf drupal-8.3.2.tar.gz
+tar -xzf drupal-8.3.2.tar.gz
 ----
 
 . Ha a kitömörítési folyamat magától nem törölte volna a tömörített fájlt, akkor töröljük le mi magunk a szerverről.
@@ -56,13 +56,13 @@ $ tar -xzf drupal-8.3.2.tar.gz
 Ha már helyére került Drupal szoftver kódbázisa, akkor akár azonnal be is indíthatjuk próbaképpen a parancssorban a gyökérkönyvtárban állva az alábbi utasítás kiadásával:
 
 ----
-$ php core/scripts/drupal quick-start standard
+php core/scripts/drupal quick-start standard
 ----
 
 Egy folyamatjelző lefutását követően perceken belül visszajelzést kapunk. Sőt, szervertől függően akár a böngészőnkben azonnal meg is nyílhat ez az ideiglenes bemutató célú webhely. Ahogy a <<install-decide>> résznél írtuk, ez pusztán csak egy demó, még _nem_ a végleges webhelyünk – amint bezárjuk a parancssort, nyom nélkül megszűnik. Mégis motiváló lehet azonnal látni előrehaladáunkat, ezért hasznos lehet bővebben is olvasnunk e funkcióról a súgóját megnyitva (angol nyelven):
 
 ----
-$ php core/scripts/drupal quick-start --help
+php core/scripts/drupal quick-start --help
 ----
 
 // ==== Related concepts

source/hu/install-prepare.txt

@@ -42,7 +42,7 @@ A <<install-run>> szakasz bemutatja az interaktív webes telepítő végigkattin
 Ha a vizuális felületnél jobban szeretjük a parancssoros hozzáférést, akkor az alábbi Drush parancs közel ugyanezt végzi el. Gépeljük a következő utasításokat a parancssorba, ahol  `example` annak a könyvtárnak a neve, ahova az alaprendszert letöltöttük, valamint a `DB_NAME`, `DB_USER` és `DB_PASS` az adatbázis hitelesítő adatai:
 
 ----
-$ drush site:install standard --db-url='mysql://DB_USER:DB_PASS@localhost/DB_NAME' --site-name=example
+drush site:install standard --db-url='mysql://DB_USER:DB_PASS@localhost/DB_NAME' --site-name=example
 ----
 
 //==== Kapcsolódó témák

source/hu/preface-conventions.txt

@@ -34,7 +34,7 @@ A Kézikönyv során a következő fogalmazási és szerkesztési gyakorlatot k
 * Minden olyan szöveget, amelyet egy parancssori ablakba kell begépelnünk, +egyenszélességű+ betűvel jelöltünk:
 +
 ----
-$ drush cache:rebuild
+drush cache:rebuild
 ----
 
 * Bár egyesek ritkán mappáknak szeretik hívni a fájlok tárolóit, a Kézikönyvben azonban az elterjedt szóhasználatnak megfelelően könyvtáraknak nevezzük őket.

source/hu/security-update-core.txt

@@ -44,7 +44,7 @@ $settings['update_free_access'] = TRUE;
 . Csomagoljuk ki a _tar.gz_ vagy _zip_ fájlt a távoli szerver egy ideiglenes könyvtárába, aminek kívül kell esnie a webhely telepítési könyvtárán (másképpen „docroot”). Valószínűleg a tárhelyszolgáltató által biztosított adminfelületnek van a kicsomagolásra szolgáló funkciója. Ha van parancssori hozzáférésünk a távoli (Linuxon futó) szerverhez, akkor használhatjuk az alábbi parancsot is:
 +
 ----
-$ tar -xzf drupal-8.3.2.tar.gz
+tar -xzf drupal-8.3.2.tar.gz
 ----
 
 . Most a webhelyünk eredeti telepítési könyvtárában töröljük ki a _core_ és _vendor_ könyvtárakat, valamint minden fájlt, ami nem alkönyvtárban van (beleértve a _.htaccess_, _composer.json_ és _autoload.php_ fájlokat is). Csak azokat hagyjuk meg, amelyekben valami módosítást végeztünk.