Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

  • »MaddinW« ist der Autor dieses Themas

Beiträge: 20

Registrierungsdatum: 21.08.2011

Derivat: Ubuntu

Architektur: 32-Bit PC

Desktop: GNOME 2.x

  • Nachricht senden

1

08.10.2011, 16:10

ls [g-w]

Liebe Ubuntugemeinde,

ich habe eine furchtbar noobische Frage zum Terminal. Ich möchte aus Übungszwecken alle Dateien eines Verzeichnisses anzeigen lassen, welche mit dem Buchstaben g,h,i...w beginnen. Nun habe ich mir Zusammengesucht, dass ich dazu die Eingrenzungsparameter mithilfe eckiger Klammern angeben kann. Aber der Aufruf "ls [g-w]" bringt mir nur die Fehlermeldung, das Vezeichnis sei nicht gefunden worden. Der Aufruf "ls . [g-w]" zeigt mir jedoch alle Dateien des Verzeichnisses an. Was kann man da machen?

2

08.10.2011, 19:11

vielleicht so

ls [gw]* wenn du dich in dem Verzeichnis befindest.

Ansonsten den Pfad angeben wie z.b

ls /home/dein Benutzername/Bilder/[abc]*

So werden dir z.b in deinem Homeverzeichniss die Bilder von a-c angezeigt

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Jeff« (08.10.2011, 19:29)


  • »MaddinW« ist der Autor dieses Themas

Beiträge: 20

Registrierungsdatum: 21.08.2011

Derivat: Ubuntu

Architektur: 32-Bit PC

Desktop: GNOME 2.x

  • Nachricht senden

3

08.10.2011, 19:34

Hm...das hat schon etwas gebracht; es wird kein Fehler mehr angezeigt, aber ich erhalte Trotzdem noch Einträge die mit a anfangen...unter anderem.

4

08.10.2011, 19:53

ja?
Dann zeig mal ein Beispiel

Also wenn ich mir zb die Bilder in meinem Homeverzeichniss von [d-g]* anzeigen lassen will, dann wird dort ausser d-g nichts anderes angezeigt.

Aber hier drin gibts auch noch Leute die davon viel mehr ahnung haben :thumbsup:

  • »MaddinW« ist der Autor dieses Themas

Beiträge: 20

Registrierungsdatum: 21.08.2011

Derivat: Ubuntu

Architektur: 32-Bit PC

Desktop: GNOME 2.x

  • Nachricht senden

5

08.10.2011, 20:22

Bitte schön:
»MaddinW« hat folgende Bilder angehängt:
  • ls.png
  • wg.png

6

08.10.2011, 20:33

ich erhalte Trotzdem noch Einträge die mit a anfangen
Die liegen dann aber in Verzeichnissen, die ihrerseits mit [g-w] anfangen. Probier einmal

Quellcode

1
ls -d [g-w]*

--
Sag ich ja: websites/...
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

  • »MaddinW« ist der Autor dieses Themas

Beiträge: 20

Registrierungsdatum: 21.08.2011

Derivat: Ubuntu

Architektur: 32-Bit PC

Desktop: GNOME 2.x

  • Nachricht senden

7

08.10.2011, 20:54

Ich verstehe. Danke schön für deine Hilfe.

wowi

Ubuntu-Forum-Team

  • »wowi« ist männlich

Beiträge: 4 264

Registrierungsdatum: 03.05.2007

Derivat: Xubuntu

Architektur: 64-Bit PC

Desktop: XFCE

  • Nachricht senden

8

09.10.2011, 01:04

Hi MaddinW,

leider hat der ls-Befehl mMn einige böse Bugs (oder Ungereimtheiten) in Verbindung mit Such-Patterns, speziell in Bezug auf Klein-Großschreibung von Dateinamen. Wenn ich z.B. ein Verzeichnis habe mit 3 Dateien darin namens a.txt, A.txt und B.txt, dann ergeben folgende Befehle teilweise unerwartete Ergebnisse:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
usera@pc:~/test$ ls -l
insgesamt 0
-rw-r--r-- 1 u u 0 2011-10-09 00:13 a.txt
-rw-r--r-- 1 u u 0 2011-10-09 00:14 A.txt
-rw-r--r-- 1 u u 0 2011-10-09 00:14 B.txt
usera@pc:~/test$ ls a*
a.txt
usera@pc:~/test$ ls A*
A.txt
usera@pc:~/test$ ls [A]*
A.txt
usera@pc:~/test$ ls [a]*
a.txt
usera@pc:~/test$ ls [b]*
ls: Zugriff auf [b]* nicht möglich: Datei oder Verzeichnis nicht gefunden
usera@pc:~/test$ ls [B]*
B.txt
usera@pc:~/test$ ls [a-b]*
a.txt  A.txt
usera@pc:~/test$ ls [a-B]*
a.txt  A.txt  B.txt
usera@pc:~/test$ ls [A-B]*
A.txt  B.txt
usera@pc:~/test$ cp B.txt b.txt
wolfi@wolfispc:~/test$ ls
a.txt  A.txt  b.txt  B.txt  c.txt
usera@pc:~/test$ ls [a-B]*
a.txt  A.txt  b.txt  B.txt
usera@pc:~/test$ ls [A-B]*
A.txt  b.txt  B.txt
usera@pc:~/test$  

Warum liefert Zeile 18 auch A.txt !?!
Zeile 20 könnte ich noch nachvollziehen, wenn eben nicht Zeile 18 so seltsam reagieren würde.
Zeile 27 könnte ich ebenfalls nachvollziehen, wenn nicht Zeile 29 auch b.txt, aber nicht a.txt liefern würde ... :huh:

Greetz
wowi

9

09.10.2011, 09:27

Ich finde das auch irgendwie verwirrend.

Aber wenn man dann mal in seinen Ordner reinschaut, wo man die Beispiel .txt angelegt hat, wird es einem schon klarer.

Allerdings vermisse ich dann in deiner Zeile 20 das kleine b.txt :S

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Jeff« (09.10.2011, 09:33)


10

09.10.2011, 14:57

Warum liefert Zeile 18 auch A.txt
Wie Jeff schon angedeutet hat: Es liegt an der Sortierung. Du siehst es an Deinen ersten drei Zeilen und dann in Zeile 26: aAbBcC... An einer längeren Kette sieht man das noch schöner.
So gesehen ist eigentlich klar: [a-b] umfasst a und A, aber nicht B. b gibt's noch nicht. Anders hier:
Zeile 27 könnte ich ebenfalls nachvollziehen, wenn nicht Zeile 29 auch b.txt, aber nicht a.txt liefern würde
[A-B] beginnt erst bei A und ignoriert daher das a, aber b und B sind enthalten. [a-B] liefert sie dann auch alle.

Allerdings vermisse ich dann in deiner Zeile 20 das kleine b.txt
Das hat wowi auch erst in Zeile 24 erzeugt. ;)
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

wowi

Ubuntu-Forum-Team

  • »wowi« ist männlich

Beiträge: 4 264

Registrierungsdatum: 03.05.2007

Derivat: Xubuntu

Architektur: 64-Bit PC

Desktop: XFCE

  • Nachricht senden

11

09.10.2011, 17:55

Hm Fredl, nach Deiner Erklärung wird es mir prinzipiell auch klar :D

Nur eine Frage: Wo findet man denn die Regeln, die beim Sortieren gelten? Ich habe diverse Manuals durchgeschaut, den Kofler und diverse Ubuntu-Handbücher bemüht, aber dazu nirgends etwas gefunden. Und von (DOS/Windows-)Zeichensätzen her gewohnt, bin ich natürlich automatisch davon ausgegangen, dass z.B. [A-Z] nur Großbuchstaben, bzw. [a-z] nur Kleinbuchstaben bedeuten würde. Im Buch "Reguläre Ausdrücke kurz&gut" von O' Reilly steht auch schon auf Seite 14 "Zum Beispiel erkennt [a-z] jeden kleingeschriebenen ASCII-Buchstaben". Ist das bei RegExp also anders, oder im Buch falsch ?(

12

11.10.2011, 00:41

Mit RegExp hat es hier eigentlich nur am Rande zu tun (wenn überhaupt). Was Dein Beispiel hier aufzeigt ist die "Pathname Expansion" der Bash. Denn Du übergibst hier Dateipfade als Parameter an 'ls'. Dazu ein Auszug aus man bash:

Zitat

Note that when using range expressions like [a-z] (see below), letters of the other case may be included, depending on the setting of LC_COLLATE.

[...] Matches any one of the enclosed characters. A pair of characters separated by a hyphen denotes a range expression; any
character that sorts between those two characters, inclusive, using the current locale's collating sequence and character
set, is matched. If the first character following the [ is a ! or a ^ then any character not enclosed is matched. The
sorting order of characters in range expressions is determined by the current locale and the value of the LC_COLLATE
shell variable, if set.

Allerdings hab ich keinen Wert für LC_COLLATE gefunden, bei dem Groß/Klein nicht gemischt rausgekommen wäre - höchstens in anderer Reihenfolge.

Mit der Dash zum Beispiel würde Dein Versuch überhaupt fehlschlagen, weil die das so nicht kennt. Am Ende ist es aber jedenfalls kein Bug in "ls", denn das kann nix dafür, was ihm die Bash da übergibt - es listet das dann nur auf ;)

Recht einfach herausfinden, was die Bash mit solchen Konstrukten anfangen wird, kann man übrigens immer mit der "Trockenübung" echo. ZB:

Quellcode

1
echo ls -l [A-Z].txt
Sagt dir sofort, was "ls" im Ernstfall zu Speisen bekommen würde :)
Das geht mit fast allen anderen Kommandos genauso zum Antesten vor dem Ernstfall.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

wowi

Ubuntu-Forum-Team

  • »wowi« ist männlich

Beiträge: 4 264

Registrierungsdatum: 03.05.2007

Derivat: Xubuntu

Architektur: 64-Bit PC

Desktop: XFCE

  • Nachricht senden

13

12.10.2011, 00:14

Mit RegExp hat es hier eigentlich nur am Rande zu tun (wenn überhaupt).

Im Buch "Reguläre Ausdrücke kurz&gut" von O' Reilly steht auch schon auf Seite 14 "Zum Beispiel erkennt [a-z] jeden kleingeschriebenen ASCII-Buchstaben". Ist das bei RegExp also anders, oder im Buch falsch
Ich habe es natürlich auch mal ausprobiert: grep macht es bei Verwendung von RegExp genauso (für mich "falsch") wie die Bash. Somit steht es als mMn also verkehrt im Buch :P Könnte es nicht sein, dass die Bash hier auf die gleichen Routinen zurückgreift?


Recht einfach herausfinden, was die Bash mit solchen Konstrukten anfangen wird, kann man übrigens immer mit der "Trockenübung" echo. ZB:

Quellcode

1
echo ls -l [A-Z].txt


Sagt dir sofort, was "ls" im Ernstfall zu Speisen bekommen würde
Da wird bei mir aber immer nur das Geschriebene ausgegeben? Meintest Du das wirklich so ?(

  • »floogy« ist männlich

Beiträge: 3 071

Registrierungsdatum: 10.03.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

Andere Betriebssysteme: debian

  • Nachricht senden

14

12.10.2011, 00:42

Da fehlt der Asterix.

Nun, Ich kann da schon Unterschiede ausmachen:

Zitat

flvstreamer$ ls -1 |grep --color "[e-tA-Z]*\.c"
amf.c
flvstreamer.c
log.c
parseurl.c
rtmp.c
rtmpsrv.c
rtmpsuck.c
streams.c
thread.c


Quellcode

1
2
flvstreamer$ echo  ls [e-tA-Z]*\.c
ls flvstreamer.c log.c parseurl.c rtmp.c rtmpsrv.c rtmpsuck.c streams.c thread.c

15

12.10.2011, 00:43

Könnte es nicht sein, dass die Bash hier auf die gleichen Routinen zurückgreift?
Jetzt kommt gleich was Kompetentes zu RegExp&Co: Sehe gerade, daß floogy auch da ist. ;)
(Edit: Schon passiert...)

Da wird bei mir aber immer nur das Geschriebene ausgegeben? Meintest Du das wirklich so
Ja, Trockenübung eben. Du siehst dann das Kommando so, wie es tatsächlich aussehen wird, nachdem die Bash ihre ganze Magie hat wirken lassen.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

  • »floogy« ist männlich

Beiträge: 3 071

Registrierungsdatum: 10.03.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

Andere Betriebssysteme: debian

  • Nachricht senden

16

12.10.2011, 00:52

Das klappt aber nur wenn der Asterix nicht fehlt, bzw. wenn ein anderer Mengenausdruck folgt (?+{1,2} z.B.).

Aber:

Zitat

Ranges are very collating-sequence-dependent, and portable programs should avoid relying on them.

Quellcode

1
man 7 regex

17

12.10.2011, 01:03

Eindrucksvoll :) Was soll das --color jetzt anzeigen? Die Treffer, die zur Ausgabe führen? In meiner man-page steht das komischerweise nicht.
Aber Du hast ja nichts mit Großbuchstaben, und darum ging es wowi ja. Ich habe Dateien mit solchen im Verzeichnis und die kommen auch bei [a-z] mit raus. Insofern stimme ich wowi derzeit noch zu.
Edit: Bezüglich des gemischten Ergebnisses stimme ich ihm zu, daß es etwas verwunderlich ist. Daß es mit LC_COLLATE zu tun hat, hab ich ja auch schon erwähnt. Aber welche collation würde man brauchen, die wowi's Zitat aus dem Buch bestätigt? Ich hab keine gefunden.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

  • »floogy« ist männlich

Beiträge: 3 071

Registrierungsdatum: 10.03.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

Andere Betriebssysteme: debian

  • Nachricht senden

18

12.10.2011, 01:24

Das --color zeigt, was gerade matcht. Ich finde das hilfreich. Der Asterix fehlt, und daher wundert sich wowie, dass echo nur den Befehl eins zu eins wiedergibt, wie er eingetippt wurde. Ich bleibe aber auch dabei, dass die Bash-Expansion etwas anders funktioniert als egrep.

LC_COLLATE betrifft wohl nur die Sortierreihenfolge?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »floogy« (12.10.2011, 01:26)


fremdkoerperfalle

Gesperrter Benutzer

  • »fremdkoerperfalle« wurde gesperrt

Beiträge: 535

Registrierungsdatum: 15.10.2014

Derivat: unbekannt

Architektur: unbekannt

Desktop: unbekannt

Andere Betriebssysteme: Debian Jessie, Android-x86 Vbox

  • Nachricht senden

19

12.10.2011, 01:26

Kleine Zwischenfrage an floogy bzgl. dem Beispiel des o.g. Mengenausdruck. Darf man das so machen?

In deinem Atom schreibst Du vor dem bound ?+. Imo bedeutet das 0 oder 1 verbunden mit 1 oder mehr Übereinstimmungen. Das würde doch von * abgedeckt werden, oder nicht? ?(

  • »floogy« ist männlich

Beiträge: 3 071

Registrierungsdatum: 10.03.2005

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: GNOME 3.0

Andere Betriebssysteme: debian

  • Nachricht senden

20

12.10.2011, 01:36

Nein, ich meinte nach einem RE, kann [RE]* der Asterix folgen, oder ?, oder +, oder {1,2}. Das war kein Ausdruck sondern eine Anmerkung in Klammern ;)

Das was die bash macht ist globbing und man muss aufpassen, dass das Globbing durch Expansion nicht auch bei grep eine Rolle spielt, denke ich.

http://tldp.org/LDP/abs/html/abs-guide.html#GLOBBINGREF

Zitat

Bash itself cannot recognize Regular Expressions. Inside scripts, it is commands and utilities -- such as sed and awk -- that interpret RE's.

Bash does carry out filename expansion [97] -- a process known as globbing -- but this does not use the standard RE set. Instead, globbing recognizes and expands wild cards. Globbing interprets the standard wild card characters [98] -- * and ?, character lists in square brackets, and certain other special characters (such as ^ for negating the sense of a match). There are important limitations on wild card characters in globbing, however. Strings containing * will not match filenames that start with a dot, as, for example, .bashrc. [99] Likewise, the ? has a different meaning in globbing than as part of an RE.