This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Side-by-side configuration is incorrect reported as permission denied
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