Connect failed: Connection timed out

[GastForen Programmierung/Entwicklung AppleScript Entzippen per AppleScript

  • Suche
  • Hilfe
  • Lesezeichen
  • Benutzerliste
Themen
Beiträge
Moderatoren
Letzter Beitrag

Entzippen per AppleScript

Hans Haesler
  
Beiträge gesamt: 5826

14. Aug 2018, 09:46
Beitrag # 1 von 7
Bewertung:
(7796 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Scripter,

entzippen per AppleScript?!? Was für eine doofe Idee! Das geht doch ganz einfach mit einem Doppelklick!

Stimmt. Aber es gibt Workflows, in welchen man das Dekomprimieren automatisch erledigen möchte.
Zum Beispiel wenn eine Mail-Message eintrifft, deren Inhalt sagt, dass eine Datei hochgeladen wurde.
Eine Mail-Rule kann daraufhin ein AppleScript starten, welches die ZIP-Datei verschiebt, entzippt und den Ordner in einen bestimmten Ordner verschiebt.

Dann wird der Verantwortliche per Mail informiert, dass das Entzippen und Verschieben geklappt hat. Zusätzlich wird das Ergebnis in eine Logdatei geschrieben.

*****
Für die erste Version benutzte ich unzip mit 'do shell script':

Code
set inflatedFolder to (do shell script "unzip -d " & destFolder & space & unzipThis) 

Das Entzippen funktioniert. Aber nicht ganz zufriedenstellend:
1. Zusätzlich wird ein Ordner namens "__MACOSX" erzeugt. Dieser kann mit einem Scriptbefehl entfernt werden.
2. Doch ein echtes Problem ist die Tatsache, dass der Inhalt von älteren Schriftdateien (z.B. vom 'Type 1') gelöscht wird.

*****
Auf eine Anregung des Kunden hin, versuchte ich es mit dem Programm Archive Utility. Dieses Dienstprogramm ist auf jedem Mac installiert und wirkt im Hintergrund, wenn Dateien per Menü-Befehl komprimiert werden. Und es agiert auch umgekehrt, wenn ein Doppelklick auf eine Zip-Datei gemacht wird.

Die letztere Aktion kann auch per AppleScript ausgelöst werden, obwohl "Archive Utility" eigentlich nicht scriptbar ist. Dennoch reagiert es auf 'open' (und auf 'quit'):

Code
set zippedFile to choose file 
tell application "Archive Utility" to open zippedFile
tell application "Archive Utility" to quit

Das ist schon alles. Weil das Programm offen bleibt, sollte es abschliessend beendet werden (dritte Zeile).

Aber Achtung: Okay, die beiden oben aufgeführten Probleme existieren nicht mehr. Doch es gibt ein neues ... Während man mit dem do-script-Befehl den Namen des entpackten Ordners (oder der Datei) zurückbekommt, ist das Ergebnis des Archive-Utility-Befehls ein unbrauchbares missing value ...

Wenn das entpackte Objekt nicht verschoben werden muss, ist das kein Problem. Aber sonst muss man den Namen erfahren können. Es reicht nicht, diesen zu "erraten", weil die Zip-Datei möglicherweise umbenannt wurde.

Die Lösung: Vor dem Entzippen eine Liste der Namen aller Objekte im selben Ordner erstellen. Und nach der Aktion erneut. Dann eine Schleife durch die Namen der zweiten Liste. Bei jedem prüfen, ob er in der ersten Liste enthalten ist. Falls nicht, ist es jener des entzippten Objekts und die Schleife kann verlassen werden.

*****
Angehängt an diesen Beitrag ist das Droplet "Entzippen_01.app". Zum Gebrauch: Eine Zip-Datei (oder mehrere) auf das Icon des Droplets ziehen.

Gruss, Hans

(Dieser Beitrag wurde von Hans Haesler am 15. Aug 2018, 08:27 geändert)

Anhang:
Entzippen_01d.zip (58.2 KB)
X

Entzippen per AppleScript

TMA
Beiträge gesamt: 399

15. Aug 2018, 07:39
Beitrag # 2 von 7
Beitrag ID: #565514
Bewertung:
(7762 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Guten Morgen Hans,
schaue dir mal 'ditto' an.

Auszug aus der manpage:
Zitat NAME
ditto -- copy directory hierarchies, create and extract archives

SYNOPSIS
ditto [-v] [-V] [-X] [<options>] src ... dst_directory
ditto [-v] [-V] [<options>] src_file dst_file
ditto -c [-z | -j | -k] [-v] [-V] [-X] [<options>] src dst_archive
ditto -x [-z | -j | -k] [-v] [-V] [<options>] src_archive ... dst_directory
ditto -h | --help

DESCRIPTION
In its first form, ditto copies one or more source files or directories to a destination directory. If the destination directory does not exist it will be created before the first source is copied. If the destination direc-
tory already exists then the source directories are merged with the previous contents of the destination.

In its second form, ditto copies a file to the supplied dst_file pathname.

The next two forms reflect ditto's ability to create and extract archives. These archives can be either CPIO format (preferred for unix content) or PKZip (for Windows compatibility). src_archive (and dst_archive) can be the
single character '-', causing ditto to read (write) archive data from stdin (or to stdout, respectively).

ditto follows symbolic links provided as arguments but does not follow any links as it traverses the source or destination hierarchies. ditto overwrites existing files, symbolic links, and devices in the destination when
these are copied from a source. The resulting files, links, and devices will have the same mode, access time, modification time, owner, and group as the source items from which they are copied. Pipes, sockets, and files
with names beginning with .nfs or .afpDeleted will be ignored. ditto does not modify the mode, owner, group, extended attributes, or ACLs of existing directories in the destination. Files and symbolic links cannot overwrite
directories or vice-versa.

ditto can be used to "thin" Universal Mach-O binaries during a copy. ditto can also copy files selectively based on the contents of a BOM ("Bill of Materials") file. ditto preserves file hard links (but not directory hard
links) present in the source directories and preserves setuid and setgid modes when run as the superuser.

ditto will preserve resource forks and HFS meta-data information when copying unless instructed otherwise using --norsrc . Similarly, ditto will preserve extended attributes and Access Control Lists (ACLs) unless --noextattr
or --noacl is passed. DITTONORSRC can be set in the environment as an alias to --norsrc --noextattr --noacl on the command line.


evtl interessant bzgl. der Resourcen:
Zitat --norsrc Do not preserve resource forks and HFS meta-data. If both --norsrc and --rsrc are passed, whichever is passed last will take precedence. Both options override DITTONORSRC. Unless explicitly specified, --norsrc
also implies --noextattr and --noacl to match the behavior of Mac OS X 10.4.


Gruß,
TMA


als Antwort auf: [#565499]

Entzippen per AppleScript

Hans Haesler
  
Beiträge gesamt: 5826

15. Aug 2018, 08:27
Beitrag # 3 von 7
Beitrag ID: #565515
Bewertung:
(7757 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Guten Morgen TMA,

danke für den Hinweis.

Von 'ditto' hatte ich schon früher gehört. Und bei meinen Nachforschungen betreffend das Entzippen tauchte es auch wieder auf.

Aber zuerst setzte ich 'unzip' ein. Und weil es klappte, blieb ich dabei. Bis zum Ersetzen durch den Einsatz von "Archive Utility".

Ich werde gelegentlich einen Versuch mit "ditto" machen.

Gruss, Hans


als Antwort auf: [#565514]

Entzippen per AppleScript

Hans Haesler
  
Beiträge gesamt: 5826

17. Aug 2018, 08:50
Beitrag # 4 von 7
Beitrag ID: #565613
Bewertung:
(7712 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo TMA,

jetzt habe ich einen Versuch mit "ditto" gemacht:

Code
set zippedFile to POSIX path of (choose file) 

set contFolder to POSIX file (zippedFile & "/..") as alias

set unzipThis to quoted form of zippedFile

set destFolder to quoted form of POSIX path of contFolder

set cmd to "ditto -xk " & unzipThis & space & destFolder

set expandedObject to (do shell script cmd)

Das Ergebnis: Die Datei wird korrekt entzippt. Nichts geht verloren. Auch die alten Schriftdateien sind unversehrt.

Aber: Das Ergebnis der Aktion ist ein leerer String. Der Name des entpackten Ordners (oder der Datei) bleibt unbekannt.

Fazit: Es gibt keinen Grund anstelle von "Archive Utility" ein do-shell-Script mit "ditto" zu verwenden.

Gruss, Hans


als Antwort auf: [#565514]

Entzippen per AppleScript

Hans Haesler
  
Beiträge gesamt: 5826

18. Aug 2018, 17:40
Beitrag # 5 von 7
Beitrag ID: #565635
Bewertung:
(7671 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo TMA,

nochmals herzlichen Dank für Deinen Hinweis.

Weil: Es gibt doch einen Grund, dem "ditto" den Vorzug zu geben! :-)

Der Kunde meldete ein Problem: Eine beschädigt (wie auch immer) hochgeladene Zip-Datei (von 94.4 MB) blockierte den Workflow.
"Archive Utility" zeigte einen Dialog, laut welchem es unmöglich ist, die Datei zu dekomprimieren, weil eine Datei oder ein Ordner fehlt.

Ein Doppelklick auf die Zip-Datei zeigt zuerst einen Forschrittsbalken und danach dieselbe Meldung.

Ein neuer Versuch mit dem oben geposteten "ditto"-Script ... Schon besser: Eine Fehler-Meldung nennt den Namen einer fehlenden Bild-Datei.
Im Arbeitsordner liegt neben der defekten Zip-Datei der Ordner "__MACOSX", welcher die leere Ordnerstruktur enthält.
Und auch der dekomprimierte Ordner, welcher vier Dateien enthält: eine ".idml", eine ".indd", eine ".pdf" sowie die übliche "Instructions.txt".
Zudem auch den Ordner "Document fonts" (samt Inhalt) und den Ordner "Links" mit drei Bild-Dateien.

Als erstes habe ich einen 'try'-Wickel um den "Archive Utility"-Befehl gelegt. Keine Verbesserung: Der "on error"-Abschnitt wird ignoriert.

Dann habe ich "Archive Utility" durch das "ditto"-Script ersetzt. Damit werden die "on error"-Zeilen ausgeführt. Dem Abteilungsleiter wird per E-Mail mitgeteilt, dass die Zip-Datei "Xyz.zip" beschädigt ist.
Nun noch aufräumen: Den Arbeitsordner leeren, indem die beiden Ordner und die Zip-Datei in den Papierkorb befördert werden.

Gruss, Hans


als Antwort auf: [#565514]

Entzippen per AppleScript

TMA
Beiträge gesamt: 399

21. Aug 2018, 08:09
Beitrag # 6 von 7
Beitrag ID: #565685
Bewertung:
(7403 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Hans,
danke für die Rückmeldung. Das hört sich doch gut an.


als Antwort auf: [#565635]

Entzippen per AppleScript

Hans Haesler
  
Beiträge gesamt: 5826

28. Nov 2018, 08:51
Beitrag # 7 von 7
Beitrag ID: #567755
Bewertung:
(5003 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo TMA,

bitte sehr. Allerdings ist nachträglich ein weiteres Problem aufgetaucht, welches diese Ursache hat: Beim Erzeugen der ZIP-Datei wurden mehrere Ordner (oder Dateien) ausgewählt. Das ergibt die Datei Archiv.zip.

Beim manuellen Entzippen bekommt man den Ordner Archiv. Dasselbe per Script mit Archive Utility.

Doch ditto schafft das nicht. Das Entzippen schon. Aber der Ordner Archiv wird nicht erzeugt.

An sich nicht so schlimm. Aber weil alles in einem Ordner in einen bestimmten Zielordner befördert werden muss, geht das nicht. Okay, das Script könnte einen Ordner erzeugen und alle Objekte hineinverschieben. Geht auch nicht, weil schon die nächste ZIP-Datei eingetroffen sein könnte.

Also kehrte ich zerknirscht zu Archive Utility zurück. Für das im Beitrag #5 erwähnte Problem habe ich eine Lösung gefunden.

Gruss, Hans


als Antwort auf: [#565685]
X