Hallo,
ich nutze den TC schon seit Jahre und bin sehr zufrieden.
Was mir aber aufgefallen ist, ist dass man nicht nach Dateinamen die einen Punkt enthalten suchen kann. Z.B. habe ich hier eine Datei mit der Bezeichnung 2.3-4.pdf, die nicht gefunden wird.
Gibt´s da eine Lösung?
Gruß
Giovanni
Suche nach Dateinamen mit Punkt
Moderators: Hacker, Stefan2, white
Hallo seb-,
es geht um die Suche mit Alt+F7.
Ich hatte nach 2.3-4 gesucht und es auch mit Anführungszeichen probiert.
Normalerweise kann ich so nach Namensbestandteilen suchen.
Aufgrund deiner Nachfrage habe ich jetzt mal den kompletten Namen inkl. .pdf gesucht - das wird gefunden. Das hilft mir aber nur bedingt, da ich meißt nicht weiß was nach 2.3-4 noch für Zeichen kommen.
Ooops: hab jetzt mal 2.3-4* versucht - und es geht.
Danke für die Nachfrage - Hilfe zur Selbsthilfe
Gruß
Giovanni
es geht um die Suche mit Alt+F7.
Ich hatte nach 2.3-4 gesucht und es auch mit Anführungszeichen probiert.
Normalerweise kann ich so nach Namensbestandteilen suchen.
Aufgrund deiner Nachfrage habe ich jetzt mal den kompletten Namen inkl. .pdf gesucht - das wird gefunden. Das hilft mir aber nur bedingt, da ich meißt nicht weiß was nach 2.3-4 noch für Zeichen kommen.
Ooops: hab jetzt mal 2.3-4* versucht - und es geht.
Danke für die Nachfrage - Hilfe zur Selbsthilfe
Gruß
Giovanni
Enthält der Suchbegriff einen Punkt, wird exakt danach gesucht, wie auch der Hilfe zu entnehmen ist:
MfG DalaiTC-Hilfe, geöffnet via F1 im Suchen-Dialog wrote:Enthält ein Suchstring einen Punkt, wird nach der EXAKTEN Übereinstimmung gesucht.
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
@Giovanni9,
die Suche nach Dateinamen, die irgendwo einen Punkt enthalten (über den einen unmittelbar vor der Extension hinaus), also, anders formuliert, insgesamt zwei oder mehr Punkte enthalten, ist in TC leider etwas speziell - aber möglich!
Wie die Hilfe schon erläutert, bewirkt ein Punkt in der Eingabe nämlich, dass der Suchbegriff von TC nicht mehr als sog. substring-search interpretiert wird, sondern eine formal-syntaktische Suche mit "Wildcards" (reservierten Joker-Zeichen), also eine sog. glob-search daraus wird.
Da ein Punkt in einer glob-search aber in aller Regel bedeutet, dass danach der Ausdruck für die "extension" folgt, ist es hier erst recht schwierig, nach einem "echten" Punkt zu suchen, der als reales ASCII/Unicode-Zeichen tatsächlicher Bestandteil des Dateinamens ist.
Lösung: gib folgenden String in die Suchmaske ein:
Lieber Christian Ghisler, falls Sie das lesen, würde ich sehr gerne diese Anfrage zum Anlass nehmen, für die nächste Version von TC, die ja in nicht allzuferner Zukunft bevorstehen dürfte, eine "uralte" Anregung meinerseits wieder aufzugreifen und um eine grundlegende Überarbeitung der Suchfunktion zu bitten.
So einfach der Punkt als Unterscheidung zwischen substring- und glob-search auch erscheinen mag, bringt er doch prinzipielle, unüberwindliche Einschränkungen mit sich.
Ich plädiere daher abermals dringend für zwei getrennte, alternative Suchmasken-Zeilen für den Namen - oder auch nur eine, die mit Auswahlkästchen explizit hin- und hergeschaltet werden kann, zwischen einer sauberen substring-search, in der ein Punkt auch wirklich einen Punkt als Textzeichen bedeutet - und einer reinen, formal-syntaktisch orientierten glob-search.
Diese Massnahme würde es auch beträchtlich vereinfachen, die von so vielen gewünschte Suche nach multiplen substrings, vielleicht sogar wahlweise verknüpft mit "und" bzw. "oder" und getrennter Eingabe eines substrings für die file-extension, sauber und frei von Einschränkungen zu implementieren.
*************** edit by algol *************
Und vielleicht ginge das ganze sogar noch als eigenständiger, von TC abgekoppelter (Hintergrund-) prozess. Doch falls Sie das aus Sicherheitsbedenken weiterhin ablehnen sollten, können wir auch in Zukunft ganz gut mit einer zweiten TC-Instanz für den Fall der Hintergrundsuche leben.
*************** gestrichen ***************
wurde soeben von HolgerK erinnert, dass dieser Wunsch mit <shift+Alt+F7> bereits realisiert ist.
Zuletzt wäre im Rahmen einer solchen Entflechtung der "Search for"-Suchmaske vielleicht noch zu überlegen, ob örtliche Einschränkungen der Suche, etwa in Verbindung mit dem "pipe"-character ("| _vti*\" bzw. "system32\", lt. Hilfe), nicht besser in der "Search in"-Suchmaske aufgehoben wären.
mfg
algol bereits realisiert ist.
Zuletzt wäre im Rahmen einer solchen Entflechtung der
die Suche nach Dateinamen, die irgendwo einen Punkt enthalten (über den einen unmittelbar vor der Extension hinaus), also, anders formuliert, insgesamt zwei oder mehr Punkte enthalten, ist in TC leider etwas speziell - aber möglich!
Wie die Hilfe schon erläutert, bewirkt ein Punkt in der Eingabe nämlich, dass der Suchbegriff von TC nicht mehr als sog. substring-search interpretiert wird, sondern eine formal-syntaktische Suche mit "Wildcards" (reservierten Joker-Zeichen), also eine sog. glob-search daraus wird.
Da ein Punkt in einer glob-search aber in aller Regel bedeutet, dass danach der Ausdruck für die "extension" folgt, ist es hier erst recht schwierig, nach einem "echten" Punkt zu suchen, der als reales ASCII/Unicode-Zeichen tatsächlicher Bestandteil des Dateinamens ist.
Lösung: gib folgenden String in die Suchmaske ein:
Code: Select all
*.*.?*So einfach der Punkt als Unterscheidung zwischen substring- und glob-search auch erscheinen mag, bringt er doch prinzipielle, unüberwindliche Einschränkungen mit sich.
Ich plädiere daher abermals dringend für zwei getrennte, alternative Suchmasken-Zeilen für den Namen - oder auch nur eine, die mit Auswahlkästchen explizit hin- und hergeschaltet werden kann, zwischen einer sauberen substring-search, in der ein Punkt auch wirklich einen Punkt als Textzeichen bedeutet - und einer reinen, formal-syntaktisch orientierten glob-search.
Diese Massnahme würde es auch beträchtlich vereinfachen, die von so vielen gewünschte Suche nach multiplen substrings, vielleicht sogar wahlweise verknüpft mit "und" bzw. "oder" und getrennter Eingabe eines substrings für die file-extension, sauber und frei von Einschränkungen zu implementieren.
*************** edit by algol *************
Und vielleicht ginge das ganze sogar noch als eigenständiger, von TC abgekoppelter (Hintergrund-) prozess. Doch falls Sie das aus Sicherheitsbedenken weiterhin ablehnen sollten, können wir auch in Zukunft ganz gut mit einer zweiten TC-Instanz für den Fall der Hintergrundsuche leben.
*************** gestrichen ***************
wurde soeben von HolgerK erinnert, dass dieser Wunsch mit <shift+Alt+F7> bereits realisiert ist.
Zuletzt wäre im Rahmen einer solchen Entflechtung der "Search for"-Suchmaske vielleicht noch zu überlegen, ob örtliche Einschränkungen der Suche, etwa in Verbindung mit dem "pipe"-character ("| _vti*\" bzw. "system32\", lt. Hilfe), nicht besser in der "Search in"-Suchmaske aufgehoben wären.
mfg
algol bereits realisiert ist.
Zuletzt wäre im Rahmen einer solchen Entflechtung der
Last edited by algol on 2015-02-26, 13:57 UTC, edited 4 times in total.
@HolgerK
Tja, Holger,
da spricht natürlich überhaupt nichts dagegen. Es ist mehr eine Frage des Ansatzes, will man überhaupt plugins (öfters) benutzen oder sollte das auch in der unmittelbaren "Primär"-Suchmaske möglich sein.
Als ich das seinerzeit über plugin probiert habe, bin ich bei dieser Alternative z.B. zunächst daran gescheitert, dass das Value-Feld so blass zu sehen war, dass es mir zunächst überhaupt entgangen ist und ich mich gefragt habe, ob man dazu jetzt wieder in die Hauptmaske zurückwechseln müsste, um dort nur den Punkt einzugeben, was natürlich nicht geklappt hat. Zugegeben, meine anfängliche Ungeschicklichkeit ist natürlich kein besonders starkes Argument.
Dennoch, ob man den konkreten Fall nun über plugin löst - oder über meinen Direkt-Suchstring (ich benutze meist den, weil es schneller ist, als auf die Plugin-Karteikarte zu wechseln und dort wieder eine mehrfache Auswahl treffen zu müssen), IMHO ändert das gar nichts an der grundsätzlichen Richtigkeit meines Vorschlags einer generellen Entkoppelung der beiden Suchverfahren (substring/glob).
Das wäre einfach die sauberere Lösung und liesse einige Einschränkungen (wie z.B. hier beim "Punkt") wegfallen bzw. könnte man dadurch, denke ich, auch die "multiple substring search" noch "mächtiger" gestalten/ausbauen. Auch könnte es die Suche für Durchschnittsbenutzer eventuell erleichtern, die mit einer glob-search überhaupt wenig anzufangen wissen und eher das look-and-feel neumodischer (IMHO Primitiv-) Suchmaschinen gewohnt sind.
Oder sähest Du durch diese Entkoppelung irgendwelche neuen Probleme bzw. prinzipielle Nachteile?
mfg
algol
Tja, Holger,
da spricht natürlich überhaupt nichts dagegen. Es ist mehr eine Frage des Ansatzes, will man überhaupt plugins (öfters) benutzen oder sollte das auch in der unmittelbaren "Primär"-Suchmaske möglich sein.
Als ich das seinerzeit über plugin probiert habe, bin ich bei dieser Alternative z.B. zunächst daran gescheitert, dass das Value-Feld so blass zu sehen war, dass es mir zunächst überhaupt entgangen ist und ich mich gefragt habe, ob man dazu jetzt wieder in die Hauptmaske zurückwechseln müsste, um dort nur den Punkt einzugeben, was natürlich nicht geklappt hat. Zugegeben, meine anfängliche Ungeschicklichkeit ist natürlich kein besonders starkes Argument.
Dennoch, ob man den konkreten Fall nun über plugin löst - oder über meinen Direkt-Suchstring (ich benutze meist den, weil es schneller ist, als auf die Plugin-Karteikarte zu wechseln und dort wieder eine mehrfache Auswahl treffen zu müssen), IMHO ändert das gar nichts an der grundsätzlichen Richtigkeit meines Vorschlags einer generellen Entkoppelung der beiden Suchverfahren (substring/glob).
Das wäre einfach die sauberere Lösung und liesse einige Einschränkungen (wie z.B. hier beim "Punkt") wegfallen bzw. könnte man dadurch, denke ich, auch die "multiple substring search" noch "mächtiger" gestalten/ausbauen. Auch könnte es die Suche für Durchschnittsbenutzer eventuell erleichtern, die mit einer glob-search überhaupt wenig anzufangen wissen und eher das look-and-feel neumodischer (IMHO Primitiv-) Suchmaschinen gewohnt sind.
Oder sähest Du durch diese Entkoppelung irgendwelche neuen Probleme bzw. prinzipielle Nachteile?
mfg
algol
Ich bin mir nicht sicher ob es wirklich nützlich ist die Suche weiter zu komplizieren ([x] Regex Suche nach: \..*\. wäre übrigens auch noch eine Alternative gewesen).
Die Hilfe lesen sowieso die wenigsten und mehr Schalter und Eingabefelder bedeuten nicht unbedingt das man schneller zum Ziel kommt.
Btw.
Gruss
Holger
Die Hilfe lesen sowieso die wenigsten und mehr Schalter und Eingabefelder bedeuten nicht unbedingt das man schneller zum Ziel kommt.
Btw.
Du meinst doch nicht etwa <Alt+Umschalt+F7> (cm_SearchStandalone)?Und vielleicht ginge das ganze sogar noch als eigenständiger, von TC abgekoppelter (Hintergrund-) prozess. Doch falls Sie das aus Sicherheitsbedenken weiterhin ablehnen sollten, können wir auch in Zukunft ganz gut mit einer zweiten TC-Instanz für den Fall der Hintergrundsuche leben.
Gruss
Holger
Wenn Du es als Komplikation siehst, dann ist es sicher nicht nützlich. Ich würde die von mir gewünschte Entflechtung aber doch eher als Vereinfachung betrachten, die es zudem gestattet, die dann gewählte Suchvariante noch effizienter zu gestalten. Wenn euch 2 getrennte Eingabezeilen für den Dateinamen stören sollten, dann tut es, wie gesagt, ja auch die eine bisherige, lediglich erweitert um eine einzige checkbox, die vorweg gestatten würde, vom "zeitgeistigen" default einer (möglichst mehrfachen) substring-search explizit auf eine syntaktische glob-search umzuschalten. Da haben frühere TC-Versionen beim Sprung auf die nächsthöhere wirklich schon mehr an Komplikationen gesehen, die jeweils mehr als aufgewogen wurden durch die damit verbundene Mehrleistung.HolgerK wrote:Ich bin mir nicht sicher ob es wirklich nützlich ist die Suche weiter zu komplizieren
Ich darf in dem Zusammenhang daran erinnern, wie mühsam es etwa früher im MRT war, Punkte - bis auf den einen vor der extension - in den Dateinamen zu ersetzen, bis dann auch dort die Entflechtung erfolgte, verbunden mit der vergleichsweise winzigen Komplikation einer zusätzlichen Checkbox für "E"(replace also in extensions).
Touché encore! Diese Option hatte ich schon wieder verdrängt, zum einen, weil sie relativ neu ist, zum anderen aber habe ich sie bisher kaum je benützt, weil es da doch, soweit ich erinnere, gewisse Komplikationen gab und man die Ergebnisse danach mit <shift>[Feed to listbox] nicht mehr in ein neues TC-Tab legen konnte, eine Option, auf die ich aber allergrössten Wert lege.HolgerK wrote:Du meinst doch nicht etwa <Alt+Umschalt+F7> (cm_SearchStandalone)?
Frage daher: funktioniert das inzwischen auch mit <Alt+Umschalt+F7> völlig klaglos? Falls ja, wäre ich äusserst erfreut das zu hören und würde natürlich diesen Teil meines "Erweiterungsvorschlags" zurückziehen, und zwar aus dem erfreulichsten aller Gründe, nämlich dem, dass mein Wunsch bereits Wirklichkeit geworden ist.
mfg
algol
2algol
Was für ein Glück, dass das nicht stimmt! Ich konnte auch in der history.txt nichts finden, was auf einen nachträglichen EInbau hindeutet. Also so wie es aussieht geht es seit 8.5 PB1 (27.08.2013).Diese Option hatte ich schon wieder verdrängt, zum einen, weil sie relativ neu ist, zum anderen aber habe ich sie bisher kaum je benützt, weil es da doch, soweit ich erinnere, gewisse Komplikationen gab und man die Ergebnisse danach mit <shift>[Feed to listbox] nicht mehr in ein neues TC-Tab legen konnte, eine Option, auf die ich aber allergrössten Wert lege.
Mir ist nicht ganz klar warum die Schnellsuche sowas kann, die normale Suche aber nicht. Absicht? Inkonsequenz? Spricht auf jeden Fall dafür das in der Suche noch nachzurüsten - gerne per simpler Checkbox wie hier vorgeschlagen...
@Giovanni: Wenn man den ungefähren Ort der Datei kennt und nicht List to Feedbox etc braucht: einfach Strg-B im Oberverzeichnis, Zeichen eintippen, in Echtzeit freuen
Das funktioniert wenn man unter Einstellungen - Schnellsuche 'Buchstaben - mit Suchen-Dialog' aktiviert, und in dem Eingabefeld dann noch auf das Symbol (Ctrl-S) klickt.
@Giovanni: Wenn man den ungefähren Ort der Datei kennt und nicht List to Feedbox etc braucht: einfach Strg-B im Oberverzeichnis, Zeichen eintippen, in Echtzeit freuen
Das funktioniert wenn man unter Einstellungen - Schnellsuche 'Buchstaben - mit Suchen-Dialog' aktiviert, und in dem Eingabefeld dann noch auf das Symbol (Ctrl-S) klickt.
2algol
Grundsätzlich finde ich die Suche viel zu kompliziert. Auf jeden Fall sollte ein globales Suchfeld alles finden, was zu den Nutzereingaben passt - also extrem gierig sein, Substrings erkennen (man kann auch über Fehlertoleranz nachdenken). Der Nutzer sollte darüber die Möglichkeit haben an Einschränkungen in dieses oder andere Felder einzutragen. Auf Basis dieses Grundprinzips kann man über alles reden.
Aber damit sowas halbwegs nutzbar ist, brauch man einen Index und dem sind ja doch viele Nutzer abgeneigt gegenüber, selbst wenn es ein Scheduled Task ist, der nachts um 4 durchläuft.
Grundsätzlich finde ich die Suche viel zu kompliziert. Auf jeden Fall sollte ein globales Suchfeld alles finden, was zu den Nutzereingaben passt - also extrem gierig sein, Substrings erkennen (man kann auch über Fehlertoleranz nachdenken). Der Nutzer sollte darüber die Möglichkeit haben an Einschränkungen in dieses oder andere Felder einzutragen. Auf Basis dieses Grundprinzips kann man über alles reden.
Aber damit sowas halbwegs nutzbar ist, brauch man einen Index und dem sind ja doch viele Nutzer abgeneigt gegenüber, selbst wenn es ein Scheduled Task ist, der nachts um 4 durchläuft.
Unter diesen Indexierungs-abgeneigten "Reaktionären" stehe ich sogar an vorderster Front, wie einige vielleicht sogar noch wissen.Lefteous wrote:Aber damit sowas halbwegs nutzbar ist, brauch man einen Index und dem sind ja doch viele Nutzer abgeneigt gegenüber, selbst wenn es ein Scheduled Task ist, der nachts um 4 durchläuft.
Der nunmehr von mir diskutierte Vorschlag einer "Entflechtung" der Eingabemaske je nach Such-Typus liesse bezüglich (nicht-) Indexierung alles beim alten und sollte lediglich die möglichen Suchkriterien erweitern bzw. deren eindeutige Eingabe vereinfachen.
Bedeutet Deine Antwort daher, dass Du ohne Indexierung und komplette Umgestaltung der Suche die von mir vorgeschlagene, vergleichsweise kleine Korrektur für wenig sinnvoll erachtest?
mfg
algol
2algol
Ich wollte nur anmerken, dass das für mich nur eine Teillösung wäre. Es gibt die Suche nach Namen, nach Inhalten bei Plaintextdateien, Erweitert, nach Metadaten über Plugins und nach Inhalten über Plugins. Das ist einfach so unübersichtlich, dass man schon mal fragen darf, ob es nicht einfacher ginge.
Grundsätzlich ist jede Vereinfachung begrüßenswert, auch wenn ein solcher Schritt nicht alle Probleme löst.
Ich weiß das natürlich noch.Unter diesen Indexierungs-abgeneigten "Reaktionären" stehe ich sogar an vorderster Front, wie einige vielleicht sogar noch wissen.
Nein, es wäre sicherlich ein Fortschritt ein Suchfeld zu haben, bei dem man z.B. durch Hinschreiben mehrerer Begriffe alle Dateien, die diese Begriffe enthalten, finden kann.Bedeutet Deine Antwort daher, dass Du ohne Indexierung und komplette Umgestaltung der Suche die von mir vorgeschlagene, vergleichsweise kleine Korrektur für wenig sinnvoll erachtest?
Ich wollte nur anmerken, dass das für mich nur eine Teillösung wäre. Es gibt die Suche nach Namen, nach Inhalten bei Plaintextdateien, Erweitert, nach Metadaten über Plugins und nach Inhalten über Plugins. Das ist einfach so unübersichtlich, dass man schon mal fragen darf, ob es nicht einfacher ginge.
Grundsätzlich ist jede Vereinfachung begrüßenswert, auch wenn ein solcher Schritt nicht alle Probleme löst.