Mam tutaj sytuację awaryjną, Linux i Bash dla początkujących i popsułem się, próbując napisać skrypt zmieniający nazwy niektórych plików. Pętla przypadkowo poszła ścieżką (uruchomiła skrypt w folderze na pulpicie) i zmieniła nazwę /bin
na /D_bin
(to D_
był prefiks, który dodałem), więc teraz system nie może używać /bin
zawartości, więc nie bash
, nie, mv
aby zmienić nazwę, nie sudo
... Pliki w /D_bin
są ok, nie nazwę, i można je skopiować i wkleić, ale nie można utworzyć folderu /bin
ponownie bez bash. System wygląda stabilnie, ale bardzo niewiele rzeczy działa i nie ma dostępu do plików na pulpicie.
Inne foldery /
podobne również /lib
/sbin
/etc
wydają się być w porządku, a pulpit graficzny nadal tam jest. Boję się ponownie uruchomić, ponieważ nie wiem, czy będzie można go uruchomić.
Czy istnieje powłoki root lub sposób, aby zmienić nazwę /D_bin
z powrotem /bin
? Potrzebujesz pomocy, bardzo ważna praca została naruszona
Mój samobójczy skrypt: $:
#!/bin/bash
files=~/Desktop/folder_1/*
for j in $files
do
cd $j
for i in 10n* #file names starting by 10n
do
find * -maxdepth 0 ! -path . -exec mv {} D_{} \;
done
cd ..
done
:( Dzięki!!!!
źródło
/D_bin/mv -T /D_bin /bin
i następnym razem nie uruchamiaj swoich skryptów jako root.Odpowiedzi:
Istnieje kilka sposobów rozwiązania tego problemu.
Jeśli masz dostęp do powłoki (dowolnego otwartego terminala), uruchom:
sudo
jest włączony,/usr/bin
więc nie ma potrzeby uruchamiania go z bezwzględną ścieżką.Inną rzeczą, którą możesz zrobić, jest dodanie
/D_bin
doPATH
zmiennej środowiskowej:Jeśli nie masz dostępu do żadnej powłoki:
na końcu linii, która zaczyna się od linux, dodaj:
naciśnij CTRL+x
Teraz zostaniesz przeniesiony do powłoki bash, powinieneś ponownie zamontować system plików jako do odczytu i zapisu.
I przenieś katalog D_bin do bin:
Następnie uruchom ponownie system.
Powinien działać, ale jeśli nic nie działało, nadal możesz uruchomić system z dysku / usb na żywo z Ubuntu i naprawić problem.
źródło
cd "$j"
(nazwa powinna być w cudzysłowie) i zamień zgorszeniecd ..
na pasujący ścisły nawias. Ponadto, dlaczego działasz jako root. Nie powinieneś być w stanie wyrządzić tyle szkód.cd ..
wstawieniupwd
usuńfind
polecenie ze skryptu, a następnie uruchom je jako zwykły użytkownik. zobaczysz skrypt, w który się wchodzi/
, ponieważ robisz płytę CD $ j, która, jak sądzę, nie jest katalogiem. więc w każdej pętli cofasz się o krok i w końcu wchodzisz/
./bin
ponieważ działał na folderach wewnątrz/bin
. Sprawdziłbym te (choć nie jako root!)mv
.Aby rozwiązać ten problem, jeśli nie masz otwartego terminalu, najpierw spróbuję znaleźć „substytut powłoki”, którego możesz użyć zamiast bash. Python jest włączony
/usr/bin
, więc to powinno nadal działać.Jeśli to nie zadziała, po prostu uruchomię z Live CD / USB i naprawię wszystko ze znanego, zdrowego środowiska.
Jako ogólną radę podałbym Jonathana Lefflera w komentarzach: nigdy nie używaj go
cd ..
w skryptach, może to łatwo prowadzić do takich problemów. Lepiej tylko cd do$j
katalogu w podpowłoce , dzięki czemu nie musisz się martwić o powrót.Oczywiście nie uruchamiaj rzeczy jako root, chyba że jest to absolutnie konieczne.
źródło
python
proces, wystarczy aplikacja terminalowa, a do uruchomieniaos.system("sudo ...")
wystarczy jądro * nix. Może wypróbuję to później na maszynie wirtualnej ...cd
pisania skryptów zwykle lepiej jestcd -
wrócić do miejsca, w którym byłeś, niż zakładać, że zapisałeś jeden katalog w dół. Jeśli zmienisz inicjałcd
, wtedycd ..
nie wrócisz tam, gdzie byłeś, alecd -
zrobi to.cd ..
bym nie używaćcd -
w skryptach, tylko w linii poleceń.cd -
jest może mniejszą gwarancją na kłopoty niżcd ..
, ale nadal nie uważałbym tego za bezpieczne - jeśli ktoś doda kolejne zmiany katalogu w środku, zabierze Cię to gdzieś niezamierzone. Natomiast podpowłoki dają wyraźnie ograniczony zakres, w którym zmienia się katalog i do którego punktu wracasz.os.system
ma nie pracować bezsh
obecne, alesubprocess.call
prace.