Peter Jensen wrote:
>>>Men spørgsmålet er om den er det program der bliver kørt.
>>
>>Jep, det ved jeg godt. Min pointe er, at du ikke kan vaere sikker.
>
>
> Hvis jeg har skrevet '#!/bin/bash' i toppen af scriptet, så kan jeg være
> sikker nok. Pointen er at man burde bruge funktioner der *kan* være
> indbyggede, i stedet for at lave dumme kald til 'ls' for at finde ud af
> om en fil eksisterer.
Du kan ikke vaere sikker paa, at /bin/bash findes paa systemet. /bin/sh
er der altid -- det skal den vaere. /bin/sh har en i en standard
defineret opfoersel, det har /bin/bash ikke.
>>>I bash kan man bruge 'enable' til at slå indbyggede funktioner til og
>>>fra. Prøv selv om ikke din shell også gør det samme. Hvis ikke, så
>>>har jeg endnu en grund til ikke at køre BSD
>>
>>Hvad shellen (og userland generelt) goer har intet med kernen at
>>goere.
>
>
> Nej, men er der nogen BSD versioner der kører med GNU værktøjerne som
> standard? Hvis ikke, så foretrækker jeg at blive ved Linux hvor GNU er
> normen. Disse værktøjer har typisk forbedret funktionalitet i forhold
> til de traditionelle.
Alle har nogle vaerktoejer fra GNU i base, men jeg ved, at i hvert fald
OpenBSD aktivt er ved at skifte dem ud med BSD-licenserede vaerktoejer.
I oevrigt er jeg ikke ude paa at omvende dig til at koere BSD. Bliv
endelig ved det operativsystem, du kender og har det godt med, til du
(maaske) finder en mangel, som et andet system kan loese for dig.
>>Jeg forstaar desuden ikke, at du ser det som en fordel, at shellen
>>bruger interne udgaver af test, echo etc. Man vinder udelukkende en
>>smule performance,
>
>
> En smule er det nu ikke. Jeg har på et tidspunkt skrevet et script om,
> så kørselstiden blev nedsat til omtrent 5% af det oprindelige. Alt
> sammen ved at bruge shell built-ins i stedet for grep, awk, cut, ls,
> osv. Igen, hvis der er tale om et script der skal køre igennem
> millioner af entries i en log-file, så kan det betyde en del.
Hvor tit har du behov for lige en enkelt gang at lave processering af
flere millioner linier tekst? Hvis det kun drejer sig om en enkelt gang,
er hastigheden ofte ogsaa mindre vigtig hvis ikke ligegyldig.
>>men hvis det er i hoejsaedet, er sh det forkerte sprog til opgaven.
>
>
> Måske, måske ikke. Hvis det tager længere tid at skrive programmet i et
> compilet sprog end det ville tage at stykke scriptet sammen og køre det,
> så er der jo ikke vundet noget.
Der findes da fortolkede sprog, der er langt hurtigere end sh. Tag nu
Perl som eksempel.
> Ved konsekvent at programmere ordentligt og udnytte de interne funktioner
> fuldt ud, kan man sikre sig at scriptet er optimalt nok til at kunne
> konkurrere med alternativerne.
``konsekvent at programmere ordentligt'' -- tager du verdensfreden i
naeste uge? Desuden er jeg ikke sikker paa din paastand om anvendelse af
interne funktioner.
> En anden grund til at favorisere shell-scripts er at de er fleksible.
Hvorledes er de mere fleksible end eksempelvis Perl-scripts? Python?
Ruby? I sh skal du ofte lave mange forskellige krumspring for at opnaa
funktionalitet, der er en del af, igen, eksempelvis Perl.
>>Jeg ser det udelukkende som en ulempe, at min shell lige overtager
>>styringen.
>
>
> Det er da dig der bestemmer om den skal dét. Der er bare ikke nogen
> reel fordel ved at bruge de eksterne funktioner, da de ifølge
> standarderne skal gøre det samme (så vidt jeg husker).
Hvorfor skal jeg fortaelle min shell, at jeg gerne selv vil have
kontrollen? Software skal ikke diktere politik men tilbyde muligheder.
>>Det er MS Office Clippy om igen.
>
>
> Nej *nu* må du lige holde op! Dét kan du ikke mene seriøst ...
Joda. ``Det ser ud som om, du er ved at checke for eksistens af
/etc/passwd. Det kan jeg goere meget smartere for dig paa denne maade.
Godt nok er det ikke saadan, du vil have det gjort, men nu goer jeg det
altsaa saaledes.''
Jeg forstaar ikke, at jeg skal goere den opmaerksom paa, at den
vitterligt skal goere det, jeg beder den om.
>>Hvis jeg har rettet i /bin/test eller udvidet echo, saa skal jeg til
>>at boevle med en shell, der ikke vil udfoere dem, fordi den mener, at
>>den er smartere.
>
>
> Undskyld jeg siger det, men hvis du først begynder at skulle rette i de
> filer, så har du større problemer. Hvis det virkelig er et problem for
> dig, så tilføj da en linje til at disable de interne funktioner i
> /etc/profile (eller noget lignende).
Hvad mener du? Jeg har et problem, fordi noget software har sin egen idé
om, hvordan det skal goere tingene.
> Alternativt kan du bruge en shell der ikke kan noget som helst selv.
> CMD.EXE lyder som noget for dig
Du har vist intet forstaaet. Jeg vil meget gerne have funktionalitet,
men jeg vil ikke have automagiske features, der foregaar bag min ryg og
laver om paa de ting, _jeg_ laver.
Der er himmelvid forskel paa at tilbyde eksempelvis understoettelse af
baade emacs- og vi-taster, og paa at erstatte udfoersel af et program
med en intern funktion. Hvordan kan shellen vide, at programmet ikke har
nogle sideeffekter, som jeg afhaenger af? Det kan den ikke.
Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)