totof2000 a écrit 9656 commentaires

Tout à fait et man est une commande qui permet de savoir ce que fait une commande (exemple de la page man d'echo ). tu peux faire man man pour savoir comment utiliser la commande man (une commande récursive … ;) ).

La consignation des démarches et leur contrôle ont un coût important, souvent largement surestimé car indirect, qui n’est plus utilisé pour la améliorer la qualité de la production.

Tu veux dire sous-estimé ? Ou alors je comprends pas ta phrase.

Pourquoi de la désobéissance ? Alors qu'avant ça il y aurait beaucoup plus simple à faire en changeant nos propres comportements.

Le problème c'est que les gens en général n'en ont rien à faire du réchauffement climatique. Ils s'en inquièteront quand il sera trop tard … Donc appeler à de la désobéissance alors qu'à la base les gens ne changent même pas leur comportement pour éviter l'impact climatique, ça me fait un peu rire.

A côté de ça on a la cohérence des écvolos qui veulent agir contre le réchauffement climatique, mais qui en même temps veulent sortir du nucléaire. Là aussi il faudrait se poser les bonnes questions : à court terme quelle est l'urgence, sachant qu'on ne peut pas pour le moment lutter sur les deux fronts.

head -n -5 $file >> $file

J'ai souvenir de comportements tranges lorsque je faisais ça ….

En shell il vaut mieux éviter d'écraser un fichier en cours de traitement …

Pour ajouter exo.tex à la fin d'un fichier total2.tex :

$ cat exo.tex >> total2.tex

Bof …

moi je ferais un truc du genre cat exo1.txt exo2.txt > total;txt.

J'ai vu aussi a la télé qu'il pouvait faire chambres d’hôte et gagner encore mieux en en faisant encore moins.

Je ne suis pas sûr que tu aies réellement compris le sens de mon commentaire, et que tu t'es arrêté juste sur une phrase (ou une partie).

Il y a de plus en plus d'agriculteurs qui font de la vente directe. J'avais vu un reportage sur ce sujet; L'agriculteur qui faisait ça bossait moins, produisait moins mais vivait mieux …

J'ai essayé sous FreeBSD, de mémoire, le comportement est identique.

D'après la page man:

     The argument argv is a pointer to a null-terminated array of character
     pointers to null-terminated character strings.  These strings construct
     the argument list to be made available to the new process.  At least one
     argument must be present in the array; by custom, the first element
     should be the name of the executed program (for example, the last compo-
     nent of path).

Cordialement.

Pour moi, vous lancez toujours un bash … qui lance un autre bash (vérifiez avec ps).

Hello. Ce détail m'a échappé, et je ne l'ai pas constaté dans mes essais précédents. Qu'est-ce qui vous fait dire ça ?

Ca m'a bien soulagé le dos.

Bonjour, ça fonctionne avec un PTY.
Merci pour votre aide.

Cool, merci pour ton retour ;)

Plop!

Une piste ?

L'erreur semble venir du read de STDIN dans le père.

Possible aussi …

J'ai plus trop le temps de regarder maintenant. Fais un retour si tu arrives à quelque chose.

Je viens d'essayer. Le bash ne se ferme pas mais il se met en arrière plan. Quand tu fais fg et que tu passes une commanbde ça marche. Je pense que c'est parce que bash n'est pas invoqué depuis un terminal.

Pour info, chez moi ça marche (prompt affiché) sous freebsd:

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

#include <sys/types.h>
#include <sys/wait.h>

#define NB_PIPE 2

int main(int argc, char **argv){
  int pid;
  char *argv2[]={ NULL, NULL };
  /* Création du processus fils */
  if((pid = fork()) == -1){
     perror("fork failed\n");
     return 2;
  }

  /* Processus fils */
  if(pid == 0){
    execve("/bin/bash",argv2 ,NULL);
  }
  /* Processus père */
  else{
    wait(0);
  }
  return 0;
}

Si tu regardes la manpage de execve, tu verras que argv[0] doit correspondre au nom du fichier lancé a l'exécution et les paramètres doivent commencer a argv[1].

Regarde la page man il y a un exemple et essaie de t'en inspirer: il me semble que dans l'exemple, argv[0] est a null.

Fais un retour si c ok, ce que tu fais m'intéresse.

Ti as quoi quand tupasses les options i et l a ta commande bash ?

Peux tu stp montrer le source et le résultat ?

Pour le problème de prompt, essaie d'utiliser bash -il

Extrait de bash:

       -i        If the -i option is present, the shell is interactive.
       -l        Make bash act as if it had been invoked as a login shell (see
                 INVOCATION below).

Une autre option qui pourrait t'intéresser:

       -s        If the -s option is present, or if no arguments remain after
                 option processing, then commands are read from the standard
                 input.  This option allows the positional parameters to be
                 set when invoking an interactive shell or when reading input
                 through a pipe.

/* Connecte STDIN a l'entrée du pipe 1 */

Tu connectes une entrée à une entrée …

/* Connecte STDOUT a la sortie du pipe 2 */

puis une sortie à une sortie.

ça peut pas marcher.

Une sortie envoie ses données vers une entrée, et une entrée ne lit que depuis une sortie

Sinon:
https://linux.die.net/man/2/read

On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal. On error, -1 is returned, and errno is set appropriately. In this case it is left unspecified whether the file position (if any) changes.

Tu ne testes pas la valeur de retour de ton write.

Enfin, d'après le man de malloc:

Description
The malloc() function allocates size bytes and returns a pointer to the allocated memory. The memory is not initialized. If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free().

Ce doit être ça la cause de ton problème: pour ne pas l'avoir, tu devrais tester le nombre de caractères récupérés sur stdin ou depuis ton pipe, et n'écrire que le contenu de ton buffer. Tu éviterais le problème de l'erreur lors de la deuxième exécution (tu utilises une zone mémoire réallouée après avoir été libérée, et comme elle est pas initialisée, elle contient des résidus de tes précédentes écritures/lectures).

Je préfère la beer ration

… qui est une abération écologique.

Ok, "2/3 ans d'expérience" : ça peut vouloir dire que la personne a fait ça pendant 1 an 1/2, et pas à 100% de son temps. De plus elle n'a peut-être pas été suivie pour apprendre à faire les choses correctement. Le contexte dans lequel elle exercait ne lui a peut-être pas appris à faire les choses comme elle aurait du les faire ?

Je ne sais pas ce qui est "basique" et ce qui requiert un peu plus de connaissances, je ne sais pas si c'est moi qui place mal le curseur ou si la personne n'est pas assez compétente.

Peut-être que le besoin n'a pas été correctement qualifié ? Tu as peut-être demandé une personne avec un peu d'expérience sans préciser exactement ce que tu attendais comme expérience et comme savoir faire ?

Comme dit plus bas, si la personne ne te convient pas, il faut mieux le dire de suite, mais n'oublie pas que c'est pas forcément le presta qui est en cause (c'est peut-être le cas celà dit mais ça ce n'est pas moi qui peut te le dire).

T'inquietes, j'ai compris ce que tu voulais dire, c'est juste que cette petite faute sur un sujet linguistique était trop tentante, j'ai pas pu m'empêcher de saisir la perche😁

c'est de ne pas me faire confiance quand je lui dis qu'il a tord dans la grammaire d'une langue.

Pour la grammaire je sais pas mais pour l'orthographe il n'a peut-être pas tort.

Déjà, il faut savoir que des entreprises de service n'hésitent pas à parachuter des gens qu'elles surévaluent vis à vis de leur client. Cepenant c'est aussi la faute de certains clients qui bien souvent demandent des gens sur-qualifiés pour certains postes. Après dans beaucoup de cas ça passe, mais parfois ça passe pas, et ce n'est pas forcément la personne en poste qui est en cause : elle peut subir la situation.

Maintenant, sans en savoir plus c'est pas simple de t'aider, mais si c'est du développement que cette personne fait, essaie de lui faire faire deux ou trois trucs basiques pour voir si elle s'en sort .. si ce n'est pas le cas, parle-en avec dans un premier temps (pour essayer de savoir si la personne s'est survendue a sa société ou si c'est sa dsociété qui l'a survendue). près ce sera à toi de voir.