Discussion :

[J4e8a16n]

Bonjour à tous,

Peut-on récupérer le nom d'un fichier redirigé en stdin sans utiliser argv?

monexe < nomdufichier.txt

[plxpy]

Sous Unix/Linux, j'ai bien peur que non.

C'est le shell depuis lequel tu tapes cette ligne de commande qui voit "<nomdufichier.txt", ouvre le fichier et écrit son contenu sur l'entrée standard de "monexe" (qu'il lance au préalable).

"monexe" n'a aucune connaissance du (nom du) fichier utilisé (argc vaut 1 et argv[0], "monexe"). Avec la banalisation des fichiers sous Unix/Linux, "monexe" n'a aucun moyen de faire la différence entre la redirection que tu utilises et des "choses" que tu taperais au clavier (jusqu'à un CTRL-D qui marque la fin de fichier).

[Médinoc]

Sous un Windows récent, il doit y avoir moyen de tricher, mais c'est le genre de chose que tu n'es pas censé faire.

Quel est ton problème exactement?

[Invité(e)]

Bonjour,
Sous linux, le répertoire /proc/numero_du_process peut donner ce genre d'informations.

[ram-0000]

Tu ne peux pas à moins de tricher. C'est le rôle du shell que de mettre le contenu du fichier dans le flux stdin.

et imagine une commande genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

monexe < `cat fichier.txt | grep "toto"`

Tu vas récupérer quoi ?
Est-ce que ce que tu risques de récupérer (peut être) aura un sens ?

[Melem]

Sous un Windows récent, il doit y avoir moyen de tricher, mais c'est le genre de chose que tu n'es pas censé faire.

GetCommandLine retourne la ligne de commande entière. Je ne sais pas si le &lt; ... fait aussi partie de la "ligne de commande". A vérifier.

[ram-0000]

GetCommandLine retourne la ligne de commande entière. Je ne sais pas si le &lt; ... fait aussi partie de la "ligne de commande". A vérifier.

Non, à partir du signe <, c'est géré par le shell et donc cela ne va pas au programme appelé. Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#include <Windows.h>
int _tmain(int argc, _TCHAR* argv[])
{
	const wchar_t *cmd = GetCommandLine();
	_tprintf(L"Command = [%s]\n", cmd);
	return 0;
}

pour

console.exe < fichier_qui_existe.txt

cela donne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Command = [console ]

Je pense qu'il n'y a pas moyen de récupérer la commande complète dans ce cas là (sauf à tricher avec le système)

[Médinoc]

En fait, je pensais plutôt à GetFileInformationByHandle() sur le handle de l'entrée standard...

[Melem]

Non, à partir du signe <, c'est géré par le shell et donc cela ne va pas au programme appelé.

Oui je sais. Ce dont je n'étais pas sûr c'est si GetCommandLine retournait la ligne de commande telle que tapée dans le shell ou la "vraie ligne de commandes" (chemin de l'exe + arguments). Maintenant, nous savons que c'est la seconde .

[plxpy]

Pour Linux, mabu m'a filé le doute avec le pseudo file system /proc mais ce que j'avançais et ce que ram-0000 confirmait n'est pas mis en défaut.

J'ai écrit quelques lignes de code, autant vous en faire profiter :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
 
int main(int argc,char *argv[])
{
    char   commande[128];
    char   cmdname[64];
    char  *ptr = commande;
    FILE  *cmdfp;
    pid_t  pid = getpid();
    int i;
 
    sprintf(cmdname,"/proc/%lu/cmdline",(unsigned long)pid);
    cmdfp = fopen(cmdname,"r");
    fgets(commande,128,cmdfp);
    fclose(cmdfp);
 
    /*************************
 
    resultat (partiel) de "man proc"
 
       /proc/[number]/cmdline
              This holds the complete command line for the process, unless the
              process is a zombie.  In the latter case, there  is  nothing  in
              this  file:  that  is, a read on this file will return 0 charac‐
              ters.  The command-line arguments appear in this file as  a  set
              of null-separated strings, with a further null byte ('\0') after
              the last string.
 
    **************************/
 
    for (i=0;;i++)
    {
        printf("arg %d : %s\n",i,ptr);
        ptr = strchr(ptr,'\0');
        if (ptr[1] == '\0') break;
        else                ptr++;
    }
}

Voici différents résultats, sous Ubuntu (mon exe s'appelle "stdin") :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
plx@sony:~$ ./stdin un 2 trois 4
arg 0 : ./stdin
arg 1 : un
arg 2 : 2
arg 3 : trois
arg 4 : 4
plx@sony:~$ ./stdin 1 deux 3 quatre < stdin.c
arg 0 : ./stdin
arg 1 : 1
arg 2 : deux
arg 3 : 3
arg 4 : quatre

On ne récupère pas plus de choses en allant chercher sous /proc qu'en examinant argc/argv.

Pour continuer sur ce sujet, ce n'est pas seulement les redirections qui ne sont pas vues par l'exécutable mais aussi tous les "wild-cards" (*, ?, etc...) qui sont traités par le "shell interactif" et c'est pour cela que sous DOS, il y a bien longtemps (je n'ai pas réessayé depuis), un "del *.*" demandait confirmation ("del" voyait le "*.*") et que, sous Linux/Unix, 'un "rm *" ne POUVAIT pas faire la différence entre "rm *" et "rm" suivi de tous les fichiers du répertoire courant.