J'ai un répertoire dans lequel j'aimerais lister tout le contenu (fichiers et sous répertoires) sans afficher les liens symboliques. J'utilise des utilitaires GNU sous Linux. La ls
version est 8.13.
Exemple:
Liste complète des répertoires:
~/test$ ls -Gg
total 12
drwxrwxr-x 2 4096 Jul 9 10:29 dir1
drwxrwxr-x 2 4096 Jul 9 10:29 dir2
drwxrwxr-x 2 4096 Jul 9 10:29 dir3
-rw-rw-r-- 1 0 Jul 9 10:29 file1
-rw-rw-r-- 1 0 Jul 9 10:29 file2
lrwxrwxrwx 1 5 Jul 9 10:29 link1 -> link1
lrwxrwxrwx 1 5 Jul 9 10:30 link2 -> link2
Ce que j'aimerais obtenir
~/test$ ls -somthing (or bash hack)
total 12
dir1 dir2 dir3 file1 file2
NOTE: Ma principale motivation est de faire un grep récursif (GNU grep 2.10) sans suivre les liens symboliques.
grep
(voir dernier paragraphe).grep -H
, si vous l'avez (voirman grep
), ou autrementgrep 'pat' '{}' /dev/null ';'
pour le faire croire qu'il existe plusieurs fichiers si vous ne l'avez pas.+
ne répond pas à cette exigence dans le cas dégénéré où il ne reste qu'un seul fichier ou un seul fichier à la fin.Ou, plus simple:
Explication
ls -l
signifie lister sous forme longue . Lorsque vous faites cela, la première chaîne de caractères donne des informations sur chaque fichier. Le premier caractère indique le type de chaque fichier. S'il s'agit d'un lien symbolique, anl
est le premier caractère.grep -v ^l
signifie filtrer (-v
) les lignes commençant par (^
) anl
.la source
for i in
-l
dansls
. Donc, cela ne fonctionnerait pas comme prévu:ls | grep -v ^l
find
, voir unix.stackexchange.com/questions/321697À partir de la version 2.12, l'
-r
option pour GNU grep ne déréférence pas les liens symboliques, sauf si vous les spécifiez à la main:la source
-R, -r, --recursive Read all files under each directory, recursively; this is equivalent to the -d recurse option.
en 2.10En zsh, ce serait facile grâce aux qualificatifs glob :
Le modèle
**/
parcourt les sous-répertoires récursivement. Le qualificatif glob.
restreint la correspondance aux fichiers standard.Sans zsh, utilisez
find
(voir la réponse de Michael Horner ). Et dans ce cas particulier, GNU grep peut faire ce que vous voulez (c'est exactement ce quigrep -r
fait) - mais seulement depuis la version 2.12, les versions antérieures suivaient des liens symboliques.la source
Vous pouvez utiliser
$LS_COLORS
pour ce faire. Si votre version dels
prend en charge la spécification des couleurs à l'aide de cette variable, vous pouvez définir la sortie par type de fichier. C'est un comportement intégré et très configurable. J'ai donc créé quelques fichiers pour faire une démonstration comme ceci:Alors maintenant je vais faire:
Et les nuls sont là aussi ...
Vous pouvez spécifier pour tout ou partie des types de fichiers. Le faire pour un seul type de fichier peut ne pas vous donner envie, car il
ls
a incorporé certaines valeurs de compilation par défaut pour les échappements de terminal. Vous feriez beaucoup mieux d'adresser l'API comme une interface unique. Voici un petit moyen simple d'analyser et d'attribuer lesdircolors
paramètres par défaut de l' environnement actuel :Sa sortie dans mon répertoire personnel ressemble à ceci:
Vous pouvez également exécuter cela avec
cat -A
et la seule différence que vous rencontrerez est que vous verrez$
pour les nouvelles lignes - il n'y a pas de caractères non imprimables introduits parls --color=always
avec cette configuration - seulement ce que vous voyez ici.ls
insère ses sorties de terminal par défaut comme ceci:... où les valeurs par défaut pour
$lc
(à gauche du code) ,$rc
(à droite du code) et$rs
(réinitialiser) sont:...respectivement.
${type_code}
est utilisé pour remplacer les diversfi
(fichier normal - non défini par défaut) ,di
(répertoire) ,ln
(lien) et tous les autres types de fichiers que je connais. Il y a aussi$no
(normal) qui est aussi par défaut non défini et qui est ici représenté par//
le début de chaque ligne. Mon petitIFS=:
bloc simple fonctionne simplement en insérant le nom de chaque configurable en tant que sa propre valeur et en ajoutant une barre oblique ou deux - bien que les\0
octets NUL feraient aussi bien.Par défaut, une autre
ls
sera$rs
immédiatement insérée immédiatement avant sa première sortie$lc
, mais elle n'est pas représentée avec précision ici. Dans ce cas, j'ai spécifié$ec
(code de fin) qui remplace dans$rs
tous les cas - lorsqu'il est spécifié, vous n'obtenez pas de supplément$rs
entre$no
et${type_code}
comme vous le feriez autrement - il ne présente que immédiatement après un nom de fichier et une fois au début de la sortie - comme vous pouvez le voir dans la barre oblique supplémentaire en tête de la première ligne.Voici un extrait du mien
$LS_COLORS
Et, en vérité, mon petit hack shell est probablement trop compliqué - il existe une interface largement disponible pour attribuer ces valeurs. Essayez
dircolors -p
dans votre cli etinfo dircolors
pour plus d'informations à ce sujet.Vous pouvez encapsuler les noms de fichiers dans des chaînes arbitraires. Vous pouvez les commenter si vous le souhaitez. Vous pouvez spécifier des comportements similaires basés uniquement sur l'extension de fichier. Il n'y a vraiment pas beaucoup de choses que vous ne pouvez pas spécifier de cette façon.
Maintenant, je n'invente pas tout cela non plus - je l'ai appris après être tombé sur le code source par accident.
Avec cette configuration particulière
ls
émettra:$no
- une fois par enregistrement au début de chaque enregistrement${type_code}
- une fois immédiatement avant chaque nom de fichier pour inclure une abréviation du type du fichier et toujours sur la même ligne que et 7 champs délimités par des espaces après$no
ou immédiatement après une->
dénotation de cible d'un lien symbolique.$ec
- une fois immédiatement avant la toute première ligne et ensuite une seule fois immédiatement après chaque nom de fichier.Toutes les autres valeurs sont vides.
Ce qui suit est un nombre nul
ls
, et cette fois je vais utilisercat -A
, mais sans lui, il ressemblerait au dernier exemple:Et donc pour supprimer de manière fiable tous les liens symboliques d'un
-l
liste ong comme celle-ci, vous pouvez apporter une modification simple:Mes résultats après la course ressemblent à ...
En utilisant une commande comme celle que je fais ci-dessus:
... (où
fc1
etfc2
sont les types de fichiers répertoriés aprèsset --
dans le sous-shell) devrait servir à supprimer de manière fiable toutes les combinaisons de types de fichiers que vous pourriez souhaiter de lals
sortie, quels que soient les caractères que les noms de fichiers peuvent contenir.la source
lc
,nc
, etc sont?ls
ladi=
valeur de. Vous auriez besoin d'ajouterdi=:
à la var pour annuler cela - et pour tous les autres. C'est ce que je veux dire par l'API - vous vous adressez à chaque type de fichier mais vous devez adresser la même interface dans tous les cas. Donc, définirln
un sens et ignorer lesdi
valeurs par défaut ne fonctionnera pas. Il y a aussi beaucoup de valeurs par défaut compilées ... Hmm. Votre question surlc
etnc
et les choses sont valables - complètement - je l'ai déjà fait l'autre jour. Je vais le lier, je pense.dircolors
. Il lit un fichier de configuration et génère uneeval
valeur var adaptée au shell . C'est assez facile - mais les quelques lignes sont aussi là-haut. Quoi qu'il en soit, si vous souhaitez l'utiliser,dircolors
enregistrez simplement deux fichiers différents et invoquez-le de cette façon. De plus, je vous ai montré l'autre jour comment faire les deux à la fois avec des\0
délimiteurs NUL dans le cadre de chaque séquence d'échappement.LS_COLORS='rs=:no=\0//:lc=:rc=:ec=\0//:'$( set -- di fi ln mh pi so do bd cd or su sg ca tw ow st ex; for fc do printf %s "$fc=/$fc//\0:"; done) ls -l --color=always | cat -A
La réponse ci-dessus conduit à ce qui suit:
Curieusement, le fait de laisser le 1 hors de la commande ls donne toujours une liste.
la source
grep -i
? Ce n'est pas comme si elle/
pouvait être en majuscules ou en minuscules.ls
par défaut au format noe-column lorsque la sortie n'est pas un terminal (c'est un pipe ici).Essaye celui-là:
la source
a -> b
. Il échouera également sur les noms de fichiers avec des sauts de ligne et d'autres étrangetés. Veuillez lire ceci pour savoir pourquoi analyser ls est une mauvaise idée.ls
est aliaséls -l
, et cela renvoie des colonnes avant le nom du fichier, soit il ne l'est pas, et cela n'a rien de spécial à propos des liens symboliques.ls
. nous analysonsls
tous chaque fois que nous imprimons sur un terminal - il y a un api . J'ai posté une réponse démontrant quelque chose comme ça ici - mais vous pouvez faire beaucoup plus. Je vous ai montré l'autre jour - vous aviez vous-même des noms de fichiers délimités par des valeurs nulles.ls
ne va pas manger vos enfants ou quoi que ce soit - c'est seulement un programme. Si vous ne l'expliquez pas, il faudra plusieurs centaines pour l'expliquer et plusieurs centaines de plus pour expliquer pourquoi les plusieurs centaines de lignes que vous venez de relier sont fausses. Et en plus - ce ne sont que deux lignes:LS_COLORS='lc=:rc=:ec=:ln=\n\n\0HERE_THERE_BE_A_LINK>>\0:' \ ls -1 --color=always | cat
Essayez cette commande:
ls -p | grep -v @
la source
find -type f
-p
ajoute simplement une barre oblique aux répertoires, vous recherchez-F
ii) votrefind
alternative ne listera pas les répertoires et iii) Veuillez tester vos réponses avant de poster.