einfache erstellung von Dateien...

._ut schrieb:
Warum ich der Überzeugung bin, dass es ein Bug ist: Es gibt im UNIX die Regel: Benutze *ein* Werkzeug für *eine* Aufgabe.
Oh, da duerfte es aber kistenweise Gegenbeispiele geben. Meist laesst sich aber mit etwas nachdenken dann doch rausfinden, dass diese Funktionen zusammenhaengen. Ist IMHO auch bei touch so. Es waere ja auch nicht wirklich Aufwand diesen sog. "Bug" durch eine Existenzpruefung zu eliminieren.

._ut schrieb:
Für die Windows-Designer ist ein Feature immer mehr wert, als die Schlüssigkeit des Konzepts.
Das unterschreib ich sofort.
Das ist auch ein Punkt, der fuer mich einen der deutlichsten Unterscheide zw. MacOS/Linux/Unix und Win ausmacht. Wenn man die Konzepte der einzelnen Systeme mal grob durchschaut hat, laesst sichs ausgezeichnet damit arbeiten. Bei allen Systemen werden die Konzepte zwar auch nur zu ca. 90% eingehalten, aber das ist schon sehr viel.

Wile

P.S.: Mich deucht, es wird langsam off-topic. :D
 
._ut schrieb:
Erkläre mir den Sinn, das Erstellungsdatum einer Datei zu ändern, die noch nicht existiert.

Zur Erinnerung: touch -- change file access and modification times
Richtig, das ist die Kurzbeschreibung, dennoch verhält sich touch eben so, das es bei nicht existierender Datei diese anlegt. Und erst mit der Option "-c" wird dies unterlassen. Genau wegen dieser Option ist auch kein Bug. Es wäre also mit Leichtigkeit möglich, dieses Verhalten umzudrehen. Wird es aber nicht, weil es sich im praktischen Einsatz als nützlich erwiesen hat. Und nun wird das ganze wieder On Topic, denn die Funktionalität die der Threadstarter möchte, kann im praktischen Einsatz nützlich sein, und nur darauf kommt es an.
 
Zuletzt bearbeitet:
Wile E. schrieb:
Oh, da duerfte es aber kistenweise Gegenbeispiele geben. Meist laesst sich aber mit etwas nachdenken dann doch rausfinden, dass diese Funktionen zusammenhaengen. Ist IMHO auch bei touch so.
Warum gerade bei touch? Bei mv könnte ich ja irgendwie verstehen, wenn keine Quelle angegeben wird, wird am Ziel eine neue Datei angelegt. (Doch mv macht das nicht, ebenso wie das GUI-Äquivalent Finder - aus dem gleichen Grunde: Es ist nicht seine Aufgabe.)
Aber bei einem Utility, dass Datei-Daten ändert, da wirds noch unsinniger. Dann müsste auch chmod und chown etc. (die ja die gleichen Aufgaben haben, wie touch - Dateisystems-Metadaten ändern) neue Dateien anlegen.

mkninc schrieb:
Wird es aber nicht, weil es sich im praktischen Einsatz als nützlich erwiesen hat.
Mag ja sein, dass der Bug sich als nützlich erwiesen hat - nachdem UNIX 25 Jahre lang ohne ausgekommen ist - aber falsch ist es trotzdem an der Stelle.
 
Zuletzt bearbeitet von einem Moderator:
._ut schrieb:
Auch Inkonsistenzen, die man kaum bemerkt, sind schlecht für den Arbeitsfluss. IdR. ziehen sie außerdem einen Rattenschwanz nach sich. Es ist Aufgabe eines guten Systemdesigners, diese zu finden und zu eliminieren, soweit möglich.
Ich kapier' nicht, wo du in Gedanken bist. Mein Argument ist, dass mein (und offenbar auch anderer Leute) Arbeitsfluss von der x+1sten Möglichkeit profitieren würde, ohne dass andere Leute unter der Anwesenheit der Methode leiden müßten (ich kann da einfach keinen Rattenschwanz entdecken).

Und von einem guten Systemdesigner würde ich die Fähigkeit erwarten, sich in unterschiedliche Benutzer-Klientel hineinzudenken, und wenn es eine elegante Möglichkeit gibt die unterschiedlichen Anforderungen abzudecken, ohne der jeweils anderen Gruppe ein Ei zu legen, das dann auch zu tun. Nicht, sich in seine eigene Meinung hineinzusteigern, und statt der nicht-vorhandenen Probleme einfach nur die Anforderungen zu eliminieren.

(Die Geisteshaltung, die ich aus deinen Postings rauslese, ist übrigens der Grund, warum ich die Diskussion hier fortführe. Im Job habe ich ständig damit zu tun, Systemdesignern einzubleuen, sie sollten die Anforderungen von Anwendern erst einmal respektieren. Auch wenn die nämlich oft ungeschickt formuliert sind, oder unsinnig klingen, so verraten sie bei genauerem Hinsehen erstaunlich viel über die wahre Problemstellung der Anwender. Wenn du dich nicht drum kümmerst, lernst du nix dazu. Wenn du dich, lieber ._ut, nicht drum kümmerst, warum es manchen Leuten scheinbar wichtig ist, eine Datei an einem bestimmten Ort anzulegen, und warum sie das lieber im Dateimanager tun, dann kannst du dich auch nicht fragen weswegen sie das eigentlich tun möchten, und in der Folge lernst du nix dazu. Und plötzlich mußt du dich hier als "Betonkopf" anreden lassen, obwohl du das sicher komplett anders siehst… Probier' doch ab und zu mal einfach einen anderen Standpunkt aus! -- so, endgültig OT jetzt, dann lassen wir mal gut sein.)
 
grabmeru schrieb:
(ich kann da einfach keinen Rattenschwanz entdecken)
Der Rattenschwanz in diesem Falle wäre folgender: Das Ablage-Menü (das im Tiger-Finder eh schon zu lang ist) wird noch länger, denn es müsste ja ein zusätzlicher Menüpunkt eingefügt werden (dazu dann noch einer als Ersatz für strg-X siehe diese Diskussion https://www.macuser.de/forum/showthread.php?t=109280 und und und). Dazu müsste ein Systemdienst eingerichtet werden, der die möglichen Dateitypen von den Programmen abfragt, die der Finder anlegen können soll (bzw. die LauchServices entsprechend erweitert werden. Die Windows-Lösung über Registry-Einträge, ist für den Mac nicht akzeptabel, weil undynamisch; funktioniert nur in einem System, in dem Programme installiert und deinstalliert werden müssen.).

Das ist jedenfalls so, wenn man die Windows-Lösung mit dem Submenü vor Augen hat. Die für mich akzeptable Lösung "Neue Datei" (Apfel-ctrl-Wahl-N) ohne Definition eines Dateityps (also nur einen Eintrag in das Dateisystem erzeugen) würde natürlich nur das Ablage-Menü verlängern.

Interessant an der Stelle übrigens, dass hier im Explorer Ordner und Dateien gleich behandelt werden, was ja sonst nicht der Fall ist. Das einzig konsequente bei Windows ist die Inkonsistenz.
Im Job habe ich ständig damit zu tun, Systemdesignern einzubleuen, sie sollten die Anforderungen von Anwendern erst einmal respektieren. Auch wenn die nämlich oft ungeschickt formuliert sind, oder unsinnig klingen, so verraten sie bei genauerem Hinsehen erstaunlich viel über die wahre Problemstellung der Anwender. Wenn du dich nicht drum kümmerst, lernst du nix dazu.
Daraus sollte aber nicht um jeden Preis Features entstehen, sondern es sollten durchdachte Lösungen entwickelt werden. Es sollte abgewägt werden, wie wichtig dieses angeforderte Feature ist, welche Gruppen davon profitieren (in diesem Falle profitieren ja, wenn überhaupt, eigentlich nur Programmierer oder Administratoren), ob es nicht schon genügend andere Lösungen gibt (gibt es am Mac eh schon sehr viel mehr, als bei Windows) etc. Der Systemdesigner muss auch den Mut haben, ein Feature eben nicht einzubauen. Wenn er jedes Feature einbaut, das irgendein Benutzer fordert, wir das System unbedienbar.
Ein guter Systemdesigner sollte einen Überblick über das Ganze haben, denn das ist mehr, als die Summe seiner Teile.




P.S. Eine Frage, die sich mir gerade stellt: Gibt es eigentlich solche Diskussionen in Windows-Foren? Also, dass jemand fragt, warum es kein Tastenkürzel für das Erstellen eines neuen Ordners gibt, man Dateien nicht mit einem Befehl Duplizieren kann oder wie man einen Formularblock erstellt etc. Wenn ja, wie laufen solche Diskussionen?
 
Zuletzt bearbeitet von einem Moderator:
._ut schrieb:
Der Rattenschwanz in diesem Falle wäre folgender: Das Ablage-Menü (das im Tiger-Finder eh schon zu lang ist) wird noch länger, denn es müsste ja ein zusätzlicher Menüpunkt eingefügt werden (dazu dann noch einer als Ersatz für strg-X siehe diese Diskussion https://www.macuser.de/forum/showthread.php?t=109280 und und und). Dazu müsste ein Systemdienst eingerichtet werden, der die möglichen Dateitypen von den Programmen abfragt, die der Finder anlegen können soll (bzw. die LauchServices entsprechend erweitert werden. Die Windows-Lösung über Registry-Einträge, ist für den Mac nicht akzeptabel, weil undynamisch; funktioniert nur in einem System, in dem Programme installiert und deinstalliert werden müssen.)…
Bei der *Implementierung* ist das klar; ich dachte an die Usability. Bei der Implementierung könnte man ja auch über die Systemeinstellungen nachdenken; man könnte z.B. nur die Dateitypen "freischalten", die man haben möchte (UTIs könnten da helfen), und den Anwender gleichzeitig das Programm zuweisen lassen, mit dem er diese Datei dann standardmäßig geöffnet haben möchte. Vorteil: Im Normalfall gibt's das Kontextmenü gar nicht, aber wer eines haben möchte, kann es sich zusammenstellen.

._ut schrieb:
… Es sollte abgewägt werden, wie wichtig dieses angeforderte Feature ist, welche Gruppen davon profitieren (in diesem Falle profitieren ja, wenn überhaupt, eigentlich nur Programmierer oder Administratoren), …
…oder Leute in größeren Organisationen mit ziemlich vielen Projektservern, wo es sowohl beim Arbeiten als auch beim Kommunizieren drauf ankommt, wo man seine Dateien ablegt bzw. wo sie von anderen gefunden werden können. Wegen der Kommunikation funktionieren private symbolische Links auch nicht so gut, weil der Kollege im Zweifel den "offiziellen" Pfad braucht. Zugegeben, das ist derzeit nicht die Hauptzielgruppe des Mac, aber soll das so bleiben?

._ut schrieb:
…Wenn er jedes Feature einbaut, das irgendein Benutzer fordert, wir das System unbedienbar.
Vielleicht würde obiger Vorschlag mit den Systemeinstellungen ja gar nich soooo unbedienbar sein.

._ut schrieb:
P.S. Eine Frage, die sich mir gerade stellt: Gibt es eigentlich solche Diskussionen in Windows-Foren? Also, dass jemand fragt, warum es kein Tastenkürzel für das Erstellen eines neuen Ordners gibt, man Dateien nicht mit einem Befehl Duplizieren kann oder wie man einen Formularblock erstellt etc. Wenn ja, wie laufen solche Diskussionen?
Keine Ahnung, da treibe ich mich nicht rum, aber wegen solcher Liebe zum Detail schätze ich ja den Mac. Macs habe ich zuhause seit 1992, finde sie immer noch sympathisch, aber im Job gibt's halt nur Windows, und sooo schlecht funktioniert das schon sein Win2000 nicht mehr, das muss man sich halt einfach mal eingestehen.
 
Das mit den Systemeinstellungen fällt wohl schon daher aus, dass beim Übergang von Mac OS zu Mac OS X zugunsten einer direkteren Lösung (Info - Öffnen mit) auf ein Kontrollfeld zur Dateityp-Zuteilung (File Exchange / Internet) verzichtet wurde.

Man könnte höchstens im Info-Dialog ein weiteres Häkchen einfügen - "Finder kann Dateien diesen Dateityps anlegen" o.ä. Allerdings müsste der Finder dann wiederum erfahren, welchen Inhalt (Header) die Dateien dieses Typs haben müssten. Windows legt ja z.B. bei "Neu > RTF-Dokument" eine Datei mit dem Suffix "rtf" und den Worten "\rtf1" in geschweiften Klammern an. Das wiederum bedeutet, dass hier ein Systemdienst die Programme nach validen Headern zum Dateitypen abfragen müsste und dass die Programmhersteller dafür entsprechende zusätzliche Einträge in die Info.plists einführen müssten. (UTIs könnten da auch nicht helfen, die beziehen sich nämlich nur auf Suffix, Typ/Creator und MIME-Typ, nicht aber auf Daten innerhalb der Dateien- das könnte aber theoretisch erweitert werden.)

Und es würde auch nichts daran ändern, dass das Ablage-Menü noch länger wird, als es eh schon ist.

Insofern finde ich immer noch die Lösung, dass Dateien prinzipiell von den entsprechenden Programmen erstellt werden und eben nicht vom Finder, als die sinnvollste, auch wenn es in Ausnahmen mal einen Klick mehr bedeutet.



Die Geschichte mit den Projektservern lässt sich meiner Erfahrung nach sehr gut per AppleScript regeln. (Ein Script, dass die benötigten Projektordner und-Dateien generiert und benennt.)
 
Zuletzt bearbeitet von einem Moderator:
._ut schrieb:
Warum gerade bei touch? Bei mv könnte ich ja irgendwie verstehen, wenn keine Quelle angegeben wird, wird am Ziel eine neue Datei angelegt.
mv faend ich unlogisch, das soll ja etwas "bewegen". Touch beruehrt eine Datei, dass da eine nicht vorhandene angelegt wird, kann man notfalls noch reininterpretieren. Passender waere nateurlich ein Befehl wie "mkfile".

._ut schrieb:
Dann müsste auch chmod und chown etc. (die ja die gleichen Aufgaben haben, wie touch - Dateisystems-Metadaten ändern) neue Dateien anlegen.
Das ch steht fuer "change". ;)

._ut schrieb:
Mag ja sein, dass der Bug sich als nützlich erwiesen hat - nachdem UNIX 25 Jahre lang ohne ausgekommen ist - aber falsch ist es trotzdem an der Stelle.
Woher weisst Du, dass es sich um einen Bug handelt? Einen dokumentierten "Bug", der sich per Kommandozeilenoption abschalten laesst?

Unabhaengig davon, Konzepte durchzuhalten ist ja eine sinnvolle Sache, aber auch Apple macht da teilweise komische Dinge. Warum muss ich manche Audio-Einstellungen in den Systemeinstellungen vornehmen und andere im Audio-Midi-Werkzeug? Warum muss man den Default-Browser nicht in den Systemeinstellungen, sondern ausgerechnet in den Safari-Einstellungen eintragen? In puncto Konsistenz ist Apple zwar MS haushoch ueberlegen (siehe allein die Office-Programme untereinander), aber es finden sich auch da genug Beispiele zum kopfkratzen.

Wile
 
Zurück
Oben Unten