Unix 'sed' spørgsmål.

skal have fjernet de sidste to linier i en fil via shell script, og har fundet ud af at det nemmest kan gøres ved brug af sed. men hvordan?

fil.txt indeholder :
a
b
c
d
e
f

ønsket fil.txt skal indeholde:
a
b
c
d

Edit: Det er selvfølgelig i linux, 'sed' er bare en standard unix kommando...

sed '$d' filnavn | sed '$d' > ny_fil

#2
tak, hvad betyder '$d' ??

sed er ikke det rigtige værktøj til den opgave.

Er det noget som skal bruges i en pipeline, så kan du bare bruge head kommandoen: "head -n -2"

Hvis du vil truncate en eksisterende fil, så er det en lidt anden sag, men det kan gøres med dd kommandoen. Men så skal du stadigvæk have udregnet hvilken position der skal truncates på. Du kunne bruge "head -n -2 | LANG= wc -c" til at optælle de nødvendige bytes, men det er ineffektivt hvis filen er stor. Så er det mere effektivt at anvende "tail -2 | LANG= wc -c" til at udregne hvor mange bytes der skal fjernes og trække det fra filstørrelsen. Den nemmeste måde at finde filstørrelsen er nok med find.

I sidste ende bliver det til

#!/bin/bash
export LANG=
dd if=/dev/null of="$1" bs=1 seek=$[$(
find "$1" -printf %s
)-$(
tail -2 "$1" | wc -c
)]

$d betyder sidste linie.

Hvis det er en meget lille opgave så synes jeg egentlig sed løsningen er okay og ingen grund til at skyde spurve med kanoner.

fjols (5) skrev:

$d betyder sidste linie.

Hvis det er en meget lille opgave så synes jeg egentlig sed løsningen er okay og ingen grund til at skyde spurve med kanoner.

hvordan slettter jeg så første linie også?

ja, det er til en lille opgave hvor jeg vil samle en bunke scripts, der dynamisk oprettes, i et script til test så jeg ikke behøver køre dem alle en efter en...

fjols (5) skrev:

Hvis det er en meget lille opgave så synes jeg egentlig sed løsningen er okay og ingen grund til at skyde spurve med kanoner.

Det er nemmere at bruge head som jeg foreslog. "head -n -2", så kan det ikke blive ret meget simplere.

Qw_freak (6) skrev:

hvordan slettter jeg så første linie også?

tail.

#6:

Hvis du vil bruge sed igen, så:
sed 1d filnavn > ny_fil

#7: Jeg overså du skrev om head. Er vist lidt bagstiv.

skulle pille første og de to sidste linier ud af et script, det blev til:

tail -n +2 fil.txt | head -n -2 >> compile.sh

og det virker fint...

kasperd (4) skrev:

Hvis du vil truncate en eksisterende fil, så er det en lidt anden sag, men det kan gøres med dd kommandoen.

Må jeg slå et slag for ofte oversete "truncate"?

truncate <filnavn> -s -$(tail -2 <filnavn> | LANG= wc -c)

hundeboll (11) skrev:

Må jeg slå et slag for ofte oversete "truncate"?

Så lærte jeg også noget nyt i denne tråd. Er det en Debian ting? Den findes på de Ubuntu systemer jeg checkede men ikke på Fedora systemerne.

kasperd (12) skrev:

Er det en Debian ting? Den findes på de Ubuntu systemer jeg checkede men ikke på Fedora systemerne.

Det ved jeg ikke... Jeg bruger Arch Linux :)

#tools

Husk at det næppe er afgørende hvor få linier der bruges eller hvor smart det er - det kritiske spørgsmål er om dem der skal vedligeholde løsningen og derfor forstå det script kan forstå det.

Qw_freak (6) skrev:

det er til en lille opgave hvor jeg vil samle en bunke scripts, der dynamisk oprettes, i et script til test så jeg ikke behøver køre dem alle en efter en...

En anden mulighed er at have et statisk script, der automatisk finder de relevante scripts og kalder dem et ad gangen. Man kan også dynamisk generere et script, der kender navnene på alle de scripts, der skal kaldes.

Hvilken af de tre løsninger, der er mest velegnet, afhænger af omstændighederne. Hvis den nuværende løsning virker godt for dig, synes jeg ikke du skal lave den om.

arne_v (14) skrev:

Husk at det næppe er afgørende hvor få linier der bruges eller hvor smart det er - det kritiske spørgsmål er om dem der skal vedligeholde løsningen og derfor forstå det script kan forstå det.

Hvis en person har vedligeholdelse af shell scripts som en del af sine arbejdsopgaver, så kan man med rimelighed forvente at vedkommende forstår head og tail kommandoerne.

Da spørgsmålet blev stillet i første omgang gav det indtryk af at det var en eksisterende fil der skulle modificeres og ikke at resultatet skulle skrives ned i en ny fil, hvilket naturligvis fører til en anden løsning.

Havde valget mellem dd og truncate været relevant (hvilket det ikke er, da det viste sig at der også skulle fjernes linier fra starten), så er der ingen tvivl om at løsningen med truncate er langt mere læselig end løsningen med dd.

Men hvis løsningen skal bruges på et system som har en dd kommando men ikke en truncate kommando, så hjælper det ikke meget at truncate kommandoen er mere læselig.

Det er altid nemmere at læse et script, hvis du kender de anvendte kommandoer. Det ville være et argument for at holde sig til et minimalt udvalg af kommandoer.

Men hvis man holder sig til et minimalt udvalg af kommandoer, så kommer man til tider til at skulle bruge dem på en kompliceret måde for at opnå det ønskede resultat. Det er et argument for at altid bruge den mest egnede kommando til et givent formål, uanset hvor mange forskellige kommandoer man kommer til at gøre brug af.

Man er nødt til at afveje de to argumenter imod hinanden. Nogle gange er det oplagt hvilket af de to argumenter der vejer tungest, men ikke altid.

At gøre sit script så kort som muligt gør det som regel mere læseligt, men ikke altid.

Forslaget i #11 er efter min mening den mest læselige løsning på problemet som formuleret i #1. Men #6 gav lidt andre oplysninger om opgaven, og en ændring af krav fører til en anden løsning, hvilket så blev den i #10.

kasperd (12) skrev:

Så lærte jeg også noget nyt i denne tråd. Er det en Debian ting? Den findes på de Ubuntu systemer jeg checkede men ikke på Fedora systemerne.

Det har været at finde i FreeBSD siden 4.2 ifølge man truncate

kasperd (15) skrev:

Hvis en person har vedligeholdelse af shell scripts som en del af sine arbejdsopgaver, så kan man med rimelighed forvente at vedkommende forstår head og tail kommandoerne.

kasperd (15) skrev:

Det er altid nemmere at læse et script, hvis du kender de anvendte kommandoer. Det ville være et argument for at holde sig til et minimalt udvalg af kommandoer.

kasperd (15) skrev:

Men hvis man holder sig til et minimalt udvalg af kommandoer, så kommer man til tider til at skulle bruge dem på en kompliceret måde for at opnå det ønskede resultat. Det er et argument for at altid bruge den mest egnede kommando til et givent formål, uanset hvor mange forskellige kommandoer man kommer til at gøre brug af.

Det giver god mening hvis dem der skal vedligeholde noget har forudsætningerne for det i orden.

Men nogen gange er virkeligheden lidt broget. Og jeg har fået det indtryk at qw_f's arbejdsplads ikke er blege for at sætte folk i gang med noget uden et halv års træning som ballast.

Hvis det også er tilfældet her så bør man kigge på hvad de folk faktisk kan. Har de Perl skills? Python skills? Måske var det en bedre løsning i konteksten.

arne_v (17) skrev:

Og jeg har fået det indtryk at qw_f's arbejdsplads ikke er blege for at sætte folk i gang med noget uden et halv års træning som ballast.

Det har du måske ret i. Men på den anden side, så kan træning også godt bestå i at blive kastet ud i en konkret opgave som man ikke har forudsætningerne for. Den fremgangsmåde skal man selvfølgelig ikke anvende, hvis den konkrete opgave har en stram deadline.

arne_v (17) skrev:

så bør man kigge på hvad de folk faktisk kan.

Men hvis man ikke ved hvem der kommer til at supportere koden efterfølgende, så er det ikke noget man bare kan undersøge.

arne_v (17) skrev:

Har de Perl skills? Python skills?

Opgaven kunne uden tvivl løses i perl eller python, men det lyder som overkill for en opgave der kunne løses med et par liniers shell script. Jeg tvivler på at

tail -n +2 | head -n -2

kunne gøres på under 10 linier, hvis det blev skrevet i Python. Hvilket så minder mig om Master Foo and the Ten Thousand Lines.

kasperd (18) skrev:

Det har du måske ret i. Men på den anden side, så kan træning også godt bestå i at blive kastet ud i en konkret opgave som man ikke har forudsætningerne for. Den fremgangsmåde skal man selvfølgelig ikke anvende, hvis den konkrete opgave har en stram deadline.

Det er netop det der er sagen her...