[Aide] Mavericks: changement du nom du dossier "Home"

Gilbert OLIVIER <gilbert.olivier@orange.fr> wrote:

TU entends quoi par là? Un exemple..., je ne connais les liens
symboliques que de noms.

man symlink dans le terminal

un man trouvé dans /usr/share/man/man7/symlink.7
(je ne sais pas l'afficher dans le terminal)


SYMLINK(7) BSD Miscellaneous Information Manual
SYMLINK(7)

NAME
symlink -- symbolic link handling

SYMBOLIC LINK HANDLING
Symbolic links are files that act as pointers to other files. To
understand their
behavior, you must first understand how hard links work. A hard
link to a file is
indistinguishable from the original file because it is a reference
to the object
underlying the original file name. Changes to a file are
independent of the name
used to reference the file. Hard links may not refer to
directories and may not
reference files on different file systems. A symbolic link
contains the name of the
file to which it is linked, i.e., it is a pointer to another name,
and not to an
underlying object. For this reason, symbolic links may reference
directories and
may span file systems.

Because a symbolic link and its referenced object coexist in the
file system name
space, confusion can arise in distinguishing between the link
itself and the refer-
enced object. Historically, commands and system calls have adopted
their own link
following conventions in a somewhat ad-hoc fashion. Rules for more
a uniform
approach, as they are implemented in this system, are outlined
here. It is impor-
tant that local applications conform to these rules, too, so that
the user interface
can be as consistent as possible.

Symbolic links are handled either by operating on the link itself,
or by operating
on the object referenced by the link. In the latter case, an
application or system
call is said to ``follow'' the link. Symbolic links may reference
other symbolic
links, in which case the links are dereferenced until an object
that is not a sym-
bolic link is found, a symbolic link which references a file which
does not exist is
found, or a loop is detected. (Loop detection is done by placing
an upper limit on
the number of links that may be followed, and an error results if
this limit is
exceeded.)

There are three separate areas that need to be discussed. They are
as follows:

1. Symbolic links used as file name arguments for system
calls.
2. Symbolic links specified as command line arguments to
utilities that are
not traversing a file tree.
3. Symbolic links encountered by utilities that are
traversing a file tree
(either specified on the command line or encountered as
part of the file
hierarchy walk).

System calls.
The first area is symbolic links used as file name arguments for
system calls.

Except as noted below, all system calls follow symbolic links. For
example, if
there were a symbolic link ``slink'' which pointed to a file named
``afile'', the
system call ``open("slink" ...)'' would return a file descriptor to
the file
``afile''.

There are nine system calls that do not follow links, and which
operate on the sym-
bolic link itself. They are: lchflags(2), lchmod(2), lchown(2),
lstat(2),
lutimes(3), readlink(2), rename(2), rmdir(2), and unlink(2).
Because remove(3) is
an alias for unlink(2), it also does not follow symbolic links.
When rmdir(2) is
applied to a symbolic link, it fails with the error ENOTDIR.

The owner and group of an existing symbolic link can be changed by
means of the
lchown(2) system call. The flags, access permissions, owner/group
and modification
time of an existing symbolic link can be changed by means of the
lchflags(2),
lchmod(2), lchown(2), and lutimes(3) system calls, respectively.
Of these, only the
flags are used by the system; the access permissions and ownership
are ignored.

The 4.4BSD system differs from historical 4BSD systems in that the
system call
chown(2) has been changed to follow symbolic links. The lchown(2)
system call was
added later when the limitations of the new chown(2) became
apparent.

Commands not traversing a file tree.
The second area is symbolic links, specified as command line file
name arguments, to
commands which are not traversing a file tree.

Except as noted below, commands follow symbolic links named as
command line argu-
ments. For example, if there were a symbolic link ``slink'' which
pointed to a file
named ``afile'', the command ``cat slink'' would display the
contents of the file
``afile''.

It is important to realize that this rule includes commands which
may optionally
traverse file trees, e.g. the command ``chown file'' is included in
this rule, while
the command ``chown -R file'' is not. (The latter is described in
the third area,
below.)

If it is explicitly intended that the command operate on the
symbolic link instead
of following the symbolic link, e.g., it is desired that ``chown
slink'' change the
ownership of the file that ``slink'' is, whether it is a symbolic
link or not, the
-h option should be used. In the above example, ``chown root
slink'' would change
the ownership of the file referenced by ``slink'', while ``chown -h
root slink''
would change the ownership of ``slink'' itself.

There are four exceptions to this rule. The mv(1) and rm(1)
commands do not follow
symbolic links named as arguments, but respectively attempt to
rename and delete
them. (Note, if the symbolic link references a file via a relative
path, moving it
to another directory may very well cause it to stop working, since
the path may no
longer be correct.)

The ls(1) command is also an exception to this rule. For
compatibility with his-
toric systems (when ls is not doing a tree walk, i.e., the -R
option is not speci-
fied), the ls command follows symbolic links named as arguments if
the -H or -L
option is specified, or if the -F, -d or -l options are not
specified. (The ls com-
mand is the only command where the -H and -L options affect its
behavior even though
it is not doing a walk of a file tree.)

The file(1) command is also an exception to this rule. The file(1)
command does not
follow symbolic links named as argument by default. The file(1)
command does follow
symbolic links named as argument if -L option is specified.

The 4.4BSD system differs from historical 4BSD systems in that the
chown and chgrp
commands follow symbolic links specified on the command line.

Commands traversing a file tree.
The following commands either optionally or always traverse file
trees: chflags(1),
chgrp(1), chmod(1), cp(1), du(1), find(1), ls(1), pax(1), rm(1),
tar(1) and
chown(8).

It is important to realize that the following rules apply equally
to symbolic links
encountered during the file tree traversal and symbolic links
listed as command line
arguments.

The first rule applies to symbolic links that reference files that
are not of type
directory. Operations that apply to symbolic links are performed
on the links them-
selves, but otherwise the links are ignored.

The command ``rm -r slink directory'' will remove ``slink'', as
well as any symbolic
links encountered in the tree traversal of ``directory'', because
symbolic links may
be removed. In no case will rm affect the file which ``slink''
references in any
way.

The second rule applies to symbolic links that reference files of
type directory.
Symbolic links which reference files of type directory are never
``followed'' by
default. This is often referred to as a ``physical'' walk, as
opposed to a
``logical'' walk (where symbolic links referencing directories are
followed).

As consistently as possible, you can make commands doing a file
tree walk follow any
symbolic links named on the command line, regardless of the type of
file they refer-
ence, by specifying the -H (for ``half-logical'') flag. This flag
is intended to
make the command line name space look like the logical name space.
(Note, for com-
mands that do not always do file tree traversals, the -H flag will
be ignored if the
-R flag is not also specified.)

For example, the command ``chown -HR user slink'' will traverse the
file hierarchy
rooted in the file pointed to by ``slink''. Note, the -H is not
the same as the
previously discussed -h flag. The -H flag causes symbolic links
specified on the
command line to be dereferenced both for the purposes of the action
to be performed
and the tree walk, and it is as if the user had specified the name
of the file to
which the symbolic link pointed.

As consistently as possible, you can make commands doing a file
tree walk follow any
symbolic links named on the command line, as well as any symbolic
links encountered
during the traversal, regardless of the type of file they
reference, by specifying
the -L (for ``logical'') flag. This flag is intended to make the
entire name space
look like the logical name space. (Note, for commands that do not
always do file
tree traversals, the -L flag will be ignored if the -R flag is not
also specified.)

For example, the command ``chown -LR user slink'' will change the
owner of the file
referenced by ``slink''. If ``slink'' references a directory,
chown will traverse
the file hierarchy rooted in the directory that it references. In
addition, if any
symbolic links are encountered in any file tree that chown
traverses, they will be
treated in the same fashion as ``slink''.

As consistently as possible, you can specify the default behavior
by specifying the
-P (for ``physical'') flag. This flag is intended to make the
entire name space
look like the physical name space.

For commands that do not by default do file tree traversals, the
-H, -L and -P flags
are ignored if the -R flag is not also specified. In addition, you
may specify the
-H, -L and -P options more than once; the last one specified
determines the com-
mand's behavior. This is intended to permit you to alias commands
to behave one way
or the other, and then override that behavior on the command line.

The ls(1) and rm(1) commands have exceptions to these rules. The
rm command oper-
ates on the symbolic link, and not the file it references, and
therefore never fol-
lows a symbolic link. The rm command does not support the -H, -L
or -P options.

To maintain compatibility with historic systems, the ls command
acts a little dif-
ferently. If you do not specify the -F, -d or -l options, ls will
follow symbolic
links specified on the command line. If the -L flag is specified,
ls follows all
symbolic links, regardless of their type, whether specified on the
command line or
encountered in the tree walk.

SEE ALSO
chflags(1), chgrp(1), chmod(1), cp(1), du(1), find(1), ln(1),
ls(1), mv(1), pax(1),
rm(1), tar(1), lchflags(2), lchmod(2), lchown(2), lstat(2),
lutimes(3), readlink(2),
rename(2), symlink(2), unlink(2), fts(3), remove(3), chown(8)

BSD March 31, 1994
BSD

--
Gérard FLEUROT <g4fleurot@free.fr> plus un

Le 14/12/2013 10:36, Gilbert OLIVIER a écrit :

Mais ils sont aussi beaucoup plus tout-terrains. Les liens symboliques
sont transparents pour les applications, quelles qu'elles soient, pas
les alias.

TU entends quoi par là? Un exemple..., je ne connais les liens
symboliques que de noms.

Ca veut dire qu'une application peut manipuler le lien symbolique comme
si c'était le fichier ou le dossier pointé, sans avoir besoin de savoir
que c'est un lien. Alors que les alias doivent être "interprétés" par
les applis.

Il existe aussi les "liens en dur" : non seulement ils sont
transparents, mais une fois créés il n'y a plus aucun moyen de les
distinguer des fichiers ou dossiers pointés. Accessoirement ils ont la
même propriété que les alias (bien qu'ils soient très différents par
nature) : si le fichier pointé est déplacé, le "lien" le suit toujours.
Autre propriété : si le fichier d'origine est supprimé, le "lien" (et le
contenu) sont toujours disponibles.

pehache <pehache.7@gmail.com> wrote:

Le 14/12/2013 10:36, Gilbert OLIVIER a écrit :
>>
>> Mais ils sont aussi beaucoup plus tout-terrains. Les liens symboliques
>> sont transparents pour les applications, quelles qu'elles soient, pas
>> les alias.
>
> TU entends quoi par là? Un exemple..., je ne connais les liens
> symboliques que de noms.
>

Ca veut dire qu'une application peut manipuler le lien symbolique comme
si c'était le fichier ou le dossier pointé, sans avoir besoin de savoir
que c'est un lien. Alors que les alias doivent être "interprétés" par
les applis.

Il existe aussi les "liens en dur" : non seulement ils sont
transparents, mais une fois créés il n'y a plus aucun moyen de les
distinguer des fichiers ou dossiers pointés. Accessoirement ils ont la
même propriété que les alias (bien qu'ils soient très différents par
nature) : si le fichier pointé est déplacé, le "lien" le suit toujours.
Autre propriété : si le fichier d'origine est supprimé, le "lien" (et le
contenu) sont toujours disponibles.

Ok ,merci à toi et à ceux qui m'ont répondu.

--
Gilbert

Fleuger <g4fleurot@free.fr> wrote:

>
> TU entends quoi par là? Un exemple..., je ne connais les liens
> symboliques que de noms.

man symlink dans le terminal

un man trouvé dans /usr/share/man/man7/symlink.7
(je ne sais pas l'afficher dans le terminal)

nroff -man /usr/share/man/man7/symlink.7 | more

On Sam 14 décembre 2013 (13:50),
Olivier Marti <olivier.marti@ensta.org> wrote:

man symlink dans le terminal

un man trouvé dans /usr/share/man/man7/symlink.7
(je ne sais pas l'afficher dans le terminal)

nroff -man /usr/share/man/man7/symlink.7 | more

man 7 symlink

--
“First, solve the problem. Then, write the code.” – John Johnson

Matt <hfrarg@thelostplatypus.org.invalid> wrote:

man 7 symlink

Merci Matt, Super, tu m'as encore appris quelque chose ;-)

Grace à toi, malgré mon âge, j'y viens tout doucement au Terminal.

À propos, avec Automator, j'ai fabriqué un service qui fabrique des
liens symboliques sur le bureau.

Au premier niveau
Obtenir les éléments du Finder indiqués
Au second niveau :
Exécuter un script Shell
Shell /bin/bash
avec la formule
ln -s "$@" ~/Desktop

Et le service une fois réalisé est placé dans ~/Bibliothèque/Services

Adieu les aliases qui pèsent plus lourd que l'original pour certains
documents. Et le lien fonctionne avec des documents dans les images
disques protégées en en demandant l'ouverture (ou le montage).


--
Gérard FLEUROT <g4fleurot@free.fr> plus un

On Sam 14 décembre 2013 (14:30),
Fleuger <g4fleurot@free.fr> wrote:

À propos, avec Automator, j'ai fabriqué un service qui fabrique des
liens symboliques sur le bureau.

Au premier niveau
Obtenir les éléments du Finder indiqués
Au second niveau :
Exécuter un script Shell
Shell /bin/bash
avec la formule
ln -s "$@" ~/Desktop

Et le service une fois réalisé est placé dans ~/Bibliothèque/Services

Adieu les aliases qui pèsent plus lourd que l'original pour certains
documents. Et le lien fonctionne avec des documents dans les images
disques protégées en en demandant l'ouverture (ou le montage).

C'est un exemple parfait d'utilisation d'Automator :)

Une des nouveautés très utile introduite avec la 10.4 ou avant son
introduction pour faire ce que tu as fait, il fallait passer par des
modules du Finder tel que « SymbolicLinker » :

<http://seiryu.home.comcast.net/~seiryu/symboliclinker.html>

--
“Software developers like to solve problems. If there are no problems handily
available, they will create their own problems.” – Anonymous

Matt <hfrarg@thelostplatypus.org.invalid> wrote:

<http://seiryu.home.comcast.net/~seiryu/symboliclinker.html>

Oui, j'ai aussi.
Je ne me souviens plus, mais c'est probablement toi qui me l'avais
indiqué.
La différence, c'est que chez moi le lien est créé sur le bureau avec le
même nom que l'original, alors que SymbolicLinker crée le lien dans le
même répertoire en lui ajoutant " symlink"
Dans les deux cas, non traduit s'il y a une adaptation linguistique
(Aide mémoires redevient Stickies)


--
Gérard FLEUROT <g4fleurot@free.fr> plus un

Je vois que tu as compris d'où venait mon problème ;->
Manfred

Bon alors, t'as vu hein? Il ne faut pas que tu te dégonfles!!!
Mathilde (and NO 1 else!)
;-)

Garfield <mat.lacassagnere@gmail.com> wrote:

> Je vois que tu as compris d'où venait mon problème ;->
> Manfred

Bon alors, t'as vu hein? Il ne faut pas que tu te dégonfles!!!

<Mode "Fufu" ON>
Non mais! C'est fini, oui?!
<Mode "Fufu" OFF>
--
Manfred
42° 42' 0" N, 9° 26' 59" E.
iMac Intel Core 2 Duo, OS X 10.8.5.
"I would trade all my technology for an afternoon with Socrates."(S.J.)