On Mon, Aug 13, 2012 at 07:32:11AM -0700, Andrew DeFaria wrote: >On 08/13/2012 01:27 AM, Corinna Vinschen wrote: >> On Aug 12 18:49, Andrew DeFaria wrote: >>> On 08/12/2012 01:35 PM, Earnie Boyd wrote: >>>> On Sun, Aug 12, 2012 at 1:56 PM, Pawel Jasinski wrote: >>>>>> If you can find a nice Linux errno which maps from >>>>>> ERROR_SXS_CANT_GEN_ACTCTX >>>>>> to something other than EACCES I'd be happy to change Cygwin. >>> [...] >>> Now I know that there are POSIX error codes and people tend to check >>> error numbers and you want to put the closest match of a POSIX errno >>> to the Windows error message. But why couldn't you just print to >>> stderr the error message that Windows returned perhaps in addition >>> to setting syserr to "Permission denied"? >> Do you really want that? >I think it would be helpful. >> There's a difference between cmd and Cygwin. Cmd is a shell, Cygwin is >> just the underlying shared lib providing a generic API. >OK so bash...
One of the points of Cygwin is that it allows you to build stuff like bash with minimal or no modification. That is the whole point of the project. If we have to modify Cygwin to provide a side-channel communication mechanism for communicating Windows errors to a process and then modify the process to use it that really flies in the face of the project. But you aren't really even suggesting that. You are apparently just suggesting that every windows error should be displayed by the Cygwin DLL. Wow. >> If an error occurs, it's the shell's responsibility to print an error >> message in the first place. All messages printed by Cygwin are not >> controllable by the calling application. Therefore we usually only >> print messages from the DLL if something very serious happens from the >> DLLs perspective. Some arbitrary Windows error code returned from >> CreateProcess is usually not something actually serious. There was >> just "some" reason that an application couldn't be started. >IMHO "some" reason that the user should be alerted about. How is it >helpful to the end user to suppress the error message? There is no "suppression". The error message that you see from cmd is printed by cmd. Cygwin isn't suppressing it. >> Also, where do you draw the border? Which windows error code is serious >> enough to justify a (pretty intrusive!) error message from the underlying >> library and which isn't? >I would draw the border at "if there's an error message". You clearly haven't thought this through. Your screen would be filled with errors. What happens when something like bash looks for ~/.bashrc and it doesn't exist? You'd see a "File not found" on your screen. Ok, so you don't want that one. You just want the error messages that you care about. Which of the thousands of Windows errors would we decide to display and which would we ignore? It's not a solvable problem. >> As cgf pointed out, Windows has zillions of error codes. We wouldn't >> want to generate the same number of POSIX-like error codes. It wouldn't >> make a lot of sense since POSIX applications only test for a limited, >> expected number of error codes, and it might break things. > >I was talking error *messages* not error *codes*. Cygwin and other windows programs do not see error *messages* when something fails, they see error *codes*. Getting the error *message* involves translating the error *code* into a *message*. We aren't actively stopping you from seeing an error message. We are translating a windows error code into a POSIX errno. Then bash reports the error using a table of error strings that it gets from Cygwin. The fact that this has to be explained to you pretty clearly illustrates that you don't understand what is going on here. You really should either go thoroughly educate yourself about this or just stop talking. Earnie's points made here: http://cygwin.com/ml/cygwin/2012-08/msg00257.html are quite pertinent. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
