[BSD] Hoe /etc herstellen?

[downtime]

Ik heb zojuist een stomme fout gemaakt toen ik probeerde om een bestand te verwijderen dat een ongeldige bestandsnaam had. Het bestand werd door ls weergegeven als ???????. Ik heb hem na wat zoeken op Internet gewist met rm -- ???????. Achteraf bekeken nogal stom natuurlijk want nu zijn alle bestanden die een naam van 7 karakters hebben verdwenen.

Nu vraag ik me af of er een simpele manier is om /etc weer te herstellen. Met een make world is het mogelijk, als ik 't goed begrijp, om de source opnieuw te compileren zodat de bestanden die gewist zijn opnieuw gecompileerd worden.
Maar een volledige make world wil ik liever niet doen omdat ik de gevolgen ervan niet volledig kan overzien. Je snapt 't, ik ben een BSD noob en wil liever niet meer schade aanrichten dan ik al gedaan heb

Ik zou graag willen weten of het mogelijk is om alleen /etc te herstellen via een make opdracht. Is dat mogelijk of moet ik dan het volledige OS opnieuw compileren?
Een volledige herinstallatie vanaf CD doe ik liever niet. Ik heb dat net gisteren gedaan omdat de systeemschijf in m'n servertje gecrashed was (wordt een RMA'tje) en ik een nieuw systeem heb moeten installeren.

Oeps, vergeten te vertellen dat ik FreeBSD 5.1 gebruik en dat ik een volledige developer installatie incl. sources heb gedaan.

[ Voor 7% gewijzigd door downtime op 21-09-2003 21:18 ]

[Verwijderd]

Misschien is de make world niet helemaal zo'n slecht idee, /etc bestaat eigenlijk alleen maar uit configuratie bestanden en worden bij een make world denk ik opnieuw aangemaakt als ze ontbreken.

[downtime]

Verwijderd schreef op 21 September 2003 @ 21:29:
Misschien is de make world niet helemaal zo'n slecht idee, /etc bestaat eigenlijk alleen maar uit configuratie bestanden en worden bij een make world denk ik opnieuw aangemaakt als ze ontbreken.

Daar ging ik ook vanuit. Maar een make world schijnt erg lang te duren en compileert het hele systeem. Ik zou daarom graag willen weten of er zoiets bestaat als een make /etc ofzo.

[Jordi]

Je kunt mergemaster proberen. Niet dat dat jouw wijzigingen zal herstellen Maar dan heb je iig wat.

[Confusion]

offtopic:
Hoe zou je zo'n bestand trouwens wel beschaafd kunnen verwijderen onder BSD? Onder linux werkt rm "???????"; ik neem aan dat dat onder BSD ook werkt (geen BSD testomgeving tot mijn beschikking)?

[MadCow*]

mergemaster lijkt me idd de route om te volgen

offtopic:
? is een wildcard, maar dan voor 1 letter, we weten allemaal wat * doet
Dus als je er 7 op een rij zet, pakt rm alle bestanden die bestaan uit 7 karakters

[ Voor 23% gewijzigd door MadCow* op 21-09-2003 22:13 . Reden: ff verduidelijken ]

[downtime]

MadCow schreef op 21 September 2003 @ 22:10:
? is een wildcard, maar dan voor 1 letter, we weten allemaal wat * doet
Dus als je er 7 op een rij zet, pakt rm alle bestanden die bestaan uit 7 karakters

Je hebt helemaal gelijk maar ik lette gewoon niet goed op. Ik vond de optie -- voor rm ergens en dacht dat het diende om de interpretatie van wildcards uit te zetten. Als ik toevallig een bestand had gehad dat * heette had ik misschien wel rm -- * gedaan

Maar ik kom er net achter dat rc.conf ook verdwenen is en ik weet niet meer precies wat daar allemaal in stond. Dat weer uitvogelen en uitzoeken hoe mergemaster werkt kost me evenveel tijd als domweg een herinstallatie doen.
Aangezien ik inmiddels wel backups van alle andere config bestanden heb is het misschien toch makkelijker om maar weer een herinstallatie te draaien. Ik zal het maar als een goeie les beschouwen voor de volgende keer.

Dank voor de hulp

[ Voor 31% gewijzigd door downtime op 21-09-2003 22:23 ]

[_Squatt_]

/downtime/ schreef op 21 September 2003 @ 22:18:Je hebt helemaal gelijk maar ik lette gewoon niet goed op. Ik vond de optie -- voor rm ergens en dacht dat het diende om de interpretatie van wildcards uit te zetten. Als ik toevallig een bestand had gehad dat * heette had ik misschien wel rm -- * gedaan

De wildcards worden geinterpreteerd door je shell (waarschijnlijk bash, maar ik ken *BSD niet zo). Door een '\' voor een karakter wordt de speciale betekenis niet meer gebruikt.

Dus: rm \?\?\?\?\?\?\? had het ook gedaan, geen '--' nodig zo ver ik weet. Overigens werkt rm ?[tab] hier ook, dan wordt er automatisch rm \?\?\?\?\?\?\? van gemaakt (als er geen andere bestanden met '?' beginnen natuurlijk).

[downtime]

FreeBSD gebruikt tcsh als standaard shell. rm \?\?\?\?\?\?\? had ik trouwens al geprobeerd maar zonder succes.
Vermoedelijk werkte het niet omdat de echte bestandsnaam niet uit vraagtekens bestond maar alleen zo weergegeven werd. Ik vermoed dat de echte bestandsnaam uit 7 [esc] codes bestond. Vraag maar niet hoe die bestandsnaam ontstaan is

Met truc met [tab] had misschien wel gewerkt maar helaas heb ik daar niet aan gedacht.

[AVL]

Wat jij wil, kan met 'mergemaster -i'. Zie man mergemaster voor meer opties.

[Verwijderd]

Confusion schreef op 21 september 2003 @ 21:57:

offtopic:
Hoe zou je zo'n bestand trouwens wel beschaafd kunnen verwijderen onder BSD? Onder linux werkt rm "???????"; ik neem aan dat dat onder BSD ook werkt (geen BSD testomgeving tot mijn beschikking)?

Escapen werkt sowieso gegarandeerd

rm \?\?\?\?\?\?\?

edit:

Woei, erg goed gelezen Niels

[ Voor 10% gewijzigd door Verwijderd op 21-09-2003 23:59 ]

[_Squatt_]

/downtime/ schreef op 21 september 2003 @ 23:20:
FreeBSD gebruikt tcsh als standaard shell. rm \?\?\?\?\?\?\? had ik trouwens al geprobeerd maar zonder succes.
Vermoedelijk werkte het niet omdat de echte bestandsnaam niet uit vraagtekens bestond maar alleen zo weergegeven werd. Ik vermoed dat de echte bestandsnaam uit 7 [esc] codes bestond. Vraag maar niet hoe die bestandsnaam ontstaan is

In dat geval had je de output van ls even kunnen pipen door euhm, ben ik even kwijt , maar dan had je kunnen ontdekken welke character codes schuil gingen achter de ?'s.

Daarmee had je dan ook 't bestand kunnen wissen. Maar dat is allemaal gepraat achteraf natuurlijk .

[CyBeR]

2 oorzaken mogelijk:
• characters die weergegeven worden als '?'
• beschadigde inode

In het eerste geval heb je mischien wat aan een pipe zoals _Squatt_ zegt (en hij bedoeld ws. hexdump)
in het tweede geval moet je fsck ff z'n gang laten gaan

Is ie al weg trouwens?

[deadinspace]

Confusion schreef op 21 September 2003 @ 21:57:
Hoe zou je zo'n bestand trouwens wel beschaafd kunnen verwijderen onder BSD? Onder linux werkt rm "???????"; ik neem aan dat dat onder BSD ook werkt (geen BSD testomgeving tot mijn beschikking)?

Het heeft weinig te maken met GNU/Linux vs FreeBSD (of welke andere BSD dan ook); het heeft uitsluitend te maken met de shell die je gebruikt

In het geval van wildcards (vooral ? en *, maar ook [123] en {blaat,meh}) is het de shell die de wildcards interpreteert en vervangt door de mogelijkheden die overeenkomen met de wildcards. Door er "" omheen te plaatsen of \ voor te plaatsen vertel je de shell dat de daaropvolgende tekens niet als wildcards geintepreteerd moeten worden, maar letterlijk genomen moeten worden.

FreeBSD heeft als ik me niet vergis de bourne SHell, oftewel sh (of eigenlijk een reimplementatie ervan) als default shell. Bash - de Bourne Again SHell, een reimplementatie van sh met een aantal toevoegingen - is in de meeste GNU/Linux distributies de default, en lijkt behoorlijk veel op sh. Veel dingen werken identiek in bash en sh, dus het escapen van wildcards is identiek in deze twee shells.

De wildcards * en ?, en de escaping mechanismen "" en \ zijn sowieso tamelijk universeel in Unix shells (en andere delen van Unices).

Om je vraag te beantwoorden: Het hangt af van de shell die je gebruikt, maar allerhoogstwaarschijnlijk op exact dezelfde manier

/downtime/ schreef op 21 September 2003 @ 22:18:
Je hebt helemaal gelijk maar ik lette gewoon niet goed op. Ik vond de optie -- voor rm ergens en dacht dat het diende om de interpretatie van wildcards uit te zetten. Als ik toevallig een bestand had gehad dat * heette had ik misschien wel rm -- * gedaan

Even voor de duidelijkheid: -- dient (iig in de GNU utils) om de interpretatie van opties voor de daaropvolgende argumenten uit te zetten, en is dus nuttig om operaties te doen op files die met een - beginnen

[ Voor 6% gewijzigd door deadinspace op 22-09-2003 00:14 ]

[downtime]

CyBeR schreef op 22 September 2003 @ 00:06:
2 oorzaken mogelijk:
• characters die weergegeven worden als '?'
• beschadigde inode

Het ging dus om het eerste geval. 7 [esc] karakters die als '?' weergegeven werden. Oorzaak: Ik probeerde in een teksteditor de "save file" dialoog met Esc af te breken. Drukte in totaal 7x op die Esc toets en uiteindelijk maar op Enter toen ik merkte dat Esc niet werkte. En tot mijn verbazing werd het bestand vervolgens met 7 [esc] karakters als bestandsnaam opgeslagen

Is ie al weg trouwens?

Hij was inderdaad al weg. Mijn probleem is juist dat er veel teveel weg is.

Even voor de duidelijkheid: -- dient (iig in de GNU utils) om de interpretatie van opties voor de daaropvolgende argumenten uit te zetten, en is dus nuttig om operaties te doen op files die met een - beginnen

Dat verhaal had ik dus verkeerd begrepen. Ik dacht dat -- diende om de interpretatie van wildcards uit te zetten.