Sans chercher à exploiter toutes les fonctionnalités qu’il propose, certaines facilités me sont maintenant indispensables lorsque je passe à bash. Une seule en fait : le ** qui se substitue à n’importe quel dossier ou sous-dossier. Un globbing puissant qui permet de s’affranchir de find.

# liste tous les fichiers, equivalent de find .
ls **/*
# recherche la chaine 'foo' dans tous les fichiers java
grep foo **/*.java
# recherche la chaine 'bar' dans tous les fichiers java qui ont pour
# repertoire parent le dossier src
grep foo **/src/**/*.java

De plus, on peut ajouter des options de recherche

# tous les fichiers contenant le nom 'dupont' en Ignorant la casse
# correspond à dupond, DUPOND, Dupond, DuPOnD, mais pas Durand
ls (#i)dupont
# liste uniquement les fichiers
ls **/*(.)
# liste uniquement les dossiers
ls -d **/*(/)
# liste tous les dossiers pleins (Full)
ls -d **/*(F)
# liste tous les dossiers vides (not Full)
ls -d **/*(^F)

Il existe beaucoup d’autres possibilités, mais juste ces quelques commandes m’ont permis de m’affranchir du sempiternel find . -type f -iname "*dupont*" | xargs svn revert.

L’autre truc bien de zsh, évidemment, c’est l’aide à la complétion de commande. Il est remarquable dans bien des cas, notamment

• tâches ant : $ ant <TAB> => liste les tâches ant disponibles
• arguments ant : $ ant --n<TAB> => liste les options de ant commençant par –n
• adresses svn : $ svn checkout http://some.svn.server/svn/trunk/src/<TAB> => liste les fichiers disponibles

Bref ça vaut le coup d’essayer. Pour mettre un pied à l’étrier (et me servir d’aide mémoire), voici le .zshrc que j’utilise. Il n’a rien d’exceptionnel, même le prompt est des plus basiques.

# Lines configured by zsh-newuser-install
HISTFILE=~/.histfile
HISTSIZE=1000
SAVEHIST=1000
setopt appendhistory autocd extendedglob nomatch notify
unsetopt beep
bindkey -e
# End of lines configured by zsh-newuser-install
# The following lines were added by compinstall
zstyle :compinstall filename '/home/cbliard/.zshrc'

autoload -Uz compinit
compinit
# End of lines added by compinstall

# Add ~/bin directory to PATH if possible
[ -d $HOME/bin ] && export PATH=$PATH:$HOME/bin

# colors
eval "`dircolors -b`"
alias ls='ls --color=auto'

function l() {
	clear; pwd; echo; ls -lh $*; echo
}

# Set up aliases
alias mv='nocorrect mv'       # no spelling correction on mv
alias cp='nocorrect cp'       # no spelling correction on cp
alias mkdir='nocorrect mkdir' # no spelling correction on mkdir
alias grep='egrep --exclude-dir=\.svn --color=auto'
alias ll='ls -l'
alias la='ls -a'
alias less='less -i'
alias diff='diff -u -x .svn'

# Less verbose ant
alias ant='ant -logger org.apache.tools.ant.NoBannerLogger'

# List only directories and symbolic
# links that point to directories
alias lsd='ls -ld *(-/DN)'

# List only file beginning with "."
alias lsa='ls -ld .*'

# Simple bold prompt
PROMPT="%{%B%}%n@%m:%~%{%b%}%# "

# select words as in bash (for Meta-backspace and Meta-d)
autoload -U select-word-style
select-word-style bash

$ sudo gems install rails -y

Oui mais voilà, Netbeans n’utilise pas sudo. Pour que Netbeans puisse gérer les gemmes lui-même, il lui faut donc les droits d’écriture sur le dossier /var/lib/gems et ses sous-répertoires. Le plus naïf est de donner tous les droits en écriture, mais c’est mal ! Sinon, on peut aussi créer un groupe nommé rubygems et donner le droit d’écriture à ce groupe. Cette approche est meilleure mais un problème se pose lorsque l’utilisateur y crée un nouveau fichier ou dossier : non seulement celui-ci appartient à l’utilisateur et non pas à root, mais en plus le groupe n’a pas le droit d’écriture. C’est là qu’interviennent les ACLs…

Démonstration avec l’utilisateur foo.

On crée un groupe ruby gems et on s’y ajoute

$ sudo addgroup rubygems
$ sudo adduser foo rubygems

On se déconnecte puis reconnecte pour prendre en compte le nouveau groupe, puis on vérifie les permissions

$ sudo mkdir /test
$ sudo chgrp rubygems /test
$ sudo chmod g+w /test
$ ls -ld /test
drwxrwxr-x 2 root rubygems 4096 2008-12-03 22:16 /test
$ touch /test/bar
$ ls -l /test/bar
-rw-r--r-- 1 foo foo 0 2008-12-03 22:21 /test/bar

Ce n’est pas bon du tout. On préférerait avoir quelque chose comme -rw-rw-r-- 1 foo rubygems afin que les autres membres du groupe rubygems puissent eux aussi modifier ce fichier. De manière plus générale, on veut que :

• le groupe soit rubygems ;
• les permissions du groupe soient rwx pour un dossier et rw- pour un fichier ;
• et que les permissions des autres soient r-x pour un dossier et r– pour un fichier.

La partie qui va suivre est issu des connaissances acquises grâce à l’article Group sharing a directory.

Attribuer le groupe automatiquement

Il est simple d’affecter le groupe rubygems automatiquement à chaque nouveau dossier créé dès qu’on connait l’astuce : il suffit de lever le bit ’set groupid’ du groupe du dossier pour que tout nouveau fichier ou dossier créé appartienne au groupe du dossier parent plutôt qu’au groupe de l’utilisateur

$ sudo chmod g+s /test
$ ls -ld /test
drwxrwsr-x 2 root rubygems 4096 2008-12-05 07:54 /test
$ touch f
$ mkdir /test/d
$ ls -l /test
total 4
drwxr-sr-x 2 foo rubygems 4096 2008-12-05 07:59 d
-rw-r--r-- 1 foo rubygems    0 2008-12-05 07:59 f
$ cd /test/d
$ touch bar
$ ls -l
-rw-r--r-- 1 foo rubygems 0 2008-12-05 08:00 bar

Permettre l’écriture au groupe automatiquement

Cette solution fait usage des ACLs. La commande

$ sudo setfacl -m default:user::rwx,default:group::rwx,default:mask:rwx,default:other:r-x /test

permet de définir les permissions par défaut pour les futurs fichiers du dossier /test. La commande est longue et peut être abrégée en

$ sudo setfacl -m d:u::rwx,d:g::rwx,d:m:rwx,d:o:r-x /test

Si la commande setfacl ne fonctionne pas, c’est parce que l’option acl n’est pas active pour votre volume. Assurez-vous d’avoir une ligne qui ressemble contienne l’option acl dans votre /etc/fstab :

/dev/hda2 / ext3 defaults,acl 0 1

Ensuite remontez votre volume pour prendre en compte les modifications

sudo mount / -o remount

Observons maintenant d’un peu plus près la définition d’ACLs

$ sudo setfacl -m d:u::rwx,d:g::rwx,d:m:rwx,d:o:r-x /test
$ ls -ld /test
drwxrwsr-x+ 3 root rubygems 4096 2008-12-05 07:59 /test
$ getfacl /test
getfacl: Removing leading '/' from absolute path names
# file: test
# owner: root
# group: rubygems
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::r-x

Le + à droite des permissions affichées par la commande ls indique qu’il y a des permissions supplémentaires visibles par getfacl. Ce dernier permet d’afficher les permissions définies avec setfacl. Essayons de créer des fichiers.

$ cd /test
$ touch polop.txt
$ mkdir hello
$ ls -l
total 16
drwxr-sr-x  2 foo rubygems 4096 2008-12-05 08:00 d
-rw-r--r--  1 foo rubygems    0 2008-12-05 07:59 f
drwxrwsr-x+ 2 foo rubygems 4096 2008-12-05 08:17 hello
-rw-rw-r--+ 1 foo rubygems    0 2008-12-05 08:17 polop.txt
$ getfacl hello
# file: hello
# owner: foo
# group: rubygems
user::rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::r-x

Les ACLs ont bien rempli leur rôle : les nouveaux fichiers créés ont la permission d’écriture pour le groupe et ont aux aussi les ACLs définis (notez le +).

Application au dossier de gemmes de ruby

Il nous faut définir le groupe les permissions pour tout fichier ou dossier existant du dossier /var/lib/gems et les ACLs ainsi que le ’set groupid’ bit pour tout dossier, sans oublier de changer le groupe pour qu’il devienne rubygems.

$ sudo chgrp -R rubygems /var/lib/gems
$ sudo chmod -R -s,g=rwX,o=rX /var/lib/gems
$ for dir in $(find /var/lib/gems -type d) ; do
> sudo chmod g+s "$dir"
> sudo setfacl -m d:u::rwx,d:g::rwx,d:o:r--,d:m:rwx "$dir"
> done

notez que si vous étiez sous zsh, vous auriez pu écrire

$ sudo chgrp rubygems /var/lib/gems/**/*
$ sudo chmod -s,g=rwX,o=rX /var/lib/gems/**/*
$ sudo chmod g+s /var/lib/gems/**/*(/)
$ sudo setfacl -m d:u::rwx,d:g::rwx,d:o:r--,d:m:rwx /var/lib/gems/**/*(/)

Voilà ! désomais vous pouvez taper

$ gems install rails -y

en simple utilisateur, ce qui signifie que d’autres programmes tiers comme NetBeans peuvent également installer des gemmes.

Autres applications

On peut trouver d’autres application très utiles au partage de dossier par ACL. Comme ça de tête :

• Quand votre serveur web est partagé entre plusieurs personnes, partager le dossier /var/www d’apache pour que l’utilisateur système www-data ait le droit d’écriture sur tous les fichiers sans donner ces droits à tout le monde ;
• Partager des fichiers sur un disque dur externe pour que chacun puisse y gérer ses films et photos sans se retrouver bloqué quand on veut déplacer ou supprimer certains éléments créés par d’autres utilisateurs.