Re: [PATCH] cabarc: Display message when extracting cab like in native.
Christian Costa <titan.costa(a)gmail.com> writes:
@@ -713,9 +716,16 @@ int wmain( int argc, WCHAR *argv[] ) argv[--argc] = NULL; } } - return extract_cabinet( buffer ); + WINE_MESSAGE("Extracting file(s) from cabinet %s\n", wine_dbgstr_a(cab_file)); + ret = extract_cabinet( buffer ); + break; default: usage(); - return 1; + ret = 1; + break; } + + cab_free(cab_file); + + return ret;
I don't think that's very useful. And freeing memory on process exit is even less useful. -- Alexandre Julliard julliard(a)winehq.org
Le 30/11/2012 11:58, Alexandre Julliard a écrit :
Christian Costa <titan.costa(a)gmail.com> writes:
@@ -713,9 +716,16 @@ int wmain( int argc, WCHAR *argv[] ) argv[--argc] = NULL; } } - return extract_cabinet( buffer ); + WINE_MESSAGE("Extracting file(s) from cabinet %s\n", wine_dbgstr_a(cab_file)); + ret = extract_cabinet( buffer ); + break; default: usage(); - return 1; + ret = 1; + break; } + + cab_free(cab_file); + + return ret; I don't think that's very useful. And freeing memory on process exit is even less useful.
I have problems this cabarc and cabinet with multi-cab I'm trying to fix. Our cabarc implementation does not display anything that make impossible to figure out what is happening. This message and some others that are only displayed when -v option is enabled (btw I don't know why we have to enable them explicitly). I don't understand why we shouldn't display standard operation messages for a command line exe as we can have native one.
Christian Costa <titan.costa(a)gmail.com> writes:
Le 30/11/2012 11:58, Alexandre Julliard a écrit :
Christian Costa <titan.costa(a)gmail.com> writes:
@@ -713,9 +716,16 @@ int wmain( int argc, WCHAR *argv[] ) argv[--argc] = NULL; } } - return extract_cabinet( buffer ); + WINE_MESSAGE("Extracting file(s) from cabinet %s\n", wine_dbgstr_a(cab_file)); + ret = extract_cabinet( buffer ); + break; default: usage(); - return 1; + ret = 1; + break; } + + cab_free(cab_file); + + return ret; I don't think that's very useful. And freeing memory on process exit is even less useful.
I have problems this cabarc and cabinet with multi-cab I'm trying to fix. Our cabarc implementation does not display anything that make impossible to figure out what is happening. This message and some others that are only displayed when -v option is enabled (btw I don't know why we have to enable them explicitly). I don't understand why we shouldn't display standard operation messages for a command line exe as we can have native one.
It's standard behavior on Unix, so that tools can be used from scripts without being drowned in a lot of irrelevant output. If the goal is to debug things you can enable debug output. -- Alexandre Julliard julliard(a)winehq.org
Le 30/11/2012 23:12, Alexandre Julliard a écrit :
Christian Costa <titan.costa(a)gmail.com> writes:
Le 30/11/2012 11:58, Alexandre Julliard a écrit :
Christian Costa <titan.costa(a)gmail.com> writes:
@@ -713,9 +716,16 @@ int wmain( int argc, WCHAR *argv[] ) argv[--argc] = NULL; } } - return extract_cabinet( buffer ); + WINE_MESSAGE("Extracting file(s) from cabinet %s\n", wine_dbgstr_a(cab_file)); + ret = extract_cabinet( buffer ); + break; default: usage(); - return 1; + ret = 1; + break; } + + cab_free(cab_file); + + return ret; I don't think that's very useful. And freeing memory on process exit is even less useful.
I have problems this cabarc and cabinet with multi-cab I'm trying to fix. Our cabarc implementation does not display anything that make impossible to figure out what is happening. This message and some others that are only displayed when -v option is enabled (btw I don't know why we have to enable them explicitly). I don't understand why we shouldn't display standard operation messages for a command line exe as we can have native one. It's standard behavior on Unix, so that tools can be used from scripts without being drowned in a lot of irrelevant output. If the goal is to debug things you can enable debug output.
Ok. I will use WINE_TRACE instead. So that would be better to remove -v option and turn all printf dependant of this option to WINE_TRACE, right ?
Christian Costa <titan.costa(a)gmail.com> writes:
Ok. I will use WINE_TRACE instead. So that would be better to remove -v option and turn all printf dependant of this option to WINE_TRACE, right ?
Of course not. Debug options are for debugging the app, -v is for normal users who want to see the details of what it's doing. -- Alexandre Julliard julliard(a)winehq.org
Le 30/11/2012 23:38, Alexandre Julliard a écrit :
Christian Costa <titan.costa(a)gmail.com> writes:
Ok. I will use WINE_TRACE instead. So that would be better to remove -v option and turn all printf dependant of this option to WINE_TRACE, right ? Of course not. Debug options are for debugging the app, -v is for normal users who want to see the details of what it's doing.
Ok. Thanks.
participants (2)
-
Alexandre Julliard -
Christian Costa