J'ai une urgence, Linux et Bash débutant ici et foiré en essayant d'écrire un script pour renommer des fichiers. La boucle a accidentellement le chemin (couru le script dans un dossier de bureau) et renommé /bin
à /D_bin
( D_
était le préfixe j'ajouté) maintenant le système ne peut pas utiliser le /bin
contenu, donc pas bash
, pas mv
de renommer, pas sudo
... Les fichiers in /D_bin
sont ok, pas renommés, et peuvent les copier-coller mais ne peuvent pas recréer de dossier /bin
sans bash. Le système semble stable, mais très peu de choses fonctionnent et n’ont pas accès aux fichiers de Desktop.
Les autres dossiers /
similaires /lib
/sbin
/etc
semblent bien aussi, et le bureau graphique est toujours là. J'ai peur de redémarrer parce que je ne sais pas s'il pourra démarrer.
Y at - il une coquille dans la racine ou une façon de renommer /D_bin
revenir à /bin
? Besoin d'aide s'il vous plaît, travail très important compromis
Mon script suicidaire: $:
#!/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
:( Merci!!!!
la source
/D_bin/mv -T /D_bin /bin
et ne lancez pas vos scripts en tant que root la prochaine fois.Réponses:
Il existe plusieurs façons de résoudre ce problème.
Si vous avez accès à un shell (n'importe quel terminal ouvert), lancez:
sudo
est dans/usr/bin
il n'y a donc pas besoin de l'exécuter avec un chemin absolu.Vous pouvez également ajouter la
/D_bin
àPATH
la variable d’environnement, comme ceci:Si vous n'avez accès à aucun shell:
à la fin de la ligne qui commence par linux, ajoutez:
appuyez sur CTRL+x
Maintenant que vous allez être déposé dans un shell bash, vous devez remonter le système de fichiers en lecture et en écriture.
Et déplacez le répertoire D_bin vers bin:
Puis redémarrez le système.
Cela devrait fonctionner, mais si rien ne fonctionnait pour vous, vous pouvez toujours démarrer le système avec un disque / usb ubuntu en direct et résoudre le problème.
la source
cd "$j"
(le nom doit être entre guillemets), et remplacez l'incident faisant malcd ..
avec la parenthèse proche correspondante. Aussi, pourquoi étiez-vous en tant que root. Vous ne devriez pas pouvoir faire autant de dégâts.cd ..
mettre unpwd
, retirez votrefind
commande à partir du script, puis exécutez en tant qu'utilisateur normal. vous verrez que le script entre/
, parce que vous faites un cd $ j qui, je suppose, sont des fichiers et non des répertoires. donc, dans chaque boucle, vous faites un pas en arrière et vous êtes enfin dans/
./bin
car il fonctionnait dans des dossiers/bin
. Je vérifierais ceux-ci (mais pas en tant que root!)mv
.Pour résoudre ce problème si vous n'avez pas de terminal ouvert, essayez tout d'abord de trouver un "substitut de shell" que vous pouvez utiliser à la place de bash. Python est dans
/usr/bin
, donc cela devrait encore fonctionner.Si cela ne fonctionne pas, je démarrerais directement à partir d'un CD / USB et réparer tout depuis un environnement de travail connu.
En règle générale, je seconderais Jonathan Leffler dans les commentaires: ne jamais utiliser
cd ..
de scripts, cela peut facilement conduire à de tels problèmes. Mieux vaut ne placer que le cd dans le$j
répertoire d’un sous - shell , de cette façon, vous n’aurez plus à vous inquiéter.De plus, bien sûr, ne lancez rien en tant que root, sauf en cas d'absolue nécessité.
la source
python
processus, vous avez juste besoin d’une application de terminal, et pour le faire,os.system("sudo ...")
vous avez besoin d’un noyau * nix. Peut-être que je l'essayerai plus tard dans une machine virtuelle ...cd
scripts, il est généralement préférable decd -
revenir là où vous vous trouviez, plutôt que de supposer que vous avez cdé un répertoire. Si vous modifiez l'initialecd
, lecd ..
ne vous ramènera pas à votre position actuelle, mais lecd -
restera.cd ..
je ne l' utilisais pascd -
dans les scripts, uniquement en ligne de commande.cd -
est peut-être moins une garantie de problèmes quecd ..
, mais je ne le considérerais toujours pas comme sûr . Si quelqu'un ajoute d'autres modifications de répertoire au milieu, cela vous mènera quelque part sans le vouloir. Tandis que les sous-coquilles vous donnent une portée clairement délimitée pour indiquer où le répertoire change et à quel point vous revenez en arrière.os.system
ne fonctionne pas sanssh
présent, maissubprocess.call
fonctionne.