Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: [Aide] Terminal
70 views
Skip to first unread message
Raspady
Feb 1, 2021, 1:24:29 PM2/1/21
to
On 2021-02-01 14:30:59 +0000, Brice said:
> En début, il était noté :
> The default interactive shell is now zsh.
> To update your account to use zsh, please run `chsh -s /bin/zsh`.
> For more details, please visit <https://support.apple.com/kb/HT208050>.
>
> J'ai fait comme indiqué dans le support Apple, je suis passé par
> Préférences Système>Utilisateurs et Groupes> puis comme indiqué.
>
> Puis j'ai démarré en mode utilisateur unique <Cmd><s>, pour y mettre la
> formule :
> /sbin/fsck -y
Je ne comprends pas. Tu cherchais à faire quoi au juste ? fsck est un
utilitaire de contrôle d'intégrité et de réparation d'un disque. Quel
rapport avec le shell par défaut ?
> pci pause: SDXC
>
> J'entre la formule :
> /sbin/fsck -y
Et rebelotte ;-)
>
> Avant j'en avais pour plusieurs minutes, là instantanément j'ai :
>
> error: container /dev/rdisk2 is mounted with write access
> localhost:/ root#
>
> Après avoir regardé sur l'iMac avec El Capitan, j'ai remis le Shell
> d'accès en /bin/bash.
>
> J'ai relancé le single user, j'ai malheureusement le même affichage.
Pourquoi démarrer le Mac en mode single user ? Quel intérêt y vois-tu ?
Si tu veux changer le shell par défaut, il est inutile de te logger en
mode single user. Il y a une manip à faire, soit en utilisant le
terminal, soit en passant par les préférences système mais pas les deux
en principe.
Pour le terminal, il suffit de taper "chsh -s /bin/zsh". Et ça marche
sur Catalina malgré la scission en en deux partitions du disque de
démarrage.
D'ailleurs sous macOS Big Sur :
Raspady@01-iMac ~ % cd /bin
Raspady@01-iMac /bin % pwd
/bin
> En début, il était noté :
> The default interactive shell is now zsh.
> To update your account to use zsh, please run `chsh -s /bin/zsh`.
> For more details, please visit <https://support.apple.com/kb/HT208050>.
>
> J'ai fait comme indiqué dans le support Apple, je suis passé par
> Préférences Système>Utilisateurs et Groupes> puis comme indiqué.
>
> Puis j'ai démarré en mode utilisateur unique <Cmd><s>, pour y mettre la
> formule :
> /sbin/fsck -y
Je ne comprends pas. Tu cherchais à faire quoi au juste ? fsck est un
utilitaire de contrôle d'intégrité et de réparation d'un disque. Quel
rapport avec le shell par défaut ?
> pci pause: SDXC
>
> J'entre la formule :
> /sbin/fsck -y
Et rebelotte ;-)
>
> Avant j'en avais pour plusieurs minutes, là instantanément j'ai :
>
> error: container /dev/rdisk2 is mounted with write access
> localhost:/ root#
>
> Après avoir regardé sur l'iMac avec El Capitan, j'ai remis le Shell
> d'accès en /bin/bash.
>
> J'ai relancé le single user, j'ai malheureusement le même affichage.
Pourquoi démarrer le Mac en mode single user ? Quel intérêt y vois-tu ?
Si tu veux changer le shell par défaut, il est inutile de te logger en
mode single user. Il y a une manip à faire, soit en utilisant le
terminal, soit en passant par les préférences système mais pas les deux
en principe.
Pour le terminal, il suffit de taper "chsh -s /bin/zsh". Et ça marche
sur Catalina malgré la scission en en deux partitions du disque de
démarrage.
D'ailleurs sous macOS Big Sur :
Raspady@01-iMac ~ % cd /bin
Raspady@01-iMac /bin % pwd
/bin
Raspady
Feb 2, 2021, 4:57:57 AM2/2/21
to
On 2021-02-01 18:59:37 +0000, M.V. said:
> Brice s'est posé une question : le fait que fsck -y ne fonctionne pas
> sous Catalina, est-ce que ça viendrait du fait que son shell est en
> bash et non en zsh. Me semble qu'il a clairement énoncé cette question.
Il n'a énoncé cette question à aucun moment ou alors dans une autre
enfilade. Comment veux-tu que ses lecteurs y comprennent quoique ce
soit ? On n'est pas dans sa tête.
> Brice s'est posé une question : le fait que fsck -y ne fonctionne pas
> sous Catalina, est-ce que ça viendrait du fait que son shell est en
> bash et non en zsh. Me semble qu'il a clairement énoncé cette question.
Il n'a énoncé cette question à aucun moment ou alors dans une autre
enfilade. Comment veux-tu que ses lecteurs y comprennent quoique ce
soit ? On n'est pas dans sa tête.
Raspady
Feb 2, 2021, 7:30:58 AM2/2/21
to
On 2021-02-02 10:55:27 +0000, M.V. said:
> J'ai répondu à Brice apparemment de façon satisfaisante : c'est tout ce
> qui importe.
Brice a abandonné le passage au shell zsh pourtant très simple à
effectuer et est revenu à bash, ce n'est pas ce que j'appellerais un
grand progrès.
> J'ai répondu à Brice apparemment de façon satisfaisante : c'est tout ce
> qui importe.
Brice a abandonné le passage au shell zsh pourtant très simple à
effectuer et est revenu à bash, ce n'est pas ce que j'appellerais un
grand progrès.
pehache
Feb 2, 2021, 9:08:37 AM2/2/21
to
Le 02/02/2021 à 11:55, M.V. a écrit :
> faisait le lien entre le shell et l'échec de la commande « fsck -y »
>
Au message précédent tu écrivais "Me semble qu'il a clairement énoncé
cette question". Maintenant c'est plutôt "en lisant entre les lignes".
Tu n'as pas l'impression de te contredire ?
>> Comment veux-tu que ses lecteurs y comprennent quoique ce
>> soit ?
>
> Le 2 février 2021 à 10 h 57, Raspady a écrit ce qui suit :
>
>> Il n'a énoncé cette question à aucun moment
>
> Tu as raison mais en lisant entre les lignes, il m'a paru évident qu'il
>
>> Il n'a énoncé cette question à aucun moment
>
> faisait le lien entre le shell et l'échec de la commande « fsck -y »
>
Au message précédent tu écrivais "Me semble qu'il a clairement énoncé
cette question". Maintenant c'est plutôt "en lisant entre les lignes".
Tu n'as pas l'impression de te contredire ?
>> Comment veux-tu que ses lecteurs y comprennent quoique ce
>> soit ?
>
> J'ai répondu à Brice apparemment de façon satisfaisante : c'est tout ce
> qui importe.
Tu n'es pas tout seul à lire ce groupe.
> qui importe.
pehache
Feb 2, 2021, 9:13:31 AM2/2/21
to
Le 01/02/2021 à 17:06, M.V. a écrit :
>
> Si tu n'utilises pas souvent le Terminal, laisse braire.
Et même s'il l'utilise souvent, il n'y a aucune nécessité à changer de
shell.
> Ayant pas mal de scripts anciens qui font appel au Terminal, j'ai gardé
> le bash (même s'il y a de fortes chances qu'ils fonctionnent avec zsh.
Les scripts peuvent parfaitement utiliser des shells qui sont différents
du shell interactif par défaut.
>
> Si tu n'utilises pas souvent le Terminal, laisse braire.
Et même s'il l'utilise souvent, il n'y a aucune nécessité à changer de
shell.
> Ayant pas mal de scripts anciens qui font appel au Terminal, j'ai gardé
> le bash (même s'il y a de fortes chances qu'ils fonctionnent avec zsh.
Les scripts peuvent parfaitement utiliser des shells qui sont différents
du shell interactif par défaut.
Gérald Niel
Feb 4, 2021, 1:58:10 PM2/4/21
to
Le Jeudi 04 février 2021 à 18:47 UTC, M.V écrivait sur
fr.comp.os.mac-os.x :
>> J'ai voulu rendre un dossier invisible avec un point, j'ai été rejeté
>> car c'est réservé au système
> Normal… mais ça se fait facilement avec le Terminal :
> rm chemin/nom_du_fichier chemin/.nom_du_fichier
mv plutôt que rm.
Parce que la commande ci-dessus va supprimer les deux fichiers (si ils
existent).
$ man mv
MV(1) BSD General Commands ManualMV(1)
NAME
mv -- move files
…
$ man rm
RM(1) BSD General Commands ManualRM(1)
NAME
rm, unlink -- remove directory entries
…
> Suivant les cas, un sudo peut être nécessaire.
L'élévation des droits via sudo ne sera nécéssaire qu'hors du
répertoire utilisateur ou si l'utilisateur n'a pas les droits sur le
fichier ou le répertoire parent.
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
précisément de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-
fr.comp.os.mac-os.x :
>> J'ai voulu rendre un dossier invisible avec un point, j'ai été rejeté
>> car c'est réservé au système
> Normal… mais ça se fait facilement avec le Terminal :
> rm chemin/nom_du_fichier chemin/.nom_du_fichier
mv plutôt que rm.
Parce que la commande ci-dessus va supprimer les deux fichiers (si ils
existent).
$ man mv
MV(1) BSD General Commands ManualMV(1)
NAME
mv -- move files
…
$ man rm
RM(1) BSD General Commands ManualRM(1)
NAME
rm, unlink -- remove directory entries
…
> Suivant les cas, un sudo peut être nécessaire.
L'élévation des droits via sudo ne sera nécéssaire qu'hors du
répertoire utilisateur ou si l'utilisateur n'a pas les droits sur le
fichier ou le répertoire parent.
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
précisément de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-
Raspady
Feb 5, 2021, 2:14:56 AM2/5/21
to
On 2021-02-04 18:06:03 +0000, Brice said:
> J'ai voulu rendre un dossier invisible avec un point, j'ai été rejeté
> car c'est réservé au système :(
> J'ai voulu rendre un dossier invisible avec un point, j'ai été rejeté
Comme déjà indiqué, tu peux utiliser la commande mv du terminal pour
renommer un fichier ou un dossier en ajoutant un point au début de son
nom mais c'est dangereux si le fichier ou le dossier en question sont
utilisés par une application, y compris le système.
Une méthode plus sûre est de modifier un des tags du fichier ou dossier
pour le rendre invisible sans pour autant en changer le nom.
"chflags hidden" suivi du chemin d'accès au fichier ou dossier le rend
invisible
Par exemple chflags hidden ~/Library
Et inversement "chflags nohidden" rend le fichier ou le dossier visible.
Si l'effet n'est pas immédiat, fermer la session puis la rouvrir.
Un "killall Dock" peut aussi marcher.
Fleuger
Feb 5, 2021, 2:29:22 AM2/5/21
to
Le 4 février 2021 à 20:06, M.V. a écrit ceci :
> Au temps pour moi…
> Comment ai-je pu faire cette bêtise alors que ce sont mes initiales !
Pour cacher un fichier
$ chflags hidden espace et glisser/déposer le fichier dans la fenêtre
ou $ chflags hidden chemin_du_fichier
Pour le révéler
$ chflags nohidden chemin_du_fichier
Ou utiliser Kilometre (clic droit sur le fichier > Services > Show info
with Kilometre > cliquer la case Invisible)
--
Gérard FLEUROT
> Au temps pour moi…
> Comment ai-je pu faire cette bêtise alors que ce sont mes initiales !
Pour cacher un fichier
$ chflags hidden espace et glisser/déposer le fichier dans la fenêtre
ou $ chflags hidden chemin_du_fichier
Pour le révéler
$ chflags nohidden chemin_du_fichier
Ou utiliser Kilometre (clic droit sur le fichier > Services > Show info
with Kilometre > cliquer la case Invisible)
--
Gérard FLEUROT
Raspady
Feb 5, 2021, 2:52:02 AM2/5/21
to
l'intérêt de lire les messages avant de poster.
Fleuger
Feb 5, 2021, 5:35:11 AM2/5/21
to
Le 5 février 2021 à 08:52, Raspady a écrit ceci :
> Tu n'as pas honte de faire un copier coller de ma réponse ? ;-) D'où
> l'intérêt de lire les messages avant de poster.
Bonjour la susceptibilité !
> Tu n'as pas honte de faire un copier coller de ma réponse ? ;-) D'où
> l'intérêt de lire les messages avant de poster.
Je t'engage à lire le livre "Du bon usage de la honte" de Serge
Tisseron.
J'avais rédigé le message hier soir et je l'ai enregistré en brouillon,
juste avant d'éteindre le mac, car je voulais vérifier les services dans
Kilometre dont tu n'as pas parlé et que Michel connaît, raison pour
laquelle ma réponse est après son dernier message et non pas dans une
réponse à Brice.
Mais tu as raison, j'aurais dû relire tous les messages avant de
l'envoyer.
--
Gérard FLEUROT
Bernd
Feb 5, 2021, 6:35:09 AM2/5/21
to
M.V. <m...@gmail.com.invalid> wrote:
> > mv plutôt que rm.
> Au temps pour moi…
> Comment ai-je pu faire cette bêtise alors que ce sont mes initiales !
Autant aussi pour les autres. Il m'est arrivé une fois d'effacer un
disque entier en tapant trop vite rm au lieu de mv !
Et d'ailleurs, j'en veux à Unix de cette espèce de proximité
linguistique entre mv et rm qui induit la confusion si on n'est pas
vigilant sans cesse - on n'a pas droit à un moment de détente d'une
seconde en écrivant rm !
Et même avec rm on peut effacer un répertoire au lieu d'un seul ou
quelques fichiers en introduisant une simple espace (où il ne faut pas)
avec *
--
A+
Romer
> > mv plutôt que rm.
> Au temps pour moi…
> Comment ai-je pu faire cette bêtise alors que ce sont mes initiales !
disque entier en tapant trop vite rm au lieu de mv !
Et d'ailleurs, j'en veux à Unix de cette espèce de proximité
linguistique entre mv et rm qui induit la confusion si on n'est pas
vigilant sans cesse - on n'a pas droit à un moment de détente d'une
seconde en écrivant rm !
Et même avec rm on peut effacer un répertoire au lieu d'un seul ou
quelques fichiers en introduisant une simple espace (où il ne faut pas)
avec *
--
A+
Romer
pehache
Feb 5, 2021, 8:35:03 AM2/5/21
to
permet d'éviter les accidents de ce genre.
Fleuger
Feb 5, 2021, 9:07:57 AM2/5/21
to
Le 5 février 2021 à 14:35, pehache a écrit ceci :
> alias rm="rm -i"
>
> permet d'éviter les accidents de ce genre.
Excellent ! Un grand merci pour cette astuce.
> alias rm="rm -i"
>
> permet d'éviter les accidents de ce genre.
"Ça m'était arrivé aussi d'effacer le dossier Utilisateurs, d'ou ma
grande peur lors de mes premières utilisations du terminal" ;-)
--
Gérard FLEUROT
Bernd
Feb 5, 2021, 9:31:51 AM2/5/21
to
pehache <peha...@gmail.com> wrote:
> > Autant aussi pour les autres. Il m'est arrivé une fois d'effacer un
> > disque entier en tapant trop vite rm au lieu de mv !
> > Et d'ailleurs, j'en veux à Unix de cette espèce de proximité
> > linguistique entre mv et rm qui induit la confusion si on n'est pas
> > vigilant sans cesse - on n'a pas droit à un moment de détente d'une
> > seconde en écrivant rm !
> > Et même avec rm on peut effacer un répertoire au lieu d'un seul ou
> > quelques fichiers en introduisant une simple espace (où il ne faut pas)
> > avec *
> alias rm="rm -i"
> permet d'éviter les accidents de ce genre.
Bien sûr que -i est efficace - Mais tu te vois répondre 2000 fois 'yes'
> > Autant aussi pour les autres. Il m'est arrivé une fois d'effacer un
> > disque entier en tapant trop vite rm au lieu de mv !
> > Et d'ailleurs, j'en veux à Unix de cette espèce de proximité
> > linguistique entre mv et rm qui induit la confusion si on n'est pas
> > vigilant sans cesse - on n'a pas droit à un moment de détente d'une
> > seconde en écrivant rm !
> > Et même avec rm on peut effacer un répertoire au lieu d'un seul ou
> > quelques fichiers en introduisant une simple espace (où il ne faut pas)
> > avec *
> alias rm="rm -i"
> permet d'éviter les accidents de ce genre.
ou 'no' si un dossier à effacer contient 2000 éléments ?
Je suis à 99% sûr de moi en principe ! Reste 1% évidemment. Ce 1%
diminuant encore avec le temps qui passe sans incident. Et c'est là que
la catastrophe guette.
Encore un mot au sujet de rm et mv : outre que les 2 commandes se
ressemblent visuellement un peu, en anglais elle sont l'abréviation de
move et remove : avouons que la confusion fatale peut arriver...
Il est étonnant (au sens classique) qu'un bout de commande comme rm -rf
/ efface tout le contenu d'un disque ! Autre cas d'anthologie, un simple
espace mal placé après une * et hop, plus rien ! Si tout de même - les
yeux pour pleurer !
--
A+
Romer
pehache
Feb 5, 2021, 9:53:46 AM2/5/21
to
Le 05/02/2021 à 15:31, Bernd a écrit :
> pehache <peha...@gmail.com> wrote:
>
>>> Autant aussi pour les autres. Il m'est arrivé une fois d'effacer un
>>> disque entier en tapant trop vite rm au lieu de mv !
>>> Et d'ailleurs, j'en veux à Unix de cette espèce de proximité
>>> linguistique entre mv et rm qui induit la confusion si on n'est pas
>>> vigilant sans cesse - on n'a pas droit à un moment de détente d'une
>>> seconde en écrivant rm !
>>> Et même avec rm on peut effacer un répertoire au lieu d'un seul ou
>>> quelques fichiers en introduisant une simple espace (où il ne faut pas)
>>> avec *
>
>> alias rm="rm -i"
>
>> permet d'éviter les accidents de ce genre.
>
> Bien sûr que -i est efficace - Mais tu te vois répondre 2000 fois 'yes'
> ou 'no' si un dossier à effacer contient 2000 éléments ?
Dans ces cas là, tu forces le rm de base en tapant /bin/rm ou \rm (les
> pehache <peha...@gmail.com> wrote:
>
>>> Autant aussi pour les autres. Il m'est arrivé une fois d'effacer un
>>> disque entier en tapant trop vite rm au lieu de mv !
>>> Et d'ailleurs, j'en veux à Unix de cette espèce de proximité
>>> linguistique entre mv et rm qui induit la confusion si on n'est pas
>>> vigilant sans cesse - on n'a pas droit à un moment de détente d'une
>>> seconde en écrivant rm !
>>> Et même avec rm on peut effacer un répertoire au lieu d'un seul ou
>>> quelques fichiers en introduisant une simple espace (où il ne faut pas)
>>> avec *
>
>> alias rm="rm -i"
>
>> permet d'éviter les accidents de ce genre.
>
> Bien sûr que -i est efficace - Mais tu te vois répondre 2000 fois 'yes'
> ou 'no' si un dossier à effacer contient 2000 éléments ?
deux outrepassent l'alias).
>
> Encore un mot au sujet de rm et mv : outre que les 2 commandes se
> ressemblent visuellement un peu, en anglais elle sont l'abréviation de
> move et remove : avouons que la confusion fatale peut arriver...
>
> Il est étonnant (au sens classique) qu'un bout de commande comme rm -rf
> / efface tout le contenu d'un disque !
la permission d'écriture. Et même un "sudo rm -rf /" en fait ne
fonctionne pas sur le disque système (mais évite d'essayer pour vérifier !)
> Autre cas d'anthologie, un simple
> espace mal placé après une * et hop, plus rien ! Si tout de même - les
> yeux pour pleurer !
pehache
Feb 5, 2021, 9:58:22 AM2/5/21
to
Le 05/02/2021 à 15:53, pehache a écrit :
>
>>
>> Encore un mot au sujet de rm et mv : outre que les 2 commandes se
>> ressemblent visuellement un peu, en anglais elle sont l'abréviation de
>> move et remove : avouons que la confusion fatale peut arriver...
>>
>> Il est étonnant (au sens classique) qu'un bout de commande comme rm -rf
>> / efface tout le contenu d'un disque !
>
> Plus exactement ça n'efface que les fichiers/dossiers sur lesquels tu as
> la permission d'écriture.
Enfin, il y a quelques années au boulot un gars a effacé par erreur tout
>
>>
>> Encore un mot au sujet de rm et mv : outre que les 2 commandes se
>> ressemblent visuellement un peu, en anglais elle sont l'abréviation de
>> move et remove : avouons que la confusion fatale peut arriver...
>>
>> Il est étonnant (au sens classique) qu'un bout de commande comme rm -rf
>> / efface tout le contenu d'un disque !
>
> Plus exactement ça n'efface que les fichiers/dossiers sur lesquels tu as
> la permission d'écriture.
le disque projet (disque réseau partagé de quelques To avec toutes les
prods en cours de la boîte, qui pour des raisons trop compliquées à
expliquer est en écriture pour tout le monde) avec un rm intempestif. Il
a fallu 24h pour remonter la dernière sauvegarde, avec toute la prod
bloquée pendant ce temps.
Jean-Pierre Kuypers
Feb 5, 2021, 10:29:04 AM2/5/21
to
In article (Dans l'article)
<1p44vbr.ie6zggjki7cwN%ro...@vat.com.invalid>, Bernd
<ro...@vat.com.invalid> wrote (écrivait) :
> > alias rm="rm -i"
> > permet d'éviter les accidents de ce genre.
>
> Bien sûr que -i est efficace - Mais tu te vois répondre 2000 fois 'yes'
> ou 'no' si un dossier à effacer contient 2000 éléments ?
Dans ce cas, tu tapes : /bin/rm
--
Jean-Pierre Kuypers
Veuillez effacer les phrases dans leur con-
texte avant de répondre sciemment.
<1p44vbr.ie6zggjki7cwN%ro...@vat.com.invalid>, Bernd
<ro...@vat.com.invalid> wrote (écrivait) :
> > alias rm="rm -i"
> > permet d'éviter les accidents de ce genre.
>
> Bien sûr que -i est efficace - Mais tu te vois répondre 2000 fois 'yes'
> ou 'no' si un dossier à effacer contient 2000 éléments ?
--
Jean-Pierre Kuypers
Veuillez effacer les phrases dans leur con-
texte avant de répondre sciemment.
pehache
Feb 5, 2021, 10:34:08 AM2/5/21
to
Le 05/02/2021 à 16:29, Jean-Pierre Kuypers a écrit :
> In article (Dans l'article)
> <1p44vbr.ie6zggjki7cwN%ro...@vat.com.invalid>, Bernd
> <ro...@vat.com.invalid> wrote (écrivait) :
>
>>> alias rm="rm -i"
>>> permet d'éviter les accidents de ce genre.
>>
>> Bien sûr que -i est efficace - Mais tu te vois répondre 2000 fois 'yes'
>> ou 'no' si un dossier à effacer contient 2000 éléments ?
>
> Dans ce cas, tu tapes : /bin/rm
>
Il y a de l'écho...
> In article (Dans l'article)
> <1p44vbr.ie6zggjki7cwN%ro...@vat.com.invalid>, Bernd
> <ro...@vat.com.invalid> wrote (écrivait) :
>
>>> alias rm="rm -i"
>>> permet d'éviter les accidents de ce genre.
>>
>> Bien sûr que -i est efficace - Mais tu te vois répondre 2000 fois 'yes'
>> ou 'no' si un dossier à effacer contient 2000 éléments ?
>
> Dans ce cas, tu tapes : /bin/rm
>
Bernd
Feb 5, 2021, 11:34:35 AM2/5/21
to
pehache <peha...@gmail.com> wrote:
> > Il est étonnant (au sens classique) qu'un bout de commande comme rm -rf
> > / efface tout le contenu d'un disque !
>
> Plus exactement ça n'efface que les fichiers/dossiers sur lesquels tu as
> la permission d'écriture. Et même un "sudo rm -rf /" en fait ne
> fonctionne pas sur le disque système (mais évite d'essayer pour vérifier !)
C'est la cas - un DD totalement mutimédia va partir au royaume des morts
> > Il est étonnant (au sens classique) qu'un bout de commande comme rm -rf
> > / efface tout le contenu d'un disque !
>
> Plus exactement ça n'efface que les fichiers/dossiers sur lesquels tu as
> la permission d'écriture. Et même un "sudo rm -rf /" en fait ne
> fonctionne pas sur le disque système (mais évite d'essayer pour vérifier !)
en qq. secondes
--
A+
Romer
Bernd
Feb 5, 2021, 11:34:36 AM2/5/21
to
Oui et je suis bien paré pour cela - mais pas pour tout - j'ai env 12 DD
en activité. Je ne peux pas en avoir 12 de plus pour sauvegarder les 12
autres ! Tant pis, il existe donc un risque de perte.
Les photos, souvenirs, travaux perso, etc. dont dûment à l'abri. Le
multimedia (musique, films, etc.) n'ont pas de parachûte.
--
A+
Romer
en activité. Je ne peux pas en avoir 12 de plus pour sauvegarder les 12
autres ! Tant pis, il existe donc un risque de perte.
Les photos, souvenirs, travaux perso, etc. dont dûment à l'abri. Le
multimedia (musique, films, etc.) n'ont pas de parachûte.
--
A+
Romer
Bernd
Feb 5, 2021, 11:34:36 AM2/5/21
to
Jean-Pierre Kuypers <Kuy...@address.invalid> wrote:
> > Bien sûr que -i est efficace - Mais tu te vois répondre 2000 fois 'yes'
> > ou 'no' si un dossier à effacer contient 2000 éléments ?
>
> Dans ce cas, tu tapes : /bin/rm
Oui cela vient d'être dit aussi par PH+
> > Bien sûr que -i est efficace - Mais tu te vois répondre 2000 fois 'yes'
> > ou 'no' si un dossier à effacer contient 2000 éléments ?
>
> Dans ce cas, tu tapes : /bin/rm
Mais j'ignore cette possibilité.
Cela entraîne quoi exactement ce /bin devant rm ?
Autant que je sache aucun bouquin sur Unix que j'ai lu ne mentionne
cela.
--
A+
Romer
pehache
Feb 5, 2021, 11:46:07 AM2/5/21
to
-rf", mais utiliser systématiquement l'option "-f" dans rm est une assez
mauvaise pratique à la base.
pehache
Feb 5, 2021, 11:50:06 AM2/5/21
to
Le 05/02/2021 à 17:34, ro...@vat.com.invalid (Bernd) a écrit :
un alias, et s'il ne trouve pas il cherche l'exécutable dans les dossiers
qui sont dans la variable d'environnement $PATH. rm est dans le dossier
bin. Si tu tapes le chemin complet /bin/rm l'OS comprend que tu veux
exécuter ce fichier bien précis et ne cherche ni dans les alias ni dans
$PATH
Bernd
Feb 5, 2021, 12:03:56 PM2/5/21
to
pehache <peha...@gmail.com> wrote:
> quand tu tapes "rm" tout seul, l'OS cherche d'abord si cette commande est
> un alias, et s'il ne trouve pas il cherche l'exécutable dans les dossiers
> qui sont dans la variable d'environnement $PATH. rm est dans le dossier
> bin. Si tu tapes le chemin complet /bin/rm l'OS comprend que tu veux
> exécuter ce fichier bien précis et ne cherche ni dans les alias ni dans
> $PATH
Oui en effet - cela invîte à taper moins vite et de façon moins
> quand tu tapes "rm" tout seul, l'OS cherche d'abord si cette commande est
> un alias, et s'il ne trouve pas il cherche l'exécutable dans les dossiers
> qui sont dans la variable d'environnement $PATH. rm est dans le dossier
> bin. Si tu tapes le chemin complet /bin/rm l'OS comprend que tu veux
> exécuter ce fichier bien précis et ne cherche ni dans les alias ni dans
> $PATH
automatique un rm à la place d'un mv.
Je fais un essai.
[...]
OK, ça marche. C'est un petit garde-fou.
--
A+
Romer
pehache
Feb 5, 2021, 3:35:02 PM2/5/21
to
Le 05/02/2021 à 21:05, Le Moustique a écrit :
> S'il n'a pas été s'amuser au ГУЛАГ c'est que ce n'était pas en Russie.
> :-)
>
Voilà :)
On a (avait ?) encore le droit de faire une erreur (même grosse) dans
notre boîte. D'autant qu'il n'y a pas eu mort d'hommes, et que la
politique "tout en libre écriture" n'est pas exempte de tout reproche :)
> Le 05/02/2021 à 15:58, pehache a écrit :
>> Enfin, il y a quelques années au boulot un gars a effacé par erreur
>> tout le disque projet (disque réseau partagé de quelques To avec
>> toutes les prods en cours de la boîte, qui pour des raisons trop
>> compliquées à expliquer est en écriture pour tout le monde) avec un rm
>> intempestif. Il a fallu 24h pour remonter la dernière sauvegarde, avec
>> toute la prod bloquée pendant ce temps.
>
> SI ça ne lui a pas coûté sa place, c'est que ce n'était pas aux US...
>> Enfin, il y a quelques années au boulot un gars a effacé par erreur
>> tout le disque projet (disque réseau partagé de quelques To avec
>> toutes les prods en cours de la boîte, qui pour des raisons trop
>> compliquées à expliquer est en écriture pour tout le monde) avec un rm
>> intempestif. Il a fallu 24h pour remonter la dernière sauvegarde, avec
>> toute la prod bloquée pendant ce temps.
>
> S'il n'a pas été s'amuser au ГУЛАГ c'est que ce n'était pas en Russie.
> :-)
>
Voilà :)
On a (avait ?) encore le droit de faire une erreur (même grosse) dans
notre boîte. D'autant qu'il n'y a pas eu mort d'hommes, et que la
politique "tout en libre écriture" n'est pas exempte de tout reproche :)
pehache
Feb 5, 2021, 3:39:03 PM2/5/21
to
Le 05/02/2021 à 21:11, Le Moustique a écrit :
> Le 05/02/2021 à 18:57, Brice a écrit :
>> J'avais un logiciel, Hider, pour effacer de la vue de tout un chacun un
>> dossier ou un fichier. L'ennui le concepteur est allé un peu loin, pour
>> moi, en filevaulsant les données, ce qui fait perdre beaucoup de temps.
>
> Dans le même style, il y a "Secret Folder", qui fonctionne très bien.
> Pas gratuit... mais il est possible de l'utiliser sans l'acheter, on
> perd juste une ou deux possibilités.
>>
>> Si ton AS permet de retrouver un dossier ou un fichier “hidden“, je suis
>> preneur.
>
> De ce point de vue, il y a ForkLift, qui permet de visualiser les
> fichiers cachés, ce qui permet de recopier leur contenu dans un autre
> dossier... un très bon substitut (ou complément) au Finder.
>
Note que le Finder permet aussi de voir les fichiers cachés, après une
manipe à faire dans le Terminal (une fois pour toutes)
> Le 05/02/2021 à 18:57, Brice a écrit :
>> J'avais un logiciel, Hider, pour effacer de la vue de tout un chacun un
>> dossier ou un fichier. L'ennui le concepteur est allé un peu loin, pour
>> moi, en filevaulsant les données, ce qui fait perdre beaucoup de temps.
>
> Dans le même style, il y a "Secret Folder", qui fonctionne très bien.
> Pas gratuit... mais il est possible de l'utiliser sans l'acheter, on
> perd juste une ou deux possibilités.
>>
>> Si ton AS permet de retrouver un dossier ou un fichier “hidden“, je suis
>> preneur.
>
> De ce point de vue, il y a ForkLift, qui permet de visualiser les
> fichiers cachés, ce qui permet de recopier leur contenu dans un autre
> dossier... un très bon substitut (ou complément) au Finder.
>
Note que le Finder permet aussi de voir les fichiers cachés, après une
manipe à faire dans le Terminal (une fois pour toutes)
Fleuger
Feb 6, 2021, 11:07:56 AM2/6/21
to
Le 6 février 2021 à 14:36, M.V. a écrit ceci :
> Je viens d'appliquer cette méthode sur plusieurs fichiers et j'obtiens
> toujours le même résultat : les fichiers sont bien rendus invisibles
> mais pas moyen de les rendre à nouveau visibles avec la commande
> « chflags nohidden »… Tu as ça aussi ?
Je découvre.
J'ai un Snapshot sur le bureau.
Je le rend Invisible avec Kilometre
-> clic sur le bureau -> OK -> disparait.
Je décoche la case Invisible
-> clic sur le bureau -> Le fichier re-apparaît.
Je le rend Invisible avec Kilometre
-> clic sur le bureau -> OK -> disparait.
J'ouvre le terminal :
➜ ~ chflags nohidden chflags nohidden /Users/fleuger/Desktop/Snapshot\
2021-01-15\ a<0300>\ 08.49.32.png
zsh: no such file or directory: 0300
➜ ~
Je le fais apparaître en affichant les fichiers invisibles.
Je l'ouvre avec GraphicConverter et je l'enregistre sous... en modifiant
le nom (* devant) pour le rendre visible et je supprime l'invisible.
J'en conclus que, contrairement à ce que je pensais, Kilometre ne rend
pas le fichier invisible par la méthode chflags, mais alors comment ?
Y aurait-il une autre méthode pour rendre les fichiers invisibles ?
Bravo pour ta curiosité ;-)
--
Gérard FLEUROT
> Je viens d'appliquer cette méthode sur plusieurs fichiers et j'obtiens
> toujours le même résultat : les fichiers sont bien rendus invisibles
> mais pas moyen de les rendre à nouveau visibles avec la commande
> « chflags nohidden »… Tu as ça aussi ?
Je découvre.
J'ai un Snapshot sur le bureau.
Je le rend Invisible avec Kilometre
-> clic sur le bureau -> OK -> disparait.
Je décoche la case Invisible
-> clic sur le bureau -> Le fichier re-apparaît.
Je le rend Invisible avec Kilometre
-> clic sur le bureau -> OK -> disparait.
J'ouvre le terminal :
➜ ~ chflags nohidden chflags nohidden /Users/fleuger/Desktop/Snapshot\
2021-01-15\ a<0300>\ 08.49.32.png
zsh: no such file or directory: 0300
➜ ~
Je le fais apparaître en affichant les fichiers invisibles.
Je l'ouvre avec GraphicConverter et je l'enregistre sous... en modifiant
le nom (* devant) pour le rendre visible et je supprime l'invisible.
J'en conclus que, contrairement à ce que je pensais, Kilometre ne rend
pas le fichier invisible par la méthode chflags, mais alors comment ?
Y aurait-il une autre méthode pour rendre les fichiers invisibles ?
Bravo pour ta curiosité ;-)
--
Gérard FLEUROT
Fleuger
Feb 6, 2021, 11:54:45 AM2/6/21
to
Le 6 février 2021 à 17:33, M.V. a écrit ceci :
> Un snapshot ? Un instantané TimeMachine, CCC ou bien une simple copie
> d'écran ?
copie d'écran. C'est le nom que je leur donne depuis des années
> fois la commande « chflags nohidden » !
Ben oui ! "chflags nohidden /Users/fleuger/Desktop/Snapshot\ 2021-01-15\
a<0300>\ 08.49.32\ 2.png" ne rend pas le fichier visible.
Oui, c'est vraiment étrange.
--
Gérard FLEUROT
> Un snapshot ? Un instantané TimeMachine, CCC ou bien une simple copie
> d'écran ?
copie d'écran. C'est le nom que je leur donne depuis des années
>
>> chflags nohidden chflags nohidden /Users/fleuger/Desktop/Snapshot\
>> 2021-01-15\ a<0300>\ 08.49.32.png
>> zsh: no such file or directory: 0300
>
> Si vraiment tu as tapé ça, normal que ça ne fonctionne pas : tu as 2
>> chflags nohidden chflags nohidden /Users/fleuger/Desktop/Snapshot\
>> 2021-01-15\ a<0300>\ 08.49.32.png
>> zsh: no such file or directory: 0300
>
> fois la commande « chflags nohidden » !
Ben oui ! "chflags nohidden /Users/fleuger/Desktop/Snapshot\ 2021-01-15\
a<0300>\ 08.49.32\ 2.png" ne rend pas le fichier visible.
>
>> J'en conclus que, contrairement à ce que je pensais, Kilometre ne rend
>> pas le fichier invisible par la méthode chflags, mais alors comment ?
>
> C'est la question que je me pose.
>> J'en conclus que, contrairement à ce que je pensais, Kilometre ne rend
>> pas le fichier invisible par la méthode chflags, mais alors comment ?
>
Oui, c'est vraiment étrange.
--
Gérard FLEUROT
Fleuger
Feb 6, 2021, 12:31:11 PM2/6/21
to
Le 6 février 2021 à 17:33, M.V. a écrit ceci :
> C'est la question que je me pose.
Trouvé ici :
> C'est la question que je me pose.
<https://www.macworld.com/article/2030765/8-ways-to-hide-files-and-folders-in-os-x.html>
en 7
If you have Apple’s Developer Tools installed, go to Terminal and enter setfile -a V followed by the
name of the file or folder. That sets its visibility attribute to invisible; you can undo this by
repeating the command with a lower-case v.
Je pense que c'est la méthode employée par Kilometre
➜ ~ setfile -a V /Users/fleuger/Desktop/Snapshot\ 2021-01-15\ a<0300>\ 08.49.32\ 2.png
fait disparaître le fichier.
Dans Kilometre, la case Invisible est cochée.
➜ ~ setfile -a v /Users/fleuger/Desktop/Snapshot\ 2021-01-15\ a<0300>\ 08.49.32\ 2.png
rend le fichier visible (comme le décochage dans Kilometre
--
Gérard FLEUROT
Fleuger
Feb 6, 2021, 12:45:33 PM2/6/21
to
Le 6 février 2021 à 18:31, j'ai écrit ceci :
> Je pense que c'est la méthode employée par Kilometre
Pas de man setfile dans macos, mais il existe dans Dash
> Je pense que c'est la méthode employée par Kilometre
et en ligne : <https://www.manpagez.com/man/1/SetFile/>
--
Gérard FLEUROT
Fleuger
Feb 6, 2021, 2:22:06 PM2/6/21
to
Le 6 février 2021 à 18:48, Matt a écrit ceci :
> C'est la réponse que je t'ai donné sur ce groupe le 27/07/2007 suite à
> cette même question ;)
>
> Message-ID: <f8ci4g$mlr$1...@talisker.lacave.net>
Incroyable !
Zut alors ! dans mes archives, j'ai un message du 26/07/2007 et un du
27/07/2007, mais rien entre les deux.
Et je ne l'ai pas retrouvé dans les archives Google Groups.
Avec de telles références, je ne peux que te croire.
Quand je te dis que j'ai une cervelle d'oiseau
Et pourtant, je n'avais que soixante deux ans ;-)
--
Gérard FLEUROT
> C'est la réponse que je t'ai donné sur ce groupe le 27/07/2007 suite à
> cette même question ;)
>
> Message-ID: <f8ci4g$mlr$1...@talisker.lacave.net>
Incroyable !
Zut alors ! dans mes archives, j'ai un message du 26/07/2007 et un du
27/07/2007, mais rien entre les deux.
Et je ne l'ai pas retrouvé dans les archives Google Groups.
Avec de telles références, je ne peux que te croire.
Quand je te dis que j'ai une cervelle d'oiseau
Et pourtant, je n'avais que soixante deux ans ;-)
--
Gérard FLEUROT
Fleuger
Feb 6, 2021, 2:22:06 PM2/6/21
to
Le 6 février 2021 à 18:59, Matt a écrit ceci :
> Elle est bien là dans ma VM Mac OS X 10.14.6, mais peut-être pas dans
> ton $MANPATH :
Ma version de man1 est du 2 février 2021* et pas de setfile.1 et pas de
GetFileInfo.1 non plus
* Mise à jour de sécurité pour Mojave 2021-1
1/SetFile.1
/Library/Developer/CommandLineTools/usr/share/man/man1/SetFile.1
/Applications/Xcode.app/Contents/Developer/usr/share/man/man1/SetFile.1:
No such file or directory
No manual entry for
/Applications/Xcode.app/Contents/Developer/usr/share/man/man1/SetFile.1
➜ ~ man -w GetFileInfo
/Applications/Xcode.app/Contents/Developer/usr/share/man/man1/GetFileInfo.1
/Library/Developer/CommandLineTools/usr/share/man/man1/GetFileInfo.1
Je n'ai pas XCode, mais uniquement les CommandLineTools
--
Gérard FLEUROT
> Elle est bien là dans ma VM Mac OS X 10.14.6, mais peut-être pas dans
> ton $MANPATH :
Ma version de man1 est du 2 février 2021* et pas de setfile.1 et pas de
GetFileInfo.1 non plus
* Mise à jour de sécurité pour Mojave 2021-1
1/SetFile.1
/Library/Developer/CommandLineTools/usr/share/man/man1/SetFile.1
/Applications/Xcode.app/Contents/Developer/usr/share/man/man1/SetFile.1:
No such file or directory
No manual entry for
/Applications/Xcode.app/Contents/Developer/usr/share/man/man1/SetFile.1
➜ ~ man -w GetFileInfo
/Applications/Xcode.app/Contents/Developer/usr/share/man/man1/GetFileInfo.1
/Library/Developer/CommandLineTools/usr/share/man/man1/GetFileInfo.1
zsh: no such file or directory:
/Applications/Xcode.app/Contents/Developer/usr/share/man/man1/GetFileInfo.1
Je n'ai pas XCode, mais uniquement les CommandLineTools
--
Gérard FLEUROT
Jean-Pierre Kuypers
Feb 6, 2021, 3:23:43 PM2/6/21
to
In article (Dans l'article) <rvmr1s$130$1...@dont-email.me>, M.V.
<m...@gmail.com.invalid> wrote (écrivait) :
> Le 6 février 2021 à 20 h 22, Fleuger a écrit ce qui suit :
>
>> Le 6 février 2021 à 18:48, Matt a écrit ceci :
>> Message-ID: <f8ci4g$mlr$1...@talisker.lacave.net>
>
> Par exemple :
<https://usenet-fr.alphanet.ch/search/message-id/%3Cf8ci4g$mlr$1@taliske
r.lacave.net%3E/0>
Autre (re)source :
<http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cf8ci4g%24mlr%241%40tali
sker.lacave.net%3E>
--
Jean-Pierre Kuypers
<m...@gmail.com.invalid> wrote (écrivait) :
> Le 6 février 2021 à 20 h 22, Fleuger a écrit ce qui suit :
>
>> Le 6 février 2021 à 18:48, Matt a écrit ceci :
>
> Par exemple :
<https://usenet-fr.alphanet.ch/search/message-id/%3Cf8ci4g$mlr$1@taliske
r.lacave.net%3E/0>
Autre (re)source :
<http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cf8ci4g%24mlr%241%40tali
sker.lacave.net%3E>
--
Jean-Pierre Kuypers
pehache
Feb 7, 2021, 3:25:20 AM2/7/21
to
Le 06/02/2021 à 20:22, Fleuger a écrit :
>
> Je n'ai pas XCode, mais uniquement les CommandLineTools
>
Je croyais qu'il fallait nécessaire installer Xcode pour avoir les CLT ?
>
> Je n'ai pas XCode, mais uniquement les CommandLineTools
>
Fleuger
Feb 7, 2021, 8:22:57 AM2/7/21
to
Le 6 février 2021 à 10:27, Le Moustique a écrit ceci :
> La commande indiquée par MV fonctionne aussi très bien, et est très
> facilement réversible (sans avoir besoin du Terminal).
Très bien adaptée à un clavier non étendu, mais avec le clavier étendu,
il faut bien écarter les doigts de la main droite.
--
Gérard FLEUROT
> La commande indiquée par MV fonctionne aussi très bien, et est très
> facilement réversible (sans avoir besoin du Terminal).
Très bien adaptée à un clavier non étendu, mais avec le clavier étendu,
il faut bien écarter les doigts de la main droite.
--
Gérard FLEUROT
Fleuger
Feb 7, 2021, 8:22:58 AM2/7/21
to
Le 6 février 2021 à 21:59, Le Moustique a écrit ceci :
> Gamin! ;-)
;-)
--
Gérard FLEUROT
> Gamin! ;-)
;-)
--
Gérard FLEUROT
Fleuger
Feb 7, 2021, 8:22:58 AM2/7/21
to
Le 6 février 2021 à 21:23, Jean-Pierre Kuypers a écrit ceci :
> <https://usenet-fr.alphanet.ch/search/message-id/%3Cf8ci4g$mlr$1@taliske
> r.lacave.net%3E/0>
>
>
> Autre (re)source :
> <http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cf8ci4g%24mlr%241%40tali
> sker.lacave.net%3E>
Oui, merci pour ces liens.
> <https://usenet-fr.alphanet.ch/search/message-id/%3Cf8ci4g$mlr$1@taliske
> r.lacave.net%3E/0>
>
>
> Autre (re)source :
> <http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cf8ci4g%24mlr%241%40tali
> sker.lacave.net%3E>
Je les avais notés, mais ils étaient tombés dans les oubliettes de ma
mémoire :-(
--
Gérard FLEUROT
Fleuger
Feb 7, 2021, 8:22:59 AM2/7/21
to
Le 6 février 2021 à 20:40, M.V. a écrit ceci :
> C'est pas ces trucs là qu'il faut chercher mais SetFile et GetFileInfo
> qui, tous les 2, sont dans /usr/bin/
Ça, ce sont les executables : mais je parlais des pages de man qui sont
normalement dans /usr/share/man/man1
À moins qu'ils ne soient contenus dans les executables.
Mais j'ai aussi SetFile et GetFileInfo dans
/Library/Developer/CommandLineTools/usr/bin/SetFile
Alors, je pense que ça devrait marcher même sans CLT.
--
Gérard FLEUROT
> C'est pas ces trucs là qu'il faut chercher mais SetFile et GetFileInfo
> qui, tous les 2, sont dans /usr/bin/
Ça, ce sont les executables : mais je parlais des pages de man qui sont
normalement dans /usr/share/man/man1
À moins qu'ils ne soient contenus dans les executables.
Mais j'ai aussi SetFile et GetFileInfo dans
/Library/Developer/CommandLineTools/usr/bin/SetFile
Alors, je pense que ça devrait marcher même sans CLT.
--
Gérard FLEUROT
Fleuger
Feb 7, 2021, 8:23:00 AM2/7/21
to
Le 6 février 2021 à 21:55, Matt a écrit ceci :
> Ceci explique cela :)
Non ! J'ai merdouillé.
J'ai recopié le lien du site Macworld : setfile -a V
Il fonctionne, mais je pense qu'il n'aurait pas dû.
En effet, la commande correcte est : SetFile -a V
Je n'ai pas de man pour setfile, mais c'est bon pour SetFile et
GetFileInfo
--
Gérard FLEUROT
> Ceci explique cela :)
Non ! J'ai merdouillé.
J'ai recopié le lien du site Macworld : setfile -a V
Il fonctionne, mais je pense qu'il n'aurait pas dû.
En effet, la commande correcte est : SetFile -a V
Je n'ai pas de man pour setfile, mais c'est bon pour SetFile et
GetFileInfo
--
Gérard FLEUROT
Fleuger
Feb 7, 2021, 8:23:01 AM2/7/21
to
Le 7 février 2021 à 12:33, Matt a écrit ceci :
> Ce n'est pas nécessaire.
> Il y a même une application qui permet de les installer directement
> (/System/Library/CoreServices/Install\ Command\ Line\ Developer\
> Tools.app)
Dans le Rerminal, entrer :
xcode-select --install
Ou avoir un compte dévelopeur
https://developer.apple.com/download/more/
télécharger et installer
--
Gérard FLEUROT
> Ce n'est pas nécessaire.
> Il y a même une application qui permet de les installer directement
> (/System/Library/CoreServices/Install\ Command\ Line\ Developer\
> Tools.app)
Dans le Rerminal, entrer :
xcode-select --install
Ou avoir un compte dévelopeur
https://developer.apple.com/download/more/
télécharger et installer
--
Gérard FLEUROT
Fleuger
Feb 7, 2021, 8:23:02 AM2/7/21
to
Le 6 février 2021 à 21:54, Matt a écrit ceci :
>> Et je ne l'ai pas retrouvé dans les archives Google Groups.
>
> Normal, Google Groups respecte le 'X-No-Archive: Yes'.
>> Et je ne l'ai pas retrouvé dans les archives Google Groups.
>
Normal que je ne l'aie pas : tu m'a confondu avec Gérard Cojot ;-)
--
Gérard FLEUROT
Fleuger
Feb 7, 2021, 8:31:43 AM2/7/21
to
Le 7 février 2021 à 13:50, M.V. a écrit ceci :
> Il y aurait même un 3ème moyen de rendre invisible un élément : par
> exemple, /Applications/News.app est invisible mais ni « GetFileInfo »
> ni « ls -aOl » n'indiquent cet état ; je ne sais donc pas le rendre
> visible.
J'ai contourné le problème.
Mon lanceur d'applications est un dossier dans la dock qui contient des
sous-dossiers avec un classement personnalisé qui contiennent des alias
d'applications et j'ai un alias pour cette application invisible dans un
dossier RSS-News.
Mais effectivement, ça doit faire une méthode de plus pour masquer les
applications.
--
Gérard FLEUROT
> Il y aurait même un 3ème moyen de rendre invisible un élément : par
> exemple, /Applications/News.app est invisible mais ni « GetFileInfo »
> ni « ls -aOl » n'indiquent cet état ; je ne sais donc pas le rendre
> visible.
J'ai contourné le problème.
Mon lanceur d'applications est un dossier dans la dock qui contient des
sous-dossiers avec un classement personnalisé qui contiennent des alias
d'applications et j'ai un alias pour cette application invisible dans un
dossier RSS-News.
Mais effectivement, ça doit faire une méthode de plus pour masquer les
applications.
--
Gérard FLEUROT
Jean-Pierre Kuypers
Feb 7, 2021, 8:33:07 AM2/7/21
to
In article (Dans l'article) <rvopjh$42s$3...@dont-email.me>, Fleuger
<g4fl...@free.fr.invalid> wrote (écrivait) :
> Oui, merci pour ces liens.
Je garde aussi <http://www.restoux.org/index.php>
--
Jean-Pierre Kuypers
<g4fl...@free.fr.invalid> wrote (écrivait) :
> Oui, merci pour ces liens.
--
Jean-Pierre Kuypers
Fleuger
Feb 7, 2021, 9:47:35 AM2/7/21
to
Le 7 février 2021 à 15:00, M.V. a écrit ceci :
> En effet, man GetInfoFile et man SetFile ne donnent rien.
Toujours avec Mojave
Dans le Terminal, écrire SetFile
Clic droit sur SetFile et Ouvrir la page de man ->
x-man-page://SetFile
et GetFileInfo -> x-man-page://GetFileInfo
--
Gérard FLEUROT
> En effet, man GetInfoFile et man SetFile ne donnent rien.
Toujours avec Mojave
Dans le Terminal, écrire SetFile
Clic droit sur SetFile et Ouvrir la page de man ->
x-man-page://SetFile
et GetFileInfo -> x-man-page://GetFileInfo
--
Gérard FLEUROT
Fleuger
Feb 7, 2021, 9:47:36 AM2/7/21
to
Le 7 février 2021 à 14:33, Jean-Pierre Kuypers a écrit ceci :
> Je garde aussi <http://www.restoux.org/index.php>
Il y avait eu un fil il n'y a pas si longtemps et j'avais aussi noté
> Je garde aussi <http://www.restoux.org/index.php>
cette adresse :-)
--
Gérard FLEUROT
Fleuger
Feb 7, 2021, 10:26:04 AM2/7/21
to
Le 7 février 2021 à 16:01, M.V. a écrit ceci :
> Je suis avec Catalina actuellement et ça ne donne rien sauf ce message :
Je reprend avec le MBA sous Catalina
Dans MacCafé, je sélectionne
x-man-page://SetFile
menu contextuel "Ouvrir l'URL" sur le texte surligné et ça ouvre bien la page de man
correspondante :
SETFILE(1) BSD General Commands Manual SETFILE(1)
[snip]
Mac OS X January 4, 2009 Mac OS X
--
Gérard FLEUROT
> Je suis avec Catalina actuellement et ça ne donne rien sauf ce message :
Je reprend avec le MBA sous Catalina
Dans MacCafé, je sélectionne
x-man-page://SetFile
menu contextuel "Ouvrir l'URL" sur le texte surligné et ça ouvre bien la page de man
correspondante :
SETFILE(1) BSD General Commands Manual SETFILE(1)
[snip]
Mac OS X January 4, 2009 Mac OS X
--
Gérard FLEUROT
Jean-Pierre Kuypers
Feb 7, 2021, 11:49:52 AM2/7/21
to
In article (Dans l'article) <rvorpo$ihk$1...@dont-email.me>, M.V.
<m...@gmail.com.invalid> wrote (écrivait) :
> Le 7 février 2021 à 14 h 33, Jean-Pierre Kuypers a écrit ce qui suit :
> > Je garde aussi <http://www.restoux.org/index.php>
>
> Oui mais en l'occurrence il ne trouve pas le message indiqué plus haut.
Toutafé !
Il y a des manques.
--
Jean-Pierre Kuypers
<m...@gmail.com.invalid> wrote (écrivait) :
> Le 7 février 2021 à 14 h 33, Jean-Pierre Kuypers a écrit ce qui suit :
> > Je garde aussi <http://www.restoux.org/index.php>
>
Toutafé !
Il y a des manques.
--
Jean-Pierre Kuypers
Jean-Pierre Kuypers
Feb 7, 2021, 11:52:24 AM2/7/21
to
In article (Dans l'article) <rvoui7$6rs$2...@dont-email.me>, Fleuger
<g4fl...@free.fr.invalid> wrote (écrivait) :
> Le 7 février 2021 à 14:33, Jean-Pierre Kuypers a écrit ceci :
> > Je garde aussi <http://www.restoux.org/index.php>
>
> Il y avait eu un fil il n'y a pas si longtemps...
Toutafé.
Et j'y exposais les nuances quant à la manière d'indiquer
l'identification du message à rechercher.
--
Jean-Pierre Kuypers
<g4fl...@free.fr.invalid> wrote (écrivait) :
> Le 7 février 2021 à 14:33, Jean-Pierre Kuypers a écrit ceci :
> > Je garde aussi <http://www.restoux.org/index.php>
>
Toutafé.
Et j'y exposais les nuances quant à la manière d'indiquer
l'identification du message à rechercher.
--
Jean-Pierre Kuypers
Fleuger
Feb 7, 2021, 2:24:37 PM2/7/21
to
Le 7 février 2021 à 20:10, Matt a écrit ceci :
> Ah mince j'ai vu ça après avoir posté, désolé :(
Pour moi, ça a été positif puisque ça m'a fait réviser comment retrouver
un message à partir de son messageID
--
Gérard FLEUROT
> Ah mince j'ai vu ça après avoir posté, désolé :(
Pour moi, ça a été positif puisque ça m'a fait réviser comment retrouver
un message à partir de son messageID
--
Gérard FLEUROT
Fleuger
Feb 7, 2021, 2:40:38 PM2/7/21
to
Le 7 février 2021 à 20:12, Matt a écrit ceci :
> Si l'on a pas un système de fichiers sensible à la casse, le
> comportement que tu observes est normal.
Pour une recherche de fichiers dans le Finder, oui.
Mais le Terminal est sensible à la casse
➜ ~ man setfile
No manual entry for setfile
➜ ~ man SetFile ouvre bien la bonne page.
--
Gérard FLEUROT
> Si l'on a pas un système de fichiers sensible à la casse, le
> comportement que tu observes est normal.
Pour une recherche de fichiers dans le Finder, oui.
Mais le Terminal est sensible à la casse
➜ ~ man setfile
No manual entry for setfile
➜ ~ man SetFile ouvre bien la bonne page.
--
Gérard FLEUROT
Gérald Niel
Feb 8, 2021, 3:54:58 AM2/8/21
to
Le Lundi 08 février 2021 à 08:44 UTC, M.V écrivait sur
fr.comp.os.mac-os.x :
>> Mais le Terminal est sensible à la casse
>> ➜ ~ man setfile
>> No manual entry for setfile
>>
>> ➜ ~ man SetFile ouvre bien la bonne page.
C'est n'est pas le terminal qui est sensible à la casse mais très
probablement man et la façon dont ça intérroge la base de données.
> En effet mais :
> GetFileInfo chemin_du_fichier
> et
> getinfofile chemin_du_fichier
> donnent les mêmes résultats de même que :
> gEtFiLeInFo chemin_du_fichier
> ou encore
> GETFILEINFO chemin_du_fichier
Sur un système de fichier insensible à la casse c'est normal.
> La sensibilité à la casse est donc variable.
D'un coté on appelle des fichiers executables et de l'autre c'est un
programme qui intérroge une base de donnée.
Ça n'est pas déconnant ni surprenant que les comportements diffèrent.
(je ne sais pas comment fonctionne man, je ne fais que supposer)
@+
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
précisément de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-
fr.comp.os.mac-os.x :
>> Mais le Terminal est sensible à la casse
>> ➜ ~ man setfile
>> No manual entry for setfile
>>
>> ➜ ~ man SetFile ouvre bien la bonne page.
probablement man et la façon dont ça intérroge la base de données.
> En effet mais :
> GetFileInfo chemin_du_fichier
> et
> getinfofile chemin_du_fichier
> donnent les mêmes résultats de même que :
> gEtFiLeInFo chemin_du_fichier
> ou encore
> GETFILEINFO chemin_du_fichier
Sur un système de fichier insensible à la casse c'est normal.
> La sensibilité à la casse est donc variable.
D'un coté on appelle des fichiers executables et de l'autre c'est un
programme qui intérroge une base de donnée.
Ça n'est pas déconnant ni surprenant que les comportements diffèrent.
(je ne sais pas comment fonctionne man, je ne fais que supposer)
@+
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
précisément de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-
Gérald Niel
Feb 8, 2021, 4:59:17 AM2/8/21
to
Le Lundi 08 février 2021 à 09:56 UTC, M.V écrivait sur
fr.comp.os.mac-os.x :
> Ce que je constate :
> - les commandes sont insensibles à la casse
> - les paramètres sont sensibles à la casse
Ce qui est parfaitement normal.
fr.comp.os.mac-os.x :
> Ce que je constate :
> - les commandes sont insensibles à la casse
> - les paramètres sont sensibles à la casse
Ce qui est parfaitement normal.
Fleuger
Feb 8, 2021, 5:16:17 AM2/8/21
to
Le 7 février 2021 à 21:39, Matt a écrit ceci :
> Expliques-nous s'il te plaît pourquoi `LS -AL` et `ls -al` produisent le
> même résultat ? (Suivant ta réponse je t'expliquerai) ;)
Bon, je sens que je vais apprendre des choses.
Tout d'abord, j'ai installé ohmyzsh <https://ohmyz.sh> pour customiser
mon terminal.
ls -al -> 7 colonnes, la dernière en couleur. j'ai un man.
LS -al -> 7 colonnes, la dernière en noir et blanc, pas de man.
ls -AL -> le contenu de la septième colonne, sur deux colonnes en
couleur moins "." et "..".
LS -AL -> même chose mais en noir et blanc.
j'en déduis que ohmyzsh ne reconnaît pas LS
Les options sont sensibles à la casse, mais pas la commande.
--
Gérard FLEUROT
> Expliques-nous s'il te plaît pourquoi `LS -AL` et `ls -al` produisent le
> même résultat ? (Suivant ta réponse je t'expliquerai) ;)
Bon, je sens que je vais apprendre des choses.
Tout d'abord, j'ai installé ohmyzsh <https://ohmyz.sh> pour customiser
mon terminal.
ls -al -> 7 colonnes, la dernière en couleur. j'ai un man.
LS -al -> 7 colonnes, la dernière en noir et blanc, pas de man.
ls -AL -> le contenu de la septième colonne, sur deux colonnes en
couleur moins "." et "..".
LS -AL -> même chose mais en noir et blanc.
j'en déduis que ohmyzsh ne reconnaît pas LS
Les options sont sensibles à la casse, mais pas la commande.
--
Gérard FLEUROT
pehache
Feb 8, 2021, 5:33:30 AM2/8/21
to
Le 08/02/2021 à 10:59, Gérald Niel a écrit :
> Le Lundi 08 février 2021 à 09:56 UTC, M.V écrivait sur
> fr.comp.os.mac-os.x :
>
>> Ce que je constate :
>> - les commandes sont insensibles à la casse
>> - les paramètres sont sensibles à la casse
>
> Ce qui est parfaitement normal.
>
Oui, mais pour compliquer un peu les choses, certaines commandes sont
> Le Lundi 08 février 2021 à 09:56 UTC, M.V écrivait sur
> fr.comp.os.mac-os.x :
>
>> Ce que je constate :
>> - les commandes sont insensibles à la casse
>> - les paramètres sont sensibles à la casse
>
> Ce qui est parfaitement normal.
>
sensibles à la casse :-))
-------------------------
$ pushd /
/ ~
$ popd
~
$ PUSHD /
-bash: PUSHD: command not found
-------------------------
La plupart des commandes sont des fichiers exécutables, donc soumises
aux règles de casse du système de fichiers. Mais certaines commandes
sont directement intégrées dans l'interpréteur du shell, et ne sont donc
pas soumises à ces règles.
Fleuger
Feb 8, 2021, 5:37:01 AM2/8/21
to
Le 8 février 2021 à 11:27, M.V. a écrit ceci :
> On est d'accord ! Voir : <news:rvr1t9$7f6$1...@dont-email.me> et Gérard
> Niel (un autre Gérard ! ) est également d'accord 🤪
Vu !
Mais le pourquoi du man ?
man ls -> OK
man LS -> No manual entry for LS
MAN ls ->
Dans cet exemple, MAN est la commande insensible à la casse et ls
devient un argument, sensible à la casse.
--
Gérard FLEUROT
> On est d'accord ! Voir : <news:rvr1t9$7f6$1...@dont-email.me> et Gérard
> Niel (un autre Gérard ! ) est également d'accord 🤪
Vu !
Mais le pourquoi du man ?
man ls -> OK
man LS -> No manual entry for LS
MAN ls ->
Dans cet exemple, MAN est la commande insensible à la casse et ls
devient un argument, sensible à la casse.
--
Gérard FLEUROT
Fleuger
Feb 8, 2021, 5:41:27 AM2/8/21
to
[Supersedes: <rvr48b$khk$1...@dont-email.me>]
Le 8 février 2021 à 11:27, M.V. a écrit ceci :
> On est d'accord ! Voir : <news:rvr1t9$7f6$1...@dont-email.me> et Gérard
> Niel (un autre Gérard ! ) est également d'accord 🤪
Vu !
Mais le pourquoi du man ?
man ls -> OK
man LS -> No manual entry for LS
MAN ls -> OK
Le 8 février 2021 à 11:27, M.V. a écrit ceci :
> On est d'accord ! Voir : <news:rvr1t9$7f6$1...@dont-email.me> et Gérard
> Niel (un autre Gérard ! ) est également d'accord 🤪
Vu !
Mais le pourquoi du man ?
man ls -> OK
man LS -> No manual entry for LS
Gérald Niel
Feb 8, 2021, 5:55:12 AM2/8/21
to
Le Lundi 08 février 2021 à 10:27 UTC, M.V écrivait sur
fr.comp.os.mac-os.x :
> On est d'accord ! Voir : <news:rvr1t9$7f6$1...@dont-email.me> et Gérard
> Niel (un autre Gérard ! ) est également d'accord 🤪
https://www.youtube.com/watch?v=xbM5uK4dWvo
fr.comp.os.mac-os.x :
> On est d'accord ! Voir : <news:rvr1t9$7f6$1...@dont-email.me> et Gérard
> Niel (un autre Gérard ! ) est également d'accord 🤪
Fleuger
Feb 8, 2021, 6:48:43 AM2/8/21
to
Le 8 février 2021 à 11:33, pehache a écrit ceci :
> La plupart des commandes sont des fichiers exécutables, donc soumises
> aux règles de casse du système de fichiers. Mais certaines commandes
> sont directement intégrées dans l'interpréteur du shell, et ne sont donc
> pas soumises à ces règles.
Moralité : en respectant la syntaxe du chapitre NAME d'un man, on ne
> La plupart des commandes sont des fichiers exécutables, donc soumises
> aux règles de casse du système de fichiers. Mais certaines commandes
> sont directement intégrées dans l'interpréteur du shell, et ne sont donc
> pas soumises à ces règles.
devrait pas avoir de problème
man builtin
--
Gérard FLEUROT
pehache
Feb 8, 2021, 8:22:38 AM2/8/21
to
toujours en minuscules.
0 new messages