BillMaier schrieb:
Ist das das eigentliche und einzige Problem? Die Buckets werden hier intern erzeugt und wir werden uns hüten, in den Namen Zeilenumbrüche einzubauen.
Das ist zumindest das für mich offensichtlichste Problem der meisten ls Implementierungen, das verhindern kann, dass deine for-Schleife wie gedacht funktioniert und zumindest dann, wenn mc ls auf das Dateisystem losgelassen wird (ich habe keine S3 Buckets zum Testen) offensichtlich ist:
$ ls -q
'test'$'\n''me.txt'
$ mc ls
[2021-04-26 09:09:15 CEST] 13B test
me.txt
for bucket in "$(mc ls | awk '{print NF}')"; do echo "$bucket"; done
5
1
Wenn man es genauer wissen wollte, müsste man sich die Implementierung von mc list für S3-Buckets ansehen und am besten mal mit "riskanten" Bucketnamen experimentieren, damit man weiß, welche tatsächlichen Beschränkungen der Ansatz hat - awk verschluckt Fehler ja oft implizit und dann wundert man sich, warum da Unsinn hinten raus kommt.
- ein Workaround dafür ist mit null-terminierten Strings zu arbeiten, was allerdings nicht alle Tools unterstützen.
Hast du mir dafür ein Beispiel, wie das in dem Kontext hier aussehen könnte? (gerne ungetestet)
mc hat laut der Dokumentation leider keine Option für eine null-Terminierte Ausgabe. Grundsätzlich könnte eine Schleife z.B. so aussehen, wenn man das auf Dateisystemebene machen wollte:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 | unset n
for e in *; do
echo Element $(( ++n )): $(stat -c '[%y] %sB' "$e") "$e"
done
# oder
unset n
while read -d $'\0' -r line
do
echo -ne $(( ++n )) "$line"
done < <(find -mindepth 1 -maxdepth 1 -printf "[%CY-%Cm-%Cd %CH:%CM-%CS %CZ] %sB %P\0")
# oder
declare -a lines
IFS= readarray -d $'\0' lines < <(find ./ -mindepth 1 -maxdepth 1 -printf "[%CY-%Cm-%Cd %CH:%CM-%CS %CZ] %sB %P\0")
for idx in "${!lines[@]}"
do
echo "Element $(( idx + 1 )): ${lines[$idx]}"
done
|
Ansonsten kann mc laut https://docs.min.io/minio/baremetal/reference/minio-cli/minio-mc.html#global-options auch JSON Lines ausgeben, was das Problem des Parsens einer nackten Ausgabe von ls abmildert, aber dafür muss man dann mit einem Tool wie jq die Ausgabe parsen.
Tja, das ist immer das gleiche: Das offizielle Container-Image für mc
bringt kein jq mit. Wenn ich kein eigenes Image-bauen will, kann ich mir da jetzt das binary mounten. Je mehr Gebastel, desto fehleranfälliger wird das allerdings auch wieder. Daher auch die Frage oben nach dem tatsächlichen Problem/Risiko.
Mir stellt sich da die Frage, warum es überhaupt ein Docker-Container sein muss - als Go-Programm ist das doch statisch gelinkt, d.h. man kann das Binary in einer Systemd-Unit mit restriktiv ausgelegten Berechtigungen weitgehend isoliert ausführen und braucht dafür nicht mal einen extra Container (der intern ja eh nicht viel anderes macht als das in eine cgroup zu packen und deren Rechte einzuschränken).