2016-06-03 22 views
0

Mein Skript ist ausführbar und ich führe es als sudo aus. Ich versuchte viele Workarounds und Alternativen zum ">>" -Operator, aber nichts schien richtig zu funktionieren.Bash-Skript kann aufgrund einer Umleitung in einer Umgebung, in der root der Eigentümer ist, nicht ordnungsgemäß ausgeführt werden.

Mein Skript:

#! /bin/bash 
if [[ -z "$1" || -z "$2" ]]; then 
    exit 1 
else 
    root=$1 
    fileExtension=$2 
fi 
$(sudo find $root -regex ".*\.${fileExtension}") >> /home/mux/Desktop/AllFilesOf${fileExtension}.txt 

Ich versuchte, T-Stück, sed und dd von, ich habe auch versucht, es mit bash -c oder in sudo -i ausgeführt wird, nichts funktionierte. Entweder erhalte ich eine leere Datei oder eine Berechtigung verweigert. Ich suchte gründlich und viele Befehle Handbücher lesen, aber ich kann es nicht

+0

"Tried' tee' "** wie **, genau? Sie müssen das 'sudo' auf den Befehl' tee' anwenden; Du kannst nicht 'sudo ... | tee outfile "und erwarte, dass es funktioniert, es muss' sudo ... | sein sudo tee outfile'. –

Antwort

1

Der $() Operator führt Befehl Substitution an der Arbeit. Wenn die gesamte Befehlszeile erweitert wird, wird der Befehl innerhalb der Klammern ausgeführt, und das gesamte Konstrukt wird durch die Ausgabe des Befehls ersetzt. Nachdem alle Erweiterungen ausgeführt wurden, wird die resultierende Zeile als Befehl ausgeführt.

Betrachten wir also diese vereinfachte Version des Befehls:

$(find /etc -regex ".*\.conf") >> /home/mux/Desktop/AllFilesOfconf.txt 

Auf meinem System, das

/etc/rsyslog.conf /etc/pnm2ppa.conf ... /etc/updatedb.conf >> /home/mux/Desktop/AllFilesOfconf.txt 

Hinweis an dieser Stelle auf einen ginormous Befehl des Formulars erweitern, dass die Umleitung getrennt von und daher unabhängig von dem Befehl in der Befehlsersetzung. Das Erweitern der Befehlsersetzung führt daher dazu, dass nichts in die Zieldatei geschrieben wird.

Aber wir sind nicht fertig! Das war nur die Erweiterung. Bash versucht nun, das Ergebnis als Befehl auszuführen. Im obigen Beispiel wird versucht, /etc/rsyslog.conf als Befehl auszuführen, wobei alle anderen Dateinamen als Argumente verwendet werden und die Ausgabe wie angegeben umgeleitet wird. Aber /etc/rsyslog.conf ist nicht ausführbar, so dass dies fehlschlägt und eine Meldung "Berechtigung verweigert" erzeugt. Ich bin mir sicher, dass Sie daraus ableiten können, welche Auswirkungen verschiedene Erweiterungen haben würden.

Ich glaube nicht, dass Sie eine Befehlsersetzung überhaupt ausführen, sondern nur den Befehl ausführen und seine Ausgabe an die angegebene Datei umleiten. Das wäre einfach sein:

sudo find $root -regex ".*\.${fileExtension}" >> /home/mux/Desktop/AllFilesOf${fileExtension}.txt 

Update:

Wie @CharlesDuffy beobachtet, die Umleitung wird in diesem Fall mit den Rechten des Benutzers/Prozess ausgeführt, um das Skript ausgeführt wird, so wie es ist in Ihrem ursprünglichen Beispiel. Ich nehme an, dass dies beabsichtigt und korrekt ist - dh das Skript wird vom Benutzer 'mux' oder von einem anderen Benutzer ausgeführt, der Zugriff auf das Verzeichnis Desktop von mux hat und auf alle vorhandenen Dateien, die das Skript erstellen oder aktualisieren könnte . Wenn das nicht der Fall ist, und Sie müssen die Umleitung auch sein privilegiert, dann kann man es wie so erreichen:

sudo -s <<END 
find $root -regex ".*\.${fileExtension}" >> /home/mux/Desktop/AllFilesOf${fileExtension}.txt 
END 

Das läuft eine interaktive Shell über sudo mit seiner Eingabe vom heredoc umgeleitet wird . Die Variablenerweiterungen werden in der Host-Shell ausgeführt, von der sudo ausgeführt wird. In diesem Fall wird die Umleitung mit der Identität durchgeführt, die über sudo erhalten wurde, was sich auf die Zugriffskontrolle auswirkt, sowie auf die Eigentümerschaft der Datei, wenn eine neue erstellt wird. Sie könnten einen chown-Befehl hinzufügen, wenn Sie nicht möchten, dass die Ausgabedateien im Besitz von root sind.

+0

Das 'sudo' wird immer noch nicht auf die Umleitung selbst angewendet und löst somit nicht das OP-Problem, ohne die Ausgabedatei zu öffnen. –

+0

@CharlesDuffy, es ist mir nicht klar, dass das Problem die Unfähigkeit ist, die Ausgabedatei zu öffnen. Die Meldung "Nachricht verweigert" stammt wahrscheinlich aus dem Versuch, eine Datei auszuführen, die nicht ausführbar ist. Tatsächlich sagt er, dass er manchmal eine leere Akte bekommt; Wenn er mit * no * file gestartet hat, zeigt das an, dass die Datei tatsächlich geöffnet ist. –

+0

Wie auch immer - das ist insofern richtig, als es geht - es behebt etwas, das ohne Zweifel ein Problem ist; es kann einfach sein oder nicht das einzige Problem sein. –