get working directory

Version imprimable

12/01/2016, 15h40
r0d

get working directory

Salut,

je bloque sur un truc tout bête, peut-être quelqu'un aura une idée.

Je suis dans un projet de test, qui utilise le framework de test de boost (boost::unit_test).
L'exécutable que je veux tester se trouve au même endroit que l'exécutable qui contient les tests. Je souhaite donc récupérer le "working directory" (ou l'endroit où se trouve l'exécutable, dans mon cas c'est la même chose) du code de test.
Problèmes:
- je ne veux pas hardcodé le path du working directory car plusieurs personnes doivent pouvoir lancer les tests et chacun a un environnement différent, y compris des O.S. différents.
- le code doit être portable, au moins linux et windows. Donc je ne peux pas utiliser GetWorkingDirectory().
- l'exécutable généré, celui qui exécute les tests, utilise le framework boost::unit_test, je n'ai donc pas de main(), puisque ce main() est automatiquement généré par le framework. Je ne peux donc pas récupérer argv[0].

J'ai pas mal cherché. Du côté de boost::filesystem::current_path() par exemple, mais cette fonction retourne le path du fichier source (.cpp ou .h), et non le "working directory".

Quelqu'un a une idée?
12/01/2016, 15h50
Bousk

Hello,
l'API C getcwd http://linux.die.net/man/3/getcwd ne convient pas ? C'est au moins sous Unix. Sous Windows tu as _getcwd https://msdn.microsoft.com/en-us/library/sf98bd4y.aspx
Plus portable je pense pas que tu trouves, va falloir écrire ta propre méthode et l'implémenter sur les différents OS amha :)

D'après la doc de boost::filesystem http://www.boost.org/doc/libs/1_60_0...reference.html current_path devrait être le bon résultat

Citation:

Returns: The current working directory path, as if by ISO/IEC 9945 getcwd(). is_absolute() is true for the returned path.

Throws: As specified in Error reporting.

[Note: The current_path() name was chosen to emphasize that the return is a path, not just a single directory name.

The current path as returned by many operating systems is a dangerous global variable. It may be changed unexpectedly by a third-party or system library functions, or by another thread. —end note]
12/01/2016, 16h27
r0d

Hmm oui, en fait mon problème venait d'un dev facétieux qui a modifié les settings du projet visual studio, notamment le "Working Directory"... :evilred:
Donc en fait, current_path() fera l'affaire.

:merci:
12/01/2016, 17h02
dragonjoker59

Méfie-toi, avec ce que VisualStudio met. Par défaut c'est le dossier de build. Je ne fie plus à ce que VS a défini.
Si tu veux le dossier de l'exécutable, je te conseille de passer par argv[0].
De plus il me semble que boost.Test fournit ce qu'il faut à ce niveau là
14/01/2016, 05h05
koala01

Salut,

Citation:

Envoyé par dragonjoker59

Méfie-toi, avec ce que VisualStudio met. Par défaut c'est le dossier de build. Je ne fie plus à ce que VS a défini.
Si tu veux le dossier de l'exécutable, je te conseille de passer par argv[0].
De plus il me semble que boost.Test fournit ce qu'il faut à ce niveau là

En fait, oui, pour autant que je sache, il est tout à fait possible d'écrire sa propre fonction main avec boost::unit_test. Mais je crois que cela se fait au dépends d'autres facilités, comme l'auto-enregistrement des tests cases.

En plus, on peut assez facilement envisager le fait que chaque fichier *.cpp implémentant des tests unitaires soit compilé en une application unique, même si certains (tous :question:) sont composés de différents tests cases. Et, dans ce cas, cela commence peut être à devenir compliqué à gérer si le besoin de connaitre le dossier de travail est présent dans plusieurs fichiers d'implémentation :P

Enfin, bon... (AUCAKOU) : si l'enregistrement manuel des suites de tests est envisageable, la fonction à utiliser pour récupérer argv est -- si l'on en croit cette page -- la fonction test_suite* init_unit_test_suite( int /*argc*/, char* /*argv*/[] )
14/01/2016, 09h56
white_tentacle

Citation:

Envoyé par dragonjoker59

Si tu veux le dossier de l'exécutable, je te conseille de passer par argv[0].

argv[0] ne contient pas forcément le dossier de l’exécutable, mais plutôt le nom sous lequel le programme a été invoqué (ce peut-être un lien symbolique, par exemple, ou quelque chose de la forme ./ma_commande).

Hors de Boost.Test, j'utilise GetModuleFileName sous Windows, et /proc/<pid>/exe sous Linux:

Code:

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
Path File::GetWorkingDirectory()
{
	Path l_return;
 
#if defined( _WIN32 )
 
	TCHAR l_path[FILENAME_MAX];
	DWORD l_result = GetModuleFileName( NULL, l_path, _countof( l_path ) );
 
	if ( l_result )
	{
		l_return = l_path;
	}
 
#elif defined( __linux__ )
 
	char l_path[FILENAME_MAX];
	std::stringstream l_stream;
	l_stream << "/proc/" << getpid() << "/exe";
	int l_bytes = std::min< std::size_t >( readlink( l_stream.str().c_str(), l_path, sizeof( l_path ) ), sizeof( l_path ) - 1 );
 
	if ( l_bytes > 0 )
	{
		l_path[l_bytes] = '\0';
		l_return = l_path;
	}
 
#else
#	error "Unsupported platform"
#endif
 
	l_return = l_return.GetPath();
	return l_return;
}

14/01/2016, 11h45
Médinoc

@dragonjoker59: La seule chose qui me choque là-dedans, c'est le nom de la fonction: Tu devrais l'appeler GetExecutableDirectory() ou un truc du genre à la place, parce que le terme "working directory" désigne le répertoire courant (celui retourné par getcwd()) qui n'est pas garanti être celui de l'exécutable (et si l'exécutable est dans le PATH, il a de grandes chances de ne pas l'être).
14/01/2016, 12h33
dragonjoker59

@Medinoc: tu as raison, je m'en occupe derechef.