Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: How to find return code/exit code after sending a mail command
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Jeremy Nicoll via curl-users <curl-users_at_cool.haxx.se>
Date: Mon, 12 Oct 2020 10:58:25 +0100
On Mon, 12 Oct 2020, at 08:32, Daniel Stenberg via curl-users wrote:
> On Sun, 11 Oct 2020, Jason Liam via curl-users wrote:
>
> > int x = WinExec(command, SW_HIDE);
> > std::cout<<"code" <<x<<std::endl;
> >
> > And the output on the console shows *code:33*
> > *Is this the return code of the command.Can i use this to check the success
> > of the sending process?*I am just learning networking so sorry if this is
> > pretty basic.
>
> That's not a networking question. That's a question about how WinExec() works
> and what its return codes mean, and I don't think this is a suitable mailing
> list to ask that - we can answer questions about curl itself though.
>
> I personally don't know but the Microsoft docs seem to say that anythin above
> 31 means the invokation failed.
This page
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-winexec
suggests that WinExec() is deprecated anyway, and suggests something else - which
looks a lot more complicated, but also, I think, may provide better error messages.
Maybe this list of error message numbers is relevant:
https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-
(found at:
https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes )
where 33 is described as
ERROR_LOCK_VIOLATION
33 (0x21)
The process cannot access the file because another process has locked a portion of
the file.
Does that make sense for whatever the OP is doing? I wonder which file in the
original command is the problem?
I'd be inclined to try WinExec with a much simpler command - not a curl one, or perhaps
just issuing curl -V in the first place to see if that works, then try more complicated
commands to see when it stops working.
Maybe there's a problem with quoting of filenames? Personally I'd never refer just to a
leafname in a command, but always provide a quoted full-path and leafname, to make
sure the file a command will use is the right one.
Date: Mon, 12 Oct 2020 10:58:25 +0100
On Mon, 12 Oct 2020, at 08:32, Daniel Stenberg via curl-users wrote:
> On Sun, 11 Oct 2020, Jason Liam via curl-users wrote:
>
> > int x = WinExec(command, SW_HIDE);
> > std::cout<<"code" <<x<<std::endl;
> >
> > And the output on the console shows *code:33*
> > *Is this the return code of the command.Can i use this to check the success
> > of the sending process?*I am just learning networking so sorry if this is
> > pretty basic.
>
> That's not a networking question. That's a question about how WinExec() works
> and what its return codes mean, and I don't think this is a suitable mailing
> list to ask that - we can answer questions about curl itself though.
>
> I personally don't know but the Microsoft docs seem to say that anythin above
> 31 means the invokation failed.
This page
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-winexec
suggests that WinExec() is deprecated anyway, and suggests something else - which
looks a lot more complicated, but also, I think, may provide better error messages.
Maybe this list of error message numbers is relevant:
https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-
(found at:
https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes )
where 33 is described as
ERROR_LOCK_VIOLATION
33 (0x21)
The process cannot access the file because another process has locked a portion of
the file.
Does that make sense for whatever the OP is doing? I wonder which file in the
original command is the problem?
I'd be inclined to try WinExec with a much simpler command - not a curl one, or perhaps
just issuing curl -V in the first place to see if that works, then try more complicated
commands to see when it stops working.
Maybe there's a problem with quoting of filenames? Personally I'd never refer just to a
leafname in a command, but always provide a quoted full-path and leafname, to make
sure the file a command will use is the right one.
-- Jeremy Nicoll - my opinions are my own. ----------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2020-10-12