Hur sparar jag ett Terminal-kommando som ett "script"?

Trädvy Permalänk
Medlem
Registrerad
Nov 2010

Hur sparar jag ett Terminal-kommando som ett "script"?

Hej!

Har ett problem då jag inte vet hur man gör sparar kommandon som snabba skript det bara är att köra från en ikon på till exempel skrivbordet.

Anledningen är att jag har ett par laptops som bekanta använder men problemet är att i dom så fungerar det inte att stänga av och sätta igång pekplattan utan att använda xinput device disable vilket orsakar att muspekaren hoppar omkring och trycker på saker när de skriver.

Kort och sagt önskar jag skapa två filer att bara klicka på, en disable och en enable.

Nybörjare på Linux? Se hit! #15665841
Google är inte din vän. www.donttrack.us
Skaffa säker epost med ProtonMail! #14698306
Spela Supreme Commander! www.faforever.com

Trädvy Permalänk
Medlem
Plats
Norrland
Registrerad
Apr 2012

Högerklicka på din fil med kommandona och markera "executable". (tror jag)

2600k @ STOCK <|> GTX 970 Omega!<|> Nån samsung 500gb ssd <|> 16 GB Kingston Hyper X <|> BenQ XL2420t
"Det finns inget skrot, bara gamla delar som kan användas på nya sätt" - Mulle Meck

Trädvy Permalänk
Medlem
Plats
~/
Registrerad
Mar 2008

Inte helt säker, men sparar man inte skriptet som en .bat-fil?

Placera den bara på skrivbordet sen.

AMD Ryzen 5 2600X, Asus ROG Strix B350-I, 16GB Corsair Vengeance LP 2400MHz, Nvidia GeForce GTX 970, Fractal Design Nano S, EVGA Supernova G2 650W.

Trädvy Permalänk
Medlem
Registrerad
Nov 2010
Skrivet av elklazor:

Högerklicka på din fil med kommandona och markera "executable". (tror jag)

Jo, men hur skapar jag filen från början?

Skrivet av saturday_sun:

Inte helt säker, men sparar man inte skriptet som en .bat-fil?

Placera den bara på skrivbordet sen.

.bat är Windows.

Skickades från m.sweclockers.com

Nybörjare på Linux? Se hit! #15665841
Google är inte din vän. www.donttrack.us
Skaffa säker epost med ProtonMail! #14698306
Spela Supreme Commander! www.faforever.com

Trädvy Permalänk
Medlem
Plats
~/
Registrerad
Mar 2008

Ahh fick för mig att det var windows.. Skriv så här i filen:

#!/bin/bash
ditt kommando

Sen sparar du som skript.sh

Du gör skriptet körbart så här:
$ chmod +x skript.sh

AMD Ryzen 5 2600X, Asus ROG Strix B350-I, 16GB Corsair Vengeance LP 2400MHz, Nvidia GeForce GTX 970, Fractal Design Nano S, EVGA Supernova G2 650W.

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002

Ibland finns det en funktionsknapp på tangentbordet för att stänga av styrplattan (Fn i kombination med något). Men det kanske var det du menade inte fungerar. Beroende på skrivbordsmiljö borde det också vara möjligt att skapa egna funktioner med egendefinierade snabbkommandon (har inte satt mig in i hur man gör detta). Kan vara smidigt om det går att koppla scriptet till något snabbkommando istället för att behöva klicka, särskilt om man har en omkringhoppande muspekare.

Trädvy Permalänk
Moderator
Registrerad
Mar 2006

Länk till en samling alternativ, beroende på DE och/eller hur du själv känner för att göra: http://xmodulo.com/create-desktop-shortcut-launcher-linux.htm...

Om skriptet innehåller flera parametrar än ett enkelt kommando kan du ju spara dem under en egen mapp ex ~/bin.

Trädvy Permalänk
Medlem
Registrerad
Nov 2010
Skrivet av saturday_sun:

Ahh fick för mig att det var windows.. Skriv så här i filen:

#!/bin/bash
ditt kommando

Sen sparar du som skript.sh

Du gör skriptet körbart så här:
$ chmod +x skript.sh

Tack! Var precis det där jag sökte. Fungerar som jag tänkt nu.

Skrivet av ronnylov:

Ibland finns det en funktionsknapp på tangentbordet för att stänga av styrplattan (Fn i kombination med något). Men det kanske var det du menade inte fungerar. Beroende på skrivbordsmiljö borde det också vara möjligt att skapa egna funktioner med egendefinierade snabbkommandon (har inte satt mig in i hur man gör detta). Kan vara smidigt om det går att koppla scriptet till något snabbkommando istället för att behöva klicka, särskilt om man har en omkringhoppande muspekare.

Muspekaren hoppar inte av sig självt, men när datorägaren skriver i LibreOffice (exempelvis) så kommer denne åt pekplattan med handflatan och får musen att hoppa dit pekaren är.

Det är just det med FN-knapparna, de flesta fungerar (Till exempel ljus och ljud) men just att stänga av och sätta igång plattan igen går inte på två av tre olika modeller av laptops jag har fixat med Mint på.

Nybörjare på Linux? Se hit! #15665841
Google är inte din vän. www.donttrack.us
Skaffa säker epost med ProtonMail! #14698306
Spela Supreme Commander! www.faforever.com

Trädvy Permalänk
Medlem
Plats
Utanför hjärnan
Registrerad
Jan 2010

Den som vill titta närmare på hur man exekverar textskript, kan söka på shebang.

Trädvy Permalänk
Medlem
Plats
Mölndal
Registrerad
Aug 2006

shellscript.sh

#!/bin/bash cat /dev/null

Gör filen körbar

$ chmod +x shellscript.sh

Kör filen

$ ./shellscript.sh

Intel i5 6600K | Be Quiet, Pure Rock! | Asus Z170 Pro Gaming | Asus GTX 1070 Strix Gaming | HyperX 16 GB (2x8GB) DDR4 2133MHz Fury Black | Samsung 850 Evo 250GB | Skärm: Samsung S27D390H | Chassi: Fractal Design Define R4 Black
Spelnick: Jernhand

Trädvy Permalänk
Medlem
Plats
Câmara de Lobos, Madeira, Portugal
Registrerad
Nov 2005
Skrivet av KimTjik:

Länk till en samling alternativ, beroende på DE och/eller hur du själv känner för att göra: http://xmodulo.com/create-desktop-shortcut-launcher-linux.htm...

Om skriptet innehåller flera parametrar än ett enkelt kommando kan du ju spara dem under en egen mapp ex ~/bin.

Av säkerhetskäl bör man inte ha någon ~/bin katalog. Lägg privata skript och program i /usr/local/bin. Ägaren skall vara root och rättigheterna 755. Helst skall /home partitionen monteras med alternativet noexecute.

Fagerja

Trädvy Permalänk
Forumledare
Registrerad
Okt 2002
Skrivet av fagerja:

Av säkerhetskäl bör man inte ha någon ~/bin katalog. Lägg privata skript och program i /usr/local/bin. Ägaren skall vara root och rättigheterna 755. Helst skall /home partitionen monteras med alternativet noexecute.

Jag ställer mig skeptisk till utsagan att man bör undvika ~/bin samt montera /home som noexec.

~/bin är rätt vedertagen för användarspecifika körbara program. Den plockas till och med upp automatiskt i standardinstallationer av de flesta (?) system. Det brukar finnas ett stycke likt det som finns i /etc/skel/.profile på en Debianinstallation (och därmed kopieras in i alla nya användares kataloger som en standard-~/.profile):

# set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi

Det inbegriper då Debian, Ubuntu, Mint, etc. Även Fedora har en liknande rad i /etc/skel/.bash_profile:

# User specific environment and startup programs PATH=$PATH:$HOME/.local/bin:$HOME/bin export PATH

vilket jag då antar även gäller standardinstallationer av RHEL, CentOS, etc. Är det något system som monterar /home som noexec som standard? Detta är måhända inget argument på isolerad hand, men om mer eller mindre alla vanliga distributioner som standard uppmanar användare till att använda ~/bin så bör det inte kunna vara speciellt mycket problem med det.

Vilka faktiska säkerhetshål skulle uppstå av att låta en användare exekvera skript från sin egen katalog? Jag hade inte ens hört detta propageras för tidigare, och jag hittade på sin höjd ett fåtal strödiskussioner via Google (fast de flesta trådarna handlade om att /home av misstag monterats noexec, och hur man skulle bli av med det) samt en omnämning i en enstaka bok om Linuxsäkerhet från 2001.

Ifall man tänker sig att en attackerare lurar till sig rättigheter för att modifiera innehållet i användarens hemkatalog — då har man redan tappat bollen. Exempelvis skulle attackeraren då kunna lägga till egna rader i ~/.profile och få sin kod körd vid varje inloggning likväl, eller vid en mängd liknande inkörspunkter. Ifall en användares integritet har äventyrats så till den grad att en attackerare kan skriva till godtyckliga användarägda filer så är det bara att hoppas på att man skött systemsäkerheten så att ingen annan användare på systemet råkar illa ut.

Däremot så ska man inte lägga skript som ska köras av root, eller för den delen andra användare, i en användares privata katalog, vilket är något jag ibland ser folk göra (främst på enanvändarsystem). Det ger en direkt väg för eskalering av privilegier för en elak användare som kommit åt ett "vanligt" användarkonto på maskinen. Ett bättre alternativ vore då exempelvis roots hemkatalog, eller /usr/local/sbin.

/usr/local/bin är tänkt att innehålla skript som systemadministratören installerat för att alla användare på datorn ska ha tillgång till dessa. En användare som skriver egna skript för eget bruk bör lägga dem i just ~/bin (på enanvändarsystem så är distinktionen mellan "administratör" och "användare" inte alltid tydlig, men men). Generellt så bör användare inte ha tillåtelse att lägga saker i /usr/local/bin överhuvudtaget, utan det ska vara förbehållt administratörens "godkända" skript.

Kan tillägga att jag hade fått nippran om min hemkatalog på ett system var noexec — visst går det att explicit ange tolk till alla program man själv skriver under en utvecklingsfas, men det låter rätt osmidigt. Även det faktum att det går att köra godtyckliga skript genom att ange tolk, och även kompilerade program utan exekverbara rättigheter på binärerna (Can I execute a Linux binary without the execute permission bit being set? [SU]) ställer ytterligare frågor om vilken faktisk säkerhet man vinner av att ha /home som noexec.

Man skulle kanske kunna tänka sig att ta bort exekverbara rättigheter från /home på ett system där man vägde användares användbarhet av systemet lägre än en potentiell (väldigt nära "security by obscurity") säkerhetsvinst, men på "vanliga" hemanvändarsystem så låter det främst som huvudvärk. Att säga att man inte "bör" använda ~/bin och att man "helst" ska montera /home som noexec går i mina ögon väl långt.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Medlem
Plats
~/
Registrerad
Mar 2008
Skrivet av phz:

Jag ställer mig skeptisk till utsagan att man bör undvika ~/bin samt montera /home som noexec.

~/bin är rätt vedertagen för användarspecifika körbara program. Den plockas till och med upp automatiskt i standardinstallationer av de flesta (?) system. Det brukar finnas ett stycke likt det som finns i /etc/skel/.profile på en Debianinstallation (och därmed kopieras in i alla nya användares kataloger som en standard-~/.profile):

# set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi

Det inbegriper då Debian, Ubuntu, Mint, etc. Även Fedora har en liknande rad i /etc/skel/.bash_profile:

# User specific environment and startup programs PATH=$PATH:$HOME/.local/bin:$HOME/bin export PATH

vilket jag då antar även gäller standardinstallationer av RHEL, CentOS, etc. Är det något system som monterar /home som noexec som standard? Detta är måhända inget argument på isolerad hand, men om mer eller mindre alla vanliga distributioner som standard uppmanar användare till att använda ~/bin så bör det inte kunna vara speciellt mycket problem med det.

Vilka faktiska säkerhetshål skulle uppstå av att låta en användare exekvera skript från sin egen katalog? Jag hade inte ens hört detta propageras för tidigare, och jag hittade på sin höjd ett fåtal strödiskussioner via Google (fast de flesta trådarna handlade om att /home av misstag monterats noexec, och hur man skulle bli av med det) samt en omnämning i en enstaka bok om Linuxsäkerhet från 2001.

Ifall man tänker sig att en attackerare lurar till sig rättigheter för att modifiera innehållet i användarens hemkatalog — då har man redan tappat bollen. Exempelvis skulle attackeraren då kunna lägga till egna rader i ~/.profile och få sin kod körd vid varje inloggning likväl, eller vid en mängd liknande inkörspunkter. Ifall en användares integritet har äventyrats så till den grad att en attackerare kan skriva till godtyckliga användarägda filer så är det bara att hoppas på att man skött systemsäkerheten så att ingen annan användare på systemet råkar illa ut.

Däremot så ska man inte lägga skript som ska köras av root, eller för den delen andra användare, i en användares privata katalog, vilket är något jag ibland ser folk göra (främst på enanvändarsystem). Det ger en direkt väg för eskalering av privilegier för en elak användare som kommit åt ett "vanligt" användarkonto på maskinen. Ett bättre alternativ vore då exempelvis roots hemkatalog, eller /usr/local/sbin.

/usr/local/bin är tänkt att innehålla skript som systemadministratören installerat för att alla användare på datorn ska ha tillgång till dessa. En användare som skriver egna skript för eget bruk bör lägga dem i just ~/bin (på enanvändarsystem så är distinktionen mellan "administratör" och "användare" inte alltid tydlig, men men). Generellt så bör användare inte ha tillåtelse att lägga saker i /usr/local/bin överhuvudtaget, utan det ska vara förbehållt administratörens "godkända" skript.

Kan tillägga att jag hade fått nippran om min hemkatalog på ett system var noexec — visst går det att explicit ange tolk till alla program man själv skriver under en utvecklingsfas, men det låter rätt osmidigt. Även det faktum att det går att köra godtyckliga skript genom att ange tolk, och även kompilerade program utan exekverbara rättigheter på binärerna (Can I execute a Linux binary without the execute permission bit being set? [SU]) ställer ytterligare frågor om vilken faktisk säkerhet man vinner av att ha /home som noexec.

Man skulle kanske kunna tänka sig att ta bort exekverbara rättigheter från /home på ett system där man vägde användares användbarhet av systemet lägre än en potentiell (väldigt nära "security by obscurity") säkerhetsvinst, men på "vanliga" hemanvändarsystem så låter det främst som huvudvärk. Att säga att man inte "bör" använda ~/bin och att man "helst" ska montera /home som noexec går i mina ögon väl långt.

Lite OT, men ändå skriptrelaterat:

Intressanta inlägg båda era. Jag kör en enkel server (Ubuntu Server 15.04) hemma som hantera en del viktiga funktioner för klanen jag är med i. Skripten jag har i min hemmapp sköter olika backupskript från MySQL (mysqldump bland annat), jag använder då .my.conf-filen där jag har lösenord för databasanvändaren/databasanvändarna. Jag har en känsla av att det inte är så bra egentligen. Har du något tips på hur man ska sköta det, om man t.ex. skulle lägga skripten i /usr/local/bin - hur gör man med databasanvändarnas lösenord om de körs därifrån?

Dumpningen av databasen är väl viktigaste funktionen, men vid @reboot monteras en dropbox-mapp via ett annat skript, zippade kopior av varje dump hamnar där.

AMD Ryzen 5 2600X, Asus ROG Strix B350-I, 16GB Corsair Vengeance LP 2400MHz, Nvidia GeForce GTX 970, Fractal Design Nano S, EVGA Supernova G2 650W.

Trädvy Permalänk
Forumledare
Registrerad
Okt 2002
Skrivet av saturday_sun:

Lite OT, men ändå skriptrelaterat:

Intressanta inlägg båda era. Jag kör en enkel server (Ubuntu Server 15.04) hemma som hantera en del viktiga funktioner för klanen jag är med i. Skripten jag har i min hemmapp sköter olika backupskript från MySQL (mysqldump bland annat), jag använder då .my.conf-filen där jag har lösenord för databasanvändaren/databasanvändarna. Jag har en känsla av att det inte är så bra egentligen. Har du något tips på hur man ska sköta det, om man t.ex. skulle lägga skripten i /usr/local/bin - hur gör man med databasanvändarnas lösenord om de körs därifrån?

Dumpningen av databasen är väl viktigaste funktionen, men vid @reboot monteras en dropbox-mapp via ett annat skript, zippade kopior av varje dump hamnar där.

En inställningsfil liksom du använder är generellt det praktiskt bästa alternativet för automatiserade processer. Se bara till att den enbart är läsbar av den användare som kör backupskriptet. Det kan till och med vara en tanke att skapa en ny användare vars enda uppgift är att skapa dessa backuper, och som lagrar användaruppgifterna i sin hemkatalog, utan att de är läsbara av någon annan (förutom root, då — det kommer man i praktiken aldrig ifrån).

Manualen för mysqldump rekommenderar just att använda sådana inställningsfiler och hänvisar till avsnittet "6.1.2.1 End-User Guidelines for Password Security" i MySQL-manualen för mer information.

Stavning.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Medlem
Plats
~/
Registrerad
Mar 2008

@phz:

Ah, tackar för tipset!

AMD Ryzen 5 2600X, Asus ROG Strix B350-I, 16GB Corsair Vengeance LP 2400MHz, Nvidia GeForce GTX 970, Fractal Design Nano S, EVGA Supernova G2 650W.

Trädvy Permalänk
Medlem
Registrerad
Sep 2009

öppna terminal skriv: vi NameOftheScript.sh
tryck "i" för att skriva.

#! /bin/bash #Your code

Tryck esc för att komma ur skriv läge sedan för att spara och avslut trycker du in ":wq".
För att bara avsluta utan att spara trykcer du in ":q!" för att spara utan att stänga tryck ":w!".

"vi" är kanske inte den lättaste text editorn att hantera men jag rekommenderar att du lär dig den som Linux människa ändå, då det en är vanligt på bl.a servrar (*nix) att vara den ända texthanteraren.

Смерть -это решение всех проблем. Нет человека - нет проблемы
Comp1: Ubuntu 16.04 Comp2: Arch Linux
Comp3: Ubuntu Server 16.04 Comp4: Centos 6.5
Comp5: Linux mint 16 Comp6: Raspberry pi (olika OS hela tiden)
Phone: Motorola Google Nexus 6

Trädvy Permalänk
Medlem
Plats
Mölndal
Registrerad
Aug 2006
Skrivet av asdfgh:

öppna terminal skriv: vi NameOftheScript.sh
tryck "i" för att skriva.

#! /bin/bash #Your code

Tryck esc för att komma ur skriv läge sedan för att spara och avslut trycker du in ":wq".
För att bara avsluta utan att spara trykcer du in ":q!" för att spara utan att stänga tryck ":w!".

"vi" är kanske inte den lättaste text editorn att hantera men jag rekommenderar att du lär dig den som Linux människa ändå, då det en är vanligt på bl.a servrar (*nix) att vara den ända texthanteraren.

Personligen finner jag Vim (Vi Improved) lättare och mer kraftfull.
På många distributioner finns ju nano alltid förinstallerad.

Intel i5 6600K | Be Quiet, Pure Rock! | Asus Z170 Pro Gaming | Asus GTX 1070 Strix Gaming | HyperX 16 GB (2x8GB) DDR4 2133MHz Fury Black | Samsung 850 Evo 250GB | Skärm: Samsung S27D390H | Chassi: Fractal Design Define R4 Black
Spelnick: Jernhand