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

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #12 le: 31 août 2016 à 11:03:44 »
Les EDI ça existe aussi sous UNIX, tu sais ?
Je ne parlais pas de ça. Je parlais de la tradition Unix de merde, d'ailleurs tout le monde avait compris.

Sinon tu pouvais aussi me répondre que le shell est de la merde mais que les gens dotés d'un peu de sens commun font leurs scripts en perl ou autre machin indépendant de l'OS.

Accessoirement, il n'y a guère que sur les systèmes UNIX que tu as une chance de trouver un compilateur installé par défaut.
Si c'est pour avoir une merde préhistorique avec des bizarreries et des types incompatibles...

Sinon, pour revenir un peu sur le fond de ton argumentaire :Quoique tu puisses en penser, la variété des shells disponibles fait partie des avantages du système.
Et la variété des comportements de /bin/sh, c'est un avantage?

Le choix est laissé à l'utilisateur d'utiliser celui qui lui convient le mieux, tant du point de vue ergonomie que fonctionnalités.
Même si ça induit de fait des incompatibilités, c'est toujours mieux que ne pas avoir de choix et devoir subir un truc comme cmd.exe.
Mais tu n'as pas toujours le choix de ton shell de login.

Produire des scripts shell portables d'un système à l'autre, ça nécessite un effort intellectuel, mais c'est tout à fait possible.
Effort à la con, intellectualisme de merde.

Je NE veux PAS salir mon cerveau avec ça.

La plupart de ceux que j'écrivais il y a une dizaine d'années fonctionnaient de la même manière sous Linux, Solaris, AIX et UnixWare.
Je devais juste m'assurer qu'il sache sur quel système il tournait, et d'utiliser les commandes et options adéquates.
CQFD

Bon, tu arrives sur un Unix bizarre et inconnu, tu installes les machins GNU, et tu ne t'occupes plus du reste. Voilà pour la compatibilité.

Si ça ne marchait jamais, ces outils auraient été abandonnés depuis bien longtemps.
Voilà, comme Windows en fait. Cela marche assez souvent.

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #13 le: 31 août 2016 à 11:13:11 »
Ça faisait 10 ans que je n'avais plus touché de Makefile ou de code C, et il m'a fallu 10 minutes pour écrire cette beauté :
Tu ne sais pas les risques auxquels tu t'exposes!

seb@gaston:~/tmp$ cat main.c
#include "defs.h"
#include "hello.h"

void main( int argc, char *argv[] )
Grave erreur!

main doit renvoyer un int, sinon tu as
- formellement : un comportement indéfini
- en pratique : une valeur de sortie non définie

En revanche, vu que tu n'as pas besoin de argc et argv, tu peux les omettre, ça vaut mieux que d'avoir des paramètres inutilisés.

hello.o: hello.c hello.h defs.h
cc -c hello.c -o hello.o
Manque plein de choses (indication de la norme souhaitée, warnings, etc.)

Tout cela n'est pas spécifique à linux ou Unix.
« Modifié: 31 août 2016 à 11:36:36 par corrector »

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #14 le: 31 août 2016 à 11:32:32 »
Mauvais développeur(s) ?
Mauvais outils.

Je te mets au défi de justifier la sémantique des shell! Même de me l'expliquer!

seb@gaston:~/tmp$ cat ../test
#!/bin/sh

for x in *
do
echo "x=\"$x\""
done

seb@gaston:~/tmp$ ../test
x="fichier
avec retour chariot"
x="fichier avec espace"
x="fichier_normal"
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.

Et surtout comme la plupart du temps il n'y a PAS d'espace dans les noms, une erreur ne se verra pas.

Tous les utilitaires classiques peuvent être appelés en utilisant leur variante POSIX.
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 ....

C'est ça, "Unix". Pour faire quelque chose de passablement simple il faut une syntaxe complètement incompréhensible pour les débutants.

Dans ce cas, la syntaxe et les résultats sont identiques partout.
POSIX stipule plein de comportements débiles et est très limité. Déjà linux est pénible, mais alors s'il faut se restreindre aux trucs standards...

Bon, en résumé : presque TOUT est TROP compliqué sous nix.

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #15 le: 31 août 2016 à 11:52:59 »
Parce que c'est si compliqué que ça de le tester par toi même avant de chercher à l'ouvrir ?
Tu cherches vraiment la petite bête là.
Dis, tu es sérieux, là?

Tu suggères vraiment de faire une vérification avec stat suivi de open?

Tu confirmes ce que je pensais de toi.

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 7 456
  • Paris (15ème)
    • Twitter
Avis de corrector sur Unix
« Réponse #16 le: 31 août 2016 à 12:18:05 »
Sinon moi j'aime bien OSX, et j'ai des espaces dans mes fichiers :p

* Huguesdelamure sort

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #17 le: 31 août 2016 à 12:50:52 »
Je ne comprends pas cette remarque, car X n'a accès qu'à ce que le noyau veut bien lui monter.
Je ne sais pas ce que tu entends par "ce que le noyau veut bien lui monter"! N'importe quel processus par définition n'a accès qu'à ce que le noyau lui expose, mais parfois cet accès est direct; mais je me demande si tu sais faire la distinction entre un accès direct et un accès avec une intermédiation significative. Par exemple, certains périphériques donnent un accès direct, comme les port série, d'autre une construction artificielle, comme la souris PS2 du noyau.

Est-ce que /dev/mem est un accès direct pour toi?

hw/xfree86/os-support/linux/lnx_video.c :

Bool
xf86EnableIO(void)
{
#if defined(__powerpc__)
    int fd;
    unsigned int ioBase_phys;
#endif

    if (ExtendedEnabled)
        return TRUE;

#if defined(__powerpc__)
    ioBase_phys = syscall(__NR_pciconfig_iobase, 2, 0, 0);

    fd = open("/dev/mem", O_RDWR);
    if (ioBase == NULL) {
        ioBase = (volatile unsigned char *) mmap(0, 0x20000,
                                                 PROT_READ | PROT_WRITE,
                                                 MAP_SHARED, fd, ioBase_phys);
/* Should this be fatal or just a warning? */
#if 0
        if (ioBase == MAP_FAILED) {
            xf86Msg(X_WARNING,
                    "xf86EnableIOPorts: Failed to map iobase (%s)\n",
                    strerror(errno));
            return FALSE;
        }
#endif
    }
    close(fd);
#elif !defined(__mc68000__) && !defined(__sparc__) && !defined(__mips__) && !defined(__sh__) && !defined(__hppa__) && !defined(__s390__) && !defined(__arm__) && !defined(__m32r__) && !defined(__nds32__)
    if (ioperm(0, 1024, 1) || iopl(3)) {
        if (errno == ENODEV)
            ErrorF("xf86EnableIOPorts: no I/O ports found\n");
        else
            FatalError("xf86EnableIOPorts: failed to set IOPL"
                       " for I/O (%s)\n", strerror(errno));
        return FALSE;
    }
#if !defined(__alpha__)
    /* XXX: this is actually not trapping anything because of iopl(3)
     * above */
    ioperm(0x40, 4, 0);         /* trap access to the timer chip */
    ioperm(0x60, 4, 0);         /* trap access to the keyboard controller */
#endif
#endif
    ExtendedEnabled = TRUE;

    return TRUE;
}

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #18 le: 31 août 2016 à 13:02:42 »
Les EDI ça existe aussi sous UNIX, tu sais ?
Oui mais tous les élèves vont être enseignés, remplis, abrutis de débilités unixoïdes avant d'apprendre les trucs bien.

Comme make, qui est le problème et non la solution dans 99% des cas. Ou apprendre que toute grammaire doit être traitée avec lex/yacc et qu'il faut être débile pour écrire un analyseur à la main - alors que c'est le contraire, il faut être débile pour vouloir tout traiter avec un outil standard.

Accessoirement, il n'y a guère que sur les systèmes UNIX que tu as une chance de trouver un compilateur installé par défaut.
C'est bien, ça permet de compiler GCC.

Non je déconne, pourquoi pas installer GCC déjà compilé?

Si ça ne marchait jamais, ces outils auraient été abandonnés depuis bien longtemps.
Avec cet argument on justifie n'importe quoi.

Encore un petit effort et tu vas me justifier le bazar de autogen et autoconf!

Je ne sais pas si tu te rends compte de l'absurdité de ta position.

Déjà expliquer un makefile simple à un débutant, à quel moment chaque symbole est spécial, les paramètres make qui ne sont pas des paramètres shell, les multiples niveaux d'interprétation... beurk!

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #19 le: 31 août 2016 à 13:11:49 »
seb@gaston:~/tmp$ cat ../test
#!/bin/sh

for x in *
do
echo "x=\"$x\""
done

seb@gaston:~/tmp$ ../test
x="fichier
avec retour chariot"
x="fichier avec espace"
x="fichier_normal"
C'est un vrai problème quand on multiplie les tubes et qu'on traite des fichiers contenant des espaces dans leurs noms, mais il y a de nombreux moyens de le contourner, même sans faire appel aux outils GNU.
Traiter des noms de fichier contenant des espaces est le bas de l'échelle du traitement de noms de fichiers quelconques par des scripts shell.

Ensuite, tu as les retours à la ligne qui sont possibles dans un nom de fichier, mais qui vont mettre la zone si tu fais find | xargs, sauf avec l'option adéquate des GNU fileutils.

Tu as aussi le gag du nom de fichier commençant par un "-", ce qui passe avec certains utilitaires ou certaines commandes shell mais pas toutes. Avec GNU, tu as la protection "--", mais sous d'autres systèmes, je crois qu'il n'y a rien.

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #20 le: 31 août 2016 à 13:30:09 »
- utilitaires moisies qu'on n'arrive pas à combiner
Comme ?
Comme sort et ses compagnons qui consomment les fichiers triés!

La commande sort est très puissante avec plein de possibilité de séparer les champs, d'inverser l'ordre, de trier selon plusieurs champs avec plusieurs interprétation (lexicographique/numérique/"humain").

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!

Donc après avoir conçu la commande sort, tu la fous à la poubelle, et tu construit un assemblage de commandes qui vont mettre l'entrée en un format simple que toutes ces commandes comprennent!

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #21 le: 31 août 2016 à 14:04:34 »
Même si ça induit de fait des incompatibilités, c'est toujours mieux que ne pas avoir de choix et devoir subir un truc comme cmd.exe.
Je ne vois pas l'intérêt de ce genre de comparaisons. Tu pourrais aussi bien dire Unix est nul, mais Winwin est pire. Bof bof.

Produire des scripts shell portables d'un système à l'autre, ça nécessite un effort intellectuel, mais c'est tout à fait possible.
Avec des compilations conditionnelles, des variantes d'implèmentations (on compile un fichier différent selon le système), des couches d'abstraction, des contorsions... tu peux aussi faire des programmes complexes qui marchent aussi bien sous linux, *BSD, MacOS et Windows. C'est juste très très cher.

Si ça ne marchait jamais, ces outils auraient été abandonnés depuis bien longtemps.
Cela "marche", à un coût considérable!

IPv4 marche, aussi.

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #22 le: 31 août 2016 à 14:29:43 »
[HS]
J'apprécie les vraies valeurs et  HAIR/MEPRISER ne font et ne feront, dans ce sens, jamais partie des verbes utilisés pour manifester les miennes.
(entre nous, s'il est question de pensée, tu devrais fortement t'inquiéter de l'état de la tienne pour en arriver à utiliser des verbes aussi forts que ceux-ci)

Puisque l'esprit semble corrompu, as-tu songé au corps par quelques activités défoulatoires ?
[/HS]
Je ne déteste que ceux qui donnent des conseils dans un domaine où ils sont notoirement incompétents, mais qui font croire qu'ils le sont, comme les économistes, les médecins, les climatologues, etc.

corrector

  • Invité
Avis de corrector sur Unix
« Réponse #23 le: 31 août 2016 à 14:46:23 »
Assistanat ça te va comme réponse.
Non, ça NE VA PAS!

Tu n'as pas l'air de comprendre que l'assistanat correspond à donner des trucs "gratuits" à des gens, en échange de rien du tout. Cette "gratuité" étant payée par l'ensemble de la communauté productrice de valeur. (Il y a aussi une communauté destructrice de valeur, dont le travail consiste à empêcher le travail de ceux qui produisent de la valeur.)

Le travail d'un logiciel n'est pas "gratuit", il est GRATUIT.

 

Mobile View