Auteur Sujet: Avis de corrector sur Unix  (Lu 12292 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 34 642
    • Twitter LaFibre.info
Avis de corrector sur Unix
« Réponse #60 le: 31 août 2016 à 21:19:44 »
Moi je sais comment fonctionne l'anti-virus sous OS X :


corrector

  • Invité
Avis de corrector sur Unix
« Réponse #61 le: 31 août 2016 à 22:28:00 »
C'est le système de types de Caml!

seb

  • Pau Broadband Country (64)
  • Client SFR fibre FTTH
  • *
  • Messages: 515
  • FTTH 100/50 Mbps sur Pau (64)
Avis de corrector sur Unix
« Réponse #62 le: 31 août 2016 à 23:34:25 »
Non, tu ne sais pas de quoi tu parles - une fois de plus.

Il y a de nombreux cas où un shell de login ne peut pas être modifié, dès que le /etc/passwd n'est pas accessible directement.
Ben non!

TCSH: Startup and shutdownAucune mention de .profile

Caramba, encore raté!
Comme je sais lire, je déduis de ces informations que c'est le fichier .login qu'il faut modifier dans ce cas.
Et surprise (mais en fait pas), ça fonctionne :
Citer
root@gaston:~# su - toto
gaston:~% echo "exec /bin/bash -l" > .login
gaston:~% logout
root@gaston:~# su - toto
toto@gaston:~$
C'est que je suis un véritable hacker, moi.

Il n'y a vraiment que dans le cas où l'administrateur aura explicitement cherché à interdire le shell que ça ne fonctionnera pas.
En somme l'exception qui confirmera la règle que tu peux changer de shell si tu le souhaites.


corrector

  • Invité
Avis de corrector sur Unix
« Réponse #63 le: 31 août 2016 à 23:40:34 »
Mais tu ne vois pas quel est le souci quand on utilise open après access.

seb

  • Pau Broadband Country (64)
  • Client SFR fibre FTTH
  • *
  • Messages: 515
  • FTTH 100/50 Mbps sur Pau (64)
Avis de corrector sur Unix
« Réponse #64 le: 31 août 2016 à 23:55:39 »
Mais tu ne vois pas quel est le souci quand on utilise open après access.
Non, clairement pas.

Car si j'avais des fichiers qui changeaient de type en l'espace de quelques microsecondes je ne me dirais pas que l'appel open() est mal fichu, mais m'interrogerais plutôt sur la raison de ces changements, et sur l'opportunité de lancer des traitements sur des données aussi instables.

Citation de: corrector
Manque plein de choses (indication de la norme souhaitée, warnings, etc.)
On se fout pas mal de la qualité de mon code C ou des options de compilation, car elles n'étaient pas l'objet de ton "défi" :
Citation de: corrector
- merdicité extrême de make (je vous mets au défi d'écrire un makefile faisant correctement ce que fait automatiquement n'importe quel compilateur intégré à la base : recompiler ce qu'il faut recompiler - même avec les extensions GNU)
Le Makefile que j'ai pondu en deux minutes répond très exactement à ce cahier des charges.

Citation de: corrector
Donc il faut TOUJOURS penser à mettre des quotes autour d'un "paramètre", désolé je ne trouve pas ça naturel et complètement débile. Et en pratique il y a des scripts qui se chient dessus si un paramètre contient des espaces.
Naturel ou pas, protéger ses variables par des guillemets en shell, ça fait partie des bonnes pratiques.
Ceux qui ne suivent pas les bonnes pratiques d'un langage de programmation sont de mauvais développeurs, ce n'est pas plus compliqué que ça, et n'a rien à voir avec les qualités et défauts intrinsèques du langage de programmation concerné.

Citation de: corrector
Justement, la variante POSIX de la commande cp ne connait pas l'option -a, et donc la seule façon fiable de copier est tar ... | tar ....
Mais un cp -a n'est pas, et n'a jamais été, une façon fiable de copier un fichier !
À moins que tu considères que l'attribut atime d'un fichier n'ait aucune valeur.

Citation de: corrector
Est-ce que /dev/mem est un accès direct pour toi?
Xorg n'a plus accès à la mémoire du système au travers de cette interface, alors en quoi est-ce gênant ?

Citation de: corrector
Après avoir appris toutes ces options puissantes, tu te dis qu'évidemment uniq et comm vont accepter les mêmes options. Et bien non!
Je me dis surtout que je ne vois pas le rapport avec la choucroute :
Citation de: corrector
- utilitaires moisies qu'on n'arrive pas à combiner

Citation de: corrector
l y a énormèment de choses implicites en shell :

Tous tes exemples sont évidents pour moi, mais c'est peut être parce que j'ai appris à marcher (comprendre les bases du shell) avant d'essayer de courir (développer des scripts).
« Modifié: 01 septembre 2016 à 01:46:30 par seb »

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #65 le: 01 septembre 2016 à 09:16:05 »
Car si j'avais des fichiers qui changeaient de type
Non, jamais. Un fichier peut changer de contenu, être tronqué, étendu, mais il ne change JAMAIS de type :

- un fichier régulier reste un fichier régulier
- un répertoire reste un répertoire
- une FIFO nommée reste une FIFO nommée
- une socket UNIX reste une socket UNIX (bon ce type-là, on peut pas le open de toute façon)
- un périphérique reste un périphérique (du même type, de mêmes numéros)

Par contre, un chemin (un nom) peut désigner une chose puis une autre.

En Unix tradi, tu as bien un moyen simple pour ouvrir un fichier uniquement si c'est un répertoire (l'option O_DIRECTORY) mais pas uniquement si c'est un fichier normal!!!

Et toi, tu trouves ça acceptable, parce que tu n'y comprends rien.

en l'espace de quelques microsecondes
Comment peux-tu garantir qu'il ne s'écoule pas plus longtemps?

Tu ne peux pas. La plupart du temps, il ne s'écoulera qu'un temps trivial. Parfois, le thread unique du processus sera suspendu, et il s'écoulera beaucoup plus de temps.

je ne me dirais pas que l'appel open() est mal fichu, mais m'interrogerais plutôt sur la raison de ces changements, et sur l'opportunité de lancer des traitements sur des données aussi instables.
Oui, parce que tu ne sais pas programmer.

Tu es parfaitement incompétent. Ce n'est pas une attaque, c'est un constat.

L'espace des noms de fichier est partagé, comme une variable globale. Les autres processus peuvent modifier les noms de fichiers à tout moment.

Tu peux croiser les doigts, mais tu n'as pas de garantie. Donc tu ne peux pas assurer la sécurité.

Mais tu ne comprends RIEN à la sécurité informatique, donc peu importe!

On se fout pas mal de la qualité de mon code C
Non. Ton code est incorrect et tu ne connais pas Unix, sinon tu saurais que tout processus a une valeur de retour. C'est un des premiers trucs qu'on apprend!

D'ailleurs make lui-même utilise cette valeur de retour : si elle est non nulle, il s'arrête parce que ça indique une erreur. Si tu ignores cela, c'est que tu ne connais pas le fonctionnement de make.

ou des options de compilation,
Tu méconnais l'importance des options parce que tu ne sais pas programmer.

Les bonnes options t'informent de ce genre d'erreur.

car elles n'étaient pas l'objet de ton "défi" :Le Makefile que j'ai pondu en deux minutes répond très exactement à ce cahier des charges.
Non. Déjà tu répliques dans un fichier externe les dépendances qui sont déjà indiquées dans le code source. Si tu trouve ça bien, tu ne comprends vraiment rien à la programmation et à l'informatique.

Si tu supprimes le #include dans le .c et le fichier .h, make va refuser de compiler ton programme.

Cela n'arrive pas dans un vrai environnement de programmation qui n'est pas cautionné par les gens ... comme toi.

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 496
  • Malissard (26)
Avis de corrector sur Unix
« Réponse #66 le: 01 septembre 2016 à 09:22:23 »
Tu chipotes : tu peux faire un void main() et sortir avec exit(valeur).

(relance la roue et part en courant)

eruditus

  • Client Orange adsl
  • Modérateur
  • *
  • Messages: 9 899
Avis de corrector sur Unix
« Réponse #67 le: 01 septembre 2016 à 09:25:00 »
Tout à fait. Personnellement, je trouve cette méthode bien plus élégante. Et maintenant, on va laisser réfléchir corrector sur l'élégance de cette solution. :)

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 496
  • Malissard (26)
Avis de corrector sur Unix
« Réponse #68 le: 01 septembre 2016 à 09:26:31 »
:/ed faut pas pousser non plus
yy
p
ed faut pas pousser non plus
:wq!
:D
Ensuite faut pas avoir honte de voir le regard des petits jeunes qui disent, "tu sais qu'ils ont inventé Word pour le traitement de texte ?"

Tu leur répond qu'il y a Latex pour avoir un doc avec une vraie mise en forme.

#TeamVieux

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #69 le: 01 septembre 2016 à 09:32:41 »
Tu chipotes : tu peux faire un void main() et sortir avec exit(valeur).

(relance la roue et part en courant)
Et non, en tout pas de façon conforme :

Citer
5.1.2.2.1 Program startup

1 The function called at program startup is named main. The implementation declares no
prototype for this function. It shall be defined with a return type of int and with no
parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though any names may be
used, as they are local to the function in which they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent;9) or in some other implementation-defined manner

ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256

Bien sûr, un compilateur peut définir d'autre prototypes autorisés, notamment en Unix, la forme à trois paramètres avec char **envp.

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #70 le: 01 septembre 2016 à 09:44:58 »
Naturel ou pas, protéger ses variables par des guillemets en shell, ça fait partie des bonnes pratiques.
Sauf dans le seul shell pas trop mal conçu (zsh).

Ne pas demander au programmeur ce genre d'attention permanente, ça fait partie des bonnes pratiques de conception d'un outil de programmation. Ce que tu ne peux pas savoir puisque tu ne sais pas programmer!

En plus, même avec les quotes, si tu utilises des utilitaires ordinaires prenant des noms de fichiers en ligne commande, tu vas avoir quelques difficultés avec les noms de fichiers commençant par "-". Le shell aura du mal à te protéger de ça, puisqu'il n'y a pas de convention universelle pour quoter "-" dans un argument en ligne de commande.

Ceux qui ne suivent pas les bonnes pratiques d'un langage de programmation sont de mauvais développeurs, ce n'est pas plus compliqué que ça, et n'a rien à voir avec les qualités et défauts intrinsèques du langage de programmation concerné.
C'est cela oui.

Si un outil demande une attention constante à des choses peu intuitives qui n'existent dans aucun langage de programmation normal... j'abandonne. Je pense que tu trolles.

Mais un cp -a n'est pas, et n'a jamais été, une façon fiable de copier un fichier !
Ah bon, alors quelle est la façon fiable de copier un fichier?

À moins que tu considères que l'attribut atime d'un fichier n'ait aucune valeur.
Bien évidemment.

Qui pense que l'attribut atime d'une copie d'un fichier n'a pas aucune valeur?

Xorg n'a plus accès à la mémoire du système au travers de cette interface, alors en quoi est-ce gênant ?
Tu me dis que si une pratique n'existe plus, ça n'a pas d'importance qu'on l'ait niée à l'époque?

Tu dis que maintenant Xorg ne peut plus attaquer le noyau?

Tu dis donc qu'il n'est plus nécessaire de désactiver Xorg pour la sécurité d'un système?

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #71 le: 01 septembre 2016 à 09:50:34 »
Tu leur répond qu'il y a Latex pour avoir un doc avec une vraie mise en forme.

#TeamVieux
Vous avez remarqué que les mathématiciens qui publient l'utilisent et que beaucoup de physiciens, non?

Cela ne vous pique pas parfois un peu les yeux?

 

Mobile View