David Marec a écrit 472 commentaires

Les ioctl sont des commandes standards envoyées depuis un logiciel vers un driver,
mais avec un contenu qui peut être fortement variable.
Le format en lui même de la fonction ioctl ne doit pas avoir d'impact sur ce genre de message d'erreur.

Tout à fait, un rapide coup d’œil et cela me semble être le cas ici, c'est l'erreur par défaut qui lancée lorsqu'un appel ioctl demandé n'est pas reconnu.
- l'opération unlocked_ioctl appelle ibioctl de sys/osfuncs.c, la liste de commandes comprises se trouvent dans le grand switch case . -

… reste à creuser pour savoir qui provoque cette erreur.

je dirais que ce message d'erreur:
Opération de contrôle d'E / S inappropriée
est le même que celui que j'ai quand j'essaie de faire un printf (en bourne) dans un script
dont stdout à probablement été fermé.

Ah bon, on ne se prend pas juste un SIGPIPE dans les dents dans ce cas là ?

Par exemple, je n'utilise que la BSD-2 clause pour ma part, pour à peu près tout ce qui n'est pas en lien avec mon activité professionnelle.

Il suffit de mettre son nom dans le copyright.

La clause n°3 a du être abandonnée partout, maintenant.

C'est con, on aurait pu faire «graine de lin», du coup.
Bon, «filet de fayot» alors ?

voila si dans mon code il y a un segfault, alors mon programme attrape le signal SIGSEGV et > lance ma fonction void gestionnaire(int num) grace à la fonction sigaction().

Attention, en matière de signaux, on ne peut pas tout faire, consultez la page de man 7 signal pour connaitre les fonctions que vous pouvez utiliser dans un handler.

Mais au bout de combien de temps le noyau va tuer mon processus ?

D'une part, ce n'est pas une question de temps et surtout, il ne va pas tuer votre processus.
Le séquenceur (donc le noyau pour répondre à la deuxième question), va suspendre le processus pour donner la main au code du gestionnaire de signal, puis, reprendre le processus là où vous l'avez laissé.

Dans le cas d'un SIGSEGV vous pouvez entrer dans une boucle infinie, terminez par un abort, quoiqu'il arrive.

Non, si ta source est plus petite que str, le dernier caractère ne sera pas écrit…
et rien ne prouve qu’il vaille '\0'

Man strncpy:

If the length of src is less than n, strncpy() writes additional null bytes
to dest to ensure that a total of n bytes are written.

Donc, si la source est plus petite que la cible, il remplira la cible de 0.
Si elle est égale, le caractère null est inclu.
Sinon, il n'y avait pas assez de place pour copier la source en entier.

Pourquoi astuce? :-)

… technique du «here-doc».

Pas de cat

Le principe se comprend mieux avec cat ( enfin, j'espère ).

et apostrophes simples autour du EOF dans l'ouverture du document ad hoc

En pratique, c'est utilisé pour, justement, utiliser des variables du shell. Sinon, l'intérêt est limité.

en utilisant l'astuce cat << EOF

#!/bin/sh

echo "script python ______________>"
cat << EOF | python

# This program adds two numbers

num1 = 1.5
num2 = 6.3

# Add two numbers
sum = float(num1) + float(num2)

# Display the sum
print('The sum of {0} and {1} is {2}'.format(num1, num2, sum))

num = 7

# uncomment to take input from the user
#num = int(input("Enter a number: "))

factorial = 1

# check if the number is negative, positive or zero
if num < 0:
        print("Sorry, factorial does not exist for negative numbers")
elif num == 0:
        print("The factorial of 0 is 1")
else:
        for i in range(1,num + 1):
                factorial = factorial*i
        print("The factorial of",num,"is",factorial)
EOF


echo voili voilou

ce qui donne:

script python ______________>
The sum of 1.5 and 6.3 is 7.8
('The factorial of', 7, 'is', 5040)
voili voilou

---

J'ai pris des exemples au pif

Oui, un test utile serait le le suivant:

if(strncpy(str, source, n)[n-1] != '\0'){
    printf("ran out of room.\n");
}

Et sous FreeBSD,

david@poudriere:~ % which diff
/usr/bin/diff
david@poudriere:~ % cat /usr/src/usr.bin/diff/Makefile 
# $FreeBSD: stable/12/usr.bin/diff/Makefile 334894 2018-06-09 20:24:17Z bapt $

.include <src.opts.mk>

PROG=   diff
SRCS=   diff.c diffdir.c diffreg.c xmalloc.c pr.c

HAS_TESTS=
SUBDIR.${MK_TESTS}+= tests

.include <bsd.prog.mk>

A noter que le traitement sur répertoires et celui sur fichiers sont bien séparés.
Le test S_ISREG sur stat(2) n'est effectué que dans le premier cas; aussi diff bloque comme sous linux dans le deuxième.

Ce qui m'a fait supposer que ce comportement est voulu par la norme. Mais je ne l'ai pas trouvé énoncé de manière claire.

Eh bien, désolé, mais il va falloir supprimer cette traduction.

Attendons qu'ils demandent d'activer le fameux article 13 de la toute récente directive européenne.

Même pas cap' !

ha! Je m'en vais de ce pas faire un svn diff sur /usr/src .

C'est 127.0.0.1 ?

Non, ::1/128.

À compter d'aujourd'hui, celui ou celle qui aura la série continue de dépêches la plus longue

Hum, Il n'y pas eu de dépêches sur la sortie de FreeBSD-12, ni sur les autres BSD, d'ailleurs. Je peux faire long.

L'accès et le contrôle sur tout ?
Oui. Sur tout. Le domaine linuxfr.org, nos comptes TuxFamily ou GitHub par exemple, les accès root sur > nos serveurs physiques dans deux datacenters,

Enfin! Enfin, on pourra installer le bousin sur un vrai OS de qualité.

et sur nos conteneurs lxc,

'connais pas, on collera le tout dans des jails ZFS.

Comme l'explique Gérald, un shell va exécuter ce qui se trouve entre entre les $( … ), ou sous son autre forme, entre des apostrophes.

` commandes à exécuter `

david:~>cat commandes
ls -l commandes
echo coucou

david:~>`grep "ls" commandes`
-rw-r--r--  1 david  wheel  29 30 mars  09:16 commandes

Par contre, si sous un terminal le presse-papier n'existe pas stricto-sensu, le copier-coller existe, lui.
Il faut sélectionner un texte avec la souris et le coller en appuyant sur le bouton droit (ou milieu, ou les deux boutons selon les OS) voire avec la séquence ctrl-insert.
Pour que cela fonctionne sous vim, il faut configurer la souris en mode visual:

:set mouse=v


Et encore, il aurait été de bon ton d'expliciter l'instanciation de make_pair<> .

Il faudrait expliquer en quoi v représente une paire en python.
A vue de nez, c'est un tableau à au moins deux éléments.

En terme d'expressivité et lisibilité, je trouve que la version Python s'en sort beaucoup beaucoup mieux.

Si le dictionnaire contient des paires, non.

Se nommer UnixSticker et ne pas proposer le moindre ×BSD, si ce n'est qu'un petit échantillon dans le pack Ultimate …

A mettre dans la même catégories que "ne pas gérer la mémoire".

• ne pas toujours contrôler le retour des fonctions, notamment les fonctions de base, par exemple {str|mem}cpy et cie.

sur un fichier, peut-être, mais comment il fait ça avec un flux sur stdin
(dont la taille est potentiellement plus large que tout la mémoire disponible pour le système) ?

Il s'agit alors d'une pipe dont la taille des buffers sera limitée à 64K (4K de base, soit une page, de mémoire).
tail va, lui, créer une chaîne de buffer, chacun limité, il me semble, au BUFSIZ de stdio.
( 1KB, je crois )

Donc, oui, tail doit attendre la fin du flux et ça peut devenir un problème.
Mais ce cas est hautement improbable avec notre sortie de ls;
mieux, si ce risque existe, un faut revoir complètement le principe, le nœud problème se situant alors en amont de tail ou de head, AMHA.

Par contre, avec tail, tu dois parcourir tout le flux pour n'en garder que la fin

Non, pas lorsque l'entrée est un fichier standard.

tail remplit un buffer en remontant depuis la fin du fichier, puis le parcours à la recherche d'une fin de ligne en marche arrière à coup de memrch.

Et effectivement le code me semble correct.

Non, tant que le shell utilisé n'est précisé, ce code n'est pas correct.

Voire, inutile de demander un -r à ls, utiliser tail plutôt que head à la place.

ls -1 | tail -1 | cut -d '.' -f 1

donne la valeur, si le format de fichier est nnnn.YYYY

J'espere que vous avez compris mon probleme.

En fait, non.
Je n'ai pas compris si le comportement des sockets, soit deux flux différents en lecture et écriture, vous convient ou pas.

Si oui, et que vous souhaitez communiquer entre deux process locaux, utiliser les sockets UNIX, plutôt que TCP ou UDP, voire une socketpair.

Si non, regardez du coté des shared memory (shm).

La deuxième solution est la recherche du dernier index crée, que l'on peut voir comme un complément
au fichier d'index.

#!/bin/sh

PREFIX="TOTO"

ls ${PREFIX}.*.ext 1>/dev/null 2>1
if [ ${?} -eq 0 ]; then
LASTID=`ls -1 ${PREFIX}.*.ext | tail -1 | cut -d . -f 2`
LASTID=${LASTID:+`expr ${LASTID} + 1 `} 
else
LASTID=${LASTID:-0}
fi
printf "${PREFIX}.%05d.ext\n" ${LASTID}
exit 0

ls trie par défaut par ordre alphabétique, il suffit donc d'extraire avec cut la partie située entre les deux points du dernier élément ( tail ) et de l’incrémenter. Le test est là pour pouvoir créer un premier fichier, ls renvoie une erreur dans ce cas.

ex: touchsh ./ceScript.sh

En ce qui concerne le deuxième cas, si on maîtrise l'environnement, on peut utiliser stocker dans un fichier le dernier index fourni:

#!/bin/sh

[ -w "./last.env" ] && . ./last.env
LASTID=${LASTID:+`expr ${LASTID} + 1 `} 
LASTID=${LASTID:-0}
echo "LASTID=${LASTID}" > last.env
printf "FILES.%05d.ext\n" ${LASTID}
exit 0

ex: touch `./ceScript.sh`
L'inconvénient est que l'on repart à zéro si le fichier d'index est perdu, mais l'on peut ajouter des contrôles pour éviter d'écraser un fichier déjà existant.

L'avantage est que l'on garde l'indexation même si les derniers fichiers sont effacés, ce qui va créé des trous.

C'est généralement ce cas là que j'utilise dans mes scripts, combiné avec une recherche en cas de doute ou d'erreur comme la demande de création d'un fichier existant.